In networking, when mutual redistribution between two routing protocols takes place at more than one point in the network, there is always a risk of routing loops. This lesson will explore the most common use case when a dual-homed site has two WAN edge routers doing route redistribution between the Cisco Overlay Management Protocol (OMP) and any site-local routing protocol running on the service side. Figure 1 represents this graphically.

OMP Route Redistribution at two places
Figure 1. OMP Route Redistribution at two places

OMP Route Redistribution

OMP supports route redistribution just like any other routing protocol in networking. 

Site-local protocol into OMP

By default, the vEdges automatically redistribute the following route types that they learn from site-local peers into OMP:

  • Connected
  • Static
  • OSPF/OSPFv3 intra-area
  • OSPF/OSPFv3 inter-area

However, to prevent routing loops, OMP requires network administrators to explicitly enable the redistribution for the following routing protocols, as illustrated in figure 2 below:

  • BGP
  • EIGRP
  • IS-IS
  • OSPF/OSPFv3 external routes

When OMP redistributes routes from legacy protocols, it sets the origin type in each vroute to reveal the route's origin. The origin type is then considered by the Cisco vSmart Controller when performing the OMP best-path algorithm. OMP also carries the original route's metric.

OMP into the site-local routing 

By default, vEdges do not automatically redistribute OMP routes into any legacy routing protocol. We must explicitly enable the redistribution for each particular local protocol on each vEdge router. This avoids excessive routing information coming from the overlay to the site-local portion of the network

OMP Default Redistribution
Figure 2. OMP Default Redistribution

Configuring OMP Redistribution

Site-local protocol --> OMP

There are two general ways of configuring OMP redistribution. The first one is to enable redistribution at a global level. We do that by entering the omp configuration hierarchy and using the advertise [protocol] command, as shown in the output below.

vEdge-1# sh run omp
omp
 no shutdown
 ecmp-limit       4
 graceful-restart
 advertise bgp
 advertise ospf external
 advertise connected
 advertise static

However, we might want to be more specific in most scenarios and enable redistribution of a particular site-local routing protocol in a particular VPN only. As shown in the output below, we do this within the omp configuration under the particular VPN-id.

vEdge-1# sh run vpn 5 omp
vpn 5
 omp
  advertise bgp
 !
  advertise network 10.1.5.0/24
  advertise aggregate 10.1.0.0/16
 !
!

In some situations, we might want to be even more specific and advertise only specific subnets or an aggregate. In such cases, we use the advertise network [prefix] command to advertise a specific prefix or an aggregate when a non-OMP route corresponding to that subnet is present in the respective VPN route table.

We can also stop the advertisement of any sub-aggregate prefixes and only advertise an aggregate, as shown in the output below.

vpn 5
 omp
  advertise aggregate 10.1.0.0/16 aggregate-only
 !
!

OMP --> site-local protocol

As we have said, the redistribution in the opposite direction, from OMP into the site-local protocol, must be explicitly enabled. We do that under the respective VPN, as shown in the output below.

vEdge-1# sh run vpn 5 router ospf     
vpn 5
 router
  ospf
   timers spf 200 1000 10000
   redistribute omp
  !
!

OMP Loop Prevention

The Cisco Overlay Management Protocol has a built-in loop prevention mechanism when interacting with BGP, OSPF, and EIGRP. In this section, we will explore the loop condition and the loop prevention mechanisms that OMP utilizes when it is being redistributed in each legacy protocol.

Site-local redundancy with BGP

We will start with the most commonly used routing protocol - BGP.

Loop Condition

The mutual redistribution between OMP and BGP makes the network susceptible to routing loops. Let's go through the example shown in figure 3 and see when it happen:

  1. vEdges 1 and 2 learn the 10.3.6.0/24 prefix via OMP from the vSmart controller and install the route in their respective VPN routing tables. The VPN id does not matter for this example.
  2. vEdges 1 advertises the 10.3.6.0/24 prefix into BGP.
  3. Onsite core switches/routers advertise the prefix back to 2 via eBGP.
  4. Here is where the loop can be formed. vEdge-2 learned the route via both BGP and OMP. Recall that OMP has an administrative distance (AD) of 250 and eBGP has an AD of 20! Therefore, in this case, the route via eBGP will be installed in vEdge-2's routing table due to a lower AD. This will create a routing loop since the eBGP route will remove the OMP route, which, in turn, will eventually remove the route via BGP and so on.
OMP into BGP Loop Condition
Figure 3. OMP into BGP Loop Condition

Loop Prevention

When redistributing OMP into BGP, the loop prevention mechanism uses the SoO (site-of-origin) extended community. Let's walk through the process using figure 4 below:

  1. vEdge-1 receives the prefix 10.3.6.0/24 via OMP. The route has a local AD of 250.
  2. When the prefix is redistributed into BGP, the router sets the SoO value to the OMP site ID value.
  3. The BGP route goes through the site-local iBGP peering to the other vEdge.
  4. When vEdge-2 receives the BGP update from the site-local BGP peering network, the SoO community matches its own site ID, so the router drops the BGP update.
OMP into BGP Loop Prevention
Figure 4. OMP into BGP Loop Prevention

All BGP peers in the network must send BGP extended communities and have the same site ID for this loop prevention mechanism to function properly.

The output below shows an example of an OMP route redistributed into BGP by vEdge-1 with site-id 1. You can see that the SoO community value is set 1 as the site-id.

R1#sh ip bgp 10.3.5.0/24
BGP routing table entry for 10.3.5.0/24, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  65001
    192.168.1.6 from 192.168.1.6 (1.1.1.1)
      Origin incomplete, metric 1000, localpref 100, valid, external, best
      Extended Community: SoO:0:1
      rx pathid: 0, tx pathid: 0x0

Site-local redundancy with OSPF

Let's now explore the loop condition of OSPF and then see what mechanism has Cisco SD-WAN utilized to prevent routing loops.

Full Content Access is for Registered Users Only (it's FREE)...

  • Learn any CCNA, DevNet or Network Automation topic with animated explanation.
  • We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.