1. Home
  2. Cisco Systems
  3. Deferred packets on a full duplex link

Deferred packets on a full duplex link

I have an old Alteon AD2 connected to a Catalyst 2950. The ports on both ends of this link are manually set to 100mbit full duplex. The link carries about 30mbit of traffic and has worked fine for the past year, but lately I'm getting about 10% packet loss.

I'm stumped. The only potential problem I see on the link is alot of deferred packets (no collisions though, its FD). I've seen deferred packets and collisions on a half duplex link, of course, but never this.

I'm having a hard time finding possible explanations for this. Could it be the cable is "going bad"? I thought possibly the deferred packets mean the wire or one of the interfaces is overloaded, but I doubt this is the problem (we've pushed alot more traffic on this link before without problems).

Here's show int:

FastEthernet0/1 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000d.2944.7b41 (bia

000d.2944.7b41) Description: AD2 MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec, reliability 255/255, txload 37/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:01, output 00:00:01, output hang never Last clearing of "show interface" counters never 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 476000 bits/sec, 624 packets/sec 5 minute output rate 14595000 bits/sec, 1257 packets/sec 232220738 packets input, 1806242814 bytes, 0 no buffer Received 69435 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 66781 multicast, 21 pause input 0 input packets with dribble condition detected 348675996 packets output, 3693672823 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 45127753 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out

Thanks, Ken

Reply to
Ken Stumpf
Loading thread data ...

I forgot to mention that these two devices are physically only 18 inches apart in the cabinet, so distance should not be an issue here.

Reply to
Ken Stumpf

You may have traffic spikes.

try configuring load-interval 30 on the interface and clear the counters before busy periods to see if this is when the deferred counter increments

Reply to
Merv

The packet loss is not related to traffic, it occurs 24/7 regardless of throughput.

Unfortunately this equipment is hosted in New Orleans, so I'm not able to get down there to troubleshoot things. We just did get off of diesel power yesterday at least.

Reply to
Ken Stumpf

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.

Reply to
Merv

Just wanted to let you know that this bug was in fact the problem. Thanks very much for pointing it out, I would not have found it on my own.

My datacenter is in New Orleans and I cant get down there to update the IOS, so I had to set both devices to autonegotiate and cycle the load balancer until they negotiated correctly (9 out of 10 times auto would result in duplex mismatch, and then Id get late collisions!).

Thanks again!

Reply to
Ken Stumpf

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.