Cisco SD-WAN Segmentation: — VPN 0, VPN 512, Service VPNs & Labels

① VPNs ARE segments — and two of them are reserved

The first thing to unlearn: in Cisco SD-WAN a VPN is not the AnyConnect-style tunnel you dial into from a café. It is a VRF — a segment with its own routing table on the same router. Rahul at Infosys can run Corp, Guest and a PCI zone on one WAN Edge, and each lives in its own table, blind to the others. Newer Catalyst SD-WAN even shows you the word VRF in places where the field has said VPN for years — they are the same idea.

Out of the whole numbering space, two VPNs are special and you cannot use them for users. VPN 0 is the transport VPN — your MPLS and Internet uplinks, the TLOCs, the default route to the underlay, and the DTLS control connections to the controllers all live here. VPN 512 is the management VPN — out-of-band SSH, SNMP and NTP to the box, completely off the data path.

The Indian-life picture that sticks: think of a railway station. VPN 0 is the main entrance off the public road — everyone and everything that comes in from outside arrives through it, and it's where the platform numbers (TLOCs) are posted. VPN 512 is the locked staff door at the back — only the station master walks through it for maintenance, and no passenger ever uses it. The service VPNs are the separate waiting rooms — first class, general, ladies — each with its own door, and a passenger in one room can't wander into another.

Four words you'll say every day on the job

Tap each card — these are the vocabulary anchors for the whole lesson.

② Service VPNs (1–511) — one VRF per department

Everything that isn't VPN 0 or VPN 512 is a service VPN, and that's where your users live. The usable range is 1–511 and 513–65525; Cisco reserves 0, 512, and 65526 and above. So Sneha at TCS gives Corp VPN 10, Guest VPN 30, and the card-data zone VPN 40 — three departments, three completely separate routing tables, on the very same WAN Edge.

Each service VPN maps one-to-one onto a traditional VRF. A prefix learned in VPN 10 goes into the VPN 10 table and only the VPN 10 table. There is no shared global table that Corp and Guest both fall into — that's the whole point. The CLI even uses VRF language on modern cEdge boxes.

vrf definition 30
 address-family ipv4
 exit
!
interface GigabitEthernet0/0/1.30
 vrf forwarding 30
 ip address 172.16.30.1 255.255.255.0
 no shutdown
!
! On vEdge/older syntax this is simply:  vpn 30  →  interface ge0/0/1  →  ip address 172.16.30.1/24

Edge-A# show ip route vrf 30 | include 172.16.30
C   172.16.30.0/24 is directly connected, GigabitEthernet0/0/1.30
L   172.16.30.1/32 is directly connected, GigabitEthernet0/0/1.30
! VPN 30's prefixes live ONLY in vrf 30 — invisible to vrf 10.

In production you almost never type this by hand — you do it once in a feature template and attach it to a hundred branches. The path Aditya at Wipro uses every day: Configuration > Templates > Feature > Add Template > VPN (set the VPN ID and what to advertise into OMP), then a separate VPN Interface Ethernet template for the LAN port. The same VPN number on every branch = the same segment end-to-end across the fabric.

③ How segmentation rides OMP — the VPN label

Here's the engine room. When you create a VPN on a WAN Edge, the router quietly assigns it a VPN label. It then advertises that label + VPN-ID together in every OMP route up to vSmart, which reflects it to the other edges. The remote edge stores: "to reach that prefix in that VPN, push this label."

The detail that trips people up: labels are locally significant. On Edge-A, VPN 30 might be label 1015; on Edge-B the very same VPN 30 might be label 1013. The numbers don't have to match — each edge advertises its own, and the sender simply copies whatever label sits in the OMP route it's using. That's why the fabric scales: adding a new edge or a new VPN never forces every other router to renumber.

Order matters in the data plane. On the way out, the ingress edge pushes the VPN label first, then wraps it in IPsec — so the label is protected inside the tunnel. On the way in, the egress edge decrypts first, reads the label, then does the route lookup in the matching VPN table. Because the lookup happens inside one specific VPN table, a Guest packet (VPN 30) physically cannot resolve a Corp prefix (VPN 10) — there's no entry for it in that table. That is the isolation, and it needs zero access-lists.

Edge-B# show sdwan omp services
Edge-B# show sdwan omp routes vpn 30

                          PATH                                  ATTRIBUTE
VPN  PREFIX            FROM PEER     ID  LABEL  STATUS  TLOC IP        COLOR        ENCAP
----------------------------------------------------------------------------------------
30   172.16.30.0/24   10.255.0.1    3   1013   C,I,R   10.255.6.6    biz-internet ipsec
30   172.16.30.0/24   10.255.0.1    4   1013   C,R     10.255.6.6    mpls         ipsec
! LABEL 1013 = this edge's VPN 30 table.  C=chosen I=installed R=resolved.

④ Controlled leaking & firewall service insertion

Isolation is the default — but the business sometimes wants a controlled hole. Two patterns cover almost everything. Route leaking shares specific prefixes between two VPNs (e.g. let a shared printer in VPN 50 be reachable from Corp VPN 10). Service insertion (a.k.a. service chaining) forces VPN-to-VPN traffic to detour through a shared firewall before it's allowed across. Both are done from the controller, not on each branch.

Route leaking uses a centralized control policy. You build VPN lists and a prefix list, then write a topology/control policy that says export the VPN 50 prefixes to VPN 10 (and, if you want it both ways, a second rule the other direction). vSmart then advertises those leaked prefixes into the target VPN's tables. The vManage path Meera at Airtel uses: Configuration > Policies > Centralized Policy > Add Policy, build the lists, then a Custom Control (Route & TLOC) topology.

Service insertion goes further: instead of leaking routes, you make traffic physically pass through a firewall. The firewall is advertised as a service from the VPN it sits in (on the hosting edge you configure service FW address <ip> so it's announced to OMP), and a centralized control/data policy then steers matched VPN-to-VPN traffic to that firewall service before delivery. The exam loves the distinction: route leaking = share a route; service insertion = detour through an appliance.