Show interface in depth

In my opinion, a good network engineer must know the “show interface” in depth; indeed, this command is useful to obtain various interface information like drop, duplex mismatch, error, tx/rx load, … Usually, the IOS switch/router have similar “show interface” output; the differences are dictated by devices, interface and IOS. Below a show interface of a TenGigabitEthernet interface. The show is issued on a Cisco WS-C6509-E in VSS Mode with IOS version 15. Ciscozine-IOS#sh int te1/5/4 TenGigabitEthernet1/5/4 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0000.0000.fd90 (bia 0008.ef4a.fd90) MTU 1500 bytes, BW 10000 Kbit/sec, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s, media type is 10Gbase-SR input flow-control is on, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, 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 7000 bits/sec, 8 packets/sec 5 minute output rate 10000 bits/sec, 11 packets/sec L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes 4495527 packets input, 488522378 bytes, 0 no buffer Received 4460539 broadcasts (1153347 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 6925984 packets output, 825456963 bytes, 0 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 0 output buffer failures, 0 output buffers swapped out Ciscozine-IOS# TenGigabitEthernet1/5/4 is up, line protocol is up (connected) Identify if the interface is phisically up and if the protocol is up.
Hardware is C6k 10000Mb 802.3, address is 0000.0000.fd90 (bia 0008.ef4a.fd90) Identify the hardware interface and the interface mac-address; the BIA aka Burned-In (MAC)
Address cannot be changed, while the “address“ can be changed with the command “mac-address 0000.0000.fd90” under the interface configuration mode. Remember: When the interface mac address is changed, the arp or mac address table associated to the interface will be “linked” with the custom mac address!
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 100 usec MTU: define the Maximum Transmission Unit. More info http://en.wikipedia.org/wiki/Maximum_Transmission_Unit BW: The bandwidth command is only there to communicate the speed of the interface to higher level protocols. Most of the time, a routing protocol needs to know the speed of the interface so it can choose the best route. In the case of routing protocols, IGRP, EIGRP, and OSPF all use the bandwidth statement. DLY: Propagation delay is the delay it takes for information to transmit from one point and be received by another down a line or through the air. Delay is another number used by a routing protocol to decide on the “best” route for traffic. It was intended to be the “delay” for packets over that path, so a routing protocol could choose the lowest delay path to send packets. reliability 255/255, txload 1/255, rxload 1/255 reliability of the interface as a fraction of 255 (255/255 is 100 percent reliability), calculated as an exponential average over 5 minutes. txload/rxload=Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes.
Encapsulation ARPA, loopback not set Define the interface encapsulation; nowadays, you will see only the ARPA. In the past, there were also SAP and SNAP encapsulation. Loopbacks are an important part of troubleshooting; they are used to isolate the fault on and end-to-end circuit (especially when the circuit is down). More info http://www.cisco.com/…/tech_note09186a00800c93c4.shtml Keepalive set (10 sec) Keepalives are used on the routers interfaces as hello mechanism to check the end to end connectivity to the other end.Routers interface used this mechanism to check the interface status.If you have no keepalive command its means that inerface status check mechansim in disabled and router will not transmit any keepalive packet on the link. Full-duplex, 10Gb/s, media type is 10Gbase-SR Define the physical speed of the interface and if it works in half or duplex mode. The last part of the line defines the type of the media.
input flow-control is on, output flow-control is off Flow-control is a mechanics allowing the receiving party of a connection to control the rate of the sending party. You may see many different implementations of flow-control technologies at different levels of OSI model (e.g. XON/XOFF for RS232, TCP sliding window, B2B credits for Fibre Channel, FECN/BECN for Frame-Relay, ICMP source-quench message, etc). More info http://blog.ine.com/2008/07/08/802-3x-flow-control
Clock mode is auto This command is supported on the 1Gb/10Gb transceivers only. If the clock mode of the near end of a link does not match the clock mode of the far end, the line protocol does not come up. The active and passive clock status is determined during the auto negotiation process before the transmission link is established. ARP type: ARPA, ARP Timeout 04:00:00 ARP type defines the encapsulation type of the interface; tipically, for ethernet interface is ARPA. The default ARP timeout is 4hours but can be customized using the command “arp timeout [timeout]” Last input never, output never, output hang never Last input, output are the number of hours, minutes, and seconds since the last packet was successfully received or transmitted by the interface. Note: This counter is updated only when packets are process switched, not when packets are fast switched. Last clearing of “show interface” counters never It is the last time the clear counters command was issued since the last time the switch was rebooted. The clear counters command is used to reset interface statistics. Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Input queue is the number of packets in the input queue. Size/max/drops = the current number of frames in the queue / the max number of frames the queue can hold before it must start dropping frames / the actual number of frames dropped because the max queue size was exceeded. Flushes is used to count Selective Packet Discard. SPD is a mechanism that quickly drops low priority packets when the CPU is overloaded in order to save some processing capacity for high priority packets. The flushes counter in the show interface command output increments as part of selective packet discard (SPD), which implements a selective packet drop policy on the IP process queue of the router. Therefore, it applies to only process switched traffic. The purpose of SPD is to ensure that important control packets, such as routing updates and keepalives, are not dropped when the IP input queue is full. When the size of the IP input queue is between the minimum and maximum thresholds, normal IP packets are dropped based on a certain drop probability. These random drops are called SPD flushes. Total output drops is the number of packets dropped because the output queue is full. A common cause of this might be traffic from a high bandwidth link being switched to a lower bandwidth link or traffic from multiple inbound links being switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps interface, this might cause output drops to increment on the 100Mbps interface. This is because the output queue on that interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and outbound bandwidths.
Queueing strategy: fifo First-in, first-out (FIFO) queuing is the default queuing strategy that applies to all interfaces with more than 2 Mbps, or, in other words, E1 size or greater interfaces. With the FIFO Queuing
strategy, packets are forwarded through the interface in the order that they are received. Other methods can be: WFQ, CBWFQ, … Output queue: 0/40 (size/max) The number of packets in the output queue. Size/max means the current number of frames in the queue/the max number of frames the queue can hold before it is full and must start dropping frames. 5 minute input rate 7000 bits/sec, 8 packets/sec 5 minute output rate 10000 bits/sec, 11 packets/sec The average input and output rate seen by the interface in the last five minutes. In order to get a more accurate reading by specifying a shorter period of time (to better detect traffic bursts for example), issue the “load-interval <seconds>” interface command. 4495527 packets input, 488522378 bytes, 0 no buffer Packets input: Total number of error-free packets received by the system. Bytes: Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system. No buffers: Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events. Received 4460539 broadcasts (1153347 multicasts) Total number of broadcast or multicast packets received by the interface. 0 runts, 0 giants, 0 throttles Runts: Number of packets that are discarded because they are smaller than the minimum packet size of the medium. For instance, any Ethernet packet that is less than 64 bytes is considered a runt. Giants: Number of packets that are discarded because they exceed the maximum packet size of the medium. For example, any Ethernet packet that is greater than 1518 bytes is considered a giant. Throttles: the number of times the receiver on the port is disabled, possibly because of buffer or processor overload. If an asterisk (*) appears after the throttles counter value, it means that the interface is throttled at the time the command is run.
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored Input error: Includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input errors count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts. CRC: Cyclic redundancy checksum generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus itself. A high number of CRCs is usually the result of collisions or a station transmitting bad data. Frame: Number of packets received incorrectly having a CRC error and a noninteger number
of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device. Overrun: Number of times the receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver’s ability to handle the data. Ignored: Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different than the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be increased. 0 watchdog, 0 multicast, 0 pause input Watchdog: Number of times watchdog receive timer expired. It happens when receiving a packet with length greater than 2048. Pause input: Counter incrementing means that the port is receving pause frame. Pause frame is a packet that tells the far-end device to stop transmitting packets until the sender is able to handle all the traffic and clear it’s buffers. It could be caused by a oversubscription of bandwidth, or a burst traffic pattern. 0 input packets with dribble condition detected Dribble bit error indicates that a frame is slightly too long. This frame error counter is incremented just for informational purposes; the router accepts the frame. 6925984 packets output, 825456963 bytes, 0 underruns Packets output: Total number of messages transmitted by the system. Bytes: Total number of bytes, including data and MAC encapsulation, transmitted by the system. Underruns: Number of times that the transmitter has been running faster than the router can handle. This may never be reported on some interfaces. 0 output errors, 0 collisions, 1 interface resets Output errors: Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the enumerated output errors, as some datagrams may have more than one error, and others may have errors that do not fall into any of the specifically tabulated categories. Collisions: Number of messages transmitted because of an Ethernet collision. A packet that collides is counted only once in output packets. Interface resets: Number of times an interface has been completely reset. This can happen if packets queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down.
0 babbles, 0 late collision, 0 deferred Babbles: Babble errors occur due to the transmission of frames in excess of 1518 bytes in size. Late collision: Number of late collisions. Late collision happens when a collision occurs after transmitting the preamble. The most common cause of late collisions is that your Ethernet cable segments are too long for the speed at which you are transmitting.
Deferred: Deferred indicates that the chip had to defer while ready to transmit a frame because the carrier was asserted. 0 lost carrier, 0 no carrier, 0 PAUSE output Lost carrier: Number of times the carrier was lost during transmission. No carrier: Number of times the carrier was not present during the transmission. PAUSE output: Pause outputs occur when the receiving port is getting overloaded and the so the device sends a pause request to the device connected to the port. 0 output buffer failures, 0 output buffers swapped out Output buffer failures: Number of failed buffers and number of buffers swapped out. Output buffers swapped out: If the outbound interface transmit queue is full, then the packet is copied from a hardware buffer to DRAM, then copied back to the transmit queue when there is room. L2 Switched: ucast: 0 pkt, 0 bytes – mcast: 0 pkt, 0 bytes L3 in Switched: ucast: 0 pkt, 0 bytes – mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes The output indicates how many packets have been L2 switched on the interface as well as how many packets have been L3 switched in and out of the interface. Remember: There is a difference between the counter of show interface command output for a physical interface and a VLAN interface. The input packet counters increment in the output of show interface for a VLAN interface when that packet is Layer 3 (L3) processed by the CPU. Traffic that is Layer 2 (L2) switched never makes it to the CPU and is not counted in the show interface counters for the VLAN interface. It would be counted on the show interface output for the appropriate physical interface. In NX-OS (Nexus device) the “show interface” output is slightly different than the IOS output, but it is it is easy to understand. Below an example: Ciscozine-NX-OS# sh interface ethernet 1/1 Ethernet1/1 is up Dedicated Interface Hardware: 1000/10000 Ethernet, address: 000d.ecdd.2fc8 (bia 000d.ecdd.2fc8) Description: TERADATA - F4238 MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA Port mode is access full-duplex, 10 Gb/s, media type is 10G Beacon is turned off Input flow-control is off, output flow-control is off Rate mode is dedicated Switchport monitor is off EtherType is 0x8100 Last link flapped 5week(s) 6day(s) Last clearing of "show interface" counters never 30 seconds input rate 51128 bits/sec, 2 packets/sec 30 seconds output rate 109088 bits/sec, 15 packets/sec
Load-Interval #2: 5 minute (300 seconds) input rate 78.13 Kbps, 9 pps; output rate 113.67 Kbps, 11 pps RX 22236230840 unicast packets 4414705 multicast packets 997021 broadcast packets 22241642569 input packets 27905275144675 bytes 881597017 jumbo packets 0 storm suppression packets 0 runts 0 giants 3 CRC 0 no buffer 3 input error 0 short frame 0 overrun 0 underrun 0 ignored 0 watchdog 0 bad etype drop 0 bad proto drop 0 if down drop 0 input with dribble 0 input discard 0 Rx pause TX 12574452594 unicast packets 112812737 multicast packets 66330588 broadcast packets 12753595920 output packets 5123002661192 bytes 1001411772 jumbo packets 1 output errors 0 collision 0 deferred 0 late collision 0 lost carrier 0 no carrier 0 babble 0 output discard 0 Tx pause 9 interface resets Ciscozine-NX-OS# References:
 http://www.cisco.com/…/reference/irfshoin.html
 http://docwiki.cisco.com/…/IOS_Interface_Comparison
Interface overrun errors, however there is no interface load nor high cpu usage on router
I have just received high interface overrrun errors on one of the routers I manage at work. On checking the cisco site, I find that these errors could occur because the interface's capability has been exceeded and it cannot process the oncoming traffic, therefore it drops the packet. However on checking the router I see that there is no interface load at all, nor is there any high cpu utilization on the router. (Its off business hours right now, so there is no one at the office). #sh processes cpu CPU utilization for five seconds: 0%/0%; one minute: 2%; five minutes: 4%. ## reliability 135/255, txload 1/255, rxload 1/255 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 3639 input errors, 0 CRC, 0 frame, 3639 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected It says 3639 errors and 3639 overrun.. However there is no packets input at all! Does that mean that the overrun counter is incrementing even though there is no packets arriving at the interface?? Is this a software bug or is there a real issue at hand?
Collisions and late collisions.
These common network errors are separate anomalies with similar resolutions. Collisions occur when more than one device tries to use the network at the same time. This is increasingly rare. Today, nearly all networks are switched networks, which means each cable run connects one device to another device, with each device equipped with separate pairs to transmit and receive data (also called full-duplex mode). Since information is transmitted on separate pairs, data from one device cannot collide with data from the other. However, sometimes network ports are misconfigured as half-duplex. When this occurs, the ports will try to use the same pairs to transmit and receive data. This results in collisions, which can quickly become excessive in high-throughput environments. Switching the connection to full duplex solves the problem. (Duplex mismatch is a related issue: One end of a connection thinks it is on full-duplex; the other is set up as half-duplex, and as a result errors mount rapidly.)
Late Collisions on Gig Ethernet interface
I would like to know if Late Collision that were caused by a duplex mismatch can cause the GigE interface to freeze. I had a situation this past weekend where customer traffic including pings from a Cisco 3925 router could not pass throught the LAN interface (GigE interface). This router is a CE router that connects to a Cisco 4506 switch, the switch side was configured with duplex full and spee 100 but the CE router was configured to Auto/Auto. The Loggs on the router were full of the Late Collision error message and these Late Collision were running for more than a week until last Saturday morning when the customer reported their service as down. Customer connectivity was reestablished or fixed when the Network Administrator shut and unshut the GigE interface. I know this seems to be a very simple question but what I would like to know is what caused the interface to freeze? Could it be the Late Collisions that have accumulated over a longer period? or could it be something else? Unfortunately I do not have the output of the show interface gig0/1 which would have given you guys more information but I can confirm that the output of the command showed more than 100 000 Late Collisions, more than 100 000 output drops, more than 100 000 output errors and I think more than 100 000 interface resets. Lastly from the Bandwidth utilization report this happened when customer traffic reached full capacity of the link's bandwidth. So I would like to know from the forum if the freeze of the interface was caused by the accumulation of the interface queues due to the retransmition of the frames or what, i would like to get a technical explanation of what caused the freeze.
lost carrier error and interface went up and down I have 2650 XM Router connected to Cable modem. It has input errors.
i changed cable also still same thing.errors do not stop. sh int fa0/0 FastEthernet0/0 is up, line protocol is up Hardware is AmdFE, address is 000f.8f6d.7e60 (bia 000f.8f6d.7e60) Internet address is MTU 1500 bytes, BW 100000 Kbit/sec, 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, 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 never Input queue: 0/75/2/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 14000 bits/sec, 30 packets/sec 5 minute output rate 1000 bits/sec, 1 packets/sec 111292 packets input, 6907618 bytes Received 109236 broadcasts, 0 runts, 0 giants, 0 throttles 4077 input errors, 0 CRC, 0 frame, 0 overrun, 4077 ignored 0 watchdog 0 input packets with dribble condition detected 2058 packets output, 184333 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out any idea how can i get rid of these errors
3550 output buffer failures underruns - network is slow
ERROR: This router has dropped 16 packet(s) from the 'Small buffers' pool, after its last reload, due to a physical memory shortage.
ERROR: This router has dropped 16988 packet(s) from the 'Big buffers' pool, after its last reload, due to a physical memory shortage.
ERROR: This router has dropped 142 packet(s) from the 'VeryBig buffers' pool, after its last reload, due to a physical memory shortage. ERROR: This router has dropped 142 packet(s) from the 'Large buffers' pool, after its last reload, due to a physical memory shortage. ERROR: This router has dropped 142 packet(s) from the 'Huge buffers' pool, after its last reload, due to a physical memory shortage. NOTE: 'No memory' tracks the number of failed attempts to create additional buffers (and the number of packets dropped subsequently) due to insufficient memory. TRY THIS: You currently have 8192 kilobytes of shared memory. ERROR: This router has dropped 74 packet(s) (100%) due to a shortage of 'Huge buffers'. NOTE: The term 'Failures' in the huge buffers tracks the number of packets that were dropped due to unsuccessful attempts to allocate a buffer. This can occur in spite of (or even because of) the router's attempts to create additional free buffers when their number declines below minimum. TRY THIS: Use the 'show memory' command to check the amount of free memory. CAUTION: Care, expertise, and follow-up monitoring are necessary if system buffers need to be adjusted. Incorrect adjustments can severely affect hardware and network performance. Almost all of my connected interfaces are reporting these: There have been 105286528 'output buffer failures' reported. If outgoing interface buffers are not available, an output buffer failure is reported. If an interface buffer is available but the Transmit Queue Limit is reached, the packet is dropped.
Troubleshooting Input Queue Drops and Output Queue Drops
Introduction
This document discusses input and output queue drops taken from the output of the show interfaces command on the router. This document describes what these drops mean, the type of problems they indicate, and how to troubleshoot the source of these problems. It provides some tips on how to prevent these problems.
Note: Drops can often be useful, because they trigger the flow control mechanisms of upper layer protocols (for example, drops decrease the TCP window size).
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions. The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Processing and Switching
In IP networks, routers make forwarding decisions based on the contents of the routing table. When a router searches the routing table, it looks for the longest match for the destination IP address. The router does this at the process level. Therefore, the search process is queued among other CPU processes, because of which, the lookup time is unpredictable and can be very long. Therefore, a number of switching methods based on exact-match-lookup have been introduced in Cisco IOS® Software. The main benefit of exact-match-lookup is that the lookup time is deterministic and very short. This has significantly shortened the time a router takes to make a forwarding decision. Therefore, routines that perform the search can be implemented at the interrupt level. This means, the arrival of a packet triggers an interrupt, which causes the CPU to postpone other tasks and handle the packet. The legacy method to forward packets is to look for a best match in the routing table. This cannot be implemented at interrupt level and must be performed at process level. For a number of reasons, some of which are mentioned in this document, the longest-match-lookup method cannot be completely abandoned, so these two lookup methods exist in parallel on Cisco routers. This strategy has been generalized, and is now also applied to IPX and AppleTalk.
For more information on Cisco IOS Software switching paths, refer to Performance Tuning Basics.
Input Queue Drops
When a packet enters the router, the router attempts to forward it at interrupt level. If a match cannot be found in an appropriate cache table, the packet is queued in the input queue of the incoming interface to be processed. Some packets are always processed, but with the appropriate configuration and in stable networks, the rate of processed packets must never congest the input queue. If the input queue is full, the packet is dropped. Here is a sample output: router#show interfaces ethernet 0/0 ... Input queue: 30/75/187/0 (size/max/drops/flushes); Total output drops: 0 Output queue :0/40 (size/max)... In this sample output, there is no way to see exactly which packets have been dropped. In order to troubleshoot input queue drops, you must find out which packets fill the input queue. In this example, 30 packets are in the input queue of interface ethernet0/0 when the show interfaces ethernet 0/0 command is issued. The queue depth is 75 packets and there have been 187 drops since the interface counters were last cleared. The system counts input queue drops if the number of packet buffers allocated to the interface is exhausted or reaches its maximum threshold. You can increase the maximum queue value with the hold-queue <value> command for each interface (the queue length value can be between 0 and 4096. The default value is 75).
Note: Shared-memory routers (1600, 2500, and 4000 series), also use the input queue for fast-switched traffic. If you get input queue drops on those platforms, ensure that all traffic uses the best switching path available (see Performance Tuning Basics). Input queue drops generally occur when a packet is process-switched. A process switch means that the router cannot use a preferable route-cache method, such as fast switching or Cisco Express Forwarding (CEF), to handle the forwarding decision. If input drops are still present, it implies that there is simply too much traffic. Consider a hardware upgrade, or try to decrease the traffic load. These are the conditions for input queue drop counter. They usually occur when the router receives bursty traffic and cannot handle all packets.
 The Rx FIFO which is accessible by the interface PHY and interface DMA is full and any new frames that arrive in this condition will be dropped (normally called as overflow) and the rx_overflow counter (seen through show controller interface-id) will be incremented. When rx_overflow counter is incremented by one, it indicates that overflow condition has occurred once and is not indicative of the number of frames dropped.
 The Rx ring which is accessible by the interface DMA and interface driver code is full. Any new frame transfers from the DMA cannot proceed with this condition, since there are no free entries in Rx ring and hence the frames sent are dropped (termed as overrun condition). The rx_int_drop counter (seen through show controller interface-id) is also
incremented by one. Again, if rx_int_drop is incremented by one it indicates that there is one occurrence of an overrun condition, and the number of frames dropped is not known.
The input hold queue size can be increased from the default 75 packets. The hold queue stores packets received from the network that wait to be sent to the client. Cisco recommends that the queue size not exceed ten packets on asynchronous interfaces. For most other interfaces, queue length must not exceed 100. The input hold queue prevents a single interface from flooding the network server with too many input packets. Further input packets are discarded if the interface has too many input packets outstanding in the system. Router(conf-if)# hold-queue length in For Catalyst Switches, Cisco recommends to make this adjustment on all L3 interfaces on the device, both physical interfaces and VLAN interfaces. L2 ports configured with the switchport command can be left at the default value. Note: After you apply this command, you need to clear the interface counters and then monitor the network.
Caution: An increase in the hold queue can have detrimental effects on network routing and response times. For protocols that use SEQ/ACK packets to determine round-trip times, do not increase the output queue. Dropping packets instead informs hosts to slow down transmissions to match available bandwidth. This is generally better than duplicate copies of the same packet within the network, which can happen with large hold queues.
Troubleshoot Input Queue Drops
You can successfully troubleshoot input queue drops while packets constantly arrive in the input queue. You cannot troubleshoot a congestion that occurred in the past. If more than one routed protocol is configured on the interface, first determine the protocol that congests the input queue. Here is the fastest way to do this is:
1. Determine the suspect protocol. Check the CPU utilization in <protocol> Input processes. To do so, run the show processes cpu exec command. If Cisco IOS Software version 12.1 or higher currently runs on the router, you can shorten the output of the show processes CPU command through the output modifiers:
2. router#show processes CPU | i ^PID|Input
3. PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
4. 10 8503 1713 4963 0.00% 0.00% 0.00% 0 ARP Input
5. 24 69864 11429 6112 0.08% 0.11% 0.10% 0 Net Input
6. 28 55099 8942 6161 26.20% 20.07% 19.26% 0 IP Input
7. 37 4 2 2000 0.00% 0.00% 0.00% 0 SSCOP Input
8. 40 8 2 4000 0.00% 0.00% 0.00% 0 ILMI Input
9. 49 8 1 8000 0.00% 0.00% 0.00% 0 Probe Input
10. 50 28209 4637 6083 0.00% 0.03% 0.04% 0 RARP Input
11. 59 8 2 4000 0.00% 0.00% 0.00% 0 SPX Input
12. 61 8 2 4000 0.00% 0.00% 0.00% 0 Tag Input
13. 68 20803 3392 6132 0.00% 0.03% 0.00% 0 IPX Input
14. 104 4 1 4000 0.00% 0.00% 0.00% 0 IPXWAN Input
107 8 1 8000 0.00% 0.00% 0.00% 0 AT Input
Table 1 lists the possible input processes and types of packets that can congest the input queue: Input Process That Uses CPU Cycles Type of Packets IP IP AT AppleTalk IPX, SPX, or IPXWAN IPX ARP IP ARP
Other input processes are not likely to congest the input queue.
15. Find out whether packets that congest the input queue are destined for the router, or are forwarded through the router. Run the show interfaces [type number] switching command from exec mode.
Note: The show interfaces [type number] switching command is hidden, and does not show up if you use the "?" or TAB keys on the command line interface. Type the full command on the router. This command is not documented in the Command Reference Guide router#show interfaces ethernet 0/0 switching Ethernet0/0 ... Protocol Path Pkts In Chars In Pkts Out Chars Out ... IP Process 12142 2211929 35 5169 Cache misses 10212 ... Check whether the number of processed packets received is followed by a high number of cache misses. If so, this indicates that the packets, which congest the input queue, are forwarded through the router. Otherwise, these packets are destined for the router.
16. If packets are destined for the router, find out which higher-layer protocol congests the input queue. For this, use one of these show traffic exec commands:
o show ip traffic
o show ipx traffic
o show appletalk traffic
Note: These commands are applicable only if you suspect any of the input processes listed in table 1.
17. Try to get more information about the packets that congest the input queue. For this, you must debug the received packets. The previous steps indicate the debug commands that you need to enable.
Note: You can execute this directly, even if you do not perform the previous steps. However, when you debug, several messages are generated, and they can be hard to read. When you follow all the previous steps, you get an indication of what to look for in the debug output.
Warning: Debug with extreme caution. Otherwise, CPU utilization can increase considerably. Do not turn debugging on for more than 5 to 10 seconds. For more information on how to use the debug commands, refer to Using Debug Commands. Never disable console logs, terminal logs, and logs on a syslog server. Enable buffer logs, and increase the logging buffer size. A good value for the size of logging buffer would be 128000 bytes. Use these commands:
o no logging <host>
o logging buffered 128000 debugging
The output must be sufficient to locate the source of the problem. You can check the debug output with the show log command after you complete the debug session. Table 2 lists the debug commands to issue based on the type of packets that congest the input queue: Type of Packets that Congest the Input Queue Debug Command to be Used IP debug ip packet AppleTalk debug apple
packet IPX debug ipx packet ARP debug arp
For more information, refer to the Cisco IOS Debug Command Reference. Alternatively, you can use the show buffers input-interface [interface type] [interface number] header command to find out the types of that packets fill up the input queue. Note: This is only useful if there are a lot of packets in the input queue. Router#show buffers input-interface serial 0/0 Buffer information for Small buffer at 0x612EAF3C data_area 0x7896E84, refcount 1, next 0x0, flags 0x0 linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0 if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None) inputtime 0x0, outputtime 0x0, oqnumber 65535 datagramstart 0x7896ED8, datagramsize 728, maximum size 65436 mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0 network_start 0x7896ED8, transport_start 0x0 source: 212.176.72.138, destination: 212.111.64.174, id: 0xAAB8, ttl: 118, prot: 1 Buffer information for Small buffer at 0x612EB1D8 data_area 0x78A6E64, refcount 1, next 0x0, flags 0x0 linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0 if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None) inputtime 0x0, outputtime 0x0, oqnumber 65535 datagramstart 0x78A6EB8, datagramsize 728, maximum size 65436 mac_start 0x78A6EB8, addr_start 0x78A6EB8, info_start 0x0 network_start 0x78A6EB8, transport_start 0x0 source: 212.176.72.138, destination: 212.111.64.174, id: 0xA5B8, ttl: 118, prot: 1 Most of the time, one type of packet is present in large quantities. Here, for example, there are several Internet Control Message Protocol (ICMP) packets (IP protocol 1). If the problem is an incorrect router configuration (for example, both fast switching and Cisco express forwarding (CEF) are disabled), there is probably no particular pattern in the debugs, or in the output of the show buffers input-interface command.
18. When you have determined the type of packets that congest the input queue, the next step is to check whether you can prevent this congestion.
There are several reasons why packets must be processed:
o Improper router configuration—Switching paths that operate at the interrupt level are disabled on relevant interfaces.
To check which switching paths are configured on an interface, run the show <protocol> interface [type number] command.
 In order to enable legacy fast switching, configure it on output interfaces.
 In order to enable netflow switching, configure it on input interfaces.
 In order to enable Cisco express forwarding (CEF), you have to enable CEF globally (on the entire router) and locally (on the incoming interface).
For more information, see Cisco IOS Switching Services Configuration Guide.
o Local destination—Packets are destined for the router.
 In stable networks, the number of routing updates must not be excessive. In unstable networks, frequent updates of large routing tables can congest the input queue.
 Check whether excessive traffic is directed to the router itself (with, for example, Simple Network Management Protocol (SNMP), telnet, Trivial File Transfer Protocol (TFTP), and ping). Debug the packets for the relevant protocol to identify the source of these packets. When you find the source, eliminate it.
o Reliable Open System Interconnection (OSI) layer 2 protocol is used for transport—Packets that go through serial interfaces with X.25 encapsulation must be processed because in the X.25 protocol suite, flow control is implemented on the second OSI layer.
o Software compression—If the packet comes in or has to be forwarded through an interface on which software compression is configured, the packet has to be processed.
o Other features are unsupported at interrupt level—This is highly dependent on the Cisco IOS Software release that runs on the router. Check the release notes to see which features are supported at interrupt level. For example, in earlier Cisco IOS Software versions, multilink PPP packets had to be processed. In higher Cisco IOS Software versions, they can be fast-switched or even CEF-switched. Features such as encryption, local-area transport (LAT) translation, and data-link switching plus (DLSW+) are not yet fast-switched.
o Excessive traffic through the router, where each packet header intentionally contains different information—Based on the configured switching path, the first packets to a destination, or in a flow, are always processed. This is because, there are no entries in the cache that matches them. If a device sends packets at an extremely high rate, and there is no match in the cache, those packets can congest the input queue.
The source of these packets are revealed after the debug session. If the source address is always different, you must continue to troubleshoot on the upstream device, from which
the packet is received. If the interface on the router is connected to a broadcast medium, you can determine the Media Access Control (MAC) address of the source or the upstream device: Configure MAC accounting on the interface with the ip accounting mac-address input interface configuration command. After that, issue the show interfaces mac-accounting exec command. This command reveals the MAC address that has sent the packets at an excessive rate.
Output Queue Drops
Output drops are caused by a congested interface. For example, the traffic rate on the outgoing interface cannot accept all packets that should be sent out. The ultimate solution to resolve the problem is to increase the line speed. However, there are ways to prevent, decrease, or control output drops when you do not want to increase the line speed. You can prevent output drops only if output drops are a consequence of short bursts of data. If output drops are caused by a constant high-rate flow, you cannot prevent the drops. However, you can control them. When packets are processed, they are sent to the output queue of the outgoing interface. Issue the show interfaces exec command to view the size of the queue, the current number of packets in the queue, and the number of drops. Based on the type of interface and the type of queueing configured, the number of output queue drops is not explicitly shown, because the output drops counter summarizes the output drops separately at the processing level and at the interrupt level: router#show interfaces serial 0/0 ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) ... router#show interfaces serial 0/0 ... Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) ... However, it takes longer to process a packet than to sent the packet from the output queue to the wire. Therefore, it is highly unlikely that output queue drops (drops at processing level) can occur without drops at interrupt level. Output queue drops occur only if the interface is already congested at interrupt level, so that packets cannot be pulled out of the output queue before the queue becomes full. Therefore, output drops at processing level (output queue drops) and output drops at interrupt level always occur together, and there is practically no need to distinguish between these two counters. Note: However, there is one exception. If the output queue is constantly full and if no packets are sent out of the interface at all, you must check for a hardware failure on the interface.
Troubleshoot Output Queue Drops
You can decrease, or even prevent, output drops if you adjust the configuration of these features:
 Duplex mode—If the interface works in half-duplex mode, configure it (if possible) to work in full-duplex.
 Layer 2 windowing mechanism—If x.25 encapsulation is configured on the interface, increase the x.25 window size. For more information, see Setting Default Window Sizes.
 Distributed switching—On Cisco 7500 routers, if Versatile Interface Protocol (VIP) cards are installed in the chassis, enable distributed switching. When you do so, the incoming VIP buffers up to 1 second of traffic for the interface if the outgoing interface is congested. This is called rx-side buffering .
Note: Never increase the output queue in an attempt to prevent output drops. If packets stay too long in the output queue, TCP timers can expire and trigger retransmission. Retransmitted packets only congest the outgoing interface even more. If output drops still occur after you adjust the configuration of the router as recommended, it means that you cannot prevent or decrease output drops. However, you can control them, and this can be as effective as prevention. There are two approaches to control output drops:
 Congestion management
 Congestion avoidance
Both approaches are based on traffic classification, and you can use them in parallel. Congestion management ensures, with appropriate configuration, that important packets are always forwarded, while less important packets are dropped when the link is congested. Congestion management comprises fancy queueing mechanisms such as:
 Priority queueing
 Class-based weighted fair queueing
Congestion avoidance is based on intentional packet drops. The window size in TCP connections depends on the round trip time. Therefore, these intentional drops slow down the rate at which the source device sends packets. Congestion avoidance uses weighted random early detection. If unwanted output drops still occur after you implement these mechanisms, you need to increase the line speed.
Commands to Obtain More Information
Here are some commands that provide more information about queue drops:
 show interfaces switching
 show interfaces stats
 ip accounting mac-address
 show interfaces mac-accounting
If you have the output of a show interfaces command from your Cisco device, you can use Cisco CLI Analyzer to display potential issues and fixes. To use Cisco CLI Analyzer, you must be a registered customer, be logged in, and have JavaScript enabled.
show interfaces switching
Description
This command shows the number of packets sent and received on an interface, classified based on the switching path. This is a hidden command.
Format
show interfaces [type number] switching
Sample Output
Ethernet0/0 Throttle count 0 Drops RP 0 SP 0 SPD Flushes Fast 0 SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 86 Drops 0 Protocol Path Pkts In Chars In Pkts Out Chars Out Other Process 75 6728 79 4740 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 IP Process 142 11929 35 5169 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 AppleTalk Process 0 0 25 1635 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 DEC MOP Process 0 0 2 154 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 ARP Process 56 3580 13 780 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 CDP Process 90 26906 27 8900 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 Field Definition
<protocol> Process Number of processed packets. This includes packets destined for the router, and packets for which there is no entry in the appropriate switching cache table. Cache misses Packets that are forwarded through process level (for which there is no entry in fast switching cache). Fast Packets forwarded at interrupt level.
show interfaces stats
Description
This command is similar to the show interfaces switching command, and provides information on the number of packets that are process-switched, fast-switched (any fast switching path), and distributed-switched (for VIP capable platforms). This is a hidden command.
Format
show interfaces [type number] stats
Sample Output
Router#show interfaces stats
FastEthernet8/0/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 64 38646 323 32790 Route cache 477985 611343050 14815 18948150 Distributed cache 0 0 3564 4558356 Total 478049 611381696 18702 23539296 Serial12/0/0 Switching path Pkts In Chars In Pkts Out Chars Out Processor 37 3783 36 2299 Route cache 14815 18800000 45118 59862772 Distributed cache 3450 4378520 0 0 Total 18302 23182303 45154 59865071 Interface Serial12/0/1 is disabled ...
ip accounting mac-address
Description
This is an interface configuration command. It accounts for the received or transmitted packets, classified based on the source or destination MAC address.
Format
ip accounting mac-address {input|output}
show interfaces mac-accounting
Description
This is an exec command. It shows the number of packets sent and received classified based on the destination and source MAC address.
Format
show interfaces [type number] mac-accounting
Sample Output
router#show interfaces ethernet 0/0 mac-accounting Ethernet0/0 Input(494 free) 0000.0c5d.92f9(58 ): 1 packets, 106 bytes, last: 4038ms ago 0004.c059.c060(61 ): 0 packets, 0 bytes, last: 2493135ms ago 00b0.64bc.4860(64 ): 1 packets, 106 bytes, last: 20165ms ago 0090.f2c9.cc00(103): 12 packets, 720 bytes, last: 3117ms ago Total: 14 packets, 932 bytes Output (511 free) 0090.f2c9.cc00(103): 8 packets, 504 bytes, last: 4311ms ago Total: 8 packets, 504 bytes
Understanding Buffer Misses and Failures
Buffer Misses and Failures
The RP divides its processor memory into pools. Each pool contains a number of memory blocks of equal size. These memory blocks are called buffers.
Buffer Pools
There are six buffer pools:
 Small—104 bytes buffers
 Middle—600 byte buffers
 Big—1524 byte buffers
 VeryBig—4520 byte buffers
 Large—5024 byte buffers
 Huge—18024 byte buffers
For example, if an interface processor needs to pass a 20 byte packet to the RP, it “asks” for a Small buffer. If an interface processor needs to pass a 500 byte packet to the RP, it asks for a Middle buffer, and so forth. Note: The interface processor must ask for a buffer of a certain size. When the interface processor asks for a buffer, this occurs:
 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 .
 When IOS fails to get a Small buffer, it does not drop the packet. It increments the failed counter and falls through to the next level buffer, which is the Middle buffer and requests a buffer there. If it fails to get a Middle buffer, it requests the next level buffer, which is a Big buffer. This process continues until it hits the Huge buffer pool. If it fails to get a Huge buffer, then it drops the packet.
 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.
Fortunately, as this document discusses, buffer failure problems are not difficult to identify and resolve. This show buffers command output shows the current state of the router’s buffer pools: dspu-7k#show buffers Buffer elements: 500 in free list (500 max allowed) 2370 hits, 0 misses, 0 created Public buffer pools: Small buffers, 104 bytes (total 16, permanent 10): 11 in free list (0 min, 10 max allowed) 1770 hits, 33 misses, 22 trims, 28 created 9 failures (0 no memory) Middle buffers, 600 bytes (total 90, permanent 90): 89 in free list (10 min, 200 max allowed) 590 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Big buffers, 1524 bytes (total 90, permanent 90): 90 in free list (5 min, 300 max allowed) 126 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) VeryBig buffers, 4520 bytes (total 10, permanent 10): 10 in free list (0 min, 300 max allowed) 50 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Large buffers, 5024 bytes (total 10, permanent 10): 10 in free list (0 min, 30 max allowed) 0 hits, 0 misses, 0 trims, 0 created 0 failures (0 no memory) Huge buffers, 18024 bytes (total 2, permanent 0): 0 in free list (0 min, 13 max allowed) 2 hits, 2 misses, 0 trims, 2 created 0 failures (0 no memory)
In the show buffers output:
 Total identifies the total number of buffers in the pool, which include used and unused buffers.
 Permanent identifies the permanent number of allocated buffers in the pool. These buffers are always in the pool and can not be trimmed away.
 In free list identifies the number of buffers currently in the pool that are available for use.
 Min identifies the minimum number of buffers that the RP should attempt to keep in the free list:
o The min parameter is used to anticipate demand for buffers from the pool at any given time.
o If the number of buffers in free list falls below the min value, the RP attempts to create more buffers for that pool.
 Max-allowed identifies the maximum number of buffers that are allowed in the free list:
o The max-allowed parameter prevents a pool from monopolizing buffers that it does not need anymore. It also frees this memory back to the system for further use.
o If the number of buffers in the free list is greater than the max-allowed value, the RP should attempt to trim buffers from the pool.
 Hits identifies the number of buffers that have been requested from the pool. The hits counter provides a mechanism to determine which pool must meet the highest demand for buffers.
 Misses identifies the number of times that a buffer has been requested and the RP detected in which pool additional buffers were required. In other words, the number of buffers in the free list has dropped below min level. The misses counter represents the number of times the RP has been forced to create additional buffers.
 Trims identifies the number of buffers that the RP has trimmed from the pool, when the number of buffers in the free list exceeded the number of max-allowed buffers.
 Created identifies the number of buffers that have been created in the pool. The RP creates buffers in these situations:
o When demand for buffers has increased until the number of buffers in the free list is less than the min buffers.
o A miss occurs because there are no buffers in the free list.
o Both of the previous situations.
 Failures identifies when IOS fails to get a Small buffer, it does not drop the packet. It increments the failed counter and falls through to the next level buffer, which is the Middle buffer and requests a buffer there. If it fails to get a middle buffer, it requests the next level buffer, which is a Big buffer. This process continues until it hits the Huge buffer pool. If it fails to get a Huge buffer, then it drops the packet.
 No memory identifies the number of failures caused by insufficient memory to create additional buffers.
You can can examine the characteristics of each pool, to determine which pools (if any) are encountering problems. The parameters for a pool can be tuned to allow the router to be better prepared to handle the load, if the pool seems to exhibit these characteristics:
 The number of misses and creates increment at a high rate (as a percentage of hits).
 There is a consistently low number of buffers in the free list.
 The number of failures or no memory increment.
buffers Configuration Command
With the buffers configuration command, you can tune these parameters for each buffer pool:
 initial—Temporary buffers that are allocated at system reload.
 max-free—Maximum number of free buffers.
 min-free—Minimum number of free buffers.
 permanent—Number of permanent buffers.
Initial Buffers
Tune initial buffers to accommodate the burst of session-establishment traffic after router reload. buffers small initial 250 These buffers are eventually “trimmed” and returned to the system. The initial buffers are designed to handle session establishment, which is always process-switched. During session establishment, the fastswitching cache (used by other route protocols) is populated; process-switched buffers are no longer required and may be returned to the system. To tune initial buffers may not be the correct solution for the IBM feature set, because almost all packets (after session establishment) are process-switched and require the additional buffering anyway. Note: For the IBM process-switched features, you should tune permanent buffers rather than tune the temporary initial buffers.
Max-Free Buffers
Tune max-free buffers so that the value is equal to or greater than the permanent buffers. If all permanent buffers are in the free list, then the RP should not try to trim permanent buffers. Max-free can be used to ensure that unused buffers that are created during irregular bursts are returned to the system memory. buffers small max-free 175 buffers small permanent 125
Min-Free Buffers
Tune min-free buffers so that the value represents the estimated minimum number of buffers required at any time. Min-free can be used to anticipate buffer shortage conditions and to ensure that a minimum number of buffers are always available.
buffers small min-free 50
Permanent Buffers
Tune permanent buffers so that the value represents the estimated number of buffers required for normal processing. buffers small permanent 125 Permanent buffers are used to accommodate the normal buffer requirements (including frequent bursts) of the router. Determination of the normal buffer requirements is an interactive process, where the show buffer output should show the total buffers used in a pool at a given time. Permanent buffers should be tuned with regard to the consistent "total" buffers required. When you tune permanent buffers, you should focus on the reduction of creates and the elimination of misses and failures.
Additional show Commands
There are two other show commands that you can use to identify problems with buffer allocation:
 show interfaces interface-identifier
 show source-bridge
This show interfaces interface-identifier sample command output includes a counter for no buffer: dspu-7k#show interfaces channel 4/2 Channel4/2 is up, line protocol is up Hardware is cxBus IBM Channel MTU 4472 bytes, BW 98304 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation CHANNEL, loopback not set, keepalive not set Virtual interface Last input 0:00:04, output 0:00:04, output hang never Last clearing of "show interface" counters never Output queue 0/40, 0 drops; input queue 0/75, 8 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 646 packets input, 27760 bytes, 8 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 328 packets output, 16959 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets, 0 restarts 0 output buffer failures, 0 output buffers swapped out In the show interfaces interface-identifier command output:
 The no buffer counter increments when the interface fails to obtain a buffer for an inbound packet.
 Both the no buffer and drops (input queue) counters increment when the interface fails to obtain a buffer for an inbound packet.
 A no buffer counter that increments in the show interfaces output correlates to the misses counter that increments in the show buffers output. The appropriate buffer pool may be tuned.
This show source-bridge sample command output includes an interface counter for throttles, when source-route bridging (SRB) is configured for the interface: dspu-7k#show source-bridge Local Interfaces: receive transmit srn bn trn r p s n max hops cnt:bytes cnt:bytes drops Ch4/2 666 1 99 * f 7 7 7 652:26020 6:266 0 Global RSRB Parameters: TCP Queue Length maximum: 100 Ring Group 99: This TCP peer: 150.10.20.2 Maximum output TCP queue length, per peer: 100 Peers: state bg lv pkts_rx pkts_tx expl_gn drops TCP TCP 150.10.20.1 open *3 261 266 0 0 0 TCP 150.10.20.2 - *3 0 0 0 0 0 Rings: bn: 1 rn: 888 locvrt ma: 4000.7000.fff1 Buff Ring888 fwd: 0 bn: 1 RN: 666 local ma: 4000.0c48.2e80 Channel4/2 fwd: 261 bn: 1 RN: 88 remote ma: 4000.4000.fff1 TCP 150.10.20.1 fwd: 322 bn: 1 RN: 250 remote ma: 4000.300f.7c09 TCP 150.10.20.1 fwd: 0 Explorers: ------- input ------- ------- output ------- spanning all-rings total spanning all-rings total Ch4/2 0 0 0 0 1 1 Local: fastswitched 0 flushed 0 max Bps 256000 rings inputs bursts throttles output drops Ch4/2 0 0 8 0 In the show source-bridge command output:
 The throttles counter increments when the interface fails to obtain a buffer for an inbound packet.
 The throttles counter that increments in the show interfaces command output correlates to a misses counter that increments in the show buffers command output. The appropriate buffer pool may be tuned.
giant
In networks, a giant is a packet , frame , cell, or other transmission unit that is too large. Network protocols specify maximum and minimum sizes (and sometimes a single uniform size) for any transmission unit. For example, ATM packages all data into 53-byte cells. Any cell larger than that is discarded and recorded as a giant by network monitoring tools. The Remote Network Monitoring ( RMON ) standard information base for network adminstration calls them "oversize packets".