Service VPN with OSPF on the LAN

A service VPN is just a VRF that carries user traffic. In this lab, VPN 10 already moves a LAN prefix from one site to the other through OMP, without OSPF. OSPF enters the picture when the LAN itself has an IGP: switches or CE routers that do not speak OMP and expect the WAN edge to look like an ordinary OSPF neighbor.

This post starts from the service VPN that is running on Cisco Catalyst SD-WAN 20.18.2.1 with C8000v routers on IOS XE 17.18.02, built in my home lab. It then explains how OSPF would plug into that VRF. I did not add an OSPF process. There is no LAN OSPF speaker here, and I was not willing to invent a neighbor just to print an empty adjacency.

This is part of the Cisco SD-WAN series. Previous: Template variables and bulk CSV attach. Next: Service-side BGP and route redistribution loops.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

The problem: the LAN does not speak OMP

Hosts at a branch need a default gateway. Remote subnets have to come back to them. OMP, the Overlay Management Protocol, is how SD-WAN edges share those subnets with each other. A campus switch or a CE router does not run OMP. It usually runs OSPF, or BGP, or just a static default.

So the WAN edge does two jobs in the service VRF:

• Face the LAN with a protocol the LAN understands.
• Face the overlay with OMP.

Think of OMP as the WAN-facing route reflector session, and OSPF as the conversation with the building next door.

What this lab already proves without OSPF

VPN 10 is up on both edges. GigabitEthernet4 is in that VRF. OMP advertises connected routes, so each site's LAN appears at the other site.

edge1:

interface GigabitEthernet4
 no shutdown
 vrf forwarding 10
 ip address 192.168.10.1 255.255.255.0

omp
  address-family ipv4
   advertise connected
   advertise static

edge1#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.2

The far prefix arrives as an OMP route, code m, administrative distance 251, via edge2's system-ip 10.0.0.2. The matching OMP table shows the local prefix sourced from 0.0.0.0 with status C,Red,R (chosen, redistributed, resolved) on both colors, and 192.168.20.0/24 learned from the Controller at 1.1.1.2.

edge2 is the mirror: connected 192.168.20.0/24, OMP toward 192.168.10.0/24. show ip ospf neighbor is empty on both boxes. show ip bgp summary returns BGP not active.

That is a complete service VPN for stub LANs. OSPF is optional until something behind GigabitEthernet4 needs it. I also did not add an OSPF parcel to the unused configuration group in Manager. The group still has only an empty System profile and no devices.

How OSPF would join this VRF

Cisco documents OSPF in any VRF except the transport and management VRFs. On IOS XE in controller mode the process is bound to the VRF:

router ospf 10 vrf 10
 router-id 10.0.0.1
 network 192.168.10.0 0.0.0.255 area 0
 redistribute omp

I did not commit that block. The network statement would look for neighbors on the VPN 10 LAN. redistribute omp would take remote OMP prefixes, such as 192.168.20.0/24, and present them to the LAN as OSPF routes.

The other direction is mostly automatic. Cisco's OMP redistribution guide says OMP advertises OSPF intra-area and inter-area routes without extra configuration. OSPF external routes need an explicit statement:

omp
 address-family ipv4
  advertise ospf external
  advertise connected
  advertise static

If the LAN injects external (type 5 or NSSA) prefixes that you want in the overlay, add advertise ospf external. Internal campus routes should show up in OMP after the adjacency is up.

Two edges at the same site that both redistribute OMP into OSPF can create a loop. Cisco relies on the OSPF DN bit in external LSAs, the mechanism in RFC 4576 and 4577, so an edge does not install those redistributed externals back into its own RIB and re-advertise them to OMP. Treat that as documented behavior. I did not build a dual-edge OSPF LAN to demonstrate the bit.

Verify the service VPN you actually have

When you do add OSPF later, keep these four commands. An adjacency without the prefix in show sdwan omp routes means OMP is not advertising it. A prefix in OMP that never appears on the LAN means redistribute omp is missing or filtered.

What breaks

• Expecting OSPF because VPN 10 works. This lab redistributes connected routes. No IGP is required for two stub LANs.
• Redistributing OMP into OSPF on two edges at one site without understanding the DN bit. Cisco documents the bit as the loop brake for externals. Read that guide before you dual-home a campus.
• Advertising OSPF externals without `advertise ospf external`. Internal routes go; externals stay local.
• Running OSPF in VPN 0. Cisco points service-side IGPs at service VRFs. VPN 0 is the transport side.

Key takeaways

• VPN 10 in this lab already extends each site's LAN across the overlay by advertising connected routes into OMP. I confirmed that on both C8000v edges.
• OSPF is the LAN-facing protocol you add when something behind the edge does not speak OMP.
• Cisco auto-advertises OSPF intra-area and inter-area routes into OMP. Externals and the OMP-into-OSPF direction are explicit.
• I did not start OSPF here: there is no LAN neighbor to form, and an empty process would not teach more than the service VPN we already have.