Deferred Packets?

marman · ‎02-21-2005

Hi,

I have a C2950 switch running Software (C2950-I6Q4L2-M), Version 12.1(13)EA1. I have a 100Mb Full Duplex service connecting into it, and another c2950 hanging off one of the ports, from which a few servers reside. When i try to do large transfers, the throughput is less then 10Mb and the deferred packet count goes through the roof. All ports are hard-coded for 100Mb Full Duplex.

Any ideas for the poor performance?

Thanks

Kevin Dorrell · ‎02-21-2005

This is strange, because deferred packets are part of the half-duplex procedure. In half duplex, if someone is using the medium, you defer the frame until the medium is free. This is not an error, it is just part of the procedure.

If you are hard coding, then the full duplex must be hard coded at both ends of the link - both on the switch and on the router or host.

I think we need to know more detail. Where are you seeing the deferred packets? Check that link for duplex mismatch. If in doubt, post the show run and show int for each end of that link, and we will see if we can sort it out.

Kevin Dorrell

Luxembourg

marman · ‎02-21-2005

Thanks Kevin,

Everything is set to 100Mb Full. I`m wondering whether the x-over cable which connects the two c2950`s is faulty. I have tried changing everyting to auto duple mode as well, but the problem re-occurs.

The deferred packets are occuring on the first switch - on the port with the x-connect to the other switch, and the incoming 100Mb service from my telco.

Kevin Dorrell · ‎02-21-2005

So, if I understand correctly, you have two ports displaying deferred counts. Both ports are on switch 1. One of the ports is the link to the other switch, and the other port is the link to your service provider. Is that right? Could you post the show int for those two ports?

Kevin Dorrell

Luxembourg

marman · ‎02-21-2005

Kevin,

This is the port to the service provider:

TELE-SW2#sh int f0/18

FastEthernet0/18 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 000d.297f.8212 (bia 000d.297f.8212)

Description: LES to Talisman House

MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:04, output hang never

Last clearing of "show interface" counters 00:20:29

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute ouxtput rate 0 bits/sec, 0 packets/sec

61654 packets input, 10428868 bytes, 0 no buffer

Received 15018 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 3706 multicast, 0 pause input

0 input packets with dribble condition detected

48819 packets output, 23500665 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 65 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

This is the port to the other switch

TELE-SW2#sh int f0/16

FastEthernet0/16 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 000d.297f.8210 (bia 000d.297f.8210)

Description: Link to 10.1.1.43

MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is off

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:00, output 00:00:00, output hang never

Last clearing of "show interface" counters 00:21:24

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute ouxtput rate 0 bits/sec, 0 packets/sec

51347 packets input, 25243500 bytes, 0 no buffer

Received 2153 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 2044 multicast, 0 pause input

0 input packets with dribble condition detected

62868 packets output, 10771333 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 84 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

The deferred packets aren`t huge at the moment, but as soon as i put a large file through they start to clock up.

Kevin Dorrell · ‎02-21-2005

I see what you mean - this a interesting. Here is what the documentation says about "deferred":

Deferred indicates that the chip had to defer while ready to transmit a frame because the carrier was asserted.

Now I had always interpreted this as being part of the half-duplex procedure, but I cannot deny that you have hard-coded full-duplex, and you are still seeing "deferred" frames. I wonder whether it is seeing spurious carrier on the Tx line, or something like that.

You mention crossed cables, and I think that would be worth investigating. Do both ports have one of these crossed cables? I wonder if the crossing pairs are mismatched within the cable. Do you have any cross-cables from a different manufacturer that you could try?

Kevin Dorrell

Luxembourg

marman · ‎02-21-2005

Kevin,

The port from the service provider has a straight ethernet cable. The one to the other switch is crossed, and here i must confess that it was one i made. Therefore i`m hedging my bets that the x-over may not be crimped properly and is not operting fully. I plan to go to the site, and try to put the service provider direct to the other switch (means a long-ish cable), but do-able. Alternatively i`ll plug one of the servers direct into the service provider and see if we get the full thoughput.

Thanks for your help anyway

marman · ‎02-21-2005

Kevin,

One thing i noticed was, when i copied a large file to a server hanging off the second switch. If at that time i pinged the switch, it would respond poorly or time out. If i pinged the server it would come back fine 100%??

V.Strange. I have read that it may be the IOS, but that strikes me as being a major issue if it is?

Kevin Dorrell · ‎02-21-2005

It is true that ping to the switch is one of the lowest priority tasks. When you copy the file, does the CPU take a nosedive? If so, perhaps we need to work out why. Do you have any access lists active?

Kevin Dorrell

Luxembourg

marman · ‎02-21-2005

No ACl`s, CPU goes to 6%.....so nothing out of the ordinary there.

I have all the ports in Vlan 1, yet when i do a sh vlan - the two cross connect ports aren`t showing up. When i do a sh vlan id 1, they then show up.

Think i`ll go and move the service providers port on the same switch as the servers and see what happens.

pouya.cisco · ‎07-31-2013

I had a similar issue and I fixed it by rate-limiting traffic on WAN port facing a third paty NTU.

paolo bevilacqua · ‎08-01-2013

pouya.cisco wrote:

I had a similar issue and I fixed it by rate-limiting traffic on WAN port facing a third paty NTU.

Just to let you know that you're respondinjg to an 8-years old thread.

Ivan Moskalev · ‎01-12-2014

"We used to have a 2950 switch that had that problem. Cisco TAC attributed it to an IOS problem. The temporary work-around was to set both the switchport and the server to auto-negotiate, which worked. (When both were hard coded to 100 full dup, the deferred packets came back). The permanent fix was an IOS upgrade, which also worked. We are now running 12.1(20)EA1a, no deferred packets.

maybe you are encounter bug CSCea56745

Bug Details

Deferred frame counted, traffic delayed when duplex set as full

Product 2950 Model 2950-24

Component hardware Duplicate of

Severity 2 Severity help Status Resolved Status help

First Found-in Version 12.1(13)EA1 All affected versions First

Fixed-in Version 12.1(13)EA1b, 12.1(14)EA1 Version help

Release Notes

[Symptom]

When interface configured its duplex as full,

deferred counter increments, then packets

through that link are delayed.

When traffic is ping, some ICMP hit timeout.

When traffic is ftp, too many retrasmission cause

low troughput.

[Condition]

12.1(13)EA1

interface duplex configured as full duplex.

Symptom can be seen both 10/full and 100/full.

Symptom not seen when 100/half, 10/half, and autonegotiation.

[Workaround]

-use autonegotiation

or

-use previous release image."