Smart questions
Smart answers
Smart people
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Member Login




Remember Me
Forgot Password?
Join Us!

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips now!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

Join Tek-Tips
*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Donate Today!

Do you enjoy these
technical forums?
Donate Today! Click Here

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.
Jobs from Indeed

Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

Question about collision fragments on a cisco switch

TechVol (MIS) (OP)
18 Oct 07 17:58
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 (MIS)
18 Oct 07 20:02
    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 (MIS)
19 Oct 07 17:16
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 (MIS)
19 Oct 07 21:43
If there is a hub attached the port should show half duplex with the "show interface status" command .  
TechVol (MIS) (OP)
20 Oct 07 11:46
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 (TechnicalUser)
21 Oct 07 18:08
when i hear fragments i think of MTU size mismatch. Just throwing that out there, what do other people think?
eliotB (TechnicalUser)
21 Oct 07 18:20
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 (MIS) (OP)
22 Oct 07 17:10
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 (TechnicalUser)
22 Oct 07 20:28
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 (MIS) (OP)
23 Oct 07 16:07
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 (MIS)
23 Oct 07 21:52
  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 (TechnicalUser)
26 Oct 07 16:04
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 (IS/IT--Management)
30 Oct 07 10:45
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 (Programmer)
30 Oct 07 12:07
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 (TechnicalUser)
30 Oct 07 12:21
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 (Programmer)
30 Oct 07 13:24
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 (TechnicalUser)
30 Oct 07 13:26
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 (TechnicalUser)
2 Nov 07 11:52
Techvol, did you get this problem sorted out?
TechVol (MIS) (OP)
2 Nov 07 20:23
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 (TechnicalUser)
2 Nov 07 20:34
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.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Back To Forum

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close