Question about collision fragments on a cisco switch

[TechVol]

I've got a couple of ports on our cisco switches at work that the "collision fragments" counter on the ethernet controllers statistics increments very slowly maybe 4 or 5 each day. The only problem is that these links are programmed as a full-duplex link. Most are hard coded on each end. I'm trying to figure out if this is a problem in the pc's or on the cable between the pc and switches. The switches were just recently updated to 3560 series switches.

** Genius is one percent inspiration and Ninety-nine percent perspiration **

 

[vipergg]

Usually to have collison fragments then you have a speed duplex mismatch where one end may be set as auto/auto and the other end is hardcoded , when this happens then the auto end will default to half duplex and thus the collision occur . I have never seen collisions on ports that are configured correctly . Verify both ends match where both the nic and switchport are both set as auto/auto for speed and duplex or you have to hardcode both ends the same such as 100/full .

 

[raftaman]

There is probably a desktop hub attached to the pc which is connected back to the switch. A hub will cause collisions like this.

 

[vipergg]

If there is a hub attached the port should show half duplex with the "show interface status" command .

 

[TechVol]

There's no hub, connected and both ends have been hard coded to speed 100 and duplex full. And it doesn't increment the collisions counter just the collision fragments counter.

 

[eliotB]

when i hear fragments i think of MTU size mismatch. Just throwing that out there, what do other people think?

 

[eliotB]

check this out:

http://www.cisco.com/en/US/docs/switches/lan/catalyst2800/ug/fs28conc.html#wp588

FragmentFree

FragmentFree switching filters out collision fragments, the majority of packet errors, before forwarding begins. In a properly functioning network, collision fragments must be less than 64 bytes. Anything greater than 64 bytes is a valid packet and is usually received without error. FragmentFree switching waits until the received packet has been determined not to be a collision fragment before forwarding the packet. In FragmentFree mode, latency is measured as FIFO.


Collision Fragments

The total number of frames of less than 64 bytes that have an integral number of bytes and bad FCS values.

http://www.cisco.com/en/US/docs/switches/lan/catalyst2900xl_3500xl/release12.0_5_wc5/swg/swtrbl.html

FCS (4 bytes) (Ethernet)

Protocol: Ethernet Ethernet PCI

Field: frame check sequence (FCS)

Length: 4 bytes

Contents: checksum.

Frames with invalid checksums are discarded by the adapter. There is no error message sent to the source station.

If the collision detection function of an adapter detects a collision while sending a frame, transmission is stopped and an additional 'jam sequence' of 32 bits in length is sent. The jam sequence is a dummy checksum needed by other station's collision detection function: If a collision passes a repeater, the frame's electrical characteristics are valid again, and the frame's corruption can only be detected as caused by a collision by the combination of 'frame short error' (less than 64 bytes) and 'checksum error' (invalid FCS value).

http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_layer9.html

 

[TechVol]

Not totally for sure on all of the stations, but i've got one that uses a 3com 3c905b card. I loaded the 3com diag software and watched it as i watched the switch. While transferring files between that workstation and mine I noticed that the Transmission Underrun counter incremented on the workstation. Definition of the transmission unerrun from 3com is a the number of times the card put data on the line without having enough data in the frame. The counter on the pc increments with the counter on the switch.

 

[eliotB]

Frames with invalid checksums are discarded by the adapter. There is no error message sent to the source station.

That sounds to me like it'd be a problem w/the workstations and not the switch. Maybe a bad cable? cable run too long, bad nic, idk. You can use the FragmentFree switching mode on the switch to filter out those bad frames from reaching the rest of the network.

 

[TechVol]

I'm leaning more towards the NIC causing this cause it's in the server room with the switch plugged in with a new patch cable directly to the switch. But as far as changing to fragment free I don't think you can change the 3560 series switching mode.

 

[vipergg]

All cisco switches are store and forward now . The only ones you could change was the old 1924 series switches . If you think it is nic problem also get the latest driver from the manufacturer before writing off the nic .

 

[jneiberger]

Do NOT hard set each side! Set both sides to AUTO and this problem will go away.

It will take a bit of explanation to illustrate what is happening. There is no mention of hard-setting speed and duplex settings in the Fast Ethernet standard. It only mentions autonegotiation. There are two ways to behave if the settings are manually configured:

1. Continue to participate in autonegotiation but only "offer" the configured settings;

2. Disable autonegotiation completely and use the configured settings.

Problems arise when you combine a device using behavior #1 with a device using behavior #2. All Cisco switches made in the last five or six years use behavior #2. Nearly every PC I've worked with in that time (mostly Dells) use behavior #1.

So, you hard set both sides to 100/Full and connect the PC to the switch. The switch will only do 100/Full and does not participate in autonegotiation. The PC, on the other hand, is still participating in autonegotiation and expects to see an autonegotiating link partner. When it does not see such a partner, it (correctly) makes the assumption that it is connected to a hub and drops back to half duplex despite the manually configured setting of full duplex.

Bam. Duplex mismatch.

Leave everything at AUTO and this sort of thing will never happen.

 

[jmann2118]

First of all yes Cisco's new switches are store and forward by default. You can change the mode however. Setting it to Fragment-free still won't fix your problem though. The last posting is wrong if you leave everything auto-neg it usually works fine. If you set both to 100/full it will probably fix your problem. The reason I know this is because I was having the same problems this morning and changed both the switch and the server to 100/full and now there are no collisions happening on that interface.

CCNA, MCSA, Security+

 

[burtsbees]

I would say bad NIC, because it sounds like it's trying to put info on the wire, but it sometimes doesn't put all the bits on the wire.

Burt

 

[jneiberger]

jmann2118, I am absolutely, definitely NOT wrong. I've had this discussion with people that design Fast Ethernet drivers. I've had this discussion with internal engineers at Cisco and successfully got them to change their documentation. Have you studied the Fast Ethernet specs? Do you understand Nway? I don't think you do.

Setting both sides to 100/Full is statistically the worst thing you could possibly do. It will work sometimes, obviously, and if you have the right mix of equipment it can work most of the time. However, in large deployments with a wide variety of equipment from different manufacturers, manually setting both sides of your connections to 100/Full is guaranteed to cause you the most problems.

Read my post again and you'll see why. Do you think I'm just making this stuff up to confuse people?

 

[burtsbees]

jneiberger is absolutely right. I have heard so many times that Cisco devices won't autonegotiate, but they don't know what they're doing.

Burt

 

[jneiberger]

To be clear, Cisco devices autonegotiate just fine when configured to do so; they only disable autonegotiation when you manually configure the speed and duplex. This behavior began a few years ago. The older XL switches behave differently.

 

[jneiberger]

Techvol, did you get this problem sorted out?

 

[TechVol]

Ok, guys thanks for all of the input. On the two situations in question. One was an older pc w/ a 3com nic plugged into a cisco 3560 catalyst, the other was a newer pc with an intel nic. On the older machine w/ the 3com it turns out to be a 3com thing. The nic is trying to keep in time with the network and instead of waiting for all 64 bytes from the cpu to be dma'd into the nic it puts the data on the wire with out all of the data. So BAM the cisco switch registers this as a collision fragment, not a collision, or fcs, or crc error. just a collsion fragment. On the 3com we replaced it with a newer netgear card off the shelf and no more collision fragments. On the intel nic it was a matter of updating the driver to the newest version of driver. But these were caused by the nics in the pc actually putting data on the wire before the pc had finished handing all of the data over.

** Genius is one percent inspiration and Ninety-nine percent perspiration **

 

[jneiberger]

Ah, bad drivers will get you everytime. We used to have all sorts of problems with those 3COM drivers back around 2002-2004. Tons of problems, even with updated drivers.