This lesson will demonstrate the major differences between the Overlay Management Protocol (OMP) and traditional routing protocols.
OMP Routing Overview
Let's summarize what we have learned so far about the Cisco OMP protocol:
- WAN edge routers do not exchange control-plane information among themselves.
- WAN edge routers send routing information only to the vSmart controller(s).
- An OMP route for a given prefix points to a TLOC next hop. For example, 10.1.1.0/24 via TLOC (1.1.1.1, mpls, ipsec).
- For an OMP route to be valid and installed in the routing table:
- The next-hop TLOC must be resolved. For example, the router must have a TLOC route for TLOC (1.1.1.1, mpls, ipsec).
- There must be an overlay tunnel in UP state to the next-hop TLOC. For example, the router must have an active BFD session to TLOC (1.1.1.1, mpls, ipsec).
- The OMP route must be considered best.
All these statements sound very logical and easy to comprehend. However, there is a significant difference in the way OMP operates compared to a traditional routing protocol such as EIGRP and OSPF. We will use a simple topology shown in figure 1 to demonstrate these differences.
OMP Routing in Failure Scenarios
We will examine two different failure scenarios - direct failure in the overlay and indirect failure in the overlay.
Initial Topology
The topology that we will use for this lesson consists of four WAN edge routers connected to a single transport. vEdges 1 and 2 are located at the same site, so there is no tunnel between them. Everything else is by default. There is no policy applied on vSmart.
EIGRP in failure scenarios
To really understand the difference between OMP and traditional routing protocols and what they mean in practice - let's suppose we are running EIGRP as a routing protocol over the IPsec tunnels, as shown in figure 2 below.
With EIGRP, the next hop of a route is an IP address.
Let's focus on routers vEdge-3 and vEdge-4. vEdge-3's best route to reach 10.1.4.0/24 is through the direct tunnel IP3 - IP4. What will happen if this tunnel goes down? Will vEdge-3 lose connectivity to 10.1.4.0/24?
When the tunnel between vEdge-3 and vEdge-4 goes down, the EIGRP protocol will run the EIGRP Query Process and will ask all other routers whether someone has a network path to 10.1.4.0/24. Then based on the Query replies, vEdge-3 will install new routes to 10.1.4.0/24 in its routing table and will still have IP reachability to vEdge-4 prefix through vEdge-1/2. Figure 3 illustrates this example.
This is a very simplified description of the EIGRP convergence process. However, the main point is that - traditional routing protocols recompute the routing topology on every path failure. The topology changes and the routes in the routing table change according to the available network paths.
OMP in failure scenarios
Let's now examine two failure scenarios, but with the Cisco Overlay Management Protocol (OMP) running between vEdges and vSmart.
Direct Failure
Every WAN edge router advertises its locally connected networks to the vSmart controller via OMP. The controller then redistributes this reachability information to all vEdges. Next-hop of OMP routes is a TLOC. Figure 4 shows the routing tables of all routers.
Let's focus again on vEdge-3 and vEdge-4. vEdge-3's best route to reach vEdge-4's local prefix 10.1.4.0/24 is over the direct tunnel between T3 and T4. What will happen this time if this tunnel goes down? Will vEdge-3 lose connectivity to 10.1.4.0/24?
Let's find out by bringing the tunnel down.
vEdge-3# show bfd sessions | t
SYSTEM SITE DETECT TX
IP ID LOCAL COLOR COLOR STATE MULTIPLIER INTERVAL UPTIME
----------------------------------------------------------------------------------
1.1.1.1 1 biz-internet biz-internet up 7 1000 0:00:24:15
2.2.2.2 1 biz-internet biz-internet up 7 1000 0:00:24:31
4.4.4.4 4 biz-internet biz-internet down 7 1000 NA
Now if we try to ping between vEdge-3 and vEdge-4, we will see that there is no connectivity.
vEdge-3# ping vpn 1 10.1.4.1
Ping in VPN 1
PING 10.1.4.1 (10.1.4.1) 56(84) bytes of data.
From 127.1.0.2 icmp_seq=1 Destination Net Unreachable
From 127.1.0.2 icmp_seq=2 Destination Net Unreachable
From 127.1.0.2 icmp_seq=3 Destination Net Unreachable
^C
--- 10.1.4.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss
Figure 5 below explains what actually happens.
When the tunnel T3- T4 goes down, vEdge-3 no longer has BFD session in UP state to 10.1.4.0/24's next-hop T4. Therefore, vEdge-3 marks the route "10.1.4.0 via T4" as Invalid and takes it out of the VPN routing table, as you can see in the output below.
vEdge-3# show omp routes vpn 1 | t
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP
--------------------------------------------------------------------------------------------------
1 10.1.1.0/24 1.1.1.30 5 1017 C,I,R installed 1.1.1.1 biz-internet ipsec
1.1.1.30 8 1007 C,I,R installed 2.2.2.2 biz-internet ipsec
1 10.1.3.0/24 0.0.0.0 68 1013 C,Red,R installed 3.3.3.3 biz-internet ipsec
1 10.1.4.0/24 1.1.1.30 1 1020 Inv,U installed 4.4.4.4 biz-internet ipsec
The same process happens on vEdge-4. In the end, both routers lose connectivity to each other's connected networks.
Indirect Failure on an Intermediate Hop
Suppose we have applied a control policy that changes the next hop of vEdge-3's route to 10.1.4.0/24 to go through vEdge-1 and the next hop of vEdge-4's route to 10.1.3.0/24 to go through vEdge-2. Basically, vEdges 1 and 2 will be intermediate hops for the traffic between vEdges 3 and 4. Figure 6 shows this visually.
In this case, what do you think will happen if we shut down the tunnel T1 - T4?
When the tunnel T1 - T4 goes down, vEdge-3 still has a valid route to 10.1.4.0/24 with next-hop T1 and it sends the traffic to vEdge-1.
However, vEdge-1 now doesn't have an overlay tunnel to vEdge-4, so the route to 10.1.4.0/24 is no longer valid. The traffic is dropped!
Key Takeaways
This example highlights some important differences between the traditional routing protocols and the Cisco Overlay Management Protocol (OMP):
- With OMP, there is no auto-discovery of routing peers and next-hops as in traditional routing protocols such as EIGRP and OSPF. All nodes peer with vSmart and not between each other.
- Subsequently, the routing topology never changes (because the topology is an overlay).
- There is no topology recalculation when a tunnel goes down.
- The OMP routes to a destination prefix never change when a tunnel goes down. They go in and out of the VPN routing table depending on the BFD session to the next-hop tloc.
- What actually changes is only the reachability to the next hops.
Okay, what does that mean in practice?
Practically speaking, this means two things:
- We provide resilience in case of direct overlay failures with multiple tunnels to the same destination. For example, if we have two tunnels between vEdge-3 and vEdge-4, when one tunnel goes down, the traffic will simply go through the other.
- We must be careful when we introduce intermediate hops in the overlay traffic path. We provide resiliency in case of indirect overlay failures with a technique called end-to-end path tracking (that we will explore in the next lesson).