L2 Layer Troubleshooting for Beginners

MAC ADDRESS, VLAN, ARP:

Important commands for troubleshooting:

• Show lldp neighbors
• Show interface status
• Int et 1/1 →  show active
• Note:

• We should never try to ping any host from a switch since it will try to ping via management interface
• Always check MAC address table on switches
• Always check ARP table on hosts only (do not check on switches)

• NOTE: Do the troubleshooting in same order as below:

1. Check if shutdown
2. Check vlans
3. Check IP configurations

• One method is to start ping from host A to host B. then, go to Host B and tcpdump on the interface. If we get both a request and reply. There is a trouble in the reply path.

• Note that we cannot see the ping on in-between devices since unicasts do not go to control plane

Case 1: Interface Shut Down:

• Go to each interface in topology and do

        #int et 1/1

        #show active

And check if it is shutdown

Case 2: Trunk and Access Mismatch:

• Go to facing interfaces (both sides of a link) in topology and do

        #int et 1/1

        #show active

• Check if both are trunk and allow the vlan used

• If one of them is access vlan X and the other is trunk allowed vlan X, then, the untagged packet from access will go to the native vlan and get dropped

Case 3: IP Configuration on hosts:

• Go to hosts and check the interface IP address

• One of the hosts will be in different subnet (Then, host A will think that host B is also in same subnet. But, host B will know that it is not in same subnet...so will not reply)

Case 4: MAC Access Lists:

• Do #show active on each interface
• Check if there is a mac access-list for another mac-address ‘B’  which blocks packets from mac-address B (using ‘in’)

Case 5: Another host ‘C’ is also receiving the ping requests that was sent for another host ‘D’. Check if true?

• Start tcpdump on both hosts C and D . (we may see that no ping packets are shown….control plane)
• But, if we checked on an in-between switch’s interface #show active , we see that mac address learning is set to NO. So, there is always a broadcast due to Unknown Unicast (#no switchport mac address learning)
• Now that we know that it is supposed to be getting broadcasts, we can confirm it by going to host C and doing

• #clear counter et 49
• #watch diff show int et 49 // Other traffic will be there also...so use the other command(OR) #watch diff show int et 49 counter bins

• Go to host A and start ping for host D using large repeat count and size

Case 6: MAC Flapping:

• Use command #show logging to see mac flaps
• #show event-monitor mac can be used to see when a mac-address entry was added and removed