Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ACE TCP Retransmision

                   I have trouble with ACE 4710, The SLB work but I see very much  bad tcp chsum.

                  

17:30:41.308878 00:0b:fc:fe:1b:01 > 00:23:ea:89:68:44, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4, IP (tos 0x0, ttl  60, id 37145, offset 0, flags [DF], length: 40, bad cksum 206 (->7925)!) 192.168.210.65.9010 > 10.170.150.253.62275: F [bad tcp cksum b1eb (->113a)!] 1:1(0) ack 2 win 49680

17:30:41.308951 00:0b:fc:fe:1b:01 > 00:23:ea:89:68:44, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4, IP (tos 0x0, ttl  60, id 37146, offset 0, flags [DF], length: 40, bad cksum 205 (->7924)!) 192.168.210.65.9010 > 10.170.150.253.62274: F [bad tcp cksum 6a97 (->f25f)!] 1:1(0) ack 2 win 49680

17:30:41.310132 00:23:ea:89:68:44 > 00:0b:fc:fe:1b:01, ethertype 802.1Q (0x8100), length 64: vlan 210, p 0, ethertype IPv4, IP (tos 0x0, ttl 121, id 10594, offset 0, flags [DF], length: 40) 10.170.150.253.62275 > 192.168.210.65.9010: . [tcp sum ok] ack 2 win 64860

17:30:41.310237 00:0b:fc:fe:1b:01 > 00:10:e0:10:2f:b7, ethertype 802.1Q (0x8100), length 64: vlan 210, p 0, ethertype IPv4, IP (tos 0x0, ttl 121, id 10594, offset 0, flags [DF], length: 40, bad cksum a3dc (->2cbd)!) 10.170.150.253.62275 > 10.0.0.10.9010: . [bad tcp cksum d5ed (->769f)!] ack 2 w 17:30:41.308878 00:0b:fc:fe:1b:01 > 00:23:ea:89:68:44, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4, IP (tos 0x0, ttl  60, id 37145, offset 0, flags [DF], length: 40, bad cksum 206 (->7925)!) 192.168.210.65.9010 > 10.170.150.253.62275: F [bad tcp cksum b1eb (->113a)!] 1:1(0) ack 2 win 49680
17:30:41.308951 00:0b:fc:fe:1b:01 > 00:23:ea:89:68:44, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype IPv4, IP (tos 0x0, ttl  60, id 37146, offset 0, flags [DF], length: 40, bad cksum 205 (->7924)!) 192.168.210.65.9010 > 10.170.150.253.62274: F [bad tcp cksum 6a97 (->f25f)!] 1:1(0) ack 2 win 49680
17:30:41.310132 00:23:ea:89:68:44 > 00:0b:fc:fe:1b:01, ethertype 802.1Q (0x8100), length 64: vlan 210, p 0, ethertype IPv4, IP (tos 0x0, ttl 121, id 10594, offset 0, flags [DF], length: 40) 10.170.150.253.62275 > 192.168.210.65.9010: . [tcp sum ok] ack 2 win 64860
17:30:41.310237 00:0b:fc:fe:1b:01 > 00:10:e0:10:2f:b7, ethertype 802.1Q (0x8100), length 64: vlan 210, p 0, ethertype IPv4, IP (tos 0x0, ttl 121, id 10594, offset 0, flags [DF], length: 40, bad cksum a3dc (->2cbd)!) 10.170.150.253.62275 > 10.0.0.10.9010: . [bad tcp cksum d5ed (->769f)!] ack 2 w

1 REPLY
Bronze

ACE TCP Retransmision

Gabriel-

What you are seeing is due to the internal network card offloading the TCP checksum (the checksum is done by the hardware.)   When the software recieves the packet, the checksum is no longer the same, but the packet is fine.  Hence, you see the error.  If you take a sniffer trace using wireshark on most modern machines, you will notice the same thing (most user-class nic's actually remove the checksum all together, the kernal sees the value as 0).

Long story short... nothing wrong, that is just a cosmetic view of the kernal.

Chris

313
Views
0
Helpful
1
Replies
CreatePlease login to create content