Troubleshoot Ethernet port
November 11, 2016
Many times when a single user reports problem with his network connection you start troubleshooting from checking the state of Ethernet port on the switch. Here are some tips how to validate Ethernet port on Cisco switch.
Why port doesn’t forward?
I listed possible reasons why the Cisco switch port does not forward frames
- Interface was disabled [administratively down; down]
- No cable plugged [down/down]
- Damaged cable [down/down]
- Wrong cable pinouts [down/down]
- The speed mismatch [down/down]
- Duplex mismatch [up/up; link will be inefficient; use show interface command]
- The device on the other end of cable is powered off or shutdown (command) or error disabled [down/down]
- Port security has disabled the interface [down/down (err-disable)];check port security status; show port-security interface]
- Port security filters the frames [up/up; check port security status; show port-security interface]
- Switch uses ACL that filters based on the source or destination address [up/up]
- Switch doesn’t know the VLAN [up/up; not configured] or VLAN is not active or interface is in incorrect VLAN (start with show vlan brief and show vtp status)
- VLAN is not allowed to pass the trunk [up/up; show interfaces trunk]
- Trunk is not enabled on one of the switches [up/up; show interfaces switchport; show interfaces trunk]
- If a given physical link was not configured properly for Etherchannel (for example: Etherchannel auto-negotiation failed) then the link is not added to the Etherchannel group and it is placed in a down state (err-disabled), and not used, until the configuration inconsistency can be resolved.
- EMI interference – [up/up; use show interface command]
show interface command
One of the most useful command on the switch is show interface command.
Switch#show interfaces fastEthernet 0/1 FastEthernet0/1 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000c.85b0.3181 (bia 000c.85b0.3181) MTU 1500 bytes, BW 100000 Kbit, 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, media type is 10/100BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 01:22:25, output 00:00:01, 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 2000 bits/sec, 2 packets/sec 5 minute output rate 2000 bits/sec, 2 packets/sec 11611 packets input, 836214 bytes, 0 no buffer Received 660 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 359 multicast, 0 pause input 0 input packets with dribble condition detected 12537 packets output, 1093550 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
Here are some tips on how to interpret the output:
- input errors counter – generic error; look on the other counters
- EMI interference – up/up; CRC counter grows but collisions counters do not
- Duplex mismatch [up/up; late collision counter may grow; runts counter may grow, collisions counter may grow]
- Cable to long – late collisions counter may grow up
- giant counter grows – switch doesn’t support Giant frames but receives them from the other switch/machine. Giants frames are often used with servers (for example in ESX VMware environment) to forward frames more effectively
- Interface resets counter grows – flapping interface [bad cable]; switch also may reset interface if it receive too many errors – it often happens if you use poor quality transceiver (for example firber2copper)
- queue counters – basically you should no have anything in the queue (switch uses ASIC). If it happens check if you have any speed problems.
- broadcast counter grows rapidly – layer 2 loop
- multicast counter grows rapidly – user connected specific device like video/monitoring streaming device
Basically you should use auto duplex setting on your ports. If you hard code it, then the other side may want to negotiate duplex, it will not receive any reply and use half duplex.
show interfaces status // shows speed and duplex with information how it was determined (auto-negotiation or manually configured) show interfaces status err-disable // shows the reason why the port is in err-disable state