All right, we have a little bit of a situation on our hands that we need to
address and this has to do with how OMP is going to carry routes, which is very
similar, by the way, to how BGP carries routes in an MPLS world.
So what are we talking about here?
Well, keep in mind that I've got an edge router here or an edge device that
might be connecting to two different customers.
So we're talking about the concepts of the VPNs. So we've got VPN 10 here. We
've got VPN 20.
And I now need to advertise these routes into the SD WAN domain.
And then on the other side, I need to separate those routes again so that any
routes that are advertised via VPN 10 only go to the VPN 10 customers and same
with VPN 20 going to VPN 10.
And I'm going to VPN 20 customers. But the interesting part lies right in here.
Because it'd be one thing for me to say, okay, I'm going to run a writing
protocol instance here, and maybe a different writing protocol instance here.
If I was running EIGRP, maybe it could do different ASN's. If I was running OSP
F, I could do different processes.
This is just a single OMP instance. So if it's one OMP or routing protocol
instance, then how am I separating these routes? Because VPN 10 could have a 10
.0.0.0/24 subnet and VPN 20 could also have this, which makes sense because if I
have multiple customers, I can't go around telling them which subnets they're
allowed to use and which subnets they're not allowed to use.
If they want to both use this subnet as a private RFC 1918 address, then they
should be able to do so.
But now again, I have a single instance. So I now have two routes that I'm
advertising.
And boy, do they look the same because they are the exact same. So not only do
I have to make sure that I keep these separate, but I also have to make sure
that I'm able to separate them out.
So I'm going to do this once they get to a point where they can be separated
out. So how am I going to accomplish this? Well, this leads to our conversation
around route distinguishes and route targets. Let's start with route
distinguishes.
As the name implies, we are going to aim to distinguish or make unique our
routes.
Down here, we see that our routes are not unique. Right now they are identical
to one another. This is truly a duplicate route at this point. We need to do
something to them in order to make them unique or in order to distinguish them
from one another.
The way we're going to do this is we're going to create an eight byte tag of
sorts.
And yes, eight bytes is a whole lot. If we think about an IP address, it's four
bytes, which is 32 bits. This is eight bytes, which is 64 bits. And the reason
we have that many is because these service provider networks can be very, very
large.
We can have thousands and tens of thousands and potentially hundreds of
thousands of different customers. And every one of those customers needs its
own route distinguish or tag in order to make their routes unique within the O
MP or an app.
OMP or MPLS world, whichever one we're talking about here.
In our Cisco configuration, what we're going to find is that within our VRF
configuration, we're going to map an R.D. And this R.D. is going to have a
specific format. It's going to have a number and then a colon and then another
number.
We're going to separate out this many different bytes to make it a little bit
more human readable because eight bytes is we get into astronomical numbers of
routing distinguishes here and we could have very, very large numbers.
So let's split them up and maybe make something that we you and I can just read
and compare to other route distinguishes.
So let's say, for example, we've got these two customers and I create a route
distinguisher that's 10, 10 for VPN 10 and a route distinguisher that's 20, 20
for VPN 20.
Well, because this is a tag that gets added on to a route, say route to the
extinguisher, I'm now going to add these on down here to the routes.
So we sort of prepend the route with the route to extinguisher and now these
routes have become unique.
There's a total here now of 12 bytes of information, eight bytes are the tag
and four bytes are the IP address.
And when you look at all 12 bytes together, these will always be unique so long
as everybody has their own route to extinguisher.
Now the network in here, OMP in our case with SD-WAN, is able to look at these
and know, hey, this route does belong to VPN 10 and this route belongs to VPN
20.
And I know that because there's a route to extinguisher on the front of the
route, which makes it clear which route belongs to which customer.
It's worth noting, by the way, that these route distinguishes are arbitrary
from a technical perspective.
Meaning that there's nothing about the tag that's going to tie back to the VRF
name or ID or anything like that.
So I did use 10 10 here. I could have easily have used 1537.
You know, the numbers are completely arbitrary, but I do need to make sure that
everything is currently configured and make sure that whatever RDI choose is
deployed consistently throughout the environment.
So as long as I assign it correctly, it can be any number that I choose.
It doesn't have to contain the VRF ID or the VPN ID in the case of the SD-WAN.
Now we're not quite done with the conversation because we also need to talk
about route targets or the RTs.
So the route targets are about traffic control. We have kind of made an
assumption here, which is to say that because I have this route tag of 10 10 in
our case, and I know that belongs to VPN 10, that that means I will
automatically advertise those routes off of this router into the VPN 10 space.
And that probably is going to be true. However, it's not going to be true until
I configure a route target.
So what route the route target does is allows me to decide which RDs I'm going
to import into a VPN or a VRF will say.
And which ones I'm going to export out of a VRF.
Now in a simple environment, this is very straightforward. For example, with my
router here, I've got a VPN 10 space, and this is going to amount to a VRF
configuration on a Cisco device. So let's say it's VRF 10.
So I know that I'm using an RD of 10 10 here. And so I'm just going to specify
a route target that says I'm going to import any routes that have a Distingu
isher of 10 10.
And I'm going to export out all of the routes as they come in as well with a
tag of 10 10. So again, traffic control. We're being very explicit as far as
which routes are allowed in and which routes are allowed out.
But we do see again in a simple environment that these are all going to be sort
of the same route Distinguisher. It's all one to one.
Where this can get a little bit more complex is when we want to do things like
route leaking between VRFs. So if I want routes that maybe I advertise globally
and I want to put that route into many different places, maybe I'm the service
provider and I want to inject a default route.
Well, now I might need to import other routes from other spaces. So that's
where it gets a little bit more complex. But in our environment in the SD WAN
world, we're trying to connect VPN 10 locations to VPN 10 other locations and
make sure the routes stay consistent between them.
This is going to stay a little bit more simplified, fortunately, by keeping
that at that one to one ratio.
Now, just to drive the point home, let's go ahead and flip over to the CLI here
. We're on edge 11. Remember, in the last skill, we took a look at or we
deployed rather VPN configuration to edges 11 and 12. They're both managing VPN
s 10 and 20.
And that becomes VRFs within the Cisco CLI. So if I do a show run VRF, which is
a classic iOS command, I can look at all the configuration from the VRF
perspective. So notice what we have here. We have VRF definition 10, which is
telling us this is VPN 10.
Remember, Cisco takes the VPN ID, turns into a VRF ID within the configuration.
We see a description here, which is nice customer 10. And then the route, Dist
inguisher.
Now, they're not using 10 10. They're using this format of one colon 10. And we
can, you know, just take that again as an arbitrary value that they've assigned
.
And it becomes significant. So long as we are deploying it correctly to all of
the other sites. So we just want to make sure we're consistent within VPN 10.
We have that route, Distinguisher everywhere. So the route, Distinguisher is
one colon 10 here. And then within the address family for IP before. This is
where we see these route targets saying that we want to export and import that
same route
Distinguisher. So fortunately, again, in an SD went environment, for the most
part, we're just going to keep this very simple and have the same RD on all of
our RTS. If you work in the service provider space, this might get a little bit
more complex from a single organization perspective.
A special if we only have one VPN everywhere. But even if we have a couple VPNs
, we're probably going to see that it's just matching the route Distinguisher
with the route targets.
So no one to see or wanted us to see this from a CLI perspective, because this
configuration has already been done. We use manager, the UI to push that
configuration down to edge 11 here and edge 12 as well.
But now we have to configure edges 13 and 14 and we're going to have to do that
via CLI because that's our CLI site. So if we're going to perform VRF and VPN
configuration over at a SD WAN location, edges 13 and 14, for example, we are
going to have to be comfortable with what the RD and RT means because we're
going to have to actually configure these within the VRF definitions.