Another important part of the control plane is going to be that protocol we
just mentioned
the overlay management protocol.
OMP is really interesting.
We just mentioned that it's a protocol that isn't just designed to carry routes
.
We can carry routes, that's one thing we can carry, but we can also carry
things like
attributes.
And we can carry things like pieces of information such as T-locks and other
things, lots and
lots of other types of information.
This is known as an extensible protocol.
It's a very fancy word and it basically means that it's extremely flexible.
We can add to it.
We can include things in it that maybe the creators of the protocol didn't
originally
have in mind.
And this should remind us of another protocol, which is BGP.
Now BGP, just like OMP, is an information-carrying protocol.
I don't personally like calling this a routing protocol because it's
information-carrying.
It doesn't just carry routes.
For example, BGP can carry IPv4 and it can carry IPv6 and it can carry, for
that matter,
multicast routes and MAC address information.
It can carry whatever we want because it's an extensible, flexible type of
protocol.
You want to look at OSPF version 2?
This was IPv4 only.
To the point that if we wanted to carry IPv6 routes, we've got to run a
different protocol,
OSPF version 3, which is designed to run IPv6.
So we didn't want this static world, instead the creators of this particular
architecture
saw fit to deploy a protocol that's much more like BGP.
Now why didn't they just use BGP?
Well, because they had a few things that BGP wasn't actually able to do for
them and
so they just thought, "Hey, rather than use BGP and be limited by the things
they wanted
to do, they just created their own protocol."
As if they just were going down to the local store and buying a loaf of bread,
they just
went down to the local store and bought themselves or made themselves a
protocol.
So that's a pretty cool story.
So the way that OMP works is going to again continuously remind us of how BGP
works.
For example, when I'm looking at, let's say, an edge node forming a OMP adjac
ency or peering
with a controller, well, at this point, this is going to be a TCP connection.
Why is that so important?
Well, because we're not using multicast, which is a local concept, which again
is what OSPF
and EIGRP rely on, they want to find attached network or attached neighbors or
adjacencies,
not physically attached, but attached to the same subnet from a layer three
perspective.
So we use multicast, just a local multicast communication in order to find our
neighbors.
We can't do that because we might have lots of underlay routers along the path
here.
And so physically, we might have to pass through a bunch of different routers,
but we know that
there's this capability for us to form a, let's say, TLS connection between the
two
and now I can use TCP to form a connection across it.
So that's the idea of forming TCP peering and why it's so important that we're
able to
do so.
Furthermore, we might say, okay, cool.
So then if I have another edge device down here, I would form an OMP peering,
right?
Well, that's actually not how it works.
We want to scale this out.
And so if I have another edge device down here, I will form an OMP peering with
my controller,
but I will not form one with other edge devices.
So if I'm going to share, let's say, subnet information, well, I'm going to
have to share
it, which colors here, I'm going to have to share that information with the
controller
and the controller will reflect that information, so to speak, and send it down
to all of the
other edge devices that are in my network.
This should also feel a little familiar from a BGP perspective because this
turns the controller
into effectively a route reflector.
BGP requires on some level that we have a full peering of peering, a full mesh
rather,
of peering, there we go.
And so we can get around that requirement by configuring route reflectors,
which allow
for these more centralized devices to be the only ones that form relationships
with the
edge devices.
And so that's the exact architecture we're going to replicate here with OMP.
The beautiful thing about this is that this helps us out with scaling,
especially for
those very large networks with hundreds or thousands of edge devices.
We don't have to worry about a full mesh of OMP communications and peering
among all of
the edge devices.
They just don't actually form peering with one another.
They only form peering with the controllers or the v-smarts.
So what exactly are they propagating?
We keep mentioning its information.
That's great.
But what type of information are we actually propagating here?
Well, there are going to be three different route types that are handled by OMP
.
The first of which is known simply as an OMP route, pretty straightforward.
An OMP route is all about carrying our subnets.
So we're going to want to advertise again subnet A here so that subnet A and
subnet
B in the bottom left rather that they can reach one another.
Now how do they reach one another?
Again, we're going to form an IPsec tunnel here and we're just going to throw
our traffic
across the IPsec tunnel.
But notice that the data plane path is very different than the control plane
path in this
case.
In many networks, we would expect that the control plane and the data plane
kind of run
against one another, where I advertise a route to you via the control plane.
I advertise that route down and the data plane goes up against the flow of that
control plane
information.
Well, that's not technically the case here because I didn't tell you where sub
net A was
nor did you tell me where subnet B was.
Instead, it's the controller that told us via out of band communications.
And that's what's so fascinating about this architecture is again, we are
hearing these
routes, these OMP routes from the controller, and they let us know where all of
the subnets
are in the environment.
Now it is worth pausing for a moment and noting that OMP, this is SDWAN only.
We're not running this in our networks.
We're not suggesting anybody replace a GRP or OSPF with OMP.
That wouldn't make any sense.
It's also Cisco proprietary.
We're not going to expect that every SDWAN provider is running OMP.
Other providers and other architectures will be using different solutions.
So here's the question.
Now we tend to draw things like this where subnet A is attached from a layer
three perspective
to the edge device.
What if it's not directly attached?
What if we have something like this where I'm connecting down to, let's say, a
layer
three switch and this layer three switch maybe has a bunch of other layer three
switches.
But even if it's just a layer three switch connection, at this point we might
have lots
of subnets.
We might have subnet A as well as subnet D attached here.
So how does the edge know where subnets A and D are?
Well, the edge is capable of running these different protocols.
It can run EIGRP.
It can run OSPF or BGP for that matter.
We can run these different local routing protocols.
We could even run static and obviously connected routes.
But we have a choice over how to run internally to the rest of the network.
Again, I'm not running OMP internally.
I am only running OMP to the controller so that I can learn where all of these
networks
are.
So how do I know where all these networks are that I'm advertising to the
controller?
Probably via internal routing protocols.
So just wanted to pause the OMP conversation to make sure we understand how
does this
edge device know where all of the downstream subnets are if they're not locally
attached.
So at this point we see that we're sharing OMP routes.
Now I know where subnet A is and subnet D lives.
And the top edge knows where subnet B lives.
So that's cool.
So we know where these are.
And so we can actually send across the IPsec tunnel to one another in order to
enable traffic
flow from a data plane perspective.
So the OMP route is going to help us out with that.
The other one, which we've already mentioned, is going to be the T-lock route.
The T-lock route is going to let me know how to reach a T-lock.
Because that's not actually part of the T-lock itself.
Now why don't we just embed that into the T-lock?
Well, because this information could change.
This could be dynamic.
And which is why it's part of a dynamic routing protocol like OMP.
And so we want the T-lock this to be static.
For the most part our T-lock information isn't going to change.
Think about that three tuple.
The system IP should never change.
The connection, the WAN connection point, that should never change either.
Because if I create a new WAN link or get rid of a WAN link that kind of scraps
the T-lock
altogether and neither should the IPsec versus GRE ever change.
This is intended to be very static.
Meanwhile, how I connect to the T-lock via this IP address or this IP address
or this
IP address, well, that could change over the course of time.
Maybe my WAN service provider provides me with a new IP address for one reason
or another.
Or I put it behind a router and now it's got a completely different IP address
for connectivity.
So the T-lock route is going to dynamically update my edge devices with
information on
how to connect to remote T-locks.
So that's the purpose of that route.
And then lastly, the third one is known as a service route.
The service route gets into more interesting elements of the software-defined
nature of
SD WAN.
It's going to allow for things such as service chaining.
Service chaining is when I want to, let's say, take a packet that comes into a
router and
it's destined for subnet A, maybe I say, you know, it's great that you're
destined for
subnet A, but I want to send that traffic through a firewall first.
And so I send it to the firewall and I use encapsulation in order to accomplish
that.
So that's all we'll say about service chaining for now, but it is an important
part of software-defined
networks to be able to do things like that and the service routes will help us
get there.
Now, one last aspect of OMP is that OMP is also going to be responsible for our
policy
enforcement.
This is important because when we think about SD WAN, one of the advantages of
SD WAN is
getting onto that manager, create and creating policy in a single place.
I might want certain traffic types to take certain WAN links.
So how do I enforce that?
How do I tell an edge that, hey, that's great and all, but now this is voice
over IP traffic
coming in and I want that traffic to go a different way?
Well the way I do that is the policy enforcement thanks to OMP.
OMP can control different routes and by doing so, it results in the policy that
I'm trying
to deploy.
So this is one of these, we use this fancy word called abstraction.
The idea here is that me as the network engineer, usually I have to directly
create the configuration
for something like this.
And this gets very, very complicated especially for large networks.
But abstraction says rather than it being a direct relationship here, now I as
the admin,
I create the policy and the policy is going to be what performs the
configuration thanks
to my manager.
So I create the policy and the manager, the manager performs the configuration
using all
of the APIs that we've talked about, usually pushing it down via OMP or
possibly via net
comp or something like that.
But in the end, what we're talking about here is the fact that I as the admin
get to
create the policies and that policy does get enforced thanks to my OMP, the way
that I'm
distributing my routes.