Ask someone new to Cisco SD-WAN what a "VPN" is and they'll describe an encrypted tunnel. Then they open the config and see vpn 0, vpn 512 and vrf forwarding 10, and none of those are tunnels.
In Cisco SD-WAN a VPN is a routing table. It's VRF-lite with a new name and a few reserved numbers. This post explains the three kinds and shows them on real routers. Then it shows a mistake I found in my own lab: a management port in the wrong VPN, leaking into the overlay. I built the overlay in my home lab on Cisco Catalyst SD-WAN 20.18.2.1, with C8000v routers on IOS XE 17.18.02.
This is part of the Cisco SD-WAN series. The previous part, TLOCs Explained, covered the transport side. If SD-WAN itself is new, read What is SD-WAN? first, then the components post. For the old names of SD-WAN Manager (formerly vManage) and the other boxes, see the name map.
The problem: three kinds of traffic, one router
A branch router carries three very different things:
- Underlay traffic: the tunnels themselves, DTLS to the controllers, routes to the ISP.
- User traffic: the LANs you're actually connecting.
- Management traffic: you SSHing in when things break.
If they share one routing table, a default route for the ISP also becomes the default route for users, and a management subnet becomes reachable from every branch. You want separate tables.
The idea: one building, separate floors
Think of an office building. The ground floor is the loading dock, where the trucks come and go. The upper floors are tenants, each with its own locked door. The basement is the maintenance room, with its own key, and it isn't on the tenant directory.
| Floor | SD-WAN name | Number | What lives there |
|---|---|---|---|
| Loading dock | Transport VPN | VPN 0 | WAN interfaces, TLOCs, the default route to the ISP |
| Tenant floors | Service VPNs | 1 to 511, 513 to 65530 | User LANs, carried across the overlay |
| Maintenance room | Management VPN | VPN 512 | Out-of-band management, local only |
Those numbers come straight from Cisco's VPN guide. Two lines in it matter most:
- VPN 512 "is converted to VRF Mgmt-Intf" on IOS XE devices.
- "VPN 512 is local to the device and not advertised in the overlay."
The parts: VPNs are VRFs
On IOS XE edges, Cisco uses VRFs in place of VPNs. A service VPN is a normal vrf definition, and VPN 0 is the global table. Here is the service side of edge1:
edge1#show running-config interface GigabitEthernet4
interface GigabitEthernet4
vrf forwarding 10
ip address 192.168.10.1 255.255.255.0edge1#show vrf
Name Default RD Protocols Interfaces
10 1:10 ipv4 Gi4
513 <not set> ipv4,ipv6 Gi1
65528 <not set> ipv4 Lo65528
65529 <not set> ipv4 Lo65529(Spacing trimmed.)
VRF 10 is VPN 10, the user LAN. Hold on to VRF 513 for later. I didn't configure 65528 or 65529. They hold internal loopbacks, and I left them alone.
VPN 0 is the global table, where the WAN interfaces and their defaults live:
edge1#show running-config | section ip route
ip route 0.0.0.0 0.0.0.0 10.10.1.1
ip route 0.0.0.0 0.0.0.0 10.20.1.1
ip route vrf 513 0.0.0.0 0.0.0.0 10.0.0.2The first two are the transport defaults, one per WAN link. They never show up in VRF 10. A user in VPN 10 can't follow them to the Internet unless you add a feature for that.
The Controller (formerly vSmart) runs the older Viptela CLI, which still says vpn:
controller# show running-config vpn 0
vpn 0
interface eth1
ip address 172.16.20.20/24
tunnel-interface
...
ip route 0.0.0.0/0 172.16.20.1
controller# show running-config vpn 512
vpn 512
interface eth0
ip address 10.0.0.15/24
no shutdown
ip route 0.0.0.0/0 10.0.0.2That's the clean pattern: transport in VPN 0 with a tunnel-interface, management in VPN 512.
How the overlay keeps VPNs apart: labels
A service VPN reaches the other side because OMP carries the VPN with every route, plus a label. On edge1:
edge1#show sdwan omp routes
VPN PREFIX FROM PEER LABEL STATUS TLOC IP COLOR
10 192.168.20.0/24 1.1.1.2 1004 C,I,R 10.0.0.2 mpls
1.1.1.2 1004 C,I,R 10.0.0.2 biz-internet(Columns trimmed.)
Label 1004 is how edge2 tagged VPN 10. When edge1 sends a packet to h2, it puts 1004 inside the IPsec tunnel, and edge2 uses it to drop the packet into VRF 10. Same idea as an MPLS VPN label, without MPLS in the underlay.
edge1#show ip route vrf 10
C 192.168.10.0/24 is directly connected, GigabitEthernet4
L 192.168.10.1/32 is directly connected, GigabitEthernet4
m 192.168.20.0/24 [251/0] via 10.0.0.2, 10:25:13, Sdwan-system-intfEach new service VPN is one more VRF on each edge. Nothing in the WAN changes. The same tunnels carry every VPN, with a different label.
The example: what I found in VPN 513
When I first looked at edge1's show vrf, I expected VPN 512 for management. Instead, the management port, Gi1, was in VRF 513:
edge1#show running-config interface GigabitEthernet1
interface GigabitEthernet1
vrf forwarding 513
ip address 10.0.0.15 255.255.255.0
ipv6 address 2001:DB8::2/64The initial bootstrap put it in VPN 513. That number is in the service range (513 to 65530), not the management one. So the edge treats it as a user VPN, and my OMP config advertises connected and static routes at the global level, which covers every VRF:
edge1#show sdwan running-config sdwan
omp
...
address-family ipv4
advertise connected
advertise staticThe result is on the Controller. Both edges advertise their management network and the management default route into the overlay, with label 1003:
controller# show omp routes
VPN PREFIX FROM PEER LABEL STATUS TLOC IP COLOR
513 0.0.0.0/0 10.0.0.1 1003 C,R 10.0.0.1 mpls
10.0.0.1 1003 C,R 10.0.0.1 biz-internet
10.0.0.2 1003 C,R 10.0.0.2 mpls
10.0.0.2 1003 C,R 10.0.0.2 biz-internet
513 10.0.0.0/24 10.0.0.1 1003 C,R 10.0.0.1 mpls
10.0.0.1 1003 C,R 10.0.0.1 biz-internet
10.0.0.2 1003 C,R 10.0.0.2 mpls
10.0.0.2 1003 C,R 10.0.0.2 biz-internet(Columns and the system-path rows trimmed.)
Two problems in one:
- A management default route is now an overlay route. Any site in VPN 513 could learn it.
- Both edges use the same 10.0.0.0/24 on their management port, so the same prefix arrives from two sites. Each edge's own connected and static routes beat OMP's distance of 251, so nothing broke here. In a real network that overlap would be a trap.
In VPN 512 (Mgmt-Intf) none of this would happen, because Cisco keeps VPN 512 out of the overlay. In my lab it's harmless, as nothing else lives in VPN 513 and no user sits there. I'm keeping it as a lesson rather than changing the bootstrap mid-series. On a real network, put management in VPN 512, or advertise per VRF instead of globally.
Verify VPNs on your own edges
| Check | Command |
|---|---|
| Which VRFs exist and which interfaces are in them | show vrf |
| Routes in a service VPN | show ip route vrf <n> |
| What OMP carries per VPN, with labels | show sdwan omp routes vpn <n> |
| VPN 0 defaults | show ip route (global table) |
| Controller transport and management | show running-config vpn 0 and vpn 512 |
What breaks
- Management in a service VPN. Shown above. It gets advertised like user traffic. Use VPN 512.
- Users can't reach the Internet. The transport defaults live in VPN 0. A service VPN needs its own path out, such as a hub or a direct Internet access feature.
- Route only in one VPN. VPNs don't leak into each other by default. If h1 in VPN 10 needs something in VPN 20, that takes a deliberate policy.
- No tunnel interface in VPN 0. Cisco's guide says a device needs at least one interface in VPN 0 to take part in the overlay. Without it there are no TLOCs.
- Overlapping subnets. Two sites can reuse a subnet in different VPNs. Reusing it inside the same VPN, as my management ports did, gives OMP two paths to the "same" network.
Key takeaways
- An SD-WAN "VPN" is a VRF. On IOS XE, service VPN 10 is
vrf forwarding 10. - VPN 0 is transport, VPN 512 is management (Mgmt-Intf), and 1 to 511 plus 513 to 65530 are service VPNs.
- OMP carries a label per VPN, so one set of tunnels serves every VPN.
- VPN 512 stays local. A management port in any other VPN gets advertised. Mine was in 513, and it showed up on the Controller.