Back
Lesson 5 of 7

Transport and Service VPNs

Objective

Understand and configure the SD‑WAN VPN/VRF separation model on a Catalyst SD‑WAN Edge: VPN0 (transport), VPN512 (management), and a service VPN (VPNn). You will create VRFs, place interfaces into the correct VPNs, add per‑VPN routes, and verify that forwarding and routing tables are isolated per VPN. This matters in production because transport isolation preserves underlay reachability while service VPNs carry tenant/user traffic — preventing accidental leakage between management, transport, and service planes.

In a real world scenario: a branch WAN Edge uses VPN0 to connect to multiple transports (MPLS, Internet), VPN512 for OOB management and telemetry, and one or more service VPNs (VPN10, VPN20...) for tenant LANs. Proper segmentation ensures the management plane remains unreachable from user LANs and that transport routing is not polluted with user prefixes.

Topology (quick recap from Lesson 1)

This lesson continues with the same two-device edge topology used previously: a single WAN Edge (Edge-A) with three local interfaces used to illustrate transport, service, and management separation. No new devices are added.

ASCII topology (interfaces and IP addresses shown):

Edge-A

[Edge-A]
GigabitEthernet0/0 (transport) 10.0.0.1/30 --- 10.0.0.2 (ISP)
GigabitEthernet0/1.10 (service, VLAN 10) 192.168.10.1/24 --- 192.168.10.254 (LAN gateway)
GigabitEthernet0/2 (management) 172.16.255.1/24 --- 172.16.255.254 (OOB/NMS)

Notes:

  • We will map these interfaces into VPNs/VRFs: VPN0 for transport (Gig0/0), VPN10 for a service LAN (subinterface Gi0/1.10), and VPN512 for management (Gi0/2).
  • The IPs above are used consistently in all configuration and verification commands in this lesson.

Key Concepts (theory + practical)

  • VPNs = VRFs (Virtual Routing and Forwarding): Think of a VRF like a separate virtual router inside the physical device. Each VRF has its own routing table, interfaces, and forwarding behavior. In SD‑WAN, VPN0 is reserved for transport (underlay), VPN512 for management (OOB), and VPNn are service VRFs.

    In production: keeping transport routing separate prevents user routes from being leaked into the underlay and avoids accidental path selection problems.

  • Control plane vs Data plane separation: Transport (VPN0) carries underlay reachability to WAN peers (in SD‑WAN this is handled by OMP). Service VPNs carry tenant/user prefixes. Management VPN512 is reserved for device management and telemetry. Each VPN’s routing decisions are independent and must be intentionally shared if needed.

  • Interface-to-VPN binding: Assigning an interface with vrf forwarding places that interface into the VRF. Packets received on that interface are routed using the VRF’s routing table. If you forget to bind the interface, traffic will be routed in the global table and you’ll see leaks.

  • Per‑VPN routing protocols and routes: Routing protocols (static, OSPF, BGP) can be run inside a VRF to populate that VRF’s routing table. In SD‑WAN, controllers propagate service routes into the edges using OMP so that service VRFs can reach remote prefixes over the encrypted fabric. For this lab we use static routes to demonstrate segregation.

  • Verification and troubleshooting: Use per‑VRF show commands (e.g., show ip route vrf , ping vrf ) to confirm isolation. Verifying the global routing table ensures you have not accidentally injected service routes into the underlay.

Step-by-step configuration

Step 1: Create the VRFs for VPN0, VPN512, and VPN10

What we are doing: Define three VRFs (VPN0, VPN512, VPN10) to represent transport, management, and a service segment. This creates separate routing tables and is the first step to ensure logical segmentation.

configure terminal
vrf definition VPN0
 rd 65000:0
 exit
vrf definition VPN512
 rd 65000:512
 exit
vrf definition VPN10
 rd 65000:10
 exit
end
write memory

What just happened: Each vrf definition created an isolated routing and forwarding context. The rd (route distinguisher) is a unique identifier for the VRF (useful when interacting with VPN technologies that require an RD). At this point the device has three distinct VRFs but no interfaces assigned yet.

Real-world note: Route distinguishers are required when VRFs interact with MPLS/BGP environments — in SD‑WAN the controllers/OMP pair handle route distribution, but VRFs still need identifiers.

Verify:

show ip vrf

Expected output:

Name                             Default RD            Interfaces
VPN0                             65000:0
VPN512                           65000:512
VPN10                            65000:10

Step 2: Place interfaces into the correct VPNs and configure IP addressing

What we are doing: Assign the physical/sub‑interfaces to their respective VRFs and configure IP addresses. This ensures that packets received on each interface are handled by the correct routing table.

configure terminal
interface GigabitEthernet0/0
 description Transport to ISP1
 vrf forwarding VPN0
 ip address 10.0.0.1 255.255.255.252
 no shutdown
 exit

interface GigabitEthernet0/1.10
 encapsulation dot1Q 10
 description Service VLAN 10 (User LAN)
 vrf forwarding VPN10
 ip address 192.168.10.1 255.255.255.0
 no shutdown
 exit

interface GigabitEthernet0/2
 description Management OOB
 vrf forwarding VPN512
 ip address 172.16.255.1 255.255.255.0
 no shutdown
 exit
end
write memory

What just happened:

  • vrf forwarding <name> binds the interface to the VRF so that traffic ingressing that interface is looked up against that VRF’s routing table.
  • The subinterface Gi0/1.10 with 802.1Q encapsulation isolates service VLAN 10 into VPN10.
  • Each interface now has an IP in its respective VRF, and the device will use the appropriate routing table when forwarding packets from that interface.

Real-world note: In production branches, management interfaces are often physically separate (OOB) and placed in VPN512 to ensure management access is never traversed by user traffic accidentally.

Verify:

show ip interface brief

Expected output:

Interface                      IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0             10.0.0.1        YES manual up                    up
GigabitEthernet0/1             unassigned      YES unset  administratively down down
GigabitEthernet0/1.10          192.168.10.1    YES manual up                    up
GigabitEthernet0/2             172.16.255.1    YES manual up                    up

Also verify VRF binding:

show ip vrf interfaces

Expected output:

Name: VPN0
 Interfaces:
  GigabitEthernet0/0

Name: VPN10
 Interfaces:
  GigabitEthernet0/1.10

Name: VPN512
 Interfaces:
  GigabitEthernet0/2

Step 3: Configure per‑VPN static routes

What we are doing: Add sample static routes inside each VRF so each routing table has a default or specific route. This demonstrates how routes are scoped and how forwarding decisions differ per VPN.

configure terminal
ip route vrf VPN0 0.0.0.0 0.0.0.0 10.0.0.2
ip route vrf VPN512 0.0.0.0 0.0.0.0 172.16.255.254
ip route vrf VPN10 10.10.10.0 255.255.255.0 192.168.10.254
end
write memory

What just happened:

  • ip route vrf <vrf> installs a static route visible only inside that VRF’s routing table. For example, the VPN0 default route uses the transport next hop (ISP), ensuring transport traffic has a proper underlay route. VPN10 has a route to a remote subnet via the local LAN gateway (simulating a local server/router). The global routing table is not modified by these entries.

Real-world note: In SD‑WAN production, service routes are typically learned/advertised via OMP from the controllers; static routes are useful for lab demos and local overrides.

Verify:

show ip route vrf VPN0

Expected output:

VPN0 routing table
     0.0.0.0/0 via 10.0.0.2, GigabitEthernet0/0

show ip route vrf VPN10

Expected output:

VPN10 routing table
     10.10.10.0/24 via 192.168.10.254, GigabitEthernet0/1.10

show ip route vrf VPN512

Expected output:

VPN512 routing table
     0.0.0.0/0 via 172.16.255.254, GigabitEthernet0/2

Also confirm the global routing table has no service or management routes:

show ip route

Expected output:

Gateway of last resort is not set

     10.0.0.0/30 is directly connected, GigabitEthernet0/0
     172.16.255.0/24 is directly connected, GigabitEthernet0/2
     192.168.10.0/24 is directly connected, GigabitEthernet0/1.10

(Notice these networks are listed as directly connected but no VRF static/defaults appear in the global table as VRF routes are kept separate.)

Step 4: Verify per‑VPN reachability and isolation

What we are doing: Use VRF‑aware ping and route checks to confirm that traffic from each interface is using its VRF routing information and that one VRF cannot route into another unless explicitly configured.

ping vrf VPN10 10.10.10.1

Expected output:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms

ping vrf VPN512 8.8.8.8

Expected output (assuming OOB/NMS next hop forwards):

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/12/20 ms

Attempt a ping from service VRF to an address reachable only via the transport default (should fail unless forwarding is allowed):

ping vrf VPN10 8.8.8.8

Expected output (no route to host via VPN10):

% Network is unreachable

What just happened:

  • ping vrf forces the ICMP to use the specified VRF routing table. The success of pings in VPN10 and VPN512 demonstrates those VRFs can reach their configured next hops. The failed ping from VPN10 to 8.8.8.8 demonstrates isolation: there is no global route for 8.8.8.8 in VPN10, so the packet is dropped locally — the VRF routing table does not consult VPN0 routes.

Real-world note: Isolation is intentional and essential for security. If you need cross-VRF reachability, implement controlled route leaking or policies at the controller/manager (in SD‑WAN) or via route-target import/export when using MPLS/BGP.

Verification Checklist

  • Check 1: VPNs/VRFs exist — show ip vrf should list VPN0, VPN10, and VPN512.
  • Check 2: Interfaces are bound to VRFs — show ip vrf interfaces shows Gig0/0 → VPN0, Gi0/1.10 → VPN10, Gi0/2 → VPN512.
  • Check 3: Routing is isolated — show ip route vrf VPN10 shows the service route but show ip route (global) does not contain the VPN10-specific static routes.

Common Mistakes

SymptomCauseFix
VRF exists but interface traffic is still in global routing tableForgot to configure vrf forwarding <name> on the interfaceReconfigure interface with vrf forwarding <VRF> and ip address under the interface; then show ip vrf interfaces
Interface shows administratively downno shutdown was not applied on the interface or subinterfaceEnter interface config and run no shutdown
Ping in VRF fails with "Network is unreachable"No default route or specific route in that VRFAdd an appropriate ip route vrf <VRF> ... or ensure the control plane (OMP/BGP) provides the route
Service routes appear in underlay/global tableRoute was configured in global context instead of VRF contextRemove the global route and reconfigure using ip route vrf <VRF> ...

Key Takeaways

  • VPNs in SD‑WAN are implemented as VRFs — each VRF is an independent routing & forwarding table. Think of them as virtual routers inside the chassis.
  • VPN0 is reserved for Transport (underlay reachability), VPN512 for Management, and VPNn for Service (user) LANs. Keep them separated to avoid leaks and maintain security.
  • Use vrf forwarding to bind interfaces to a VRF and ip route vrf <name> to configure routes scoped to that VRF. Verification commands such as show ip route vrf <name> and ping vrf <name> are essential to prove isolation.
  • In production SD‑WAN, OMP (the SD‑WAN control plane) typically distributes service routes between edges; local static routes are useful for lab scenarios but do not reflect full SD‑WAN dynamic route distribution. Always validate that management paths (VPN512) are out‑of‑band to preserve access during data-plane issues.

Tip: Always confirm the device’s management (VPN512) connectivity from an external NMS before deploying changes that could affect user traffic. In production, losing management visibility is a major operational hazard.

This lesson explained both the theory (why VRFs are used and how SD‑WAN maps VPNs to VRFs) and practical configuration steps you can reproduce in a lab. In the next lesson we will explore how controller‑based route distribution (OMP) populates these service VPNs across the fabric and how application‑aware policies use those VPNs for traffic steering.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security