The control plane continues to be a big part of SD-WAN.
We've got a lot of information to share among all of these different WAN edges
and even
among some of our other control and management nodes.
Well this information is going to be shared with a protocol we refer to as the
overly management
protocol or OMP.
OMP is sort of like a routing protocol, except it's also sort of not like a
routing protocol.
And by the way, this is Cisco proprietary because it was developed by the Vept WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And by the way, this is Cisco proprietary because it was developed by the Vept
ella, the company
they acquired, and it's really only used within the world of SD-WAN, at least
at the time
of this recording.
We don't see it used on networks otherwise.
So what exactly is OMP?
Well I said it's sort of like a routing protocol.
I prefer to think of it as an information carrying protocol.
And some of that information can be routes, but it can also carry a lot of
other information.
In fact, this might sound familiar to you because if we've ever studied BGP, BG WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, this might sound familiar to you because if we've ever studied BGP, BG
P is also
an information carrying protocol.
I can carry a lot of different things besides just IP4 routes and IPv6 routes.
I can carry MAC address information if I want to and BGP because it's not built
strictly
for IPv4 routing, whereas OSPF and BG or EIGRP, they were developed
specifically and only
to carry IPv4 routes, which is why they had to come out with a new version to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to carry IPv4 routes, which is why they had to come out with a new version to
carry IPv6
routes because they couldn't carry them natively.
So even then, they built them to be only carrying IPv6 routes.
So kind of an interesting thing and a nuance, a difference between a true
routing protocol
like OSPF and EIGRP and an information carrying protocol like OMP and BGP.
In fact, more and more, I would refer to OMP as very BGP-like.
There's a lot of BGP-like behaviors with how OMP operates. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
There's a lot of BGP-like behaviors with how OMP operates.
For example, another similarity is that it uses TCP connections.
Most routing protocols, IGPs especially, don't use TCP, they use multicast to
find their
neighbors and they have to be directly attached.
TCP implies that I can have long range connections, which is important in a WAN
circuit space because
I need to connect across a layer 3 environment, which is my WAN circuits.
So I form a TCP connection knowing what the IP address is that I'm connecting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I form a TCP connection knowing what the IP address is that I'm connecting
to.
Furthermore, our V-Smart is going to operate as a route reflector.
Our reflectors in BGP allow us to not have a full mesh of adjacencies and
neighborships.
So I don't need to have all of my WAN edge devices appear with all of the other
WAN edge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
WAN edge
devices.
So instead, what we find is we've got a bunch of WAN edges down here and these
WAN edges
are all trying to communicate to one another and form tunnels.
But the question is, how do I take a subnet and advertise this subnet to the
rest of the
network?
Well, what I do is I send it up here to the V-Smart and this advertisement is
going to make
it so that I don't have to advertise it to the dozens or hundreds or thousands WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it so that I don't have to advertise it to the dozens or hundreds or thousands
of other
WAN edge routers.
Instead, I advertise it just to my V-Smart and the V-Smart pushes it down.
And this is that route reflector type of behavior because again, it prevents me
from having a full
mesh of adjacencies.
A bunch of EIG, RP routers all shared a space they would all be neighbors with
one another
and that's not perfectly ideal, especially not when we're talking about massive
scaling.
And one of the other important parts in all of this and again, it comes back to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And one of the other important parts in all of this and again, it comes back to
the fact
that it's an information carrying protocol is the fact that we're going to
carry attributes.
There's a lot of different attributes we can carry and so we might say that,
hey, you
can get to subnet A this way via this WAN circuit, but keep in mind, we've got
this other
WAN circuit over here.
And maybe for a particular application, I actually want to go this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And maybe for a particular application, I actually want to go this way.
Maybe this is my voice over IP packets and I want to send it via MPLS rather
than the
internet.
And so deciding on application-based forwarding, this is going to rely heavily
on more information
than just a subnet ID and how far away it is.
I'm going to use these attributes to make those types of forwarding decisions.
Now OMP has several different route types.
So when it's advertising, it's not just a single update like most of our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when it's advertising, it's not just a single update like most of our
routing protocols.
And just say, here's your update of a bunch of information.
And said we have three different types of routes that we share.
First of all, are simply OMP routes.
OMP routes are going to carry these subnets to advertise site networks so we
know how to
route between our end user subnets.
That's kind of one of the biggest parts of SD-WAN is being able to route from
subnet A to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
subnet A to
subnet B through this SD-WAN environment.
And so that's how we're going to have this.
It also is going to map these local subnets to our T-locks.
And that's going to be part of the glue that holds all this together because
then we can
look at a second route type which is a T-lock route.
A T-lock route tells us how to get to the T-locks.
So it's great that I know, for example, that if I want to get to subnet A, that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's great that I know, for example, that if I want to get to subnet A, that
I should
send to this specific T-lock, we'll just call it T-lock A.
So we're trying to send to this T-lock, but remember, a T-lock doesn't have an
IP address.
So how do I know where that is?
Well that's what the T-lock route does.
It maps a T-lock to the proper IP address for connectivity.
This allows me to build the tunnel to the remote T-lock and then I can then use WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This allows me to build the tunnel to the remote T-lock and then I can then use
the information
I get from the OMP routes so know how to connect the actual subnets.
Now the last type is a service route and the service route is going to allow me
to do
things like service chaining.
Service chaining enables me as an admin to force traffic to go a particular way
.
Maybe I want the traffic to go through a particular device in order to get ins
pected before sending
out to the rest of the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
out to the rest of the network.
So the service route gives me that opportunity.
So what we find at the end of the day here is that OMP is responsible for
sharing routes.
That's great, but it also allows me to push policy and it allows me to form
tunnels.
It brings everything together from a control plane perspective and we can see
why something
like EIDGRP or OSPF wouldn't do the job.
And even BGP, we could adapt BGP for this purpose, but we see that we want WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And even BGP, we could adapt BGP for this purpose, but we see that we want
these three
different route types and so there's a reason why Viptela and by extension
Cisco ended up creating
this custom protocol in order to carry all of the information needed to glue
our SD-WAN
environment together.