2950-RUNT PACKETS-Receive Errors

[david_marangoni]

I'm receiving a huge amount of runt packets on some switchports, they come up as Receive Errors.The switch is a 2950-24 and all of the interfaces/workstations are hardcoded to 10Meg Half duplex.My sniffer doesn't show any sign of runt packets.If I change the interface/workstation to 10 Meg Full the runts are gone. Could it be cosmetic or are they truely errors ? Thanks in advance..

Regards,

Dave

[Kevin Dorrell]

That means your switch port must believe it is full duplex. This is what happens: the PC believes it is impolite to speak when being spoken to (half duplex), but the switch believes it can talk any time (full duplex).

The PC starts transmitting a frame. The switch, believing it is full duplex, also starts transmitting. The PC thinks "oops, I'd better stop talking". The frame from the PC becomes a runt.

Don't forget, the half/full duplex protocol is between the PC and the local switch port, not end-to-end.

Yes, they are real errors. run full-full, half-half, or auto-auto. (auto-half also works at 100Mbps, but is not very elegant). But never full-half or full-auto.

Here is some goodstuff on this subject: http://www.cisco.com/en/US/tech/tk389/tk214/technologies_tech_note09186a0080094781.shtml

Kevin Dorrell

Luxembourg

[david_marangoni]

Thanks Kevin,

I agree if it was a duplex mismatch but I have the pc and the switch port set at 10half-10half and that's when I get the runt errors. Would the switch port still think that it's full duplex eventhough it's set to half ? Maybe I'll change the port and the pc to 10full-10full ?

cheers,

dave

[Kevin Dorrell]

Well, that is strange. In fact, if it was half-half, then I would expect the collision counter to be incrementing rather than the runts. Runts are definitely errors in anyone's book, but I can't think where they are coming from.

Oh ... do I remember a bug where the switch was counting as runts any frames that were truncated because of a collision? It shouldn't do. I'll look through the bug database. What IOS version are you running?

You don't have one of those old AUI/10BaseT transceivers with the SQE switched on by any chance?

Are you getting this phenomenon on all PC ports?

If the port is set to half-, you can be pretty sure it is doing half-. It should say so in the "show int".

Runts could also be due to buffer underruns at the PC, but it would need to be quite an old and slow PC for this to be a problem. Do you have the latest drivers on you PC NICs?

You could try full on both sides, but I don't think that explains what is going on.

Kevin Dorrell

Luxembourg

[glen.grant]

If the users are transmitting a lot of data in half duplex mode you will tend to get increasing collisions and or runts . If you have to run them at 10/half you are going to see runts if the ports are heavily used . Always use full/dupplex if the equipment on both ends support it . Seeing that most moden nics support 10/100 speeds not sure why you wouldn't run the switch as auto and the nics at auto or hardcode both ends to 100/full . The 2950's will do either .

A little blurb from a Cisco doc.

Excessive runt frames

In a shared Ethernet environment, runt frames are almost always caused by collisions.

[Kevin Dorrell]

Does this mean that the switch counts collisions as runts? If not, what are the conditions for counting the collision as a runt?

Kevin.

[glen.grant]

the technical explanation. The collision causes runts because one sender thought it ok to send information so he starts to send but a very short ways into the packet he gets a collision with another user, this would cause a runt. A collision may or may not cause a runt dpends on what point of packet transmission the collision occurs on.

The collision does typically result in a short malformed packet called a runt. The runt is just the part of a packet that the first sender managed to transmit before the collision occurred. If the Ethernet construction rules are adhered to, the runt will be easily identified because it will be shorter than the Ethernet minimum (64 bytes). Its CRC will also be incorrect. Runts are common and cause little difficulty on individual Ethernet segments.

[david_marangoni]

In response Kevin's questions:

- IOS version, 12.1(11)EA1a.

- I don't have any AUI/10BaseT tranceivers with SQE.

- This doesn't happen on all ports.

- I believe the latest drivers are installed on the workstations,I will check with PC support.

Glen, thanks for the input. We don't run the workstations at auto or 100 because we don't like to over subscribe the uplinks to the cores. . Since the pc's involved are transmitting a lot of data using a legacy radio application called Dalet, after reading both of your inputs, I'm going to propose changing the pc's and the switchports to 10 full. Thanks again, I realy appreciate it.

cheers.

[Kevin Dorrell]

I take back what I said about runts. I've just been reading from the authority on Ethernet, Charles Spurgeon, (http://www.oreilly.com/catalog/enettdg/), who says:

"Most runts are the result of a collision, and as such, are completely a normal and expected event on an Ethernet. A runt could also be caused by an interface that aborts a frame transmission for some reason. .... Since a valid collision must occur sometime in the first 512 bit times .., a runt is defined as being smaller than 512 bits, but larger than a short event. This counter provides a look at normal network operations, and does not indicate an error."

So, I was wrong.

It seems from the other postings that whether a collision results in a runt depends entirely on how the transmitter reacts to the collision - whether it aborts the frame or not.

I'm learning ... I'll get there in the end.

Kevin Dorrell

Luxembourg

[david_marangoni]

no worries Kevin. Thanks for the book referral, I will surely pick it up.

cheers.