NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will create and assign Security Group Tags (SGTs) in Cisco ISE, compare static vs dynamic SGT assignment, and understand inline tagging propagation across the fabric. This matters because SGTs enable identity‑based segmentation (TrustSec) independent of IP/VLAN — in production networks SGTs let you enforce consistent access control for user groups (employees, contractors, IoT) across campus, branches and data center, even when IPs change.

Real-world scenario: An enterprise wants Employees (SGT 900) and IoT devices (SGT 5) to follow different access policies across campus and WAN. ISE assigns SGTs; edge devices propagate or enforce them inline. This lesson shows how to create SGTs, use dynamic assignment for RADIUS/AD-derived groups, and apply static IP→SGT mappings for devices that cannot authenticate.

Note: This is Lesson 2 of 7 for Lab 46: End-to-End Segmentation — TrustSec/SGT. We assume you completed Lesson 1 topology and device basics.

Quick Recap

We continue using the same topology from Lesson 1. No new devices are added in this lesson — we work with:

ISE (identity and SGT authoring)
Campus Catalyst switch (fabric edge / inline tagging)
Firewall/FTD or data center Catalyst (enforcement / SGT-aware)
Endpoint hosts in VLANs (Employee VLAN 120, IoT VLAN 180)

If you completed Lesson 1 you already configured network connectivity and RADIUS authentication between ISE and the switches. This lesson focuses on SGT creation and assignment inside ISE and mapping to network devices.

ASCII Topology (same as Lesson 1 — interfaces and IPs shown for clarity)

All interfaces below use the same management addressing you configured in Lesson 1.

[ISE] 192.168.100.10
    |
    | RADIUS / SXP / Admin
    |
[Catalyst-9500] 192.168.100.2  --- Campus Access Switches --- Hosts
                      |                                   |
                      | inline SGT tagging                HostA: Employee (VLAN120) 10.120.1.10 SGT: 900
                      |                                   HostB: IoT (VLAN180)      10.180.1.10 SGT: 5
                      |
                [FTD / DC Catalyst] 192.168.100.3

Every interface above shows the management IP for the device used in this lesson (these are the same addresses used in Lesson 1).

Key Concepts

Before touching any configuration, understand these core concepts and behaviors:

Security Group Tag (SGT): A 16‑bit identity tag (e.g., 900, 950, 4, 5) that labels traffic with a group identity (Employee, Contractor, IoT). Think of SGTs as "virtual VLANs for identity" — routing and IP addressing stay the same, but policy uses the SGT to enforce access.
Dynamic SGT Assignment (ISE/RADIUS): When a user or device authenticates via 802.1X, MAB, or VPN, ISE can return an SGT in the RADIUS authorization response. The access switch receives the SGT and applies it to the endpoint’s traffic. Protocol detail: on successful 802.1X authentication, the switch records the session and applies the returned SGT into the hardware (TCAM) or tags the frame inline.
Static IP→SGT Mapping (SXP / Manual): For non‑authenticating devices (printers, legacy IoT), you map an IP to an SGT. This mapping can be provisioned manually on devices or distributed via SXP from ISE to SGT‑aware devices. In production, static mappings are used when endpoints cannot do 802.1X or when you must ensure consistent tagging across devices.
Inline Tagging vs SXP: Inline tagging means the SGT is carried end‑to‑end with the packet (e.g., Ethernet CMD), allowing downstream switches to evaluate SG‑ACLs without needing IP→SGT lookup. SXP is a control‑plane mechanism that distributes IP→SGT bindings to devices that cannot see an inline tag. In production, inline tagging is preferred for scalability and lower TCAM churn; SXP is used during transition or for devices that cannot propagate tags.
Enforcement Points and TCAM: Enforcement is performed by SGT‑aware enforcement points (switches, firewalls). Be mindful of TCAM size: too many dynamic SGT mappings or huge SG‑ACLs can exhaust hardware resources. In production, plan for TCAM limits and prefer inline propagation where supported.

Step-by-step configuration

We will perform four major steps:

Create SGTs in ISE (authoring).
Configure dynamic assignment (example 802.1X/RADIUS authorization result).
Configure a static IP→SGT mapping (for legacy IoT).
Verify inline tagging and SGT propagation on the Catalyst switch.

Each step below shows the action, the exact commands or GUI actions you perform (where a GUI is primary, the commands show how to verify on the network device), why it matters, and verification output.

Step 1: Create Security Group Tags in ISE

What we are doing: Author SGTs (for example, Employee SGT 900, IoT SGT 5) in ISE so that they can be used in authorization policies and returned in RADIUS responses. Creating SGTs centrally in ISE standardizes group names and SGT numbers across the network.

# ISE GUI action (describe exact GUI path — ISE is GUI driven)
# In ISE Admin GUI:
# 1) Policy > Policy Elements > Results > Security Groups > Add Security Group
#    Name: Employee
#    SGT: 900
#    Save
# 2) Policy > Policy Elements > Results > Security Groups > Add Security Group
#    Name: IoT
#    SGT: 5
#    Save

What just happened: You created two Security Group objects in ISE: "Employee" mapping to SGT 900 and "IoT" mapping to SGT 5. These objects appear in the ISE policy element library and can be referenced in authorization sets. When ISE returns an authorization containing one of these SGTs, the network access device will learn and apply the tag.

Real-world note: Central SGT authoring prevents mismatched SGT numbers across sites; use a naming convention and an SGT registry.

Verify:

# On ISE (GUI) verify Security Groups list shows entries (screenshot or GUI view)
# On the Catalyst switch, verify ISE is reachable and RADIUS is configured:
show running-config | section radius

Expected output (example):

radius server ISE-PRIMARY
 address ipv4 192.168.100.10 auth-port 1812 acct-port 1813
 key Lab@123
!

The show output confirms the switch has the ISE RADIUS server configured and can receive SGT attributes in RADIUS responses.

Step 2: Configure Dynamic SGT Assignment via Authorization (ISE Policy)

What we are doing: Create an authorization rule in ISE that returns an SGT for authenticated employees (e.g., when AD group matches). This makes SGT assignment dynamic based on identity and posture.

# ISE GUI actions (Policy > Authorization > Authorization Policy)
# 1) Add Rule: Name = "Employee-Access"
#    Condition: If IdentityGroup == "AD-Employees"
#    Result: PermitAccess with SecurityGroup=Employee (SGT 900)
#    Save and apply

What just happened: ISE now has an authorization rule that, upon successful authentication and identity matching (e.g., AD membership), returns an authorization result containing the Security Group "Employee" (SGT 900). The switch will receive this in the RADIUS Access-Accept and will apply SGT 900 to the session.

Real-world note: Use AD attributes or ISE profiling to assign SGTs dynamically to users; this scales better than manual mapping.

Verify:

# On the switch (after a test endpoint authenticates), check the session and SGT:
show authentication sessions interface gigabitEthernet1/0/10
show cts role-based-permissions

Expected output (example):

Interface: Gi1/0/10
  User: host-employee
  Auth method: 802.1X
  Authentication State: AUTHORIZED
  Security Group Tag: 900
  Policy: Employee-Access

CTS Role Based Permissions:
  Role: Employee
  SGT: 900
  Permitted: ip any any (example ACL mapped)

The first command shows the active auth session on the specified interface and the applied SGT; the second shows CTS role/SGT mapping used by the switch for policy evaluation.

Step 3: Configure a Static IP→SGT Mapping (for legacy IoT host)

What we are doing: For devices that cannot perform 802.1X (like legacy cameras), create a static IP→SGT mapping so the network enforces policies against them as IoT (SGT 5). This prevents those devices from being treated as unclassified.

# On Catalyst switch (static IP→SGT mapping)
configure terminal
  cts manual
  ip sgt-map address 10.180.1.10 5
exit
write memory

What just happened: You created a manual (static) mapping telling the switch that traffic sourced from IP 10.180.1.10 should be treated as SGT 5. The switch will tag or evaluate incoming traffic from that IP as IoT, enabling SG‑ACL enforcement. This is crucial for non-authenticating devices.

Real-world note: Use static mappings sparingly — too many manual entries increase administrative overhead. Prefer dynamic methods when possible.

Verify:

show ip sgt-map

Expected output:

IP to SGT mappings:
  10.180.1.10 -> SGT 5 (static entry)

This confirms the switch has the static mapping and will use SGT 5 for that IP.

Step 4: Verify Inline Tagging and SGT Propagation

What we are doing: Confirm the switch is sending or carrying the SGT inline so downstream devices can enforce SG‑ACLs without IP→SGT lookup. We also check SXP bindings if you rely on SXP for distribution.

# Verify inline SGT tagging on traffic and SXP bindings
show cts internal statistics
show sxp binding
show cts role-based-permissions

What just happened: These commands reveal whether CTS inline tagging is active, whether SXP has distributed any IP→SGT bindings, and which roles/SGTs the device knows for enforcement. Inline tagging will show as frame tagging in the CTS internal stats; SXP bindings list the IP→SGT learned via SXP.

Real-world note: Inline tagging is the preferred propagation method across fabric segments; verify your interconnects are SGT‑aware to avoid losing tags.

Verify:

show cts internal statistics

Expected output (example):

CTS Internal Statistics
  Inline Tagging: ENABLED
  Inline Tagged Frames: 1250
  Inline Untagged Frames: 10
  SXP Bindings: 2

show sxp binding

Expected output:

SXP Bindings
  10.180.1.10 -> SGT 5  (source: static)
  10.120.1.10 -> SGT 900 (source: ISE dynamic)

These outputs show inline tagging is active and SXP has bindings available for devices that rely on control-plane distribution.

Verification Checklist

Check 1: ISE Security Groups present — Verify in ISE GUI under Policy Elements > Security Groups that "Employee" (SGT 900) and "IoT" (SGT 5) exist.
- How to verify: ISE GUI list; on switch confirm RADIUS server configured: show running-config | section radius.
Check 2: Dynamic assignment working — Authenticate an employee endpoint and confirm the switch session displays SGT 900.
- How to verify: show authentication sessions interface <int> shows Security Group Tag: 900.
Check 3: Static mapping applied — Confirm static mapping for IP 10.180.1.10 to SGT 5 exists and SXP binding (if used) is present.
- How to verify: show ip sgt-map and show sxp binding show the mapping and distribution.

Common Mistakes

Symptom	Cause	Fix
SGT not applied after 802.1X success	ISE authorization returned no Security Group attribute or wrong AD group matching	Check Authorization Policy result; ensure Security Group is selected in the authorization result for the matching rule
Downstream device shows no SGT	Inline tagging not negotiated or removed on trunk links	Verify intermediate links and devices are SGT-aware and preserve CMD/inline tags; enable inline tagging on the fabric edge
Static mapping not used	Typo in IP or mapping configured on wrong device	Use `show ip sgt-map` to confirm mapping and correct any IP typos
SXP not distributing bindings	SXP session not established between ISE and device	Verify SXP peering (IP reachability and credentials), check `show sxp connections` and re‑establish SXP if needed

Key Takeaways

Centralize SGT authoring in ISE — treat SGTs as objects you reference in authorization policies to maintain consistency.
Prefer dynamic SGT assignment via RADIUS/802.1X for scale; use static IP→SGT mappings for legacy or unauthenticating devices.
Inline tagging (Ethernet CMD) is the most scalable propagation method because it carries identity with the packet; SXP is useful during transition or for devices that cannot tag inline.
Always verify both the authentication/authorization pipeline (ISE policies) and the enforcement plane (switch/FTD TCAM entries, SXP bindings) — a failure in any link will result in missing SGTs and failed enforcement.

Final real-world insight: In production deployments, plan for TCAM capacity, prefer inline propagation, and maintain a clear SGT registry to avoid collisions and enforcement gaps. Use static mappings only when necessary, and monitor SXP bindings and CTS counters to detect propagation issues early.