Ganglia's gmond multicast traffic across kvm/qemu vnet0 bridge

Discussion in 'Linux Networking' started by Guest, Dec 27, 2013.

  1. Guest

    Guest Guest

    Dear All,
    Has anyone come across this before?

    I am running Ganglia's gmond daemon on a KVM guest and using multicast
    as with the default configuration for gmond on all hosts to
    communicate with each other and with the central gmetad. This all
    works nicely on bare metal hosts, just the kvm guest was not
    communicating via multicast. I found the following,

    (1) 'tcpdump -i eth0 dst 239.2.11.71' on the guest only sees multicast traffic
    created by gmond running on that guest.

    (2) 'tcpdump -i vnet0 dst 239.2.11.71' on the guest's bare metal host
    also only sees multicast traffic created by the gmond running on its
    guest.

    (3) 'tcpdump -i br123 dst 239.2.11.71' on the guest's bare metal host
    sees all the multicast traffic from all the other gmonds on our LAN
    but none from its guest. br123 is the bridge device setup for 123
    tagged packets on our 802.1Q VLAN. At the br123 interface stage the
    packets are untagged so I presume this is not a VLAN problem.

    Using virt-manager GUI for the guest's setup I have for the virtual NIC,

    Source device: Host device eth0.123 (Bridge 'br123')
    Device model: virtio

    where eth0.123 is the corresponding Ethernet device extracting
    untagged 123 network packets from the tagged packets on the eth0
    physical NIC plugged into the switch.

    ifconfig shows eth0.123, br123 & vnet0 are all multicast enabled.

    By trial and error I found a solution was to do,

    echo 2 > /sys/class/net/vnet0/brport/multicast_router

    Then the guest's multicast traffic is forwarded to the rest of the LAN
    and the guest receives multicast traffic from the LAN as expected.

    I could not find any documentation on this. Can anyone shed any light?

    I also discovered that re-writing 2 to these pseudo files results in a
    total system freeze!

    Cheers
    Tom Crane
    (PP IT Support)

    OS details: SLC6.5 (SLC ~= RHEL)
    Kernel: 2.6.32-431.1.2.el6.x86_64
    KVM S/W RPMs: qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64,
    libvirt-0.10.2-29.el6.1.x86_64, virt-manager-0.9.0-19.el6.x86_64

    --
    Ps. The email address in the header is just a spam-trap.

    Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
    Egham, Surrey, TW20 0EX, England.
    Email: T dot Crane at rhul dot ac dot uk
     
    Guest, Dec 27, 2013
    #1
    1. Advertisements

  2. Guest

    Guest Guest

    Earlier I wrote:
    : Dear All,
    : Has anyone come across this before?

    [cut]

    : By trial and error I found a solution was to do,

    : echo 2 > /sys/class/net/vnet0/brport/multicast_router

    : Then the guest's multicast traffic is forwarded to the rest of the LAN
    : and the guest receives multicast traffic from the LAN as expected.

    It seems I jumped the gun a bit here. Re-checking I found that '2'
    also needs to be written to both,

    /sys/devices/virtual/net/br123/bridge/multicast_router &
    /sys/devices/virtual/net/eth0.123/brport/multicast_router

    before the multicast traffic would be routed beyond the br123 device
    on the host system and onto the LAN. I also found that trying to repeat
    the process with a second VLAN also resulted in a system hang. A routing
    loop perhaps?

    [cut]

    : I also discovered that re-writing 2 to these pseudo files results in a
    : total system freeze!

    I noticed that the 'total system freeze' was not quite that. A 'top'
    session running the console continued to run.

    Cheers
    Tom Crane
    (PP IT Support)

    Ps. The email address in the header is just a spam-trap.
     
    Guest, Dec 29, 2013
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.