----- 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)