I was mucking with etherchannel today and discovered a cool command that I was not aware of: show interface [interface] counters etherchannel.
You can run this command on your port-channel interface:
sw4#sh int po1 count ether
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 23863 15 229 0
Fa0/19 1899894 835 18864 0
Fa0/20 1903864 835 18862 5
Fa0/21 1945733 835 19307 5
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 3653 15 14 0
Fa0/19 181124 834 533 5
Fa0/20 171050 834 494 0
Fa0/21 169510 834 469 0
If you run it on one of the bundled links, you’ll get an error message:
sw4#sh int fa0/19 count ether
Etherchannel not enabled on this interface
Clearing the counters for this command takes a bit of work. If you clear the counters on the port-channel interface, it will not clear the counters on the individual bundled links:
sw4#clear count po1
Clear “show interface” counters on this interface [confirm]
sw4#
*Mar 1 02:20:57: %CLEAR-5-COUNTERS: Clear counter on interface Port-channel1 by console
sw4#sh int po1 count eth
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 1504 3 13 0 <-cleared
Fa0/19 1900270 838 18865 0
Fa0/20 1904240 838 18863 5
Fa0/21 1959175 838 19447 5
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 0 0 0 0 <-cleared
Fa0/19 181500 837 534 5
Fa0/20 171426 837 495 0
Fa0/21 169886 837 470 0
You can clear each bundled link on its own:
sw4#clear count fa0/19
*Mar 1 02:25:35: %CLEAR-5-COUNTERS: Clear counter on interface FastEthernet0/19 by console
sw4#sh int po1 count eth
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 136047 87 1311 0
Fa0/19 94 1 0 0 <-cleared
Fa0/20 1909733 866 18877 5
Fa0/21 2082732 866 20717 5
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 16479 84 42 0
Fa0/19 0 0 0 0 <-cleared
Fa0/20 176919 865 509 0
Fa0/21 175379 865 484 0
You can clear both the port-channel and the bundled links’ counters all at once with “clear counters”. Personally, I very rarely use that command. I feel that it’s like dropping a nuke on a mosquito. Sure you clear the counters that you want cleared, but you also destroy a ton of historical data by wiping out the all of the counters. I hate trying to troubleshoot an issue after another engineer has run this command. But if you must use it 🙂
sw4#clear count
Clear “show interface” counters on all interfaces [confirm]
*Mar 1 03:40:48: %CLEAR-5-COUNTERS: Clear counter on all interfaces by console
sw4#sh int po1 count eth
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 1222 0 13 0
Fa0/19 0 0 0 0
Fa0/20 0 0 0 0
Fa0/21 1222 0 13 0
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 0 0 0 0
Fa0/19 0 0 0 0
Fa0/20 94 1 0 0
Fa0/21 94 1 0 0
You can use this command to illustrate the method that the switch is using to “load balance” over the etherchannel links:
First, let’s create an SVI on each side of the Etherchannel
sw4(config)#vlan 100
sw4(config-vlan)#int vlan 100
sw4(config-if)#ip address 100.0.0.4 255.255.255.0
sw3(config)#vlan 100
sw3(config-vlan)#int vlan 100
sw3(config-if)#ip address 100.0.0.3 255.255.255.0
Let’s clear etherchannel counters, then ping the hell out of the 100.0.0.3 address:
sw4#sh int po1 count eth
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 3760 0 40 0
Fa0/19 188 2 0 0
Fa0/20 94 1 0 0
Fa0/21 5828 1 61 0
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 282 3 0 0
Fa0/19 188 2 0 0
Fa0/20 188 2 0 0
Fa0/21 94 1 0 0
sw4#ping 100.0.0.3 re 10000 si 1500
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
—–output truncated—–
Success rate is 100 percent (10000/10000), round-trip min/avg/max = 1/2/28 ms
Now let’s look at the etherchannel counters:
sw4#sh int po1 count eth
Port InOctets InUcastPkts InMcastPkts InBcastPkts
Po1 15512981 10018 323 0
Fa0/19 15481343 10008 3 0 <-note
Fa0/20 1249 7 3 0
Fa0/21 32739 7 338 0
Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Po1 15483747 10021 9 0
Fa0/19 15481343 10008 3 0 <-note
Fa0/20 1343 8 3 0
Fa0/21 1249 7 3 0
So why did one interface handle all of the pings? Let’s use another nifty little command to find out:
sw4#show etherchannel load-balance
EtherChannel Load-Balancing Operational State (src-mac):
Non-IP: Source MAC address
IPv4: Source MAC address
IPv6: Source IP address
sw4#sh arp | i 100.0.0.4
Internet 100.0.0.4 – 000a.8a1c.c400 ARPA Vlan100
We are “load balancing” based on the source mac-address. The ping is sourced by 100.0.0.4 and the source-mac address will not change, so all of our pings took the same route. This is good to know for the real world as well. Depending on the traffic source, that 8-gig etherchannel you set up to the server may only be giving you 1 gig of possible bandwidth. 🙂
Cisco Documentation:
show interfaces counters