A WAN that carries finance, guest Wi-Fi, and plant-floor traffic in one routing table is one leak away from a bad week. Segmentation is how you keep those groups apart from the branch LAN, across the overlay, and into the campus or data center on the far side.
In Cisco Catalyst SD-WAN the first cut is a service VPN, which is a VRF with a number. The optional second cut is a Security Group Tag (SGT) that a TrustSec-capable switch stamps on a frame. The WAN edge can carry that tag across the overlay so the far campus can enforce the same group policy.
This post walks that path on Cisco Catalyst SD-WAN 20.18.2.1 with C8000v routers on IOS XE 17.18.02, built in my home lab. VPN 10 is up and isolated from VPN 0. I do not have a second service VPN or a TrustSec switch, so the SGT half is documented rather than reproduced.
This is part of the Cisco SD-WAN series. Previous: Multi-Region Fabric basics. Next: Upgrading SD-WAN controllers and WAN edges.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
The problem: the underlay must not see the tenants
You want guest users at a branch to reach the internet or a DMZ, and you want the corporate VLAN to reach a data-center VRF, without those two groups sharing routes. The MPLS or internet underlay should not need a VRF for each tenant. The overlay has to carry the separation itself.
SD-WAN does that with VPN IDs.
- VPN 0 is the transport VPN, the global table on IOS XE. WAN circuits, static defaults to the PE, and DTLS sessions live here. We used that table in the underlay post.
- VPN 512 is out-of-band management.
- Service VPNs are the remaining VPN IDs (not 0 and not 512). Each service VPN is a VRF on the edge, with its own interfaces, its own routing table, and its own OMP prefixes.
The edge keeps a per-VPN routing table and puts a VPN label in the overlay packet. The far edge uses that label to land the packet in the matching VRF. The underlay only sees IPsec between TLOCs.
Think of the service VPN as a colored folder. Every file that leaves the branch goes into a folder of that color. The courier does not open the folder. The far office files it in the drawer with the same color.
SGTs are stickers on the files inside the folder. A TrustSec switch at the branch classifies the user or device and writes the sticker. The WAN edge can propagate that sticker across the IPsec tunnel. A TrustSec switch at the far site enforces it. The edge is the courier for the sticker, not the policy brain.
What this lab already proves with one service VPN
VPN 10 exists on both edges. GigabitEthernet4 is in that VRF. OMP advertises connected routes, so each site's LAN appears at the other site and nowhere in VPN 0.
interface GigabitEthernet4
vrf forwarding 10
ip address 192.168.10.1 255.255.255.0edge1#show ip route vrf 10
C 192.168.10.0/24 is directly connected, GigabitEthernet4
m 192.168.20.0/24 [251/0] via 10.0.0.2The global table (VPN 0) has the WAN subnets and the two static defaults. It does not have 192.168.10.0/24 or 192.168.20.0/24. That is the isolation you paid for: LAN prefixes stay in the service VRF.
OMP carries the VPN with the prefix:
edge1#show sdwan omp routes vpn 10
TENANT VPN PREFIX FROM PEER LABEL STATUS TLOC IP COLOR
0 10 192.168.10.0/24 0.0.0.0 1004 C,Red,R 10.0.0.1 mpls
0 10 192.168.10.0/24 0.0.0.0 1004 C,Red,R 10.0.0.1 biz-internet
0 10 192.168.20.0/24 1.1.1.2 1004 C,I,R 10.0.0.2 mpls
0 10 192.168.20.0/24 1.1.1.2 1004 C,I,R 10.0.0.2 biz-internetBoth prefixes use VPN 10 and label 1004. A ping from edge1 in VRF 10 to 192.168.20.10 was 5/5. Traffic that is not in VRF 10 cannot use that table.
There is no VPN 20, no guest VRF, and no SGT configuration on GigabitEthernet4. show running-config interface GigabitEthernet4 is the VRF and an address. I did not invent a second tenant just to print an empty table.
How a second VPN, and then an SGT, would plug in
A second service VPN is the same pattern with a new number. Create VRF 20, put a LAN interface or subinterface in it, and advertise it into OMP. The two VRFs do not leak unless you configure leaking on purpose (extranet). OMP will show a different VPN column and a different label.
From Manager you do this with a VPN feature template plus an interface template, or with a configuration group service profile. The edges here are still CLI-managed, and I did not attach those objects.
SGT propagation is documented from IOS XE 17.3.1a / Manager 20.3.1. The TrustSec switch at the branch writes an inline CMD tag toward the edge. The edge strips that Ethernet tag, carries the SGT across the SD-WAN tunnel, and the far edge rebuilds the CMD frame toward its switch. Classification and enforcement stay on the switches.
On a service interface the knobs are:
- Enable SGT propagation
- Propagate
- Optionally trust the incoming tag
- Optionally enforce a tag on the interface
In a configuration group those sit under the LAN interface TrustSec settings, and 20.18 also lets you set TrustSec in the Other profile. The equivalent idea in a feature template is the TrustSec section of the VPN Interface Ethernet template.
None of that is present here. There is no TrustSec switch attached to GigabitEthernet4.
Regions, from the MRF post, do not replace VPNs. A region limits which edges mesh. A VPN limits which prefixes share a table. You can have both.
Verify the segmentation you actually have
| Check | Command | This lab |
|---|---|---|
| Service table | show ip route vrf 10 | Local LAN plus far LAN via OMP |
| Transport table | show ip route | WAN subnets and static defaults only |
| VPN and label | show sdwan omp routes vpn 10 | VPN 10, label 1004 |
| LAN interface | show running-config interface GigabitEthernet4 | vrf forwarding 10, no TrustSec |
| Data plane | ping vrf 10 192.168.20.10 | 5/5 |
What breaks
- Putting a user VLAN in VPN 0. Those prefixes mix with transport routing, and you lose the folder.
- Reusing the same subnet in two service VPNs and then leaking them. The point of a second VPN is isolation. Extranet leaking is a deliberate exception.
- Expecting the WAN edge to classify users the way an ISE-enabled access switch does. Cisco's SGT design leaves classification and enforcement on the TrustSec switches and uses the edge for propagation.
- Turning on propagate without a trusted tag source. You will carry whatever landed on the wire, or nothing useful.
- Confusing MRF regions with VPNs. Different problems, different knobs.
Key takeaways
- SD-WAN segmentation starts as service VPNs (VRFs) with a VPN label in OMP. The underlay does not need a tenant VRF.
- This lab has one service VPN, VPN 10. Its LAN prefixes stay out of the global table, OMP advertises them with label
1004, and a VRF 10 ping across the overlay succeeds. - SGT inline tagging is the campus handoff: TrustSec switches classify and enforce, and IOS XE edges can propagate the tag. I did not configure that, because there is no TrustSec switch here.
- Add a second VRF when you have a second tenant to isolate. Add SGT when the LAN in front of the edge already speaks TrustSec.