Advanced SGT Multi-Domain Context
Introduction
Modern enterprise networks span campuses, branches, remote workers, SD-WAN fabrics, and cloud data centers. Maintaining consistent security policy across all of these domains is one of the most pressing challenges facing network and security engineers today. SGT multi-domain context solves this challenge by providing a unified framework where Security Group Tags classify, propagate, and enforce policy regardless of where users, devices, or workloads reside.
The fundamental idea is straightforward: build context in each local domain, store it as standard scalable group tags, share that context everywhere across networking and security domains, and enforce consistent SGT-based policies for a simple and unified policy experience. Rather than managing thousands of IP-based access control lists tied to network topology, SGT multi-domain deployments decouple security policy from the underlying infrastructure. The result is a security architecture that scales with business intent rather than network complexity.
This article provides an in-depth exploration of advanced SGT deployment across multiple domains. We will cover the core classification, propagation, and enforcement model, then walk through real-world use cases spanning campus and branch networks, hybrid work with remote access VPN and ZTNA, SD-WAN fabrics, SD-Access overlays, firewall integration, and data center environments with ACI. Whether you are preparing for the CCIE Security exam or architecting a production zero trust deployment, this guide will give you the technical depth you need.
What Are Security Group Tags and Why Do They Matter for Multi-Domain Networks?
Security Group Tags are 16-bit identifiers assigned to users, endpoints, servers, and workloads based on their role or function within the organization. Instead of writing access control policies based on IP addresses and subnets, SGTs allow you to express policies in business terms. For example, a policy matrix might state that the Employees group (SGT 9) is denied access to the ipcamera group (SGT 23), while the nvr group (SGT 19) is permitted access to the ipcamera group (SGT 24).
This business intent becomes immediately visible on the network device itself:
Edge-Cat9300#show cts role-based permissions
IPv4 Role-based permissions default: Deny IP-00
IPv4 Role-based permissions from group 19:nvr to group 24:ipcamera
Permit IP-01
IPv4 Role-based permissions from group 9:Employees to group 23:ipcamera
Deny IP-00
The power of this approach becomes apparent in SGT multi-domain deployments. When an employee connects at a campus site, they receive the same SGT regardless of which switch port they plug into. When that same employee connects over remote access VPN, they receive the same SGT. When the policy says "Employees cannot reach IP cameras," that policy is enforced at the campus switch, the branch router, the SD-WAN edge, and the firewall, all without a single IP address in the policy definition.
Classification into Functional Groups
The classification model groups assets by business function rather than network location. Typical groupings include:
- SGT_Employee for managed user endpoints
- SGT_Contractor for third-party or temporary workers
- SGT_Printers for shared print devices
- SGT_Building Management for temperature sensors, HVAC systems, and similar building automation
- SGT_FinanceServer for financial application servers
- SGT_ipcamera for physical security surveillance devices
These business-based groupings provide consistent policy and access independent of network topology. The assignment leverages items such as location, device type, RADIUS attributes, and Active Directory membership to allocate group assignments dynamically.
How Does SGT Classification Work Across Domains?
Classification is the first pillar of the SGT architecture. The fundamental principle is to classify where appropriate for the use case, based on the assets you need to protect.
Classification Methods by Location
| Network Location | Classification Method |
|---|---|
| Campus access port | End user/endpoint classified with SGT via 802.1X or MAB |
| WLAN | BYOD device classified with SGT via RADIUS authorization |
| SVI interface | SVI interface mapped to SGT statically |
| VLAN | VLAN mapped to SGT for bulk classification |
| Physical server | Server mapped to SGT via IP-to-SGT static binding |
| Data center (ACI) | Workloads classified via ESG/EPG integration with ISE |
| Cloud IaaS | Cloud connectors gather workload attributes for SGT assignment |
ISE Creation of IP-to-SGT Bindings from AAA
When a user authenticates via RADIUS, ISE creates an IP-to-SGT binding based on the authentication and authorization result. The RADIUS accounting message must be formatted in a way that ISE can use to bind the IP address and SGT together. This is the foundation of dynamic classification. Any access device can participate in this process as long as RADIUS accounting is formatted according to specification.
For example, when an Auditor authenticates through ISE against Active Directory, ISE creates the binding:
| IP Address | SGT |
|---|---|
| 10.1.10.1 | Auditor |
This binding is then distributed to enforcement points throughout the network via propagation mechanisms.
Default Route Classification
Starting with IOS XE 16.11, the default route can be classified with an SGT. This is essential for classifying "Internet" or SaaS traffic. The default route (dynamic or static) must exist for proper classification and enforcement. Note that 0.0.0.0/0 is not exported via SXP per design specification on IOS XE.
cat9300-1(config)# cts role-based sgt-map 0.0.0.0/0 sgt 2500
%Please ensure default route is created using ip route 0.0.0.0 command
Cat9300-1#show cts role-based sgt-map all details
Active IPv4-SGT Bindings Information
IP Address Security Group Source
======================================================================
0.0.0.0/0 2500:Internet_SGT CLI
cat9300-1#show ip route
--snip--
Gateway of last resort is 172.23.41.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 172.23.41.1
With this configuration, any traffic destined for the Internet receives the Internet_SGT (2500) as its destination group tag, enabling SGACL enforcement between internal groups and Internet-bound traffic:
Cat9300-1#show cts role-based permissions
--snip--
IPv4 Role-based permissions from group 60:IoT_Sensors to group 2500:Internet_SGT:
deny_log-01
Static Data/Voice VLAN SGT Assignment
A newer IOS XE feature (17.15(2) and 17.16(1)) allows per-VLAN SGT assignment on trunk ports, supporting separate SGTs for data and voice VLANs on the same interface:
interface GigabitEthernet1/0/4
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 20
device-tracking attach-policy access_track
cts role-based sgt-map vlan-id 10 sgt 4
cts role-based sgt-map vlan-id 20 sgt 8
end
Previously, port-based SGT assignment was limited to just the data VLAN using the older syntax with cts manual policy static sgt.
How Does SGT Propagation Work in Multi-Domain Environments?
Propagation is the mechanism by which SGT information travels between network devices and domains. There are two fundamental categories: inline (data plane) methods and control/management plane methods.
Inline Propagation Methods (Micro-Segmentation)
Inline methods embed the SGT directly into the data plane traffic:
- Ethernet Inline Tagging (CMD): Uses EtherType 0x8909 with a 16-bit SGT encapsulated within the Cisco Meta Data (CMD) payload. This is the most common method for Layer 2 adjacencies between switches.
- IPsec / L3 Crypto: SGTs are carried inside the IPsec header. This is used for SD-WAN overlays and site-to-site VPN connections.
- VXLAN: The SGT (16-bit) is inserted into the Security Group field of the VXLAN header. This is the primary method used within SD-Access fabrics.
Inline Propagation Methods (Macro-Segmentation)
For macro-level segmentation:
- 802.1Q: VRF is mapped to VLAN via VRF-Lite for macro-level separation
- IPsec VPN: VRF/VPN separation via encrypted tunnels
- VXLAN VNI: VXLAN Network Identifier provides VRF-level separation
The VXLAN header structure carries the SGT in the overlay:
| Field | Description |
|---|---|
| Outer MAC Header | Underlay Layer 2 |
| Outer IP Header | Underlay Layer 3 |
| UDP Header | Transport |
| VXLAN Header | Contains VNI + Security Group (SGT) |
| Inner MAC Header | Original Layer 2 |
| Inner IP Header | Original Layer 3 |
| Original Payload | Application data |
Control Plane Propagation: SXP
The SGT eXchange Protocol (SXP) provides IP-to-SGT binding exchange over TCP port 64999. SXP operates with a Speaker/Listener model where:
- ISE can act as both an SXP Speaker and Listener
- SXPv5 is VRF-aware, allowing an ISE SGT Domain to represent a VN/VPN/VRF
- Network devices generally use the control plane bindings to mark traffic in the data plane
Control Plane Propagation: pxGrid
The Platform eXchange Grid (pxGrid) enables context sharing with both first-party and third-party ecosystem partners. Subscribers can consume SGT Domains (VN/VPN/VRF) as part of the pxGrid SXP Topic. All major NGFW vendors, SASE/SIG vendors, and SD-WAN competitors are interoperable via pxGrid.
Pro Tip: SXP published as an Informational Draft to the IETF based on customer demand. Open source SXP implementations exist in both Java (OpenDaylight) and C. CMD and VXLAN GPO encapsulations are also published via IETF drafts, making SGT an open, interoperable technology.
What Is the SGT Multi-Domain Enforcement Model?
Enforcement is where SGT policies translate into actual permit or deny decisions on the network. The enforcement model uses Security Group Access Control Lists (SGACLs) applied at the egress point of the policy path.
SGACL Egress Policy Matrix
SGACLs are defined in a matrix format where the source SGT and destination SGT determine which access control list applies. A typical SGACL might look like this:
deny icmp
deny udp src dst eq domain
deny tcp src dst eq 3389
deny tcp src dst eq 1433
deny tcp src dst eq 1521
deny tcp src dst eq 445
deny tcp src dst eq 137
deny tcp src dst eq 138
deny tcp src dst eq 139
deny udp src dst eq snmp
deny tcp src dst eq telnet
deny tcp src dst eq www
Dynamic Policy Download
One of the most powerful aspects of the SGT enforcement model is dynamic policy download:
- A new user, device, or server is provisioned on the network
- The switch requests policies for the assets it protects
- Policies are downloaded and applied dynamically from ISE
- All controls are centrally managed in one place for auditing
The result is that security policies are completely decoupled from network topology. There are no switch-specific security configurations needed, and there is one place to audit network-wide policies.
Directional SGACL with TCP Established
For more granular control, SGACLs support directional enforcement using the established keyword:
! Policy from Employee to Web Server
permit tcp dst 80
permit tcp dst 443
deny ip
! Return policy from Web Server to Employee
permit tcp established
deny ip
! Policy from Admin to Employee Desktop
permit tcp dst 3389
deny ip
! Return policy from Employee Desktop to Admin
permit tcp src 3389 established
deny ip
Verifying SGACL Enforcement
Use show cts role-based counters to validate enforcement:
C9K-CORE-1#show cts role-based counters
Role-based IPv4 counters
From To SW-Denied HW-Denied SW-Permitted HW_Permitted
* * 0 0 48002 369314
3 20 53499 53471 0 0
4 5 0 0 0 3777
3 6 0 0 0 53350
4 6 3773 3773 0 0
The From * to * line represents the default rule. Separate counters are displayed for hardware-switched and software-switched packets. SGACL enforcement is primarily done in hardware. Only if the packet needs to be punted to software (for example, when TCAM is full or the ACE has logging enabled) will the software counter increment.
SGT Multi-Domain Deployment in Campus and Branch Networks
A common real-world use case involves a manufacturer deploying SGT across campus and branch sites. The business requirements typically include:
- Allow authorized users on trusted devices onto the site LAN/WLAN
- Isolate IoT devices (building automation, physical security cameras) from managed users and devices
- Meet governance, risk, and compliance directives within a defined timeline
Starting Design: Ingress Filtering via Site IP-to-SGT
The initial design uses ISE as the classification engine and SXP to distribute bindings:
- A single ISE cluster serves the global network
- IOS SXP peering routers below ISE provide scaling and filtering capability
- SGT Domains create site-level IP-to-SGT groupings
- SXP delivers all site-level IP-to-SGT bindings for in-scope SGTs to ingress enforcement points
- Only in-scope devices receive SGTs. Out-of-scope devices (users with ZTNA agent) inherit an "Enterprise SGT"
- Internet/SaaS traffic (including ZTNA termination) is classified with an "Internet_SGT" via default route or prefix list
An example partial policy matrix for this deployment:
| SRC / DST | ipcamera (24) | nvr (19) | nvr_central_data (40) | Employees (4) | Network_Services (3) | Internet_SGT (2500) |
|---|---|---|---|---|---|---|
| ipcamera (24) | deny | permit | deny | deny | permit | deny |
| nvr (19) | permit | deny | permit | deny | permit | deny |
| nvr_central_data (40) | deny | permit | deny | deny | deny | deny |
| Employees (4) | deny | deny | deny | deny | permit | permit |
| Network_Services (3) | permit | permit | deny | permit | permit | deny |
| Internet_SGT (2500) | deny | deny | deny | permit | deny | deny |
| Default | Deny | Deny | Deny | Deny | Deny | Deny |
ISE SGT Domains for Multi-Site Scaling
SGT Domains (formerly called SXP Domains) separate the global SGT binding table into separate tables for specific purposes. This provides granular control over mapping distribution:
- By default, IP-to-SGT mappings to SXP peers are shared within SGT Domain Default
- Dynamic session mappings go to SGT Domain Default
- SGT carried in the data plane removes the need to exchange IP-to-SGT mappings between SGT Domains
- SGT Domain Filters can filter by subnet, SGT, or Virtual Network (VN)
Design Evolution: Scaling Beyond Ingress
Some sites encounter scale issues with ingress switch enforcement. The solution is to move enforcement closer to the egress point:
- The source SGT is derived from the packet (inline tag)
- The egress point only stores the IP-to-SGT bindings of the destination endpoints it directly protects
- The return traffic benefits from the same architecture
- The access layer only stores the policies for the endpoints attached to it at any given moment
This egress enforcement model dramatically reduces the number of IP-to-SGT bindings each switch must hold and the number of SGACL entries in security TCAM.
Configuring Links for SGT Inline Tagging
To enable SGT inline tagging between switches, configure CTS manual mode with trust:
C9K-1(config)# interface GigabitEthernet1/5
C9K-1(config-if)# cts manual
C9K-1(config-if-cts-manual)# policy static sgt 2 trusted
C9K-1(config-if-cts-manual)# no cts role-based enforcement
C9K-2(config)# interface GigabitEthernet1/0/14
C9K-2(config-if)# no switchport
C9K-2(config-if)# ip address 10.10.20.2 255.255.255.0
C9K-2(config-if)# cts manual
C9K-2(config-if-cts-manual)# policy static sgt 2 trusted
C9K-2(config-if-cts-manual)# no cts role-based enforcement
Pro Tip: Best practice is to "shut" and "no shut" the interface after configuring CTS if the device does not apply the configuration immediately. Also, port-channel is supported -- configure CTS on the physical interface and then add it to the port channel.
Verify the configuration:
C9K-1#show cts interface brief
Global Dot1x feature is Enabled
Interface GigabitEthernet1/1:
CTS is enabled, mode: MANUAL
IFC state: OPEN
Authentication Status: NOT APPLICABLE
Peer identity: "unknown"
Peer's advertised capabilities: ""
Authorization Status: SUCCEEDED
Peer SGT: 2:Device_sgt
Peer SGT assignment: Trusted
SAP Status: NOT APPLICABLE
Propagate SGT: Enabled
Cache Info:
Expiration : N/A
Cache applied to link : NONE
L3 IPM: disabled.
Why Disable Enforcement on Inter-Switch Links?
On links between network devices, enforcement should be disabled to avoid issues with SGT-to-Unknown SGT matching. If a Medical_Device (SGT 10) sends traffic to a destination whose SGT is not known at the intermediate switch, the DGT lookup returns "Unknown." If the default policy is deny, the traffic is dropped even though a valid policy exists at the egress enforcement point. Disabling enforcement on inter-switch CMD links prevents this premature drop.
SGT Multi-Domain Integration with SD-Access
SD-Access provides a two-level segmentation hierarchy that maps directly to the SGT model:
- Macro-level: Virtual Networks (VNs) provide first-level segmentation ensuring zero communication between specific groups. For example, OT-Manufacturing VN versus Carpeted VN.
- Micro-level: Security Group Tags provide second-level segmentation within each VN, enabling role-based access control between groups such as Finance SGT and Employee SGT.
Intra-VN Policy Enforcement in SD-Access
Within a single VN in an SD-Access fabric, the traffic flow for SGT enforcement follows these steps:
- Routing lookup for the destination IP determines the VXLAN tunnel location
- SGT-tagged traffic is encapsulated in VXLAN and sent to the tunnel location over potentially non-SGT-capable devices in the underlay
- The egress switch looks up the DGT for the destination IP
- The egress switch looks up the policy for the SGT/DGT combination
- Action is taken according to the policy
Inter-VN Policy via Firewalls
For traffic between Virtual Networks, a firewall typically enforces policy. There are two deployment models:
Non-SGT-aware Firewall:
- Firewall is connected externally to the campus fabric
- Campus fabric prefixes are advertised to the firewall via routing protocol
- Firewall policy is based on interface, subnet IP/mask, and IP ACLs
SGT-aware Firewall:
- Firewall is connected externally to the campus fabric
- SXP connection between ISE and the firewall provides IP-to-SGT mappings
- Firewall policy is based on SGTs and SGACLs (Group Based Policy)
- The firewall also supports interface/subnet IP-based policy for brownfield integration
Starting with FTD 7.4, a Policy-Based Routing (PBR) policy matching srcIP any / dstIP any / SGT any triggers internal table loading that enables the control plane to tag outgoing data plane traffic. This PBR policy can be applied to any interface, not just SGT propagation interfaces.
Extending SGT Multi-Domain Context to SD-WAN
Extending SGT inline tagging across SD-WAN is supported starting with IOS XE 17.5 / SD-WAN 20.5. The traffic flow for a multi-VN site-to-site connection across SD-WAN proceeds as follows:
- SGT is encapsulated in VXLAN across the SDA fabric within the source VN
- The border node strips the VXLAN header and transports the SGT in CMD via a trunk port
- The SD-WAN router encapsulates the SGT into IPsec within the appropriate VPN-ID
- The remote SD-WAN router strips the IPsec header and transports the SGT in CMD via a trunk port
- The remote border node encapsulates the SGT in the VXLAN header within the destination VN
- The egress switch looks up the DGT for the destination IP
- The egress switch looks up the policy for the SGT/DGT combination
- Action is taken according to policy
SD-WAN TrustSec Configuration
The tunnel interface requires CTS manual configuration:
interface Tunnel1
ip unnumbered GigabitEthernet0/0/1
no ip redirects
ipv6 unnumbered GigabitEthernet0/0/1
no ipv6 redirects
cts manual
tunnel source GigabitEthernet0/0/1
tunnel mode sdwan
The Ethernet interface with VRF-lite sub-interfaces:
interface GigabitEthernet1
no ip address
no ip redirects
ip mtu 1500
load-interval 30
negotiation auto
cts manual
policy static sgt 2 trusted
no cts role-based enforcement
!
interface GigabitEthernet1.10
encapsulation dot1Q 10
vrf forwarding 10
ip address 10.200.10.20 255.255.255.0
no ip redirects
ip mtu 1400
ip tcp adjust-mss 1360
cts manual
policy static sgt 2 trusted
no cts role-based enforcement
!
interface GigabitEthernet1.20
encapsulation dot1Q 20
vrf forwarding 20
ip address 10.1.20.20 255.255.255.0
no ip redirects
ip mtu 1400
ip tcp adjust-mss 1360
cts manual
policy static sgt 2 trusted
no cts role-based enforcement
ISE and SD-WAN Manager Integration
Starting with IOS XE 17.10.1, ISE integrates with Catalyst SD-WAN Manager and Controller to provide SGT-based Zone-Based Firewall (ZBFW) policy on SD-WAN routers. ISE shares user/device-to-SGT mappings with the SD-WAN Manager via pxGrid, and the SD-WAN devices enforce SGT-based policies alongside traditional ZBFW rules. The SD-WAN controller distributes IP-to-SGT mappings via OMP.
SD-WAN Monitoring
Verify inline tagging statistics on SD-WAN routers:
ASR1KX-1#show platform hardware qfp active feature cts datapath stats
Tagged Packets rcv: 883329 xmt: 625925
Def tag: 0 Unknown SGT: 4986 Unknown DGT: 0
Invalid tags (drop): 0 Bad format (drop): 0
No xmt buffer: 0
IPSec SGT tagged packets received: 0
IPSec Invalid SGT tagged packets received: 0
GRE SGT tagged packets received: 0
VXLAN SGT tagged packets received: 0
SGT Multi-Domain Context for Hybrid Work and Remote Access
Hybrid work introduces additional domains where SGT context must be maintained: remote access VPN and cloud-delivered security.
Adding Segmentation to RAVPN
When users connect via AnyConnect to an FTD VPN headend, ISE assigns the SGT during RADIUS AAA. The firewall then enforces SGT-based policy for traffic between RAVPN users and on-premises or cloud resources. For example:
| Source Criteria (SGT) | Destination Criteria (SGT) | Service | Action |
|---|---|---|---|
| IT_Users | Biz_Servers | HTTP | Allow |
| OT_Device | Dev_Servers | HTTPS | Allow |
| Partner | any | TCP | Block |
| any | any | any | Block |
To enable CTS inline tagging on FTD interfaces for RAVPN users:
interface Ethernet1/1
cts manual
propagate sgt
preserve-untag
CTS is disabled by default on all FTD interfaces and must be explicitly enabled depending on your ISE and switch configuration.
ZTNA with Secure Access and SGT
For Zero Trust Network Access, ISE provides static subnet-to-SGT bindings for resource connector regional destination FQDNs or IP addresses via SXP. Resource connectors are supported on AWS and VMware ESXi. The architecture uses DTLS outbound tunnels from resource connectors through a ZTNA proxy and SSE IPsec tunnels to connect remote users to on-premises data center resources.
SSE Context Sharing with SD-WAN
Starting with Catalyst IOS XE 17.15 and Catalyst SD-WAN Manager 20.15, ISE can share SGT namespace and context with Secure Access SSE. The SD-WAN Manager maps VPN-IDs to the context, enabling SGT-based and VPN-ID-based policy decisions at the SSE layer for Internet-bound traffic from branch sites.
SGT Multi-Domain Scaling and Platform Considerations
Memory Usage of IP-to-SGT Bindings
Understanding where IP-to-SGT bindings consume memory is critical for scaling SGT multi-domain deployments. There are three locations:
-
SXP Database (stored in RAM): Contains IP-to-SGT bindings for every peer, including path length and origin SXP Node-ID. Multiple paths can exist for each binding.
-
Role-Based Master (RBM) Database (stored in RAM): A normalized IP-to-SGT binding table used by the data plane. It is possible to have more bindings in the RBM database than the data plane can handle, which is acceptable if the device is only used for SXP relay/aggregation.
-
Data Plane Memory: Stored in TCAM for ASICs, high-speed memory for NPUs, or DRAM/SRAM for CPU forwarding platforms. This is the published scaling number for each platform.
Catalyst 9300 Scaling Example
9300#show platform hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC [0]
Table Max Values Used Values
----------------------------------------------------------------------
SGT_DGT 8192/512 4060/512
Key scaling numbers for the Catalyst 9300:
- SGT/DGT enforcement: 255 prior to 17.1(1), increased to 4K as of 17.1(1)
- IP-SGT bindings: 10K limit officially for the 9300 platform
SXP-to-Inline Tagging Conversion
Using standard SXP configuration, arriving IP packets with an existing IP-to-SGT binding are tagged on the egress interface when inline tagging is configured:
RTR-1#show run | inc sxp
cts sxp enable
cts sxp default source-ip 10.99.1.10
cts sxp default password cisco123
cts sxp connection peer 10.99.10.12 source 10.99.1.10 password default mode local listener
cts sxp connection peer 10.99.10.13 source 10.99.1.10 password default mode local listener
cts sxp connection peer 10.99.188.1 source 10.99.1.10 password default mode local listener
RTR-1#show run int gi0/0/0
interface GigabitEthernet0/0/0
ip address 10.1.46.2 255.255.255.0
negotiation auto
cts manual
policy static sgt 2 trusted
no cts role-based enforcement
cdp enable
Pro Tip: Control plane to data plane conversion (SXP bindings used to tag outgoing inline traffic) happens by default. Data plane to control plane conversion (reading inline SGTs and populating SXP bindings) is supported on routers only.
SGACL Download and CTS Server List
The CTS server list must be defined in ISE when using multiple Policy Service Nodes (PSNs). The switch requests the policy from the first server for the SGT it protects and falls back to the next server when the first one goes down. The default server list only has the Primary PAN name and address. In large environments, use dedicated CTS PSNs or SLB VIPs.
Policy Download Methods
| Method | Introduced | Notes |
|---|---|---|
| RADIUS (UDP) with PAC | ISE 1.0+ / IOS XE 16.12.2+ | Legacy method, requires PAC and TLS 1.0 prior to ISE 3.0P5 |
| TLS 1.2 Client JSON Parsing | ISE 2.7+ / IOS XE 17.1.1+ (switches), 17.6+ (routers) | Reliable transport, no PAC requirement |
| PAC-less RADIUS (UDP) | ISE 3.4+ / IOS XE 17.15+ | Simple RADIUS config without PAC, no TLS 1.0 requirement |
Pro Tip: ISE FIPS mode disables SGT/SGACL/SXP due to certification testing. However, FIPS compliance via audit is possible without enabling ISE FIPS mode.
SGT Multi-Domain Context with ACI Data Centers
ISE 3.4 introduces powerful inbound and outbound SGT Domain rules for ACI integration, supporting multi-ACI, multi-tenant, and multi-VRF environments.
Inbound SGT Domain Rules
Inbound rules define how ISE subscribes to workload information from various domains:
| Rule Name | Logic | Result |
|---|---|---|
| SDA OT Inbound | SGT = PLC & VN = OT | SGT Domain OT |
| ACI Tenant OT Inbound | ACI1 Tenant = OT | SGT Domain OT |
| Global Table | Any | SGT Domain Default |
ISE subscribes to selected ESGs/EPGs in ACI fabric via SGT Domain inbound rules, normalizes them into SGTs, and distributes them to enforcement points.
Outbound SGT Domain Rules
Outbound rules control which SGTs are published to which destinations:
| Rule Name | Logic | Result |
|---|---|---|
| SDA OT Outbound to ACI | SGT Domain OT | ACI1 Tenant OT |
| SDA OT to SXP VRF OT | SGT Domain OT | SXP Peer 1 VRF OT |
| Global Table | Any | Any pxGrid or SXP Listener |
Use Case: On-Prem DC to Colo DC
For on-premises to colocation data center communication, ISE subscribes to ESGs/EPGs in both ACI fabrics via inbound SGT Domain rules. SGTs are sent to the SD-WAN Manager for policy configuration, and IP-to-SGT mappings are sent to the SD-WAN Controller. This supports ACI Multi-Site, Multi-Tenant, and Multi-VRF topologies, with inter-DC communication enforced on SD-WAN routers.
Cloud Workload Classification
ISE cloud connectors gather workload attributes and key/value pairs from multiple clouds. ISE evaluates these attributes and assigns SGTs based on policies, enabling classification of hybrid cloud workloads alongside on-premises ACI and non-fabric environments.
Monitoring and Troubleshooting SGT Multi-Domain Deployments
NETCONF Monitoring
RESTCONF/NETCONF provides programmatic access to SGT binding and memory information:
curl --silent -k -H 'Accept: application/yang-data+json' \
-u admin:Lab@123 \
https://lab.nhprep.com/restconf/data/trustsec-state/cts-rolebased-sgtmaps
This returns JSON with all IP-to-SGT bindings including source type (CLI, local, VLAN, session) and VRF information.
SGACL Logging
SGACL logging provides telemetry on policy enforcement. Support was introduced in IOS XE 16.3 for Catalyst 9K with performance optimizations in 17.3:
*Jan 27 13:33:43.355: %RBM-6-SGACLHIT: ingress_interface='GigabitEthernet1/0/24'
sgacl_name='DenyIP_Log-01' action='Deny' protocol='tcp' src-vrf='default'
src-ip='10.10.18.101' src-port='64382' dest-vrf='default'
dest-ip='10.10.35.201' dest-port='80' sgt='4' dgt='4' logging_interval_hits='1'
Flexible NetFlow for SGACL
Starting with IOS XE 17.13.1, Flexible NetFlow records can capture SGACL permit and deny actions, providing deeper visibility into traffic flows matched by SGT-based policies.
SGACL CoA Push
When an administrator creates new policy in ISE (for example, denying access from SGT Employees to SGT Development_Servers), ISE triggers a Change of Authorization push. The network device downloads the new policy dynamically:
aaa server radius dynamic-author
client 10.200.100.39 server-key 7 01100F175804575D72
client 10.200.100.40 server-key 7 060506324F41584B5
The PAN IP address is used for SGT-related CoA, while PSN IP addresses handle 802.1X/MAB-related CoA.
Frequently Asked Questions
What platforms support SGT classification, propagation, and enforcement?
The supported platform list is extensive and includes Catalyst 9200, 9300, 9300-M, 9400, 9500, and 9600 series switches, Industrial Ethernet 9300/4000/3x00/2000, WLC 9800/8540/5760, Catalyst 8000V/8200/8300/8500 routers, ISR 1000/4000, ASR 1000, ASAv/FTDv, Cisco Secure Firewall 1200/3100/4200, Firepower 1010/1100/2100/4100/9300, ISA 3000, Meraki MS390/MS130X/R, Meraki MR access points (802.11ac wave 2 and Wi-Fi 6), Meraki MX appliances, and ISE.
How does SXPv5 differ from SXPv4 for multi-domain environments?
SXPv4 is not VRF-aware, meaning ISE must peer with every VRF on a particular router if SXP bindings are required in multiple VRFs. A single SXPv5 connection from a router can carry mappings from both VRFs simultaneously, with each binding tagged with its VRF association. This dramatically reduces the number of SXP peering sessions needed in multi-VN deployments.
Why should enforcement be disabled on inter-switch links?
On links between network devices, enforcement should be disabled (no cts role-based enforcement) to prevent issues where traffic to a destination whose SGT is not known at the intermediate switch results in a DGT lookup returning "Unknown." If the default policy is set to deny, this causes legitimate traffic to be dropped before it reaches the proper egress enforcement point.
Can third-party vendors interoperate with SGT?
Yes. All major NGFW vendors are interoperable via pxGrid, SASE/SIG vendors are interoperable via pxGrid, SD-WAN competitors are interoperable via inline tagging and pxGrid, and switching and wireless competitors have implemented SGT. Third-party ASIC vendors also have public documentation of CMD and VXLAN GPO support. SXP and CMD/GRE encapsulations are published as IETF drafts.
What is the relationship between SGT and ISE FIPS mode?
ISE FIPS mode disables SGT, SGACL, and SXP functionality due to certification testing requirements. However, FIPS compliance via audit is achievable without enabling ISE FIPS mode. This is an important distinction for organizations that need both FIPS compliance and SGT-based segmentation.
How does Meraki Adaptive Policy relate to SGT?
Meraki Adaptive Policy uses inline SGTs as the tag mechanism for security policy based on identifying tags rather than IP addresses. It supports all Meraki 802.11ac wave 2 and Wi-Fi 6 MR access points (requires MR27 firmware), all Meraki MS390 switching platforms, and requires an MR Advanced License. Meraki and Catalyst SGT policies can be synchronized through ISE, enabling consistent SGT/SGACL enforcement across mixed Meraki and Catalyst environments.
Conclusion
SGT multi-domain context represents the most scalable and operationally efficient approach to enterprise network segmentation available today. By classifying users, devices, and workloads into business-aligned security groups, propagating that context across campus, branch, SD-WAN, SD-Access, hybrid work, and data center domains, and enforcing consistent policies at every enforcement point, organizations achieve true zero trust segmentation without the operational burden of managing thousands of IP-based ACLs.
Key takeaways from this deep dive:
- Classification happens wherever assets connect -- via RADIUS authentication, static IP-to-SGT mapping, VLAN mapping, cloud connectors, or ACI ESG/EPG integration
- Propagation spans inline data plane methods (CMD, VXLAN, IPsec) and control plane methods (SXP, pxGrid) to carry SGT context across every domain boundary
- Enforcement uses centrally managed SGACLs downloaded dynamically, decoupling security policy from network topology entirely
- ISE 3.4 introduces SGT Domain inbound and outbound rules that enable multi-ACI, multi-tenant, multi-VRF integration at scale
- Open standards including IETF drafts for SXP, CMD, and VXLAN GPO ensure broad third-party interoperability
SGT is the foundation for unified common policy across networking and security domains. Whether you are segmenting IoT devices in a manufacturing facility, enforcing PCI compliance for financial applications, or extending zero trust to remote workers, SGT multi-domain context provides the architecture to do it consistently and at scale.
To deepen your understanding of these concepts and practice the configurations covered in this article, explore the CCIE Security training resources available at nhprep.com.