Blog-Hero.jpg

Blog

Cisco SD-WAN Series Part 4 – Overlay Management Protocol (OMP)

In my last post we looked at the steps that a vEdge goes through to bring up its control plane connections and authenticate itself onto the fabric. In this post we will follow on from where we left off and see how we use these control plane connections to exchange topology information, WAN policies and security keys via OMP.

Side note: In the series I have been referring to our SD-WAN capable routers as “vEdges”. In recent months Cisco has released a SD-WAN image to run on its ASR1K, ISR4K and ISR1K platforms. These platforms when running this new SD-WAN image are being collectivity referred to as “cEdge” devices while the Viptela hardware continues to be called “vEdge” devices. The all-encompassing term when referring to both platforms is now “WAN Edge”. Going forward I will refer to our SD-WAN routers as WAN Edges since the features we will be covering are platform agnostic.

For this week’s post we will be focusing on our two branch sites 3 and 4. The diagram below can be used as a reference when looking at the screenshots and packet captures presented.

SDWAN Series Entry 4 image 1

I have shut down our second WAN transport PRIVATE2” to simplify our captures and streamline our command line output. WAN Edge router “E31” will be used in a future post on TLOC extension but can be ignored for today’s purposes.

OMP is the heart of the Cisco SD-WAN overlay routing solution. It runs inside of our DTLS control plane connections and forms a peering relationship between WAN Edges and vSmart Controllers. The diagram below depicts these peering relationships.

SDWAN peering relationships

Note that OMP peerings are never made between our WAN edge devices. This once again highlights our separation of control and data plane in the SD-WAN architecture.

OMP is a propriety protocol that is enabled by default in our Transport VPN (VPN0), so you do not need to configure anything to make it come up. As soon as our DTLS connections to our vSmart are established our OMP peerings will automatically be formed.

OMP peerings are formed between the system-IP of the two devices, and the protocol is responsible for the advertising service side prefixes and associated VPNs, data plane security parameters, overlay routing policy and transport network location mappings. As you can see from this list OMP does a lot more than your traditional routing protocol.

Ok let’s take a step back as I introduced a few new terms in that previous paragraph that we will need to know before proceeding with our OMP discussion.

Transport VPN – Defined as VPN 0 in our configuration. This special use VPN is associated with all the interfaces that connect to our WAN transports. Only interfaces in VPN 0 can create control and data plane tunnels. In our diagram above the red and green lines connected to our WAN Edge routers are in this transport VPN.

Service VPN – Defined as any VPN between 1 and 65530 (excluding 512). Interfaces associated with these VPNs are LAN facing. Our traditional routing protocols run in these VPNs. Each VPN can be thought of in the same way as a traditional VRF. Service VPNs cannot communicate with each other without an explicit policy being defined to allow the communication. In our diagram above the grey lines connected to our WAN Edge routers are in Service VPNs.

System-IP – is a 32bit number presented in the classic IPv4 dotted-decimal notation. Every node (vBond, vManage, vSmart, WAN Edge) in our fabric needs to have a single unique system-ip defined. This address lives in our transport VPN (VPN 0). You can think of the system-ip to be equivalent to a router-id that you would configure for our classic routing protocols OSPF, BGP and EIGRP. The system IP address does not need to be routable in your environment, although I always recommend to customers that they allocate system-ip’s from a valid range of ipv4 addresses allocated to the site where the WAN edge will be deployed. We can then make the system ip appear to be routable by creating a loopback interface in one of our service VPNs. 

OMP is responsible for advertising three different types of routes:

OMP Routes (vRoutes) – Prefixes that live in our service side VPN. These prefixes can be injected into OMP as either Connected, Static routes or redistributed in from BGP or OSPF running in the service side VPN. OMP routes require and resolve into TLOCs for functional forwarding. In comparison with BGP, an OMP route is the equivalent of a prefix carried in any of the BGP AFI/SAFI fields.

Transport locations (TLOCs) – Identifiers that live in our transport side VPN and tie an OMP route (vRoute) to a physical location. TLOCs are defined by the three components system-IP, color and encapsulation type. A TLOC is the only entity in the OMP domain that is visible to the underlay network. In comparison with BGP, the TLOC acts as the next hop for OMP routes.

Service Routes – Identifiers that tie an OMP route to a service in the network, specifying the location of the service in the network. Services include firewalls, Intrusion Detection Systems (IDPs), and load balancers. Service route information is carried in both service and OMP routes.

Ok time to try and put all this information together and take a walk through how a WAN Edge router builds its RIB from OMP. The below command output taken from our WAN Edge “E32” shows that both of our OMP sessions to our vSmart controllers “LP-vSmart-1” and “LP-vSmart-2” are in an up state and have been so for a little shy of 9 hours. The far-right hand column shows us the number of OMP routes that we have received and sent. In this example we are sending one route and receiving one route. Also, note that the route received from LP-vSmart-1 (1.1.253.1) has been installed into our RIB. LP-vSmart-1 route is preferred due to it having a lower system-ip.

SDWAN command output taken from our WAN Edge “E32”

Now I know that my OMP peerings are up and that I’m sending and receiving routes, but which routes are they? The below command output lets us view our OMP routing table. Here we can see that we are receiving the prefix 10.4.1.0/24 from both of our vSmart OMP peers and that LP-vSmart-1 (1.1.253.1) is the preferred route as it has been installed (“I” in status column). We can also see that to reach this prefix we need to leverage the TLOC {10.4.0.1, private1, ipsec}. Remember that our TLOCs are defined by {system-ip, color, encapsulation type}.

We can also see that we have redistributed (“Red” in the status column) our local prefix 10.3.1.0/24 into OMP and this is the route that we are sending to our vSmarts.

Finally note that both OMP routes are associated with VPN 1, this is the service side VPN number that we are using at both of our sites.

SDWAN E32 OMP Routes Table

So, we know that to send a packet to the 10.4.1.0/24 network we need to reference the TLOC {10.4.0.1, private1, ipsec}. The below command shows us what TLOC routes we have received from OMP, and we can confirm that we have received a TLOC matching the 3-tuple of values referenced in the OMP route above. Just like the OMP route we have learned this TLOC from both our vSmart controllers and are preferring the lower system ip of LP-vSMart-1. This TLOC advertisement gives our WAN Edge router all the information it needs to build a data plane ipsec tunnel to E41.   

SDWAN E32 OMP TLOCS TABLE

Let’s generate a icmp ping and capture the packets to see how they relate to the above output.

SDWAN icmp ping

Our 5 pings sourced from site 3 (E32) and destined to site 4 (E41) are successfully delivered.

Looking at the packet capture below we can see that these icmp pings were ipsec encrypted and encapsulated in UDP with a destination port of 12366 and a IP header with a destination address of 100.64.4.1 which are the same attribute values associated with our TLOC for the OMP route 10.4.1.0/24.

SDWAN packet capture

Ok that’s a wrap for now. In my next post I’ll continue with our lab and take a closer look at some of the attributes in our vRoutes and TLOCs and explain what they are used for.

Until then may your overlays and underlays routing never get leaked and your WAN bandwidth be plentiful and lossless.

previous blog vedge router bring up next blog cedge branch site integration

 

 

 

 

 

Written By: Chris Marshall, LookingPoint Senior Solutions Architect - CCIE #29940

If you are interested in having LookingPoint install SD-WAN into your network, feel free to contact us here!

CONTACT US

Subscribe to Our Blog

Subscribe to the informative Newsletter to be Notified Updates in the Technology world.

subscribe to our blog

CONTACT INFO

Phone Number: 925-566-3480

Email: sales@lookingpoint.com

HEADQUARTERS
391 Taylor Blvd. Suite 120
Pleasant Hill, California 94523
GET IN TOUCH
Join our mailing list to stay up to date and get notices about our new releases!

© 2016 Lookingpoint - ALL RIGHTS RESERVED