So as we've mentioned,
we are talking about running OMP between our Edge device here,
as well as our vSmart or SD-WAN controller upstream.
This is intended to help us scale.
Because as we look out across the scope of what SD-WAN can become,
we can truly have thousands or even tens of thousands of Edge devices.
So as we mentioned, if we're trying to full mesh peer among all of these Edge devices,
it would become unmanageable very, very quickly.
So we needed to have some kind of way to scale this out,
and the answer here is to form OMP peerings,
not between the Edge devices,
but between Edges and controllers.
Now, this goes beyond Edges and controllers,
because as we mentioned just a moment ago in the last video,
we could have multiple controllers,
and this could just be for redundancy.
Cisco typically recommends at least two vSmarts for redundancy.
I know in our lab environment,
at least the way that we have set it up,
we only have a single controller.
Perhaps in your lab environment,
you spun up multiples.
But either way, this is for the sake of redundancy,
which is very important even in small environments.
But as our network scales out,
we're going to find that we might actually want multiple vSmart controllers beyond two.
So maybe a third or a fourth or a fifth or even a sixth vSmart controller.
So once we do that,
we're going to start seeing that we do open up
more OMP peerings with all of these controllers.
Furthermore, these controllers are going to form
a full mesh of relationships among themselves.
So in our environment here with just a pair of controllers,
we would just form a OMP relationship between these.
However, let's say we have a third vSmart down here.
Now we're going to have a full mesh in this fashion.
So as I look at my edges out here,
we're going to have more and more edges forming relationships with the controllers.
But again, it's only one relationship per controller.
So this is where we start to see again that
route reflector topology start to build itself out.
Now also recall that these OMP peerings are not
formed natively just out in the open in an unsecured way.
OMP peerings are formed via control plane tunnels.
Yes, all of this is happening at the control plane.
We should also clarify that.
Remember, we've got orchestration and management planes as well,
This is where our controllers or our vSmart operate,
But the control plane, like the data plane,
does form these tunnels.
They're just slightly different tunnels.
It has been a while since we talked about this.
So just in quick review here,
at the control plane, we're going to form TLS or DTLS tunnels,
with DTLS being the default.
Now the primary, really the only difference between
these two tunnel types is that TLS is TCP-based,
and DTLS is UDP-based.
UDP tends to go through firewalls a little bit easier,
and it's lighter load,
and that's why it's the default setting.
However, if we have reason to want to use TCP,
either for the reliability or for
possibly firewall inspection and such,
then we can certainly switch that over.
So what's going to happen here is an edge will spin up,
and it will form a tunnel with the vSmart or the controller again,
and the OMP peering will happen inside of the tunnel.
This makes sure that everything that happens from
an OMP perspective is protected,
it's secured, it's encrypted,
and it's encrypted in this, again,
DTLS tunnel by default or TLS if we so choose.
Also keep in mind how the onboarding process really happens.
So we're talking about onboarding of a new edge device.
The edge device is going to go back and forth with the VBond or the validator,
and this is going to alert it to all of the controller IP addresses.
So we're going to learn about the different controllers
as part of the onboarding process,
and then this is when the edge starts to
establish communications with the individual controllers.
Just keep in mind that, yeah,
we've got these other control components such as the validator here,
such as manager, or again,
what used to be called VBond and VManage,
but these do not run OMP.
OMP strictly runs at the control plane,
it does not run at the data plane,
it does not run at the orchestration plane,
and it does not run at the management plane.
So OMP is truly reserved for edge-to-controller communication,
and then once again,
controller-to-controller communication as well.
Now, we're going to be injecting some CLI commands in here
just for the sake of being able to perform configuration and verification,
and certainly when it comes to OMP,
one of the ways that we can verify what's happening is to do a show,
and we might have to inject SDWAN in here,
show SDWAN OMP peers.
So keep in mind with our CLI configuration that anytime we're running iOS XE,
basically what we used to call C edges,
now we just call them SDWAN edges,
then we usually have to insert SDWAN in there to get the original Viptela command.
If I'm just running this on a Viptela device,
like for example, a controller,
the time of this video that still runs Viptela software,
then I wouldn't need the SDWAN because it's not running iOS XE.
But I can check out my OMP peers this way and find out what's going on.
So let's do a quick demo of that.
Let's flip over to our CLI,
and I'm on Edge 13.
So this is our lab environment.
So this Edge 13 device
is sharing routes with all of the other edges in the environment.
So if I do that show SDWAN OMP peers command,
I'm going to see what exactly?
Well, that I only have a single peer.
That's maybe the surprising thing.
I might expect, well, wait a second,
I've got all these other Edge devices in the network,
I should have a lot of peerings.
That's what I'm used to seeing in networking because I'm used to OSPF and EIGRP.
However, in this route reflector topology,
where I don't form relationships with other edges,
I truly only have one peering relationship and it says what type it is.
I'm connecting to a vSmart, which is a controller.
So when I look at the controller side,
and again, I don't have to do SDWAN here.
If I try to do that, it's not going to know what it is
because our controllers or all of our control components,
Cisco has yet to convert that in any way over to iOS XE.
So controllers are still running the telecode.
So I can just do show OMP peers.
Now I see that I've got four relationships
because I'm connecting to all of the other vEdges.
Oh, it looks like one of them is in a down state.
Well, I probably left some interface down, but that's fine.
So now if we had other controllers in the lab environment,
then we'd see those here as well.
But again, in our lab environment,
I only have one controller and so our relationship
is truly just limited to these four peerings.
We've got four Edge devices all communicating to the controller,
and in a environment where we only have one controller,
that's exactly what we'd expect.