output buffer failures and underruns

[mishao]

hi all,

I found the counters of output buffer failures and underruns will increase at the same time. i change " buffer size " and the counters still increase. could anyone meet this situation ?

best regards.

fred.

3550#show inter fas 0/8

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

Hardware is Fast Ethernet, address is 000f.34f2.7b80 (bia 000f.34f2.7b80)

Internet address is 202.145.254.118/30

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

reliability 255/255, txload 197/255, rxload 105/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:01, output hang never

Last clearing of "show interface" counters 00:03:44

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 41434000 bits/sec, 9752 packets/sec

5 minute output rate 77639000 bits/sec, 17051 packets/sec

2155504 packets input, 1166162153 bytes, 0 no buffer

Received 26 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 26 multicast, 0 pause input

0 input packets with dribble condition detected

3903360 packets output, 2225723199 bytes, 6494 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

6494 output buffer failures, 0 output buffers swapped out

[irisrios]

If a free buffer exists within the requested pool, the buffer is granted. Otherwise, the request generates a ?miss? and the buffer algorithm tries to ?create? more buffers for that pool.

If additional buffers can not be created, the request generates a ?failure? and the packet is dropped.

When you use the IBM feature set, a miss almost always generates a failure.

Although the IBM features may be process-switched, the code to get a buffer to pass a packet from an interface to the RP executes at interrupt level.

Buffers can not be created at interrupt level; consequently, a miss queues its request for more buffers to the RP.

Because an additional buffer can not be created on the spot, the buffer request fails, and the packet is dropped.

Buffer failures are one of the most common reasons for packet drops. When packet drops occur because of buffer failure, this occurs:

After a buffer failure, the RP has an outstanding request to create more buffers of the appropriate size for the particular pool.

While the RP is servicing the create buffers request, there may be additional failures in the pool.

The RP may even fail to create more buffers, because of memory constraints in the system when the extra buffers are required.

Essentially, the create buffers operation could take several microseconds, in which packets are continually dropped because of the buffer shortage.

In addition, if buffers are used as quickly as they are created, the RP could be forced to spend more time on buffer creation than on packet processing.

This may cause the RP to begin to drop packets so quickly that performance degrades and sessions are lost.

[mishao]

But how to solve it? i tried to modified the buffer but it didn't work.

[Jagdeep Gambhir]

Hi ,

Basically when we the rate of traffic switch to a port and it can?t handle the amount of

traffic it will buffer to the packets to Tx buffer when the buffer is full we start drop

the packets and we?ll increase the underruns and output buffer failures counters.

Definitions:

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.

To find out whether it is actually caused by over subscription, we can do the following:

Investigate the devices connected to interface

1.Clear the counter then set loading interval to 30 sec and issue the sh interface on ingress port and egress port and see the average traffic going through the links.

2.Use SNMP station to keep polling the ingress and egress interfaces every 5 secs to check the traffic load on ingress and egress ports.

Please rate helpful post.

Regards,

~JG

[poulid]

Hello. I know this post has been sitting for awhile, but we are seeing the same problem on a 3550. The interface complaining about all of the output buffer failures and underruns is connected to our providers router, and is only running 10Mb/sec. The provider is only giving us 6Mb to the WAN, so it can't be oversubscription. Also, the 5 minute output rate shows only 2Mb.

We are seeing about 500 output buffer failures/minute, and this is mot during prime usage hours. Could this be a hardware problem?

Thanks.