From: ssw@bronze.ucs.indiana.edu (steven wallace)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Weird Ethernet Behavior
Date: 6 Oct 92 00:29:40 GMT
Organization: Indiana University

In <Oct.5.18.01.25.1992.7644@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:

>ssw@bronze.ucs.indiana.edu (steven wallace) writes:

>>Yea, yea, yea,  I assumed that SPX was checksumed and it isn't.
>>But, I just ran a little experiment that still suggests that the
>>show ip/ipx/appletalk traffic is relevant.  We captured a good IPX
>>frame heading towards a cisco with the sniffer, changed it checksum
>>from FFFF to 67FF, and resent it to the cisco.  The cisco counted
>>it as a IPX checksum failure.  If none of our ciscos are recording
>>any other IPX checksum failures, it suggests that corrupted packets
>>caught by the ethernet CRC are not making it into the router.  All
>>our ciscos are recording IP checksum failures, suggesting that the
>>ethernet CRC is begin ignored.

>This experiment doesn't mean what you think it does.  If you set the
>IPX checksum to a value other than 67FF, then Cisco will either reject
>it because it isn't FFFF (which Novell requires), or compute the
>checksum of the packet, and find that it isn't actually 67FF.  But in
>the normal case the value is FFFF.  This is a special value meaning
>"don't care".  When the value is FFFF, Cisco will not compute the
>checksum of the packet.  The packet could be completely trashed.  As
>long as the trashing doesn't happen to hit the checksum field, you'll
>never see a checksum failure.

My point was that if parts of the packet were being trashed,
occasionally you might trash the checksum field.  That's the point I was
trying to make.

>This is not the case with IP.  Cisco will actually compute the header
>checksum, or in cases where the packet is addressed to it, the UDP/TCP
>checksum, and verify that the packet's computed checksum matches the
>checksum field.  

>So if for one reason or another you're getting corrupted packets,
>you'll see IP checksum failures and you won't see IPX checksum
>failures.  
Unless it corrupted the checksume field.

Now why you're getting corrupted packets is a question I
>can't answer.  Perhaps it indicates that Ethernet CRC is not being
>properly checked.  Perhaps there is a hardware problem that is
>corrupting the packet after the CRC has been checked (i.e. bad memory,
>in either the interface or the main box), or perhaps it means that
>something in one of your hosts is corrupting the packet before the
>Ethernet CRC is being added.  The only point I'm trying to make is
>that the fact that you're seeing checksum failures for IP and not for
>IPX does not indicate that Ethernet CRC's are being handled
>differently for the two protocols.  

It turns out that the IP header checksum failures are due to a cisco
corrupting an IP packet, forwarding it in a good ethernet frame, and the
next cisco computing the checksum and discarding the packet (recording
the error in the second router).

You are correct. After talking to cisco, it doesn't look like our
problem is the cisco accepting corrupted ethernet packeta, but a heavily
loaded cisco doing the corruption.

-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Acting Associate Director     |  wallaces@iubacs          (bitnet)
Network Systems UCS           |  (812) 855 - 0960         (voice)
Newsgroups: comp.dcom.sys.cisco