Segmentation is the entire reason most organisations buy SD-Access. Not the automation, not the roaming - the ability to say "guests cannot reach the finance systems, IoT devices cannot reach each other, and contractors only touch the two applications they need" and have it enforced consistently everywhere, without maintaining a thousand ACLs. SD-Access does this in two layers, and understanding the difference between them is understanding SD-Access segmentation.
This article covers macro-segmentation (virtual networks) and micro-segmentation (SGTs). It is a concept piece - the policy is authored in Cisco Catalyst Center and ISE - but the underlying TrustSec/SGT technology is real and PingLabz has captured it standalone. For the wider context, see the network virtualization pillar.
Two layers, two questions
Mechanism: the virtual network (VN) - a separate VRF and routing table, mapped to a VXLAN VNI. Total isolation. Traffic in one VN cannot reach another VN except through a controlled leak point (the fusion router).
Analogy: different buildings. You are in the Employees building or the Guests building, and the buildings do not connect except through a guarded lobby.
Mechanism: the Scalable Group Tag (SGT) - a tag on every packet, with policy (SGACLs) deciding which groups can talk to which. Fine-grained, within a VN.
Analogy: rooms within a building. Everyone is in the same building (VN), but your badge (SGT) only opens certain doors.
The mental model that makes this click: a virtual network is a building; an SGT is a badge that controls which rooms you can enter within it. You use both - macro to separate broad trust domains completely, micro to control who talks to whom inside a domain.
Macro: virtual networks
A virtual network is a complete routing separation. Employees, Guests, IoT, and Building-Management might each be their own VN. Each is a VRF on the fabric, mapped to its own VXLAN VNI, with its own routing table. Traffic cannot cross between VNs at all - not filtered, not restricted, but genuinely separate, the same way two customers' VRFs in an MPLS L3VPN are separate.
When two VNs do need to communicate (say, IoT devices need to reach a shared DNS server), the traffic goes out to the fusion router at the border, which leaks the specific routes between the VRFs. This is deliberate: cross-VN communication requires an explicit, auditable route leak, not a rule someone forgot about. VRF route-leaking is standard, real technology PingLabz has captured.
The design guidance: use few, broad VNs. A VN is heavyweight - it is a whole VRF, a whole routing table, a whole segment to manage. You do not want dozens. Employees, Guests, IoT, and maybe Building-Management is a typical set. Finer distinctions belong to SGTs, not VNs.
Micro: scalable group tags
Within a VN, you rarely want everyone talking to everyone. Employees and Employees-Contractors might share the Employees VN but need different access. IoT cameras and IoT sensors might share the IoT VN but should not talk to each other at all. That is micro-segmentation, and it uses SGTs.
An SGT is a 16-bit tag assigned to an endpoint at onboarding (by ISE, based on identity) and carried in every packet. Policy is expressed as a matrix: source SGT × destination SGT → permit or deny, enforced by SGACLs. The beauty is that it is topology-independent - the policy is "Contractors cannot reach Finance-Servers", not "10.1.5.0/24 cannot reach 10.2.9.0/24". Renumber, move, roam - the policy holds because it follows the tag, not the address.
The SGT is real and PingLabz has captured it
SGTs and TrustSec are not SD-Access-specific - they predate it and run on standalone IOS XE. From the real TrustSec/802.1X captures on the site, an endpoint carrying its assigned SGT:
Switch# show cts role-based sgt-map all
Active IPv4-SGT Bindings Information
IP Address SGT Source
============================================
10.1.10.50 10 LOCAL (Employees)
10.1.10.60 20 LOCAL (Contractors)
10.1.20.30 30 LOCAL (IoT-Cameras)
Switch# show cts role-based permissions
IPv4 Role-based permissions from group 20:Contractors to group 100:Finance-Servers:
Deny IP-00That last block is micro-segmentation in action: a policy denying Contractors (SGT 20) from reaching Finance-Servers (SGT 100), enforced regardless of IP address or location. This is real TrustSec, captured on IOS XE, and it is exactly the enforcement mechanism SD-Access uses - the difference is only that Catalyst Center and ISE author and distribute the policy centrally instead of you configuring the SGACL by hand.
How the SGT travels in the fabric
Inside the fabric, the SGT rides in the VXLAN header (SD-Access uses VXLAN-GPO, which has a field for the group tag). So the tag is carried with the packet across the entire fabric, and the destination edge node enforces the SGACL at egress. The endpoint's group membership follows it everywhere, and enforcement happens as close to the destination as possible.
The one place the SGT can be lost is at an IP-transit border handoff - plain IP transit does not carry the SGT past the border unless you extend TrustSec to the next device (via SXP, which propagates IP-to-SGT bindings, or inline tagging on a capable link). This is the segmentation consequence of the border-handoff choice covered in the border handoff article: SDA transit preserves the SGT end to end, IP transit does not by default.
Using both together
A worked example makes the two-layer model concrete:
- Employees VN (macro): contains Employees (SGT 10) and Contractors (SGT 20). Micro-policy: Contractors can reach the two applications they need and nothing else; Employees have broader access. Both are in the same building; different badges.
- IoT VN (macro): completely isolated from Employees at the VN level - an IoT device cannot even route to an employee subnet. Within IoT, micro-policy stops cameras (SGT 30) talking to sensors (SGT 31), limiting lateral movement if one is compromised.
- Guests VN (macro): isolated from everything internal; can only reach the internet via the border. No SGT policy needed beyond "guests reach the door and nothing else".
The rule of thumb: macro-segment by broad trust domain, micro-segment within it. Use a handful of VNs for the fundamental separations, and SGTs for the fine-grained, identity-driven policy inside each. This keeps the VN count low (manageable) and pushes the complexity into SGT policy (topology-independent and centrally managed).
What needs the controller, and what does not
- Needs Catalyst Center + ISE: defining VNs, authoring the SGT policy matrix, distributing SGACLs, mapping identities to SGTs, the centralised policy administration.
- Real and standalone: TrustSec/SGT enforcement itself (SGACLs,
show cts role-based, SGT-in-packet), captured on IOS XE. VRF separation (the macro mechanism) is standard VRF technology, also captured. The fusion-router route leak between VNs is plain VRF route-leaking.
Every enforcement mechanism SD-Access segmentation uses is real technology PingLabz has captured. What Catalyst Center adds is the central authoring and distribution of the policy - turning "configure this SGACL on every switch" into "draw the matrix once". We describe the orchestration honestly and point to the real TrustSec captures for the mechanism.
Key takeaways
- SD-Access segments in two layers: macro (virtual networks - separate VRFs, total isolation) and micro (SGTs - fine-grained policy within a VN).
- The model: a VN is a building; an SGT is a badge controlling which rooms you enter within it. Use both.
- VNs are heavyweight (a whole VRF each) - use few, broad ones. Cross-VN traffic requires an explicit route leak at the fusion router.
- SGTs are topology-independent - the policy is "Contractors cannot reach Finance", not an IP-based ACL. It follows the endpoint everywhere.
- The SGT rides in the VXLAN header across the fabric. It is preserved end-to-end over SDA transit but dropped at an IP-transit border unless you extend TrustSec.
- TrustSec/SGT enforcement and VRF separation are real, standalone-captured technology; Catalyst Center + ISE provide the central policy authoring. We are clear which is which.
Next: SD-Access design questions - where fabrics fit and where they don't. The full cluster index lives on the network virtualization pillar, cross-linked to 802.1X and TrustSec.
