Cisco Catalyst SD-WAN uses VPN identifiers to separate transport, management, and service-side routing.<\/p>\n
The word \u201cVPN\u201d can be confusing here because these are not simply remote-access VPN tunnels. In Catalyst SD-WAN, the VPN identifier is a segmentation construct closely related to VRF separation.<\/p>\n
The current 300-415 ENSDWI<\/a> v1.2 blueprint includes VPN segmentation, topologies, and policy as fundamental parts of the solution.<\/p>\n VPN 0 is reserved for the WAN transport side.<\/p>\n Cisco’s current documentation describes VPN 0 as the transport VPN that contains the interfaces used to connect the edge device to WAN networks and carry overlay control-plane traffic.<\/p>\n An edge needs transport reachability before it can build the secure overlay.<\/p>\n That means VPN 0 is not where user LAN routes normally live.<\/p>\n It represents the underlay-facing side of the SD-WAN device.<\/p>\n Transport-VPN troubleshooting should stay focused on underlay reachability and overlay establishment. The WAN interfaces, default or dynamic routes needed to reach the control components and remote transport endpoints, NAT behavior where relevant, and tunnel-interface settings all live in this part of the design.<\/p>\n Putting user-side routes into VPN 0 would blur the trust and routing boundary that SD-WAN is designed to maintain. The transport VPN should carry what the overlay needs to build itself, not become a convenient global table for business applications.<\/p>\n VPN 512 is reserved for out-of-band management traffic.<\/p>\n Cisco devices commonly use a management interface placed in VPN 512 so management traffic remains separate from the normal service and transport routing contexts.<\/p>\n This gives the platform a dedicated management routing space.<\/p>\n It also means an engineer should not attempt to use VPN 512 as a normal user segment.<\/p>\n Cisco explicitly reserves it.<\/p>\n VPN 512 is local out-of-band management context and is not advertised through the overlay like a normal service VPN. That detail explains an important operational case: a device can lose its dedicated management path while continuing to forward user traffic through service VPNs.<\/p>\n If management reachability is required through<\/em> the SD-WAN overlay, it should be designed in an appropriate service VPN rather than assuming VPN 512 will be transported between sites. Separating those two management models avoids accidental dependency on the user overlay for true out-of-band access.<\/p>\n Service VPNs represent the service-side network segments.<\/p>\n Cisco currently documents service VPN identifiers in the ranges outside the reserved transport and management values.<\/p>\n Each service VPN has its own routing context.<\/p>\n That is conceptually similar to VRF<\/a>: two interfaces can exist on the same physical router while their routing tables remain isolated.<\/p>\n That separation supports business requirements such as:<\/p>\n The segmentation can extend consistently across many sites through the SD-WAN overlay.<\/p>\n Current Cisco documentation reserves VPN 0 for transport and VPN 512 for management, while service-side segments use other supported identifiers. The exact high end of the configurable range has changed across releases and features, so production designs should follow the release documentation rather than treating one historical range as universal.<\/p>\n The more important concept is the routing boundary. On IOS XE Catalyst SD-WAN devices, the VPN construct maps to a VRF-style routing context. Interfaces, routes, routing protocols, and policies are evaluated inside that context, which allows overlapping addresses and independent forwarding decisions across business segments.<\/p>\n Routes in Catalyst SD-WAN are not advertised as one global pool with no segment identity.<\/p>\n OMP associates reachability with the relevant VPN or VRF context.<\/p>\n That lets the controller distribute routes while maintaining segmentation.<\/p>\n An edge can therefore learn the same IP prefix in different service VPNs without treating those routes as identical forwarding entries.<\/p>\n The VPN context is part of the route’s meaning.<\/p>\n Cisco SD-WAN architecture<\/a> explains the OMP and controller roles that distribute reachability; segmentation adds the routing separation that keeps one tenant or business function from automatically reaching another.<\/p>\n OMP carries the VPN identity with the route, so two otherwise identical prefixes can remain distinct because they belong to different service VPNs. The remote edge installs each route into the matching routing context rather than merging them into one global table.<\/p>\n This is the control-plane counterpart to data-plane segmentation. Across the overlay tunnel, traffic also carries information that lets the receiving edge associate the packet with the correct VPN. One common IPsec fabric can therefore transport several logically isolated services without giving every segment access to every other segment.<\/p>\n Creating multiple service VPNs establishes separate routing contexts, but the design still needs deliberate policy.<\/p>\n If every route is leaked everywhere, the logical segmentation can be weakened.<\/p>\n The engineer therefore needs to distinguish:<\/p>\n The correct design normally exposes only the routes or services that actually need to cross a boundary.<\/p>\n Segmentation policy should begin with the required trust boundaries and shared services. A guest segment may need only internet access. A point-of-sale segment may need payment and DNS services but no reachability to corporate endpoints. An operations segment may need tightly controlled access to shared monitoring.<\/p>\n If the design starts by leaking broad route sets and tries to restrict traffic later, the routing topology becomes harder to reason about. A better model is to keep routing contexts separate and add only the cross-boundary reachability that has a documented purpose.<\/p>\n Cisco supports route leaking between the global routing context and service VPNs and, in supported releases, between service VPNs.<\/p>\n Route leaking copies or redistributes selected routing information across otherwise separate contexts.<\/p>\n That is useful when multiple segments need access to a shared service such as DNS, authentication, security inspection, or another centralized application.<\/p>\n Cisco’s current route-leaking documentation describes the feature as a mechanism for sharing common services across isolated segments.<\/p>\n This is why route leaking should be treated as an exception to segmentation, not as a default.<\/p>\n Route leaking does not merge the VPNs.<\/strong><\/p>\n A leaked route does not turn two service VPNs into one routing table.<\/p>\n The VPNs remain logically separate.<\/p>\n The configuration selectively makes specific reachability available across the boundary.<\/p>\n That distinction matters for troubleshooting because a route may appear in a second VPN even though the original interface and local routing still belong to the source VPN.<\/p>\n Always identify where the route originated, how it was leaked, and which protocol or policy installed it in the destination context.<\/p>\n Route leaking is selective route replication, not a collapse of the VRFs. The source route still belongs to its original context; the destination context receives reachability according to the leak configuration and route policy. Return-path reachability must be considered separately so shared services can send traffic back through the correct segment.<\/p>\n This is especially important with overlapping prefixes. A shared service design that is simple with unique addressing can become ambiguous when two service VPNs use the same subnet. The routing and policy design must identify which segment a request belongs to rather than relying only on the destination address.<\/p>\n Catalyst SD-WAN can also use policy to control which sites learn which VPN routes.<\/p>\n For example, one service VPN might use a full-mesh topology while another uses hub-and-spoke.<\/p>\n The same physical WAN transports can therefore support different logical topologies.<\/p>\n This is one of the major benefits of software-defined segmentation: topology and policy can be expressed per service rather than being permanently tied to separate physical WANs.<\/p>\nVPN 0 is the transport VPN<\/h2>\n
VPN 512 is the management VPN<\/h2>\n
Service VPNs carry user and application traffic<\/h2>\n
\n
OMP preserves VPN context when routes are advertised<\/h2>\n
Segmentation is not complete if policy leaks everything<\/h2>\n
\n
Route leaking enables controlled service sharing<\/h2>\n
Centralized policy can build different topologies per segment<\/h2>\n