Hands-On Lab: Configuring PVLAN Edge (Protected Ports)

This hands-on lab configures PVLAN Edge (protected ports) on two access ports within the same VLAN, isolating them from each other at Layer 2 while both retain normal connectivity to an uplink port, demonstrating a lightweight isolation feature that requires no separate VLAN.

PVLAN Edge ConfigurationProtected PortSwitchport Isolation

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure two access ports on the same switch and VLAN as protected ports, verify they can no longer communicate directly with each other, and confirm both retain normal connectivity through a shared uplink port.

Lab Purpose

Creating a separate VLAN for every pair of devices that should not communicate with each other, discussed earlier in this series regarding VLAN design, is often unnecessary overhead when only simple host isolation is needed — such as guest devices on a hotel or hotspot network that should reach the internet but never each other. PVLAN Edge provides this isolation with a single per-port command, no VLAN or trunking changes required.

Lab Topology

Switch1 (all ports in VLAN 50)
  Gi1/0/1 ---- Guest-PC-A
  Gi1/0/2 ---- Guest-PC-B
  Gi1/0/24 ---- uplink to router (not protected)

Task 1: Verify Normal Connectivity Before Protection

Confirm Guest-PC-A and Guest-PC-B can currently ping each other, since they share the same VLAN.

Task 2: Configure Both Ports as Protected

Enable the protected port feature on Gi1/0/1 and Gi1/0/2.

Task 3: Verify Protected Ports Cannot Communicate

Confirm Guest-PC-A can no longer ping Guest-PC-B.

Task 4: Verify Both Ports Still Reach the Uplink

Confirm both PCs can still reach a device through the non-protected uplink port, such as the default gateway.

Solution and Verification

Guest-PC-A> ping 192.168.50.11

Reply from 192.168.50.11: bytes=32 time=1ms
-- Normal connectivity confirmed before
-- protection is applied

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# switchport protected
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# switchport protected

Guest-PC-A> ping 192.168.50.11

Request timed out.
Request timed out.
Success rate is 0 percent (0/5)
-- Two protected ports cannot exchange
-- traffic directly at Layer 2, regardless
-- of being in the same VLAN

Guest-PC-A> ping 192.168.50.1

Reply from 192.168.50.1: bytes=32 time=1ms
-- The default gateway, reached through the
-- non-protected uplink port, remains fully
-- reachable

Switch1# show interfaces gigabitethernet1/0/1 switchport | include Protected

Protected: true

Key Takeaway

The protected port rule applies specifically to traffic between two protected ports on the same switch — a protected port always retains normal connectivity to any non-protected port, which is exactly what allows guest devices isolated from each other to still reach a shared, non-protected gateway or server without any VLAN redesign.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه