%MLS_STAT-DFC4-4-IP_CSUM_ERR: IP checksum errors

rlortiz · ‎03-31-2003

I have a customer with a Cisco Catalyst 6509 and saw the following error message in the log file:

I found a similar error message in the Cisco website:

%MLS_STAT-4-IP_CSUM_ERR: IP checksum errors

It stated to do a SHOW MLS STATISTICS and look for relevant information, which I have below. There was no action or reference to what should be done next:

Statistics for Earl in Module 4

L2 Forwarding Engine

Total packets Switched : 28959640064

L3 Forwarding Engine

Total Packets Bridged : 9763643935

Total Packets FIB Switched : 13023412786

Total Packets ACL Routed : 0

Total Packets Netflow Switched : 0

Total Mcast Packets Switched/Routed : 21397778

Total ip packets with TOS changed : 0

Total ip packets with COS changed : 0

Total non ip packets COS changed : 0

Total packets dropped by ACL : 27211

Total packets dropped by Policing : 0

Total Unicast RPF failed packets : 0

Errors

MAC/IP length inconsistencies : 0

Short IP packets received : 0

IP header checksum errors : 309

MAC/IPX length inconsistencies : 0

Short IPX packets received : 0

As you can see, the IP header checksum errors were from the Earl in Module 4.

Here is some information I got from a SHOW TECH:

Mod Ports Card Type Model Serial No.

4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAD054205J2

Mod MAC addresses Hw Fw Sw Status

4 00d0.c0d6.fb94 to 00d0.c0d6.fba3 1.1 12.1(5r)E1 12.1(13)E4, Ok

Mod Sub-Module Model Serial Hw Status

4 Distributed Forwarding Card WS-F6K-DFC SAD0540050S 2.0 Ok

Online Diagnostic Result for Module 4 : PASS

Online Diagnostic Level when Module 4 came up = Minimal

Test Results: (. = Pass, F = Fail, U = Unknown)

1 . TestGBICIntegrity :

Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

----------------------------------------------------

U U U U U U U U U U U U U U U U

Name: Gi2/4

Switchport: Enabled

Administrative Mode: dynamic desirable

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Operational private-vlan: none

Trunking VLANs Enabled: 1,38,60,76,1002-1005

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

What is the best action plan, at this point? Do we need to replace Module 4?

Any help would be appreciated

Rich

raymong · ‎04-03-2003

The error message that you are receiving is saying that the switch forwarding engine is receiving an IP-packet which has an invalid checksum, therefore the packet was dropped. In older code we just used to silently drop the packet and count it in the forwarding engine stats.

The only thing you have to be concerned about is that there is a device which is sending these bad packets (possibly due to bad nic driver, nic driver bug (or) bad application etc..). Unfortunately, our forwarding engine doesn't keep track of the source-ip of the device which is sending these bad packets. The only way to detect these devices is to put a sniffer and track it down to a particular source.

steinar.haug · ‎04-03-2003

Is it possible to get these packets out to a SPAN destination (then I could

run tcpdump which would tell me about invalid checksums), or will they be

dropped before SPAN takes place?