Help with troubleshooting CRC issues

I've got a Cisco 2610 that's getting some CRC errors comming in from my e 0/0 interface. Does anyone know a good / easy way to narrow down which node it's comming from? My network has about 80 nodes on a fully switched 100base-t subnet spanning six different 3Com switches.

My first thought was to put a node between the switches and the router, then run a packet sniffer (Ethereal to be specific) and see where the faulty packets are comming from....well, either I don't know Ethereal enough to know what to filter for, or the faulty packets aren't showing up through the sniffer.

Does anyone have any good ideas?
Thanks for the help in advance...

You could check your logs on your 3com switches manually, a bit of a pain, but for 6 switches, it's prolly 30min of work.

Good switches wouldn't pass CRC error frames to begin with ;-) Most software sniffers are at the mercy of the NIC to process error frames, it's likely the NIC isn't even showing ethereal the "broken" packets. Older NICs that don't do IP processing on board tend to work better for this if you have one around.

Like jajmon said you're going to have to check the 3com boxes to see what ports are racking up the errors. Occasional CRC errors are no biggie; the thumb-rule is 1% (some say as much as 3%) of total packets. You might try clearing the stats on the 2160 and seeing how it looks after a day. Unless your seeing tons of them I wouldn't sweat it. They're like collisions, even a perfect network will have some by design. If you start seeing them on a serial interface, that's a different matter alltogether.

Hope this helped!

If your 3Com switches are managed, there's a chance that you can set them to "Store and Forward" mode, which will detect and drop bad frames.

If not, you can try the commands: "debug packet", or "debug error"... I don't have anything to test that with, but I believe one of those should show the crc errors as they happen.. they will, however, spam your console quite nicely, and the router may take a performance hit while they're on... i'd suggest using debug error to a syslog server, and reading it there.

Another option is to drop a ethereal box on the network (best if you have a hub before the 2610, or if the 3Coms let you port-mirror the uplink to the 2610.

Thanks for the help guys. The total % of CRC errors is only around .5%; far better then last Friday when I was out of office (go figure). The odd part is that before then, we almost never had any CRC's. The 3COMs (most all are 3300XM)...I'll have to go through the logs again. I might have an old NIC that I might try with Ethereal. I'm not too worried, but my boss is pairanoid about this stuff...

Probably just a bad NIC somewhere in the network... maybe a bad cable.

If you have a server that everyone uses, you could run ethereal on that, if you don't mind the performance hit.. eventually it'll get hit with a bad packet, and you'll have the source IP and MAC from it.

do you know what I use in Ethereal to filter for?
is it ip.checksum_bad or tcp.checksum_bad or what else?
I guess that's display filters...
Do you know what to use as a Capture Filter?

...Thanks for the help

capture filters are not very robust... best to capture all traffic, or only TCP, and filiter from there.

The entries you are looking for will have a "(should be xyz)" beside the summary.

Thanks so much for the help...maybe I wasn't clear in my last question. Now that I've captured all of these packets, how do I know which ones are the ones with the CRC errors?


...perhaps Shazbot is right that my NIC is discarding them before Ethereal is even getting them?

IIRC, On the line describing the traffic, bad packets say "(should be [xyz])", where [xyz] is the corrected tcp header