The troubleshooting of Layer 2 issues seems like it may be the easiest, as the information is really taught quite thorough at the CCNA level, however there are some caveats that are potential exam landmines for TSHOOT to avoid on exam day!
First I want to start with some verification commands that are critical for success!
“sh interface gi1/1 switchport” – This command will show you everything Layer 2 related about the interface, including if its an Access or Trunk port, which VLAN it is / was configured in (will show Inactive if its VLAN is deleted), and lots of other good information so this is a must know when reviewing Layer 2 portions of the Topology
“sh int trunk” – Gives all trunk information needed to verify Native VLANs, manually pruned VLANs, VTP pruned VLANs, Trunk Encapsulation types and modes, etc
“sh vtp status” – This provides all information outside of the password (sh vtp password for that), including the Domain Name, Rev #, VTP version running, VTP mode, and the MD5 digest of hashed passwords (VTPv3) that can be used to verify the password as well
“sh vlan brief” – Gives information about all known VLANs to the switch, and port assignment to the different VLANs
“sh mac address-table dyn” – This is a third way to verify which vlan the switch believes a host is on, based on the port it is learned off of, the information will also include the VLAN information associated to that port (which can also be viewed with “sh int (int) switchport” command)
Trunking issues and a surprising non-issue from TSHOOT OCG
First I’d like to point out that in the TSHOOT OCG, it is said that if two switchports tag traffic in the same Native VLAN, that the traffic will be forwarded whether it is an Access port on one side and a Trunk port on the other. If that Access Port resides in what is configured as the Native VLAN for the Trunk port on the other end of the link, the traffic will be passed.
So Auto – Auto, Nonegotiate – Auto, Access – Trunk ports will not form a Trunk, however they will still pass traffic if both sides are configured with the Native VLAN.
(The “Limited Connectivity” in the matrix below will forward Native VLAN data)
This is not however an issue with ISL, as ISL does not support the Native VLAN concept.
Watch for this on exam day, because it is potentially a non-issue that looks blatantly like an issue, when the real connectivity problem resides somewhere else in the network!
Some common issues that will cause a Trunk like not to form:
- Native VLAN mismatch – Both sides must have the same Native VLAN
- Encapsulation mismatch – Both sides must be either dot1q or ISL
- Trunk mode mismatch – The following graph contains which modes will form a Trunk, while “Limited Connectivity” will allow only communication only if the Native VLAN matches on each side (as described above):
- VTP Domain Name mismatch will cause a Trunk not to form if DTP is in use, this means that if both sides are configured as “Trunk Nonegotiate” a trunk will still form of VTP Domains do not match
- When a Trunk IS formed, be aware of both manual and dynamic pruning using either “VTP Pruning” if VTP is in use, or manual pruning using “switchport trunk allowed vlans …” command, allowed VLANs both manual and dynamic can be verified with “sh int trunk”
VTP issues and troubleshooting them
- Domain Name mismatch – These are case sensitive, and if they are different between switches, they are considered to be in different domains
- VTP Version Mismatch – Only Version 2 and Version 3 can be mixed / are backwards compatible, Version 1 is “kind of on” by default (with Null values), but if configured as the Version to be used it will not communicate with Versions 2 / 3 being run
- VTP Mode issues – Server Mode allows creation / deletion / changing of the VLAN Database and increments the Revision Config # for each change, which then propagates to other switches. Client mode cannot perform any changes to the VLAN Database but will update its VLAN DB and pass along the update within the VTP Domain upon receiving a new higher # value Config Revision. Transparent mode ignores Config Revisions but will pass them along, and VTP “Off” mode means the device is not participating in any function of VTP (including forwarding ads)
- Password Mismatch – This can be confirmed via “sh vtp password” or by comparing the MD5 Digest section of the “sh vtp status” output, as the hash should match (this is more for v3 where passwords are not in plain text format)
- Higher Revision # nuking switched network – This happens if a non-production switch is in Server mode with the same Domain Name / Password as the production switched network, and is plugged in after testing changes in a lab environment. This is apparent when Switchports can be seen in VLANs that do not exist on the switch (“sh int gi1/1 switchport” with the VLAN section showing “Inactive”). To avoid this switches should be kept in Transparent mode unless a confirmed VTP Server change is being pushed, then they should be temporarily changed to VTP Client mode to accept the update and transitioned back to Transparent mode. VTPv3 also has a Server Primary mechanic so that only trusted updates from the Primary VTP Server will be accepted despite the higher config rev # received
VLAN issues and how to identify and troubleshoot them
- Client IP Addressing incorrect – Issuing an “ipconfig” on the client or remote server can reveal they are in the incorrect subnet, which indicates the switchport they connect to is in the incorrect VLAN or a possible DHCP issue
- Missing VLAN – If ports are missing from “sh vlan brief” and are not showing up under “sh int trunk” output, it is possible the VLAN was deleted manually or indirectly by VTP nuking the VLAN with a higher revision config, this can be identified using the “sh int gi1/1 switchport” command to check the VLAN and more importantly whether it has (Inactive) next to it, in this case you will either need to recreate the VLAN (possible on a VTP server or manually on the switch) or move the switchport to the appropriate new VLAN to communicate
- Incorrect VLAN assignment – Pretty straight forward, make sure the interfaces are in the correct VLANs for the subnetwork they need to be in with “sh vlan brief” and using the “sh int gi1/1 switchport” command to verify its current VLAN
Utilizing the MAC Address table to assist in troubleshooting Layer 2
“sh mac address-table dynamic” – This will show you the dynamically learned addresses and which interface they are discovered off of, and which VLAN that interface is associated with all in the same table.
Using thing information with the “sh int x/x switchport” and “sh vlan brief” commands should give you all the info you need to determine which VLAN the port is currently in, and whether the placement is correct.
You can all use “clear mac address-table dynamic” to clear the MAC table of all learned addresses, to confirm when the MAC table repopulates you have the most current dynamically learned devices in the table!
Some scenarios where you might troubleshoot an issue and find a Layer 2 issue
- Pinging a PC returns no response, a look at the MAC table might show that MAC address learned off an interface that is in an incorrect VLAN, at which point you would want to configure it with the correct vlan via “switchport access vlan #”
- Pinging a PC returns no response, upon looking at “sh mac address-table dyn” it shows the correct VLAN, but “sh vlan brief” does not show that VLAN, in this case you will want to look at how to re-add it (VTP or manually)
- Pinging a PC returns no response, you try to ping the default gateway and it also times out, this may indicate an SVI IP Address issue, whether it is not configured or incorrectly configured
- Ping a PC returns no response, run “ipconfig” on client, and find it has a 169.254.x.x self-assigned IP address, confirming that there is a DHCP issue on the network that needs to be addressed
That is it for now, more advanced Layer 2 troubleshooting will be covered!
Things like VACL, DHCP, DHCP Snooping, Dynamic Arp Inspection, STP, all sorts of fun topics to troubleshoot!
For most of these topics there are full throated posts on the subject, so please feel free to use the search function to search for a keyword, and there is most likely an exhaustive lab post regarding the subject!
The DEVNET GRIND! 