> > 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?
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
