[ovs-discuss] multicast problems with OVSIntPort

Dietmar Maurer dietmar at proxmox.com
Fri May 9 06:19:20 UTC 2014


> > But it does not work when I configure an extra OVSIntPort to assign the IP:
> >
> > -------config2-(fails)--------------------
> > allow-vmbr1 test1
> > iface test1 inet static
> >         address  10.11.12.1
> >         netmask  255.255.255.0
> >         ovs_type OVSIntPort
> >         ovs_bridge vmbr1
> >
> > auto vmbr1
> > iface vmbr1 inet manual
> >         ovs_type OVSBridge
> >         ovs_ports eth1 test1
> > --------------------------------------------
> The above config is a little different than what we recommend in
> debian/openvswitch-switch.README.Debian of the repo.
> It probably works in your case because of a different style of integration of
> ovs with proxmox with different startup scripts.

Yes, we have slightly different setup on Proxmox, but configuration works.

> >
> > Please can someone explain the difference between those 2
> > configuration? And why does config2 triggers multicast problems?
> You can look at the o/p of 'ovs-vsctl show' in both cases to make sure you are
> creating what you intended?

The interesting one is for config2:

# ovs-vsctl show
adde2fdb-a317-4a75-8ee9-32b470767b3e
    Bridge "vmbr1"
        Port "vmbr1"
            Interface "vmbr1"
                type: internal
        Port "eth1"
            Interface "eth1"
        Port "test1"
            Interface "test1"
                type: internal
    ovs_version: "2.0.90"

So that looks correct to me. Also, normal traffic works without problems (ssh, ping). 
I even managed to run multicast with omping - that work also.

> In the second case, looks like you are intending to create a bridge - "vmbr1"
> and then add an internal port to it called "test1". The ip of
> 10.11.12.1 is assigned to
> 'test1'. I am not sure why you want to do it. 

The goal is to setup a VLAN on 'test1' to separate  traffic .

> In either case, just the
> "multicast" traffic should not have any negative effect.

tcpdump reveals that corosync packets have wrong cksum:

# tcpdump -envv "port 5404" -i test1
07:50:59.927572 be:94:dc:b2:f8:8c > 01:00:5e:40:a6:1e, ethertype IPv4 (0x0800), length 161: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 147)
    10.11.12.1.5404 > 239.192.166.30.5405: [bad udp cksum 0xac7b -> 0x36e2!] UDP, length 119
07:51:01.622390 be:94:dc:b2:f8:8c > 86:cc:93:20:7b:49, ethertype IPv4 (0x0800), length 183: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 169)
    10.11.12.1.5404 > 10.11.12.2.5405: [bad udp cksum 0x2cbf -> 0xf054!] UDP, length 141
07:51:01.622622 86:cc:93:20:7b:49 > 01:00:5e:40:a6:1e, ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 64, id 30731, offset 0, flags [+], proto UDP (17), length 1500)
    10.11.12.2.5404 > 239.192.166.30.5405: UDP, length 1473
07:51:01.622629 86:cc:93:20:7b:49 > be:94:dc:b2:f8:8c, ethertype IPv4 (0x0800), length 183: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 169)
    10.11.12.2.5404 > 10.11.12.1.5405: [udp sum ok] UDP, length 141
07:51:01.622753 be:94:dc:b2:f8:8c > 01:00:5e:40:a6:1e, ethertype IPv4 (0x0800), length 1514: (tos 0x0, ttl 64, id 20546, offset 0, flags [+], proto UDP (17), length 1500)
    10.11.12.1.5404 > 239.192.166.30.5405: UDP, length 1473
07:51:01.832120 be:94:dc:b2:f8:8c > 01:00:5e:40:a6:1e, ethertype IPv4 (0x0800), length 161: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 147)
    10.11.12.1.5404 > 239.192.166.30.5405: [bad udp cksum 0xac7b -> 0xf4c4!] UDP, length 119

The nodes are directly connected using a crossover cable, so there is no switch involved.

Any ideas? 
 


More information about the discuss mailing list