Switchport Protected Command

By daxm

Similar to Private VLAN’s concept of an isolated VLAN is a command called Switchport Protected.  It is similar in that any interface that is in the same VLAN and is in “switchport protected” mode cannot see each other but can see other ports NOT in switchport protected mode that are in the same VLAN.  This feature ONLY works on a per switch basis.  So protected interfaces on different switches can communicate with each other as if the protected command wasn’t there.

Here is my graphic to display this:

So all the “PCs” shown are in VLAN 3.  All the ports connecting to the PCs are in switchport protected mode except the one connecting to PC 101.  (In my examples the “PCs” are actually routers but the concept still applies.)  The green arrows indicate successful intercommunications whereas the red arrow indicates communication that is denied due to the switchport protected feature.

To validate the configuration of this setting use the “show interface <num> switchport” command:

SW1#sh int g1/0/3 switchport
Name: Gi1/0/3
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 3 (VLAN0003)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: true
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

Note the section in red.


This author published 11 posts in this site.


FacebookTwitterEmailWindows LiveTechnoratiDeliciousDiggStumbleponMyspaceLikedin


September 26th, 2012

What if link between both switches wasn not a trunk and port on left switch was connected as protected too, would .103 be isolated from .100 too ?
Asked another way : can you setup a tree-like/cascading switching infrastructure where all end-hosts would be isolated from each other at level 2 with this command ?

September 26th, 2012

An interesting thought. I’d think the port that was setup as protected would treat all traffic incoming from the “down stream” switch as all protected within its fabric backbone. I haven’t tried this but I will try to do this an report back.

February 6th, 2014

Well explained man, thanks!!! I can´t see much usage of this, as it´s only applicable if the VLAN is local to the switch and not extended… except that it´s easier to configure then private VLANs.

Jon Hartman
April 7th, 2014

Thanks for the write-up. The diagram was a nice touch, too.

April 13th, 2016

The use case I’m considering for this is to setup core 3560x switch supporting PVLAN cascading down to other 2960’s that don’t support PVLAN but do support Protected mode. So each distribution switch connecting to the core switch will be in its own community PVLAN which is then protected mode at the access layer.

April 13th, 2016

I’m not sure a fully understand. Are you saying that the ports connecting the Core switch to the Distribution switch(es) will be in access mode and that each of these ports, on the Core side, are in unique PVLANs? If so, I don’t see why that wouldn’t work. However, bear in mind that each of your Distribution switch(es) are now islanded from each other so the VLAN database will have to be updated manually on each. There won’t be any trunking (i.e. multi-vlan) ports.

Leave a comment