utput hang never Last clearing of "show interface" counters 3w4d Queueing strategy: fifo Output queue 0/40, 548941 drops; input queue 0/75, 3717 drops 5 minute input rate 1509000 bits/sec, 258 packets/sec 5 minute output rate 259000 bits/sec, 241 packets/sec 287554125 packets input, 3659652949 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, o throttles 819 input errors, 559 CRC, 227 frame, 0 overrun, 0 ignored, 33 abort 282883104 packets output, 3613739796 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up Looking at this information, you should notice some things right away. First, this is a T1, and second, the bandwidth is 1,544 Kbps (see 1 and 2). Remember that the bandwidth given when you use show interface is not necessarily representative of the true bandwidth of the link. While this value is correct by default, it can be changed with the bandwidth interface command. This field is used for calculations in EIGRP and other protocols, which is why it can be altered. Looking further down (4) you can see that the five-minute input rate is 1,509,000 bps at 258 packets per second (pps). That's 1,509 Kbps used on a 1,544 Kbps link. You might be tempted to say, "Hey, the link's got 33 Kbps left!" However, remember that this is a five-minute average. Perhaps an easier way to get a sense of the utilization is on 3, which shows: reliability 255/255, txload 42/255, rxload 249/255 Looking at these numbers, you can see that the transmit load (txload) is only 42 out of 255, but the receive load (rxload) is 249 out of 255. If you use some simple math (249/255 100), you can see that the link is 97.65 percent utilized. Ever wonder why the rxload and txload numbers are based on 255 and not 100? The decimal number 100 in hex is 64. If we need to burn two hex digits in the router's memory, why not use them to their fullest? The largest number we can represent with two hex digits is FF, wh