Hands-On Lab: Configuring Segmentation with Scalable Group Tags (SGTs)

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 separation

Task 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 VLAN

Guest-PC> ping SharedServer
Reply from SharedServer...
-- Currently permitted -- no SGACL policy
-- exists yet to restrict this

Switch1(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 rule

Switch1# show cts role-based permissions

From SGT: 20 (Guests)
To SGT: 30 (Servers)
  DENY-GUESTS
-- Policy confirmed active for this
-- specific group pair

Guest-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 identity

Key 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.