Bad checksums reported by tcpdump are not necessarily actually bad. What
is happening is that the checksum field is not updated when HW checksums
are enabled... the code depends on the HW to tell it if the checksum is
bad or not (on receive), and depends on the HW to generate the checksum
(on transmit). So the packet in the mbuf which tcpdump is parsing may
not have a filled-in checksum field.
If you are getting actual communications glitches, e.g. pings not
returning, tcp throughput problems, and so forth, then you might have a
real problem.
-Matt
On Thu, Apr 17, 2014 at 2:13 AM, k simon <[email protected]
<mailto:[email protected]>> wrote:
Hi,List,
I have tested haproxy on dfly 3.6.2 and found a lot of bad checksum
unless "ifconfig igb0 -txcsum -rxcsum -tso".
Simon
P.S.
igb0@pci0:1:0:0: class=0x020000 card=0xa04c8086
chip=0x10c98086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82576 Gigabit Network Connection'
class = network
subclass = ethernet
igb1@pci0:1:0:1: class=0x020000 card=0xa04c8086
chip=0x10c98086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = '82576 Gigabit Network Connection'
class = network
subclass = ethernet
# ifconfig igb1
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=5b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,RSS>
inet6 fe80::21b:21ff:fea8:f6b5%igb1 prefixlen 64 scopeid 0x2
inet 192.168.130.17 netmask 0xfffffe00 broadcast
192.168.131.255
ether 00:1b:21:a8:f6:b5
media: Ethernet 1000baseT <full-duplex>
status: active
# tcpdump -vv -n -i igb1
tcpdump: listening on igb1, link-type EN10MB (Ethernet), capture size
65535 bytes
00:55:45.864386 IP (tos 0x0, ttl 64, id 24083, offset 0, flags [DF],
proto TCP (6), length 670)
192.168.130.50.3002 > 192.168.130.17.15231: Flags [P.], cksum
0x9e22
(correct), seq 2769251432:2769252062, ack 3651462828, win 33580,
length 630
00:55:45.864403 IP (tos 0x0, ttl 64, id 30506, offset 0, flags [DF],
proto TCP (6), length 40, bad cksum 0 (->3e11)!)
192.168.130.17.15231 > 192.168.130.50.3002: Flags [.], cksum 0xcccc
(correct), seq 1, ack 630, win 16890, length 0
00:55:45.864435 IP (tos 0x0, ttl 64, id 59651, offset 0, flags [DF],
proto TCP (6), length 40, bad cksum 0 (->cc37)!)
192.168.130.17.15231 > 192.168.130.50.3002: Flags [F.], cksum
0xcccb
(correct), seq 1, ack 630, win 16890, length 0
00:55:45.864449 IP (tos 0x0, ttl 64, id 29524, offset 0, flags [DF],
proto TCP (6), length 40, bad cksum 0 (->41e7)!)
192.168.130.17.15231 > 192.168.130.50.3002: Flags [R.], cksum
0xccc7
(correct), seq 2, ack 630, win 16890, length 0
00:55:45.864626 IP (tos 0x0, ttl 64, id 24105, offset 0, flags [DF],
proto TCP (6), length 40)
192.168.130.50.3002 > 192.168.130.17.15231: Flags [.], cksum 0x8b99
(correct), seq 630, ack 2, win 33580, length 0
00:55:45.864635 IP (tos 0x0, ttl 64, id 17387, offset 0, flags [DF],
proto TCP (6), length 40, bad cksum 0 (->7150)!)
192.168.130.17.15231 > 192.168.130.50.3002: Flags [R], cksum 0x22c0
(correct), seq 3651462829, win 0, length 0
00:55:46.176994 IP (tos 0x0, ttl 64, id 8022, offset 0, flags [DF],
proto TCP (6), length 48, bad cksum 0 (->95ef)!)
192.168.130.17.15232 > 192.168.130.32.3003: Flags [S], cksum 0x75b2
(correct), seq 3024833635, win 16384, options [mss 1460,nop,nop,sackOK],
length 0
00:55:46.177062 IP (tos 0x0, ttl 64, id 6400, offset 0, flags [DF],
proto TCP (6), length 44)
192.168.130.32.3003 > 192.168.130.17.15232: Flags [S.], cksum
0x069f
(correct), seq 2868943112, ack 3024833636, win 32768, options [mss
1460], length 0
00:55:46.177074 IP (tos 0x0, ttl 64, id 45321, offset 0, flags [DF],
proto TCP (6), length 40, bad cksum 0 (->444)!)
192.168.130.17.15232 > 192.168.130.32.3003: Flags [.], cksum 0x59ec
(correct), seq 1, ack 1, win 17520, length 0
00:55:46.177101 IP (tos 0x0, ttl 64, id 21368, offset 0, flags [DF],
proto TCP (6), length 80, bad cksum 0 (->61ad)!)
