cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
456
Views
4
Helpful
1
Replies

lots output buffer failures on one side ???

rico_hao40
Level 1
Level 1

I have 3550 through fibre converter goes to 2950, on 3550 side I have lots of underruns and output buffer failures, but on 2950 side no such failures.

3550:

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

Hardware is Fast Ethernet, address is 000b.5f32.d22a (bia 000b.5f32.d22a)

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

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 10/100BaseTX

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

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

Last input 00:00:55, 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)

30 second input rate 0 bits/sec, 0 packets/sec

30 second output rate 5000 bits/sec, 7 packets/sec

15213424 packets input, 99938169 bytes, 0 no buffer

Received 8700189 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 8658647 multicast, 0 pause input

0 input packets with dribble condition detected

50054756 packets output, 4257661420 bytes, 4894 underruns

0 output errors, 0 collisions, 1 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

4894 output buffer failures, 0 output buffers swapped out

2950:

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

Hardware is Fast Ethernet, address is 0013.c304.1558 (bia 0013.c304.1558)

Description: backbone to 3550

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

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 100BaseTX

input flow-control is unsupported output flow-control is unsupported

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

Last input 00:00:01, output 00:00:02, 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 18000 bits/sec, 22 packets/sec

5 minute output rate 11000 bits/sec, 14 packets/sec

41708620 packets input, 2497436974 bytes, 0 no buffer

Received 35994473 broadcasts (0 multicast)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 20939622 multicast, 0 pause input

0 input packets with dribble condition detected

13490662 packets output, 2760151410 bytes, 0 underruns

0 output errors, 0 collisions, 2 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

Is the media converter ??

Thanks

1 Reply 1

smothuku
Level 7
Level 7

Hi ,

Here is an explanation of underruns & output buffer failures:

Output buffer failures description: Cisco IOS sh interfaces counter. The number of failed buffers and the number of buffers swapped out.

Common Causes: As an example, consider a scenario where a 1gig multicast stream is being forwarded to 24 100 Mbps ports. If an egress interface is over-subscribed, it would be normal to see output buffer

failures incrementing along with Out-Discards.

Underruns Description: The number of times that the transmitter has been running faster than the switch can handle.

Common Causes: This can occur in a high throughput situation where an interface is being hit with a high volume of bursty traffic from many other interfaces all at once. Interface resets may be occurring along

with the underruns.

It basically means due to overwhelming amount of traffic sent to the switch port, it will use Tx buffer and when this buffer is full, we start to see dropping of the packets and counters for the underruns and output buffer failures will be increased.

**** It is normal to see a large number of frames being discarded when an egress

interface is over-subscribed .The "Discarded frames" count indicates how many packets are dropped because the egress notify queue is full due to over-subscription. This is also reflected in the "Output buffer failures"

statistics in "show interface", which has nothing to do with the CPU buffers in "show buffers".

You can check the bug CSCdy09531 :Output buffer failures on fastethernet ports.

Hope it helps you.

Thanks,

satish

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card