So how does OMP facilitate the distribution of routes in our environment?
Well, this is going to come down to, first of all,
how exactly do we know what routes need to be advertised?
So we've got an edge,
let's say this is similar to our lab topology.
So this is edge 11 here,
and edge 11 has a subnet behind it, subnet A.
I say behind it relative to the wide area network.
So here's our transport.
We've got the underlay happening here.
We've got edge 13 on the left,
maybe edge 12 down here,
and we've got all of our tunnels formed.
So what's happening is that we have a connected route here,
and as we've said, connected routes are going to be
automatically distributed into OMP,
which is really convenient.
At this point, we've actually seen
OMP distributing routes in our lab environment,
even though we haven't told it to do anything.
We've not done a single line of OMP configuration.
We haven't used manager to push any configuration down,
and yet we see that edge 13 over here,
when we look at its routing table,
that it is going to insert subnet A,
and it will have learned subnet A via OMP.
Now, always keep in mind that when we are talking
about client subnets that are
hanging off of an SD-WAN environment,
that this must be part of a service side VPN.
VPN is just a fancy way of saying VRF,
and so when we say that this is,
let's say VPN 10,
this becomes VRF 10 on our Cisco devices.
So this routing table on the right really is
part of a specific VRF, in our case, VRF 10.
If I have another subnet B,
well, then maybe that's part of VPN 10,
maybe it's part of VPN 20.
It just depends on the environment.
If we're just running a single organization's network,
it's probably all part of the same VPN.
If we're running a service provider network,
then maybe there are more VPNs involved.
Either way, just worth noting that
routing tables are going to be specific to the VRFs.
We could actually, in a lot of situations,
say that a VRF is simply its own routing table.
We could almost flip the definition on its head and say,
we could say that VRFs simply are different routing tables.
So we have the default routing table,
which points into the underlay.
We have the routing table for VPN 10,
and the VPN zero over there.
That points to the service side subnets.
So we might have a subnet over here.
Let's say this is subnet B, now attached to 13.
And likewise, because it is connected to edge 13,
this gets advertised into the OMP environment.
OMP distributes it.
Again, we've got our controller here.
So we pass these routes to the controller.
The controller acts as a route reflector
and pushes them back down.
And so now I know where subnet A is on the right.
On the left, our routing table for VRF or VPN 10
is going to have subnet B that I learned via OMP.
And therefore, when a device on subnet A
wants to send a packet destined for subnet B,
this router knows what to do.
It checks its routing table.
It sees that subnet B was learned via OMP
and specifically which edge it belongs to.
And then it sends it in the appropriate data plane tunnel
to edge 13, which then delivers it.
And by the way, this works just fine in reverse as well.
So we send a response packet back towards subnet A,
edge 13 knows that subnet A is attached via OMP
to a specific edge, and it sends it back over to edge 11,
which delivers it to the end host.
All of that was facilitated
because when we look at OMP distribution of routes,
that our connected routes are automatically distributed.
We didn't have to configure anything.
Just the fact that the subnets are attached
to the edge itself as part of a specific VPN,
that means that it gets injected into that routing table
and advertised via OMP.
That's great.
What if we have something other than connected routes?
In fact, that's going to be pretty common in the real world.
I might well have a layer three switch down here.
And one thing that layer three switches are really good at
is managing many subnets.
So I might have many VPNs for many different hosts.
If I'm a good network engineer,
I'm dividing my network up into smaller subnets.
maybe 10 or even 20 subnets or something along those lines.
So I've got subnets.
What are we up to now?
C and D and E and F and G.
And so we've got, that's a queue.
All right, we'll say subnet queue.
Not sure why that came out,
but we've got a lot of subnets here
and none of them are attached to edge 12.
In fact, I've got a layer three link
probably between the layer three switch and edge 12.
So that layer three link is its own subnet.
We'll call it subnet G
since I skipped over subnet G earlier.
We don't want to rob it.
So subnet G is here.
So now we've got a lot of subnets at this site.
This looks like a little bit more of a mess.
How do we go about letting all these other sites
Well, this is where the concept of redistribution of routes
comes into play and it's a very important part
of distributing our routes through OMP in general.
The idea here is that I can take routes
that I learned from OSPF or EIGRP
and I can now advertise these intentionally into OMP.
So that means a couple of things.
First of all, I need to pick one of these protocols.
It could be OSPF, it could be EIGRP, it can be BGP.
We've got lots of options available.
And this relationship is going to be established
between some downstream device,
let's just call this switch one,
and then an edge device, let's call this edge 12.
And these are going to be running this protocol.
So let's just pick OSPF.
OSPF is going to run now between edges 12,
or edge 12 rather, and the layer three switch.
So great, now we have run OSPF.
And yes, I can configure OSPF via the CLI
and I can configure it via the graphical user interface
by logging into manager.
I can make sure that OSPF is running and forms adjacencies.
We call them adjacencies in OSPF,
neighborhoods in EIGRP.
It's the same thing.
They're just peering with one another
and they are intending to share routes with one another.
So that's the first step.
We have to run a routing protocol of our choice
as long as it's supported by SD-WAN
and these protocols specifically are supported.
Something to keep in mind is that EIGRP
is a relatively recent addition to this solution
because it's Cisco proprietary
and Viptela was not able to support it
before they got acquired by Cisco.
So they would run OSPF or BGP,
and that was the extent of it.
But now we can run EIGRP as well.
At this point, the next step
is to advertise those routes into OMP.
So now this edge, edge 12 is aware
that there is a subnet C and a subnet D
and a subnet E and a subnet F and a subnet Q.
And those are all learned via OSPF.
So these show up as OSPF routes in the routing table.
But now I'm going to turn around and advertise them
to the controller via OMP.
So they become OMP routes.
And then once again, the controller's job
is to push those OMP routes down to these other locations.
So it doesn't matter if it's connected or not.
Yes, connected routes are automatically
advertised everywhere.
However, we can absolutely set up OSPF or EIGRP or BGP,
and we will perform this later on in the lab environment
to make sure we know how this all works.
Now, one last piece in all of this,
which is kind of interesting,
has to do with OMP path selection.
We are going to unpack this more in greater detail
later on, but I want to leave us with this.
Think about the fact that usually
we have two transports here.
So I've got another transport down here
and I probably have connections.
Let's just look at edges 12 and 13.
So edges 12 and 13 have connections
into this transport network,
which means they can communicate to one another
one of two ways.
We can either go through the original transport
Interestingly, edge 13 is going to have OMP routes
that tell it that it can, let's say, get to subnet C,
and I can go to TLOC1,
which would be on the old transport here,
or I can go to TLOC2, which would be the new transport.
In fact, this is realized first by the controller,
and we might have many different TLOCs
that are part of this if we have multiple transports
and if we have multiple edges at each site.
The controller is going to realize that this subnet
is accessible multitude of different ways,
which is not just a matter of saying,
hey, just come here to this edge device.
Maybe it's also edge 11 if it happens to connect in
to edge 12, or maybe it's through another transport network.
So the question is, how do we decide
which one of these paths to take?
And for that matter, what if I have so many paths
that I'm not able to advertise them all?
Well, this is going to come down
to our path selection criteria,
which is something that we're going to have to look at.
But we do need to recognize
that as these routes get advertised,
that the controller is going to have some decisions to make
as far as which routes to prioritize over other routes
if it appears to be the same,
or at least if those subnets are accessible
through a variety of different WAN links
and a variety of different edges.
Thank you.