Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

comparatively fast increase of deferred counter with a FE .

Hello!

anybody knows,if the comparatively fast increase of deferred counter with a FE will cause the LAN performance degrading.

if 300 deferred per min is to be considered as a serious problem ,which cause the packet loss on the LAN at 1 percentage or so?

And how to solve it

Thanks a lot!

4 REPLIES
Gold

Re: comparatively fast increase of deferred counter with a FE .

The "deferred" counter is the number of times that the Ethernet controller had to hold off on transmitting a packet because another station was transmitting on the wire at the time. This is the "carrier sense" part of CSMA/CD; the router is checking to see if another station is on the wire before transmitting its own frame, to avoid a collision if at all possible.

It's hard to say if 300/min is an outrageous amount of deferrals for your situation, but it's probably on the high side. You might want to post the entire "show interface" output to this thread. If the router is attached to a hub, especially a slow 10Mb/s hub, that LAN segment may be very busy. If you have the router attached to a switch, you might want to try to use full-duplex rather than half-duplex, which eliminates the potential for collisions. Make sure you match the duplex setting on the switch side.

New Member

Re: comparatively fast increase of deferred counter with a FE .

Hi,Sir

Thank you for your response.

Actually,I checked the CCO and I have not fond any specific description

about if a big deferred counter could cause the packet loss,with your

experience,do you think that could be the reason of light packet loss

on my LAN .I have router and switch sides auto negotiating .

Thanks!

Gold

Re: comparatively fast increase of deferred counter with a FE .

A very busy LAN segment often has some packet loss. Your incrementing deferrals counter would tend to support the idea that your LAN segment is busy. It also implies that your router and switch are talking at half-duplex. Some interface hardware will tell you explicitly in "show interface EthernetX/Y", some will not. Confirm by checking to see that the 'collisions' counter is incrementing. If you have collisions, you're definitely at half-duplex.

If you are indeed connected to a switch (and not a hub), and autonegotiate isn't resulting in a full-duplex connection, consider forcing both sides to full-duplex. This will help improve throughput and will eliminate collisions and deferrals entirely. This will not work if the router is attached to a hub, forcing the router to full duplex will result in terrible packet loss and performance issues.

If that doesn't help, please go ahead and post the output of "show interface EthernetX/Y" here so that we can see what sort of traffic and collision rate you have.

New Member

Re: comparatively fast increase of deferred counter with a FE .

Hi,sir

Thank you very much.

But the fact is the FE at both router(3640) and switch(2950) sides autonegotiated and worked in Full-duplex and 100M mode.But the deferred counter keeps going up rapidly. when I hard code both sides to Full-duplex and 100M ,unfortunately,after 20 mins or so,the FE at the router side broke

down,and can not even be enaled after restarted the router. I think it's the

hardware trouble.

Let me post the output here,hope if you can hepl me get some solution.

Thank you.

3640:

FastEthernet0/0 is up, line protocol is up

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

reliability 255/255, txload 6/255, rxload 9/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, 100BaseTX/FX

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:37:20

Queueing strategy: fifo

Output queue 0/40, 0 drops; input queue 3/75, 15 drops

5 minute input rate 3652000 bits/sec, 557 packets/sec

5 minute output rate 2414000 bits/sec, 565 packets/sec

1447901 packets input, 1213930022 bytes

Received 12810 broadcasts, 0 runts, 0 giants, 0 throttles

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

0 watchdog

0 input packets with dribble condition detected

1439891 packets output, 775635491 bytes, 0 underruns(0/0/0)

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 46061 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

2950:

FastEthernet0/1 is up, line protocol is up

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

reliability 255/255, txload 9/255, rxload 6/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:21, output 00:00:00, output hang never

Last clearing of "show interface" counters 1d16h

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 2401000 bits/sec, 543 packets/sec

5 minute output rate 3693000 bits/sec, 559 packets/sec

5862550 packets input, 2573917690 bytes, 0 no buffer

Received 30387 broadcasts, 0 runts, 0 giants, 0 throttles

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

0 watchdog, 28436 multicast, 0 pause input

0 input packets with dribble condition detected

6134866 packets output, 858949286 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

181
Views
0
Helpful
4
Replies