If you search archives, there is some recommendation of turning off checksum using ethtool. You can try that.
Search for "udp checksum issue with openvswitch" On Fri, May 9, 2014 at 7:18 AM, Gurucharan Shetty <[email protected]> wrote: > That is a little weird. > I hope someone that understands kernels well will reply. > > On Fri, May 9, 2014 at 1:40 AM, Dietmar Maurer <[email protected]> wrote: >>> > 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 >> >> I just noticed that I get bad checksum also with 'config1', so that cannot >> be the reason. >> Any idea why we get bad checksum - is that normal? >> >>> The nodes are directly connected using a crossover cable, so there is no >>> switch involved. >> >> The bug somehow depends on kernel and network card/driver, for example >> using igb 5.1.2 work with kernel 3.10, but fails with kernel 2.6.32: >> >> /lib/modules/2.6.32-29-pve/kernel/drivers/net/igb/igb.ko ==> fails >> /lib/modules/3.10.0-2-pve/kernel/drivers/net/ethernet/intel/igb/igb.ko ==> >> works >> >> The bug always triggers when I use Broadcom Tigon3 tg3.ko 3.132. >> >> So 'config1' works always, and 'config2' depends on kernel/driver. >> >> And idea how to debug that? >> >> _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
