Above is a visual of Private VLANs and how they can communicate with each other, however this is going to be a lot of Switch security, so lets get to it.
Port Security troubleshooting
Some common issues that can cause Port Security not to work:
- Port Security is configured but not enabled – This is when port-security settings are set on an interface, but it is missing the command to enable it, “switchport port-security”, verified with commands “sh port-security” and “sh port-security int (int)” to verify it is enabled (also confirmed in “sh run” under interface setting)
- A static MAC address is not configured correctly – Can confirm if this is setup correctly by getting the host MAC with “ipconfig /all” on the PC, and using command “sh port-security address” on the switch, this will show “SecureSticky” (Sticky) and “SecureConfigured” (Static) addresses allowed on that port
- The max # of MAC addresses has been reached preventing access – This is a result of using “switchport port-security max #” command, and can be found by either using “sh port-security” or “sh port-security int (int)” to confirm the max and current address count to verify if this is your issue, increase max # to resolve
- Running config not saved to startup config (lost on reboot) – Self Explanatory š
The different types of Port Security violation, configured per interface with “switchport port-security violation (type)”, what happens and how to resolve them:
- Protect – Any Frame from the MAC Address in violation is dropped without a notification, and violation count (in “sh port-security”) is not incremented
- Restrict – Any Frame from the MAC Address is dropped, log messages generated
- Shutdown – When violation occurs, port is placed into err-disable state, and additional frames will be dropped and log messages will be generated
So drops frames, drops and logs frames, err-disables port and logs frames.
There are two ways to show an err-disable interface, and a command to view all mechanisms that may trigger an err-disable state on an interface:
- “sh interface status” – This will show any state of all interfaces including connect, notconnect, err-disable, as well as port configs like speed / duplex settings
- “sh interface (int)” – This of course will show you the full output of all information relating to the port, including its state right at the top of the output
- “sh errdisable detect” – This will show a list of all services that will put a port into an err-disable state
***If unable to run “show” commands in an exam environment, doing a shut / no shut on the suspect interface will generate a syslog message indicating it going back into an err-disable state upon coming back up and going back into the state***
Bouncing the interface to produce this syslog message can also expose what is causing the issue, as the syslog is often accompanied by a “cause” message when the port is put back into the err-disable state.
To configure a port to automatically recover from an err-disable state:
- “errdisable recovery cause (something)” – This will cause ports to recover without a shut / no shut, with a default time of 300 seconds (5 minutes)
- “sh errdisable recovery” – Shows all err-disable types with auto recovery enabled
These issues are largely found by checking “sh port security” and “sh interface status” to determine if a port is in err-disable state, get the MAC address of the host with “ipconfig /all”, and use “no …” in front of the incorrect port-security commands on the interface and input the correct command / correct MAC address.
That wraps up the basic port-security troubleshooting, most of the battle is knowing the command to verify what is happening, the second half is simply knowing to negate the incorrect command and input the correct information and shut / no shut the port to bring it back online (or set err-disable recovery).
DHCP Snooping Troubleshooting
DHCP Snooping not only defines a trusted port for DHCP Discover and Response request packets on the switch, but also creates a DHCP Snooping Binding table, that maps IP Addresses to interfaces which is then used by both IP Source Guard and Dynamic ARP Inspection (DAI).
Quick review of DHCP Snooping:
- Enabled globally with “ip dhcp snooping”
- Enabled for specific vlans with “ip dhcp snooping vlan #”
- Trusted interfaces (facing the DHCP server) configured with “ip dhcp snooping trust” command
- All other interfaces untrusted by default
- Issue “no ip dhcp snooping info option” to disable option 82
Verification commands for DHCP Snooping:
- “sh ip dhcp snooping” – This will show all information about IP DHCP Snooping configured, including all VLANs configured, option 82, everything!
- “sh ip dhcp snooping binding” – This is a biggy, this will show the MAC Address / IP Address / VLAN # / Interface # information for all hosts learned by DHCP Snooping!
Dynamic ARP Inspection (DAI) Troubleshooting
This relies on the information contained in the DHCP Snooping Binding table to prevent MAC Address spoofing on a switch, and is configured both per VLAN and per port with the following commands:
- “ip arp inspection vlan #” – Enable DAI for a VLAN (global config)
- “ip arp inspection trust” – Configured on interfaces that DAI should not be running on, like interfaces not in the DHCP Snooping Binding table
DAI works by dropping any ARP’s that come in on an “untrusted” interface, that does not match the MAC / IP Address combination in the DHCP Snooping Binding table, and will generate syslog messages every time DAI drops an ARP request.
IP Source Guard Troubleshooting
This also relies on the DHCP Snooping Binding table, and is used to prevent IP Address spoofing by referencing incoming packets on the port against the Binding table info.
To configure IP Source Guard, DHCP Snooping must be enabled for the VLAN, and the following must be configured on the interface itself:
- “ip verify source” – Enforces filtering by IP Address only
- “ip verify source port-security” – Enforces filtering by IP and MAC Address
- “sh ip verify source” – Shows all active filters / modes running for IP Source Guard
An interface may show “deny-all” meaning the interface has no binding in the DHCP Snooping Binding table, which is confirmed with “sh ip dhcp snooping binding”
With all 3 Spoof-Prevention mechanisms in place, there should not be any issues with Rogue DHCP servers, however if there is you will want to review all these settings and ask yourself some of the following questions:
- Is option 82 disabled on the switch (often causes issues when enabled), this is verified via “sh ip dhcp snooping” to see if option 82 is enabled
- Is the interface pointed at my DHCP Server “Trusted”?
- Is the Host having issues in my DHCP Snooping Binding table? Is the information in it correct?
- Is the host in my DAI Table (“sh ip verify source”), and does that info look correct?
- Does “sh int status” show any ports in a err-disable mode?
- Are any interfaces “trusted” that should not be per the diagram?
Also it is worth mentioning that one way you probably won’t use in the exam room but may be asked as a method of troubleshooting an incorrect DHCP assignment, would be to use SPAN / RSPAN to monitor a port, and then do an “ipconfig /renew” on the host to observe where the DHCP response comes from then verify that in your DHCP Snooping configurations as to whether it is correct.
Troubleshooting Access-Control at Layer 2
The two means of providing Access-Control is by configuring Private VLANs or VLAN Access-Control Lists (VACLs), though both are completely different configurations, both have the same goal of providing filtering within the same subnet / VLAN but by different means of doing so.
Protected Ports
At its most basic, a “protected port” can only communicate with ports that are not also configured as a “protected port” and that is it at its most basic.
“Protected Ports” are ports that reside in the same VLAN on the same Switch, that should not be talking to each other. This being the case, there are really only two issues you will be troubleshooting in this scenario:
- Ports that are communicating with each other that should not be
- Ports that are NOT communicating with each other that SHOULD be
This can be caused both by if a port is “protected” when it should not be (port should be open for all communication), or if a port is NOT “protected” but should be (port should not receive traffic from all sources).
This is incredibly easy to troubleshoot, as the configuration and verification is simple:
- “switchport protected” – This command configures a port to be “protected”
- “sh run int (int)” – This will show “protected port” config on the interface
- “sh int (int) switchport” – This will show “Protected: True/False” in the output
If two ports cannot communicate, issue “no switchport protected” on the appropriate side, and issue is resolved.
Private VLAN Troubleshooting
This uses the concept of having “Secondary VLANs” inside of a Primary VLAN, which only allows certain “Secondary VLANs” to communicate with each other as pictured above which goes as follows:
- Community Ports can talk to ports within their community, but not other communities, and not to isolated ports
- Isolated Ports cannot talk to any other Secondary VLAN port type, except for the Promiscuous Port
- Promiscuous Ports can talk to all Secondary VLAN ports, and can be though of essentially as the “Gateway” for Secondary VLAN port traffic to talk to the rest of the network
This basically expands on the Protected Ports concept by grouping protected ports in the case of “communities” and making single ports protected via “isolated” ports.
One issue right up front, is with VTP, in that if VTPv3 is not the version in use the VTP mode on the switch MUST be Transparent or Off!
I cannot cover everything here for PVLANs, so I highly advise giving my lab post of this a once over, which can be located in this link.
A quick breakdown of a PVLAN config in the running config would be:
!
vtp mode transparent
!
vlan 100
Ā private-vlan primary
Ā private vlan association 201,301
!
vlan 201
Ā private-vlan community
!
vlan 301
Ā private-vlan isolated
!
interface gi1/0/1
Ā switchport private-vlan mapping 100 201,301
Ā switchport mode private-vlan promiscuous
!
interface gi1/0/2
Ā switchport private-vlan host-association 100 201
Ā switchport mode private-vlan host
!
interface gi1/0/3
Ā switchport private-vlan host-association 100 201
Ā switchport mode private-vlan host
!
interface gi1/0/4
Ā switchport private-vlan host-association 100 301
Ā switchport mode private-vlan host
!
interface gi1/0/5
Ā switchport private-vlan host-association 100 301
Ā switchport mode private-vlan host
!
Ok so I almost ran out of colors / went cross eyed typing that, but to review by color:
Grey = Setting switch to VTP Transparent mode
Blue = Configuration of Primary VLAN (the main / non-Private VLAN)
Green = Configuration of the Community Private VLAN #
Orange = Configuration of the Isolated Private VLAN #
Pink = Promiscuous Port Configuration, associating Primary to Secondary VLANs
Red = Interfaces associated with the Community Secondary / PVLAN
Purple = Interfaces associated with the Isolated Secondary / PVLAN
This is to give a very basic, but very straight forward example of a configuration, and how Secondary VLANs are associated to interfaces.
- The Primary and Secondary VLAN #’s and types are configured
- The Promiscuous port is defined by associating it to both the Primary and Secondary Private VLANs
- The individual interfaces are associated to a VLAN # depending on what they need to be able to communicate with WITHIN THE VLAN
- All port types will be able to communicate with the Promiscuous Port and everything beyond it (the entire network), the Private VLAN settings ONLY effect what the ports can communicate WITHIN THE VLAN!!!
That is a critical concept to understand, that if you are troubleshooting a Private VLAN issue, it is an issue with two hosts communication within the same VLAN (whether its that they should be able to communicate or CAN communicate and shouldn’t be).
If you are not familiar or need to brush up, I recommend hitting the full post on PVLANs.
To get a quick view of which interfaces are in which Private VLANs:
SW1#sh vlan private-vlan
PrimaryĀ Secondary Ā Type Ā Ā Ā Ā Ā Ā Ports
Ā Ā Ā āā- Ā Ā Ā āāā Ā Ā āāāāāāĀ Ā Ā Ā āāāāāāāāāāāāāā
Ā Ā Ā 300Ā Ā Ā Ā Ā Ā Ā Ā Ā 100Ā Ā Ā Ā Ā Ā Ā Ā community Ā Fa1/0/1, Fa1/0/2
Ā Ā Ā 300 Ā Ā Ā Ā Ā 200 Ā Ā Ā Ā Ā Ā isolated Ā Ā Ā Fa1/0/3, Fa1/0/4
SW1#
This output was taken from the full lab post, to demonstrate how it should look.
Private VLAN info can also be found per interface with “sh int (int) switchport”
To cap off Private VLANs, if there is a communication issue, depending on whether devices should or shouldn’t be talking you need to configure them to be able to communicate by either placing them in the same community or putting them in a different community / making and putting them in an isolated PVLAN.
VLAN Access-List (VACL) Troubleshooting
VLAN Access-Lists solve the issue presented by Protected Port and Private VLAN filtering, and that is that those two options are “all or none” connectivity between hosts, where VACL filtering gives more granular control via Extended Access-List (Layer 4) filtering.
If you are not familiar with VACL’s, I highly advise reviewing my full lab here.
VACL’s are comprised of either Standard or Extended IP Access-Lists, that are then referenced in a “vlan access-map” using the same concept as a route-map, by defining certain traffic via IP ACL then assigning an action to that traffic.
The trick to troubleshooting VACL’s is that the IP Access-List for Intra-VLAN traffic to be effected must be “Permitted” on the IP Access-List, even if you want to deny the traffic between hosts, the “Deny” part is done in the “vlan access-map” configuration by defining the IP ACL (with all traffic permitted) and then in the second sequence defining the action “Drop” to filter or drop the traffic.
When troubleshooting you will need to confirm the correct traffic is being permitted on the IP Access-List and VLAN access-map using the following commands:
- “sh access-lists” – This is to verify the IP ACL, remember to PERMIT traffic!
- “sh vlan access-map” – This is to verify correct IP ACL’s are being called out, and that the sequence / actions are all correct in the VACL Map
The order of building a VACL goes:
- Create an IP Access-List
- Create a VLAN Access-Map
- Create “VLAN filter-list” to associate a VLAN Access-Map to a VLAN
An IP ACL can be applied to both an interface to use for Layer 3 filtering, and be in use by a VLAN Access-Map, so if you see this on exam day this is a non-issue unless the Access-Lists themselves are somehow misconfigured or incorrectly applied!
That is all I have for Layer 2 Security / Spoof-Prevention / Filtering
If you are not familiar with the subjects here I would again highly advise familiarizing with them before TSHOOT exam day, and for real world troubleshooting, however I feel these notes cover all the bases pretty well so I will put this post to rest!
The DEVNET GRIND! 