Core: Network Virtualization

Infrastructure segmentation

Miro Kosut

Miro Kosut

— 8 min read
Share

Requirement / business driver

Isolate tenants / security zones / traffic at the right plane and scale - from basic L2 separation to scalable identity-based microsegmentation.

Options

  • VLAN - L2 broadcast-domain separation.
  • PVLAN - sub-segmentation inside a VLAN (isolated/community ports).
  • VRF-Lite - L3 routing-table separation, configured per hop.
  • SGT / TrustSec - policy/identity tag carried with traffic, enforced anywhere.

Comparison

segmentation-matrix

Tradeoffs

VLAN is basic L2; PVLAN isolates ports within one subnet (DMZ/hosting); VRF-Lite doesn't scale because it's hop-by-hop - scale L3 separation with MPLS-VPN or VXLAN/EVPN instead; SGT scales as a group tag independent of topology and integrates with ISE for macro/microsegmentation.

Recommendation / justification

Combine planes: VLAN/VRF for structure, and SGT for scalable policy/microsegmentation; when L3 separation must scale beyond a few hops, use MPLS L3VPN or VXLAN/EVPN rather than stretching VRF-Lite. Justify by the number of segments and whether policy must follow identity end-to-end.

SD-Access (SD-LAN)

Software-defined campus ("SD-LAN") separates a data plane, control plane, and policy plane so segmentation and policy are independent of the physical topology. Cisco's realisation, SD-Access, builds a campus fabric with a LISP control plane (endpoint ID/location mapping), a VXLAN data plane (Overlays and BGP EVPN), and ISE for policy. Segmentation is two-tier: macro-segmentation via virtual networks (VNs = VRFs) and micro-segmentation via SGTs (Network access control and segmentation - NAC, TrustSec, guest and BYOD). Fabric roles: edge nodes (access), border nodes (fabric-to-external), and control-plane nodes (the LISP map server/resolver).

Network virtualization end to end: device, path, service

Segmentation on one box is only the start; carrying it across the campus and WAN is the real design. The model has three layers. Device virtualization separates control/forwarding on a single node (VRFs, contexts). Path isolation carries that separation between nodes by one of three techniques: VRF-Lite hop-by-hop (every device in the path needs the VRF and a sub-interface per segment - simple but does not scale and is operationally heavy), MPLS L3VPN (the label stack carries many VRFs with no per-hop config in the core - scales best), or a tunnelled overlay (multi-hop GRE/DMVPN per VRF, or VXLAN/EVPN - VRFs ride tunnels over any underlay). Service virtualization then offers per-segment services (virtual firewall contexts, per-VN inspection). The decisive WAN choice is coordinated/dependent vs independent: coordinated path isolation depends on the transport/provider (MPLS L3VPN - the SP carries your VRFs, so you inherit their reach and SLA but are tied to that service), whereas independent path isolation is self-deployed over any transport (VRF-Lite, or GRE/DMVPN/VXLAN tunnels you run yourself - transport-agnostic and provider-independent, at the cost of operating the overlay). Choose coordinated when you already buy MPLS and want the SP to carry separation; choose independent when you must stay transport-agnostic (internet/hybrid WAN, multi-provider) or avoid provider lock-in (MPLS L3VPN and L2VPN, Tunneling technology selection).

Separation is not confidentiality

Segmentation isolates; it does not conceal. A VLAN tag, VRF, VNID, or SGT is not encryption - anyone with access to the transit path can still read the payload, and a virtual circuit across a public or provider network is barely more private than sending the traffic natively. Split the requirement in two: separation (no cross-talk between tenants or communities - what segmentation delivers) vs confidentiality (protection from whoever carries or taps the path - which needs MACsec/IPsec/TLS on top, chosen by asking is the data confidential, and is there an insider threat on the transit?). Scenario trap: an SLA that promises customer privacy is asking for both, not for segmentation alone (Security design fundamentals - CIA and defense in depth).

Carrying the tag - inline SGT vs SXP, and where to enforce

Group-based policy stands on two transports. Inline (native) tagging writes the SGT into a Cisco MetaData field of the Layer 2 frame (~20 bytes on the wire, invisible to the IP MTU and fragmentation budget), so it must be supported by the hardware on every hop that carries it - and because the tag is a policy input, protect it hop-by-hop with MACsec (MACsec and secure transport). The carrier list is a tunnel-selection fact: Ethernet and MACsec links, and IPsec, DMVPN, and GET-VPN tunnels all carry the CMD field, while LISP and VXLAN have native SGT bits in their headers - so the overlay chosen in Tunneling technology selection largely decides whether identity crosses the WAN in the packet or must be rebuilt beyond it via SXP. Where a hop cannot carry it - a WAN, a brownfield core, a non-participating firewall - SXP bridges the gap: a BGP-like TCP peering (speaker -> listener) that distributes IP-to-SGT bindings instead of tagged frames, so a downstream device can re-tag or enforce with full knowledge of who is who. SXP's second use is deliberate: with inline tagging only the destination edge knows both source and destination tags, so a deny executes after the traffic has already crossed the network - SXP-feeding a campus/branch core creates a strategic enforcement point where policy drops traffic before it burns WAN capacity. Enforcement itself is the SGACL matrix on switches/routers (or a group-aware firewall), and the matrix is the scale ceiling to watch: policy cells grow with the square of the group count, which is why group design stays coarse (Network access control and segmentation - NAC, TrustSec, guest and BYOD).

The version of the SXP peering becomes a scaling decision once the fabric is virtualised. The ladder: v2 added IPv6 bindings, v3 subnet-to-SGT bindings, v4 loop detection and built-in keepalives - and all of them are VRF-blind, so a border exporting bindings for many virtual networks runs one SXP connection per VN. SXPv5 makes the peering VN-aware: bindings carry their VRF context and a single connection transports all VNs - session count at the border stops scaling with the segmentation design. Until the policy engine itself speaks v5, the interim pattern is an SXP reflector: a switch terminates the per-VN v4 sessions from ISE on one side and re-advertises the aggregate over one v5 session on the other - a binding route-reflector in all but name.

Where enforcement lands is equally mechanical: the drop happens on the first device along the path that simultaneously holds the source binding, the destination binding, enforcement enabled on that platform and VLAN, and the policy. Only the destination edge reliably knows the destination binding, which makes egress the default - and the economical one, because each enforcement point downloads only the SGACLs matching the bindings it holds: per-NAD policy state scales with locally attached destinations, not with the whole matrix. The capacity anchors make the same point in numbers: a deployment plans around 4000 SGTs and 64-256 VNs per site at the controller and matrix level, but access-class hardware enforces on the order of 255 unique destination groups locally - comfortably enough at an edge, which sees few destination groups, and exactly what breaks when enforcement moves to a border that imports the DC and cloud side's full group diversity. Two postures to set explicitly: traffic arriving as SGT 0 (unknown) hits the default entry, so the unknown-tag action is a migration decision (permit while classification coverage grows -> deny at steady state); and SGACLs have their own monitor mode - count matches without dropping - the staged-enforcement rung for every brownfield rollout (Network access control and segmentation - NAC, TrustSec, guest and BYOD).

What would change this (mid-scenario twist)

  • Segment count grows beyond a handful of hops -> MPLS-VPN or VXLAN/EVPN.
  • Policy must follow users/devices regardless of topology -> SGT/TrustSec.

Validation checks

  • Does the segmentation propagate correctly across devices (trunks, MP-BGP, or SXP/inline tagging)?
  • Does it scale to the required tenant/segment count without per-hop sprawl?

IPv6 / dual-stack note

VRFs and SGTs are address-family agnostic; ensure v6 is segmented identically (RA/ND within the right segment).

Spaced repetition

Why does VRF-Lite not scale, and what do you use instead for many L3 segments?

It is configured hop-by-hop; scale L3 separation with MPLS L3VPN or VXLAN/EVPN.

The segmentation method that follows identity end-to-end as a tag, independent of topology, is [...].

The segmentation method that follows identity end-to-end as a tag, independent of topology, is SGT / TrustSec.

PVLAN provides isolation [...] (e.g., isolated ports in a DMZ).

PVLAN provides isolation within a single VLAN/subnet (e.g., isolated ports in a DMZ).

What is SD-Access (SD-LAN) built from?

A campus fabric with a LISP control plane, VXLAN data plane, and ISE policy; macro-segmentation via virtual networks (VRFs) and micro-segmentation via SGTs; roles = edge, border, control-plane nodes.

Name the three layers of end-to-end network virtualization and the three path-isolation techniques.

Device virtualization (VRFs/contexts on a node), path isolation (carrying it between nodes), and service virtualization (per-segment services). Path isolation is done by VRF-Lite hop-by-hop, MPLS L3VPN, or a tunnelled overlay (GRE/DMVPN per VRF, or VXLAN/EVPN).

Coordinated/dependent vs independent path isolation - difference and when each?

Coordinated depends on the transport/provider (MPLS L3VPN carries your VRFs - SP reach/SLA but tied to that service); independent is self-deployed over any transport (VRF-Lite or GRE/DMVPN/VXLAN - transport-agnostic, provider-independent, but you run the overlay). Use coordinated when you already buy MPLS; independent for internet/hybrid/multi-provider or to avoid lock-in.

A customer SLA promises 'privacy' between tenants - is a VRF per tenant enough?

No - segmentation delivers separation (no cross-talk), but a tag is not encryption; confidentiality against whoever carries or taps the transit additionally needs MACsec/IPsec/TLS.

When does SGT propagation need SXP instead of inline tagging?

Inline tagging carries the SGT in the L2 frame and needs hardware support on every hop (protect it with MACsec); SXP is a BGP-like TCP peering distributing IP-to-SGT bindings across non-participating gaps - WAN, brownfield, firewalls - so devices beyond the gap can re-tag or enforce.

With inline tagging only the destination edge knows both tags, so [...]; the SGACL matrix scales with [...], keeping group design coarse.

With inline tagging only the destination edge knows both tags, so SXP-feeding a campus/branch core creates a strategic enforcement point that drops denied traffic before the WAN; the SGACL matrix scales with the square of the group count, keeping group design coarse.

What does SXPv5 change at a multi-VN fabric border, and what bridges the gap until then?

The peering becomes VRF/VN-aware - one SXP connection carries IP-SGT bindings for all virtual networks, where v4 needs a connection per VN; until the policy engine speaks v5, an SXP reflector terminates the per-VN v4 sessions and re-advertises everything over a single v5 session.

TrustSec enforcement fires on the first device that holds [...] - in practice the egress edge, which also downloads only the SGACLs matching its own bindings.

TrustSec enforcement fires on the first device that holds the source binding, the destination binding, enforcement enabled on that platform/VLAN, and the policy - in practice the egress edge, which also downloads only the SGACLs matching its own bindings.

Access-class hardware enforces on the order of [...] locally; moving enforcement to a border imports the DC/cloud side's group diversity - another reason egress-edge enforcement wins.

Access-class hardware enforces on the order of 255 unique destination groups locally; moving enforcement to a border imports the DC/cloud side's group diversity - another reason egress-edge enforcement wins.

Sources

  • Cisco Live BRKENT-2076 (APJC 2022): SGT carrier list per encapsulation; enforcement capacity anchors (4000 SGTs, 64-256 VNs/site, ~255 local destination groups) and the border-inflation caveat.
  • Cisco Live BRKSEC-2154 (Next-Gen Segmentation: Group-Based Policy, SXPv5 and PxGrid Direct; Casillas/De La Vega, 2024 deck, user-supplied PDF, all 85 pages passed 2026-07-26) - SXP version ladder and SXPv5 VN-awareness, reflector pattern, enforcement conditions and egress economics, CMD overhead.
  • Cisco Press, CCNP Security SISE 300-715 OCG - native tagging/CMD, SXP speaker-listener, strategic enforcement points, SGACL/SGFW enforcement.
  • Cisco Press, CCNP/CCIE Security Core SCOR; TrustSec design guides.

domain: Core · blueprint-ref: Core 5.2.i Infrastructure segmentation methods · type: design-decision · status: complete · tags: [core, core/virtualization, tradeoff/scale, tradeoff/security]

Read more