Evaluating txload and rxload

I often notice confusion among newbie networkers regarding the txload and rxload fields of IOS' show interface command output. txload and rxload roughly measure the amount of traffic passing out of and into an interface, respectively, relative to its perceived bandwidth. For example, we can generate around 250 kbps of combined incoming and outgoing traffic on an otherwise quiet FastEthernet interface by issuing a continuous ping:

Router# ping 192.168.1.140 repeat 1000 size 1400

Type escape sequence to abort.
Sending 1000, 1400-byte ICMP Echos to 192.168.1.140, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...

This negligible amount of traffic barely registers in the interface statistics (250 kbps out of 100 Mbps is only around 0.25%):

Router# show interface f0
FastEthernet0 is up, line protocol is up 
  Hardware is PQ3_TSEC, address is 001b.2a02.523c (bia 001b.2a02.523c)
  Internet address is 192.168.1.186/24
  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: 2/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 227000 bits/sec, 39 packets/sec
  30 second output rate 227000 bits/sec, 39 packets/sec
     68319 packets input, 67517830 bytes
  ...

Note that the input and output rates shown above are for a 30-second interval, configured with the interface configuration command load-interval 30.

To inflate the impact of our meager traffic flow on the interface load values, we can administratively configure an artificially low interface bandwidth; say, 256 kbps.

Router(config)# interface f0
Router(config-if)# bandwidth 256

Keep in mind that the bandwidth command modifies only the perceived bandwidth of the interface: it has no effect on the actual speed at which packets are transmitted or received. Now if we retry our extended ping, we should observe much higher txload and rxload values.

Router# ping 192.168.1.140 repeat 1000 size 1400

Type escape sequence to abort.
Sending 1000, 1400-byte ICMP Echos to 192.168.1.140, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
...
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/1/8 ms
Router# show interface f0
FastEthernet0 is up, line protocol is up 
  Hardware is PQ3_TSEC, address is 001b.2a02.523c (bia 001b.2a02.523c)
  Internet address is 192.168.1.186/24
  MTU 1500 bytes, BW 256 Kbit/sec, DLY 100 usec, 
     reliability 255/255, txload 157/255, rxload 156/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ...

The 8-bit txload and rxload values are easily converted to more human-friendly percentages by simple division:

157 / 255 = 0.615, or roughly 62%
156 / 255 = 0.611, or roughly 61%

So, this output tells us that the interface is utilizing around 62% of its perceived transmit bandwidth and around 61% of its perceived receive bandwidth (effectively the same amount of traffic in either direction). These two values are never added together such that they might total to 255; if you wanted to express total utilization as a single number, you would add both and divide the sum by 510 (255 + 255).

Our ping above didn't result in an observed 100% utilization because it lasted only a few seconds. While it is theoretically possible to see 255/255 for either value, the interface would need to experience maximum saturation for an extended period of time.