Lab Objective
Configure two endpoints to receive different Scalable Group Tags upon 802.1X authentication, define a Security Group ACL denying traffic from one group to a specific destination group, and verify enforcement occurs based on group membership even when both endpoints share the same subnet.
Lab Purpose
The VACLs and VLAN-based isolation covered earlier in this series segment traffic based on network topology — which VLAN or subnet a device sits in. SGTs decouple segmentation from network topology entirely, tagging traffic based on the authenticated identity of the device or user, allowing policy to follow an endpoint even as it moves between different physical locations or subnets.
Lab Topology
Switch1 (fabric edge)
Gi1/0/1 ---- Employee-PC (authenticates
via 802.1X, RADIUS assigns
SGT 10 "Employees")
Gi1/0/2 ---- Guest-PC (authenticates via
802.1X, RADIUS assigns
SGT 20 "Guests")
Both PCs share the SAME subnet/VLAN --
segmentation must come entirely from SGT
policy, not VLAN separationTask 1: Verify Both Endpoints Receive Their Assigned SGTs
Confirm the RADIUS server assigns SGT 10 to Employee-PC and SGT 20 to Guest-PC upon successful 802.1X authentication.
Task 2: Verify Baseline Connectivity Without an SGACL
Confirm both PCs can currently reach a shared server, since no SGT-based restriction exists yet.
Task 3: Define a Security Group ACL Denying Guest-to-Server Access
Create an SGACL denying traffic specifically from SGT 20 (Guests) to the shared server's SGT.
Task 4: Apply the SGACL Between the Relevant Group Pair
Configure the policy matrix entry applying this SGACL to traffic from SGT 20 toward the server's SGT.
Task 5: Verify Enforcement Based on Group, Not Subnet
Confirm Guest-PC is now blocked from the server while Employee-PC, on the identical subnet, remains permitted.
Solution and Verification
Switch1# show authentication sessions interface gigabitethernet1/0/1 details | include SGT
SGT: 0010-10 (Employees)
Switch1# show authentication sessions interface gigabitethernet1/0/2 details | include SGT
SGT: 0020-10 (Guests)
-- Both endpoints received their SGT
-- dynamically from RADIUS as part of
-- 802.1X authentication, discussed earlier
-- in this series, despite sharing the
-- same physical VLANGuest-PC> ping SharedServer
Reply from SharedServer...
-- Currently permitted -- no SGACL policy
-- exists yet to restrict thisSwitch1(config)# cts role-based sgt-map SharedServer-address sgt 30
Switch1(config)# ip access-list role-based DENY-GUESTS
Switch1(config-rb-acl)# deny ip
Switch1(config-rb-acl)# exit
Switch1(config)# cts role-based permissions from 20 to 30 DENY-GUESTS
-- This single policy statement matches
-- traffic purely by SGT pair (20 to 30) --
-- no IP subnet, VLAN, or interface is
-- referenced anywhere in this ruleSwitch1# show cts role-based permissions
From SGT: 20 (Guests)
To SGT: 30 (Servers)
DENY-GUESTS
-- Policy confirmed active for this
-- specific group pairGuest-PC> ping SharedServer
Request timed out.
Success rate is 0 percent (0/5)
-- Guest-PC, tagged SGT 20, is now blocked
Employee-PC> ping SharedServer
Reply from SharedServer...
!!!!!
Success rate is 100 percent (5/5)
-- Employee-PC, tagged SGT 10, remains
-- fully permitted -- despite BOTH PCs
-- being on the exact same subnet and VLAN,
-- enforcement differs entirely based on
-- their authenticated group identityKey Takeaway
SGT-based policy enforcement operates at a layer entirely above IP addressing and VLAN membership — the same policy matrix travels with a device or user regardless of which physical port, VLAN, or subnet they connect through, since the tag is assigned dynamically at authentication rather than being derived from network location, a fundamental shift from the VLAN- and subnet-based segmentation approaches covered throughout most of this series.