SGT Propagation Across Fabric

Objective

In this lesson you will learn how Security Group Tags (SGTs) propagate across a fabric using inline tagging and SXP. You will understand the differences between transporting SGTs in-band (inline tagging) versus exchanging IP→SGT bindings out-of-band (SXP), when each method is appropriate in production, and how SGTs are propagated across domains such as SDA fabrics and SD‑WAN edges. Real-world context: many large enterprises replace SXP at remote sites with inline tagging and SD‑WAN propagation to avoid TCAM exhaustion and scale issues while maintaining consistent group-based policy enforcement across campuses and branches.

Quick Recap

This lesson continues from the topology introduced in Lesson 1. No new physical devices or IP addresses are added in this lesson. We reuse the same fabric components (SDA Border Nodes, SD‑WAN WAN Edges, data center Catalyst 9500s and branch switches). The following SGTs and VLANs are referenced exactly as in the source material:

• SGT values: 900, 950, 4, 5
• VLANs: Employee VLAN 120 (SGT = 4), IoT Dashboard VLAN 180 (SGT = 5)
• Platforms: SDA Border Nodes, SD‑WAN WAN Edge1 (SGT: 900), WAN Edge2 (SGT: 900), Catalyst 9500s, 9K platforms

ASCII topology (logical, showing exactly the SGTs and VLAN identifiers from the reference):

                 +---------------------------+
                 |        Data Center        |
                 |  Catalyst 9500 (tagging) |
                 |  SGT: (tags unknown north)|
                 +---------------------------+
                           |
                           | (Fabric VXLAN - SDA Border Nodes carry SGT inline)
                           |
   Campus Fabric ----- SDA Border Node ----- SD-WAN WAN Edge1 (SGT: 900)
   (Employee VLAN 120  SGT=4)                 |
   (IoT VLAN 180 SGT=5)                       |
                                              |
                                         SD-WAN Fabric
                                              |
                                         SD-WAN WAN Edge2 (SGT: 900)
                                              |
                                         Remote Branch / 9K switches
                                         (Legacy SXP may have been used here)

Note: The topology emphasizes SGT propagation points and exact SGT values from the reference material. No additional IP addresses or interface names are added.

Key Concepts (theory + practical implications)

Before touching configurations, understand these core behaviors and why they matter.

• Inline SGT Tagging (in-band propagation):

  • Theory: SGT is carried inside the packet (for example, within an encapsulation header such as VXLAN when the fabric supports it) so the destination device receives the tag directly and can enforce SG‑ACLs at the point of egress.
  • Practical: Use inline tagging between SDA Border Nodes and SD‑WAN routers to transport SGTs across sites; this avoids reliance on out-of-band mapping services and places enforcement at the destination.

• SXP (Security eXchange Protocol) — out-of-band binding exchange:

  • Theory: SXP distributes IP→SGT bindings from the Identity Service (ISE) to devices that cannot carry SGT inline. Devices then use these mappings to tag or enforce policy.
  • Practical: SXP scales poorly on large numbers of SXP connections and can lead to TCAM exhaustion on platforms like the 9K family if the full matrix is downloaded. In production, SXP is a fallback for legacy devices or third‑party firewalls.

• Why scale and TCAM matter:

  • Theory: When SXP shares the full matrix to enforcement devices, each binding consumes TCAM or other hardware resources.
  • Practical: In a large rollout, hundreds or thousands of SXP connections can destabilize update distribution and exhaust platform capabilities. This is the primary reason to prioritize inline tagging where possible, and to decommission SXP at remote SDA sites.

• Cross-domain propagation with SD‑WAN and SDA:

  • Theory: SD‑WAN can propagate SGTs natively across tunnel/transport mechanisms (for example, in the encapsulation used by the WAN fabric).
  • Practical: By enabling SGT propagation on SD‑WAN WAN edges (SD‑WAN WAN Edge1/2), SGTs travel end‑to‑end across the WAN, enabling consistent group-based enforcement at remote sites and data centers.

• Static IP→SGT mappings and unknown traffic:

  • Theory: Static mappings can be used to tag traffic when dynamic mapping is unavailable. Also, devices like Catalyst 9500s can tag traffic originating from third‑party firewalls using IP→SGT mappings learned via SXP.
  • Practical: During migration from SXP to inline tagging, deploy static IP‑SGT mappings to avoid an immediate network-wide deny when policies default to deny.

Analogy: Think of inline tagging like writing a user's group on the envelope that travels with the letter; SXP is like keeping a central address book that every router must consult to know which letter belongs to which group.

Step-by-step configuration

Each step below follows the required pattern: what we are doing, commands, what just happened, a real‑world note, and verification commands with expected output. Because this lesson focuses on propagation methods and planning, steps are configuration‑conceptual and verification uses platform show commands illustrating SGT state. All SGT values and VLAN numbers used are taken from the reference material.

Step 1: Enable inline SGT propagation on SDA Border Nodes

What we are doing: Configure the fabric border nodes to transport SGTs in the VXLAN header so that SGTs are preserved across the fabric and to SD‑WAN connected edges. Inline propagation ensures the tag arrives at the enforcement point without requiring SXP.

configure terminal
! Enable SGT inline propagation (fabric / VXLAN SGT transport)
! (Example configuration concept showing enabling TrustSec/VXLAN SGT transport)
fabric border-node trustsec inline-tagging enable
exit
write memory

What just happened: The command set enables inline SGT propagation on the fabric border nodes. From a protocol perspective, the border node will now include the SGT value inside the fabric encapsulation (VXLAN or similar) so downstream devices that understand the encapsulation can extract the SGT and enforce SG‑ACLs.

Real-world note: Inline tagging within the fabric is preferred because it avoids filling enforcement TCAMs through distribution of the entire IP→SGT matrix.

Verify:

show trustsec inline status
Inline Tagging: Enabled
Transport Mechanism: VXLAN
Border Nodes: SDA-Border-Node-1
Active SGTs: 4, 5, 900, 950

Step 2: Enable SGT propagation on SD‑WAN WAN Edge routers (Inline)

What we are doing: Configure the SD‑WAN WAN Edge devices to accept and forward SGTs in the tunnel/transport so that SGTs travel end‑to‑end across the SD‑WAN fabric (SD‑WAN WAN Edge1 and WAN Edge2 use SGT: 900 per the reference).

configure terminal
! Enable SGT propagation on SD-WAN WAN Edge interfaces
sdwan edge trustsec propagate-sgt enable
exit
write memory

What just happened: The SD‑WAN edges are instructed to carry SGTs in their encapsulation and to preserve SGTs on the tunnel. This makes SGT: 900 available across both WAN Edge1 and WAN Edge2 and allows downstream branch devices to receive the SGT inline.

Real-world note: SD‑WAN provides automation and native SGT support; use it to avoid SXP at remote sites and leverage centralized SD‑WAN management for consistent propagation.

Verify:

show sdwan edge trustsec status
SD-WAN Edge: WAN-Edge1
TrustSec Inline Propagation: Enabled
Local SGT: 900
Remote Peers: WAN-Edge2 (SGT: 900)
Active VXLAN/VPNs carrying SGT: VPN0, VPN1

Step 3: Decommission SXP at remote SDA sites (plan and apply)

What we are doing: Remove reliance on SXP at remote SDA/branch sites after inline propagation is established. This prevents excessive SXP connections that may lead to TCAM exhaustion and stability issues on 9K platforms.

configure terminal
! Disable SXP client at branch switch to stop pulling full matrix
no sxp enable
exit
write memory

What just happened: The branch device stops participating as an SXP client and will not download the full IP→SGT matrix. Enforcement is now expected to rely on inline tags carried over SD‑WAN and the fabric, rather than on SXP mappings.

Real-world note: Decommissioning SXP is a critical migration step — ensure inline tagging is validated end‑to‑end before removing SXP to avoid traffic disruption.

Verify:

show sxp status
SXP Service: Disabled
SXP Peer Connections: 0
Notes: SXP decommissioned at this site to avoid TCAM and scale issues

Step 4: Configure static IP→SGT mappings for unknown or legacy north/south traffic

What we are doing: Add static IP→SGT mappings on enforcement devices (for example, data center 9500s) to tag traffic coming from third‑party firewalls or legacy devices. Static mappings prevent untagged north/south flows from being dropped when default matrix behavior is deny.

configure terminal
! Create static IP to SGT mapping for a critical server/netblock
cts manual ip 192.0.2.10 sgt 950
cts manual ip 198.51.100.0/24 sgt 900
exit
write memory

What just happened: The enforcement device now maps the specified IP addresses/netblocks to the listed SGTs. This ensures that traffic from these IPs is treated with the correct SGT for policy evaluation, useful when traffic arrives from non-TrustSec-aware firewalls.

Real-world note: Use static mappings selectively — use for known, stable endpoints (servers, third‑party firewall exit IPs) during migration to inline tagging. Overuse may reintroduce scale issues.

Verify:

show cts manual
Manual IP to SGT mappings:
IP Address         SGT
192.0.2.10         950
198.51.100.0/24    900

Step 5: Verify end-to-end SGT propagation and enforcement

What we are doing: Validate that SGTs assigned in campus VLANs (Employee VLAN 120 → SGT 4; IoT VLAN 180 → SGT 5) are visible and enforced at remote sites and the data center.

! Verify campus switch local tagging
show port vlan 120 trustsec
VLAN 120 SGT: 4

show port vlan 180 trustsec
VLAN 180 SGT: 5

! Verify SD-WAN edge sees SGTs
show sdwan edge trustsec sgt-table
SGT Table:
SGT 4 -> Source: Campus VLAN 120
SGT 5 -> Source: Campus VLAN 180
SGT 900 -> Local Edge Tag

! Verify data center enforcement sees tags (via hardware tagging or SXP fallback)
show trustsec sgt-usage
SGT 4: active
SGT 5: active
SGT 900: active
SGT 950: active

What just happened: Your verification confirms VLANs are tied to SGTs locally, SD‑WAN edges are propagating SGTs, and the data center enforcement plane sees the propagated SGTs. This indicates end-to-end tagging and enforcement are functional.

Real-world note: Always test policy enforcement with real traffic flows and test accounts; verify audit logs in tools such as Cisco Secure Network Analytics to validate that SGTs are applied correctly.

Verification Checklist

• Check 1: Campus VLANs are associated with the correct SGTs — verify with show port vlan 120 trustsec and show port vlan 180 trustsec.
• Check 2: SD‑WAN WAN edges propagate inline SGTs — verify with show sdwan edge trustsec status and show sdwan edge trustsec sgt-table.
• Check 3: Data center Catalyst 9500s see or tag north/south traffic via IP→SGT mappings — verify with show cts manual and show trustsec sgt-usage.

Common Mistakes

Symptom	Cause	Fix
SGTs not visible at remote branch	Inline tagging not enabled on SDA border nodes or SD‑WAN edges	Enable inline SGT propagation on SDA border nodes and SD‑WAN edges and re-verify show trustsec inline status
TCAM exhaustion or high CPU on 9K devices	Too many SXP connections causing full matrix downloads	Decommission SXP at remote sites and enable inline tagging; use static mappings only when necessary
Traffic from third‑party firewall arrives untagged and is denied	Firewall cannot tag packets and no IP→SGT mapping exists on the data center switch	Create static IP→SGT mapping on Catalyst 9500s (e.g., cts manual ip <ip> sgt <value>) while migration completes
After disabling SXP, traffic is dropped	Inline tagging not verified end-to-end before SXP removal	Re-enable SXP temporarily, validate inline tags end-to-end, then remove SXP after validation; use static mappings to bridge during cutover

Key Takeaways

• Inline SGT tagging is the preferred method for transporting identity (SGT) across fabrics because it preserves the tag end‑to‑end and reduces reliance on large out‑of‑band binding distributions that can exhaust TCAM.
• SXP is useful for legacy devices or third‑party firewalls, but it does not scale well in very large deployments; plan to decommission SXP at remote SDA sites in favor of inline propagation where possible.
• SD‑WAN can natively carry SGTs across the WAN fabric — leveraging SD‑WAN for SGT transport simplifies large‑scale deployments and reduces per‑device SXP connections.
• Use static IP→SGT mappings sparingly during migration to prevent a network-wide deny while you validate inline tagging; always plan cutovers to avoid sudden policy enforcement failures.

Final practical insight: In production, architect your TrustSec rollout to the capabilities of your weakest enforcement point. Start with inline propagation where possible, use SD‑WAN to bridge domains, and only rely on SXP or static mappings for legacy constraints — this minimizes TCAM pressure and increases stability.