Macro and Micro Segmentation in SDA
Macro and Micro Segmentation in SDA
Introduction
Segmentation is one of the most critical functions of any modern campus network. Without it, every device on your network can potentially reach every other device, creating a flat attack surface that is difficult to secure and impossible to scale. SD-Access solves this problem through two distinct layers of segmentation: macro segmentation using Virtual Networks and micro segmentation using Security Group Tags.
In this lesson, you will learn:
- What macro segmentation is and how Virtual Networks (VNs) provide complete traffic isolation
- What micro segmentation is and how Security Group Tags (SGTs) enable granular, address-independent policy enforcement
- How SGT classification works through multiple methods including 802.1x, MAB, and static binding
- How the SDA policy model ties VNs and SGTs together to enforce security across wired and wireless clients
- How segmentation extends across domain boundaries into SD-WAN and ACI fabrics
Key Concepts
Macro Segmentation — Virtual Networks
A Virtual Network (VN) is the macro segmentation construct in SD-Access. A VN is fundamentally a VRF — it maintains a completely separate routing table for each instance. Every endpoint placed into a VN can only communicate with other endpoints in the same VN by default. There is no cross-VN communication unless you deliberately introduce a fusion device such as a firewall.
The SDA control plane uses LISP, and each VN is identified by a LISP Instance ID. The default VRF uses Instance ID 4098. On the data plane, VXLAN encapsulation carries a 24-bit VNID in its header to identify the Virtual Network a packet belongs to.
The default policy for macro segmentation is straightforward:
- Within a VN: allow any-to-any communication
- Between VNs: no communication (requires a fusion device)
This makes VNs ideal for separating fundamentally different classes of traffic — for example, corporate users, IoT devices, and guest users.
Micro Segmentation — Security Group Tags
While VNs provide broad isolation, Security Group Tags (SGTs) provide fine-grained control within a VN. An SGT is a 16-bit logical policy object used to group users and devices. Rather than writing access control lists based on IP addresses, SGTs let you build address-independent, group-based policies.
Here is how SGTs work in the forwarding path:
- SDA Edge Nodes add an SGT to the VXLAN fabric encapsulation when a packet enters the fabric
- Edge or Border Nodes use the SGT to enforce local Security Group ACLs (SGACLs)
- SGACLs can permit or deny traffic within a VN based on source and destination SGT pairs
SGTs have two jobs: (1) group the hosts, and (2) enforce policies between groups of hosts. ISE controls the policies, defining how endpoints are assigned to SGTs and whether SGTs can communicate with each other.
Comparing the Two Layers
| Attribute | Macro Segmentation (VN) | Micro Segmentation (SGT) |
|---|---|---|
| Construct | Virtual Network (VRF) | Security Group Tag |
| Scope | Complete routing isolation | Policy enforcement within a VN |
| Default behavior | Any-to-any within VN; no cross-VN traffic | Controlled by SGACLs (permit/deny per SGT pair) |
| Identifier size | 24-bit VNID in VXLAN header | 16-bit SGT in VXLAN header |
| Control plane | LISP Instance ID | ISE policy engine |
| Cross-VN traffic | Requires fusion device | Not applicable — SGTs operate within a VN |
Equivalent Constructs Across Domains
SD-Access is not the only fabric architecture that uses segmentation. Understanding how constructs map across SDA, SD-WAN, and ACI helps when you integrate these domains.
| Function | SDA | SD-WAN | ACI |
|---|---|---|---|
| Management | Catalyst Center | SD-WAN Manager | APIC |
| Control Plane | LISP | OMP | COOP-BGP, IS-IS |
| Data Plane | VXLAN | IPSec / MPLS | iVXLAN |
| Macro Segment | VN (Infra VN in GRT + User VNs) | VPN (VN 512 OOB + VN #) | VRF + Tenant |
| Micro Segment | SGT (Security Group Tag) | Carries SGT | EPG / ESG (End Point Groups) |
| Underlay basis | RLOC (GRT) | TLOC (VN 0) | VTEP |
How It Works
SGT Classification Methods
Before an SGT can be enforced, endpoints must be classified — that is, assigned to an SGT. ISE supports several classification methods:
- 802.1x: The endpoint authenticates using a supplicant with certificates, username/password, or other EAP methods. ISE assigns the SGT based on the authentication result and authorization policy.
- MAB (MAC Authentication Bypass): For devices that cannot run a supplicant, the switch sends the MAC address to ISE, which assigns an SGT based on the known MAC.
- Web Authentication: Users authenticate through a captive portal, and ISE assigns the appropriate SGT.
- PassiveID (Active Directory): ISE integrates with Active Directory to learn user-to-IP mappings passively without requiring 802.1x.
In addition to dynamic methods, static SGT binding is available:
- By port
- By VLAN
- By IP subnet
- By IP address
These static methods are useful for infrastructure devices or servers that do not participate in 802.1x.
The SDA Policy Model
The SDA policy model draws a parallel to ACI. An SDA fabric site is comparable to an ACI tenant. A Virtual Network maps to a VRF, an IP pool with an anycast gateway maps to a bridge domain and subnet, and an SGT maps to an EPG — a group of hosts.
A key design principle is that a single IP pool can contain multiple SGTs. For example, a global IP pool such as 22.2.144.0/22 can be assigned to a Virtual Network, and within that pool, endpoints are classified into different SGTs like "vip," "isolated," or "branchuser1." Contracts (SGACLs) between these SGTs define what traffic is permitted or denied.
Important: There is no difference in how SGT policies apply to WiFi or wired clients. ISE enforces the same policies regardless of the access medium.
The default SGT policy model is a default permit model — SGT policies function as more intelligent access lists without requiring a firewall. You define specific deny rules between SGT pairs that should not communicate, while everything else is allowed. This can be inverted to a default deny model depending on your security posture.
SGT Propagation Across Domains
One of the most powerful aspects of SGT-based segmentation is that it travels across domain boundaries.
SDA to SD-WAN propagation:
- Inside the SDA fabric, the SGT rides in the VXLAN header (16 bits) alongside the VNID (24 bits)
- At the SDA Border, the SGT is placed into the CMD (Cisco Metadata) header on the Ethernet frame
- The SD-WAN Edge reads the SGT from the Ethernet CMD header and transfers it into the IPSec header
- The SGT is carried across the WAN transport to remote SD-Access sites
- At the remote site, the process reverses — IPSec header to CMD header to VXLAN header
SDA to ACI propagation:
- ISE uses REST API and pxGrid connections to APIC to retrieve and share security context
- Granular control determines which SGTs are pushed to ACI and to which tenants
- Granular control also determines which EPGs or ESGs are pushed from ACI back to ISE
- Policy enforcement can occur in the campus, in the datacenter, or on a transit firewall
- Multiple fabrics, multiple tenants/VRFs, and multiple L3Outs are supported for policy enforcement on ACI
Configuration Example
SDA and SD-WAN Domain Integration
When connecting SDA to SD-WAN, VRF-Lite is used on the handoff interfaces between the SDA Border and the SD-WAN Edge. Each SDA Virtual Network maps to a dedicated SD-WAN Service VPN.
| SDA Virtual Network | SD-WAN Service VPN |
|---|---|
| Infra VN (Underlay) | Service VPN 10 |
| Campus VN | Service VPN 20 |
| Guest VN | Service VPN 30 |
The integration has three planes:
Control Plane Integration: BGP peering is automated for each VN/VRF on the handoff interfaces. Prefixes learned via BGP on the SD-WAN Edge and SDA Border are redistributed into OMP and LISP respectively using a 1:1 mapping of a dedicated service VPN for each fabric VN.
Data Plane Integration: Separate 802.1Q encapsulation sub-interfaces are created for every VRF using VRF-Lite to extend connectivity between the two domains.
Policy Plane Integration: The SGT from the VXLAN header is placed into the CMD header on the Ethernet frame, then transferred from the CMD header into the IPSec header, and carried end-to-end across the WAN.
Best Practice: The SDA fabric underlay, which is part of the Global Routing Table (GRT), should be mapped to a dedicated Service VPN on the WAN Edge.
Best Practice: Ensure the same MTU is configured on both ends for all interfaces and sub-interfaces connecting the SDA Border and SD-WAN Edge.
Warning: Validate platform support for inline tagging on both the SDA Border and the SD-WAN Edge, as well as any interim node in the path. Not all platforms support CMD inline tagging.
Inline Tagging Header Details
Understanding the header structure helps when troubleshooting segmentation across domains:
| Header Type | Field | Size |
|---|---|---|
| VXLAN Header | VNID | 24 bits |
| VXLAN Header | SGT | 16 bits |
| Ethernet 802.1Q | VLAN ID | 12 bits |
| CMD (Cisco Metadata) | SGT | 16 bits |
| MPLS Labels | VPN | 20 bits |
| IPSec Header | SGT (via CMD) | 16 bits |
Real-World Application
Campus Segmentation Design
A typical campus deployment uses three or more Virtual Networks:
- Campus VN: Corporate users and managed devices
- IoT VN: Sensors, building management systems, and unmanaged devices
- Guest VN: Visitor internet access with no internal resource visibility
Within the Campus VN, SGTs provide granular control. For example, you might define SGTs for executives, finance, engineering, and contractors. SGACLs between these groups enforce policies such as preventing contractors from reaching finance servers, without writing a single IP-based ACL.
Multi-Site Segmentation with SD-WAN
When your campus extends across multiple sites connected by SD-WAN, the SGT propagation through CMD and IPSec headers means your micro segmentation policy is consistent everywhere. A user classified as SGT 17 at one site is recognized as SGT 17 at every other site. This eliminates the need to duplicate ACLs at each branch.
Datacenter Integration with ACI
For organizations running ACI in the datacenter, the ISE-to-APIC integration via REST API and pxGrid means your campus SGTs can map to datacenter EPGs. Policy enforcement can happen at whichever boundary makes the most sense — the campus edge, the datacenter leaf, or a transit firewall in between.
Summary
- Macro segmentation through Virtual Networks (VNs) provides complete routing isolation between network segments. Each VN is a separate VRF with its own LISP Instance ID and VXLAN VNID. Cross-VN traffic requires a fusion device.
- Micro segmentation through Security Group Tags (SGTs) enables address-independent, group-based policy enforcement within a VN. SGACLs on edge and border nodes permit or deny traffic based on source and destination SGT pairs.
- SGT classification can be dynamic (802.1x, MAB, Web Auth, PassiveID) or static (by port, VLAN, subnet, or IP address), all managed through ISE.
- Cross-domain SGT propagation preserves micro segmentation policy across SD-WAN (via CMD and IPSec headers) and ACI (via REST API and pxGrid integration with APIC).
- SDA-to-SD-WAN integration uses VRF-Lite with 802.1Q sub-interfaces on handoff links, automated BGP peering for control plane, and inline tagging for policy plane continuity.
In the next lesson, we will explore fabric operations and troubleshooting techniques to verify that your segmentation policies are working as expected across the SD-Access fabric.