I have had similar issues with a Broadcom 5700 based NIC. Both tg3 and bcm5700 driver exhibits checksum problems. The Xen guys have not been able to resolve this, perhaps because there haven't been enough users experiencing the problem. A workaround to the checksum problem is to wrap everything in gre tunnels. The extra header seems to avoid whatever the checksum generation/offload issue is. Not very practical though. Using a bridged setup instead of routed also seems to avoid this problem. I have also been experiencing MTU issues. Connections will stall unless I set mtu <1000. I don't know why this is. Again I have just worked around it. This might not help you with your problem, but it does highlight that Xen (as much as I love it) seems to have some annoying network stack/driver bugs still. Tim:> --- Greg Brackley <lists-linux-vlan@xxxxxxxxxxxxxxxxxxxx> wrote: > ----- Original Message ----- > From: "Greg Brackley" <lists-linux-vlan@xxxxxxxxxxxxxxxxxxxx> > > In the past I have tried an e1000 driver (As the machine also has a > dual > > pro/1000 mt card in it), and not had any success. I'll try it > again. > > I switched over to using the Intel PRO/1000 dual MT port. I noticed > two > things. > > 1. I could get pings of size 1472 through (c.f. 1460 with the sk-9e22 > port) > > 2. I setup a 'dig slashdot.org' to loop around and generate a > constant UDP > packet stream. A tcpdump on the next hop was getting the UDP packets, > but > they appeared to have a bad checksum. A tcpdump of the packets as > they left > the VLAN interface said the checksum was ok. I tried turning off (and > then > back on) tx and rx checksum support, but didn't see any change (would > this > change automagically propagate through the stack, or do I need to > pull > everything down). > > Is this a real checksum error or a phantom bad checksum? > > Greg. > > > ----- dump of eth3 (which the VLAN interface is on) ---------- > # tcpdump -i eth3.148 -n -vv > 20:07:21.461176 arp who-has 192.168.148.254 tell 192.168.148.1 > 20:07:21.461259 IP (tos 0x0, ttl 64, id 2, offset 0, flags [DF], > proto 17, > length: 58) 192.168.148.1.32828 > 192.168.134.6.domain: [udp sum ok] > 25138+ > A? slashdot.org. (30) > > # tcpdump -i eth3 -n -vv > tcpdump: WARNING: eth3: no IPv4 address assigned > tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size > 96 > bytes > 20:11:16.503715 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > proto 17, > length: 58) 192.168.148.1.32828 > 192.168.134.6.domain: [udp sum ok] > 14858+ > A? slashdot.org. (30) > > ----- dump from the next hop machine 192.168.148.254---------- > # tcpdump -i bond0.148 -n -vv > 20:08:42.522754 arp who-has 192.168.148.254 tell 192.168.148.1 > 20:08:42.522762 arp reply 192.168.148.254 is-at 00:12:3f:20:69:f0 > 20:08:42.542368 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], > proto 17, > length: 58) 192.168.148.1.32828 > 192.168.134.6.domain: [bad udp > cksum > b608!] 42859+ A? slashdot.org. (30) > > > _______________________________________________ > Vlan mailing list > Vlan@xxxxxxxxxxxxxxx > http://www.lanforge.com/mailman/listinfo/vlan > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
