Well if you're working your way through the course sequentially, we just got done
looking at OMP and how OMP routes propagate. And so we want to look at our
lab topology and we know, let me just bring the lab topology here onto the
screen, we know that our lab topology looks like this. We've got edges 11 and
12 over on the left there and edges 13 and 14 on the right. Each one of these
edges at this point has a connection through internet and through MPLS. Yeah
we don't have physical connections necessarily in all cases, but those T-lock
extensions make it so that our overlay topology is symmetrical. We truly
have connections going to each edge through each service provider cloud, or
in our case little layer two switches. And so what we want to do now is we want
to make sure that the OMP routes match up to that and for that matter what does
it look like at the routing table. And when we're looking at the actual
routing table that we're used to looking at on iOS XE devices. Now I've
got the perspective changed a little bit here from our normal one, made the text a
little smaller and stretched it out. And the reason for that is because we're
going to use a command show SD-WAN OMP routes. This is a Viptela command and so
we have to insert SD-WAN here in the middle. But when I hit enter here it
gives us a whole lot of information and it doesn't look very good if we're using
large text or squishing it down. In fact it still doesn't look great admittedly
even with this resolution. But I want to pay attention to a couple of things. Now
we are looking at this on edge 11 and so when we pay attention to the prefixes
that site 11 or edge 11 is aware of, we can look at 10.10 and then dot the site
ID. So we've got these edge subnets that are part of a VPN. So this right here is
indicating as part of VPN 10. The site at dot or the subnet at site 11 is
locally attached. And so this could the status right here RED means that
we're redistributing that. So that's a good indication that this is not
something I learned from SD-WAN directly. It's something that I learned
downstream of SD-WAN. Now these other statuses are very important. See if we
scroll up here we see C means chosen. This means I'm choosing this route right
there. It hasn't scrolled up all the way. So we are choosing this route and then
if we're installing it there should be an I there. And if we can resolve it
meaning we can get to it then there's an R there. Now if I look at the path here
I'm not actually installing an SD-WAN path for this subnet. That's why we see
redistributed instead of installed. But for like site 12's subnet 10 dot 10 dot
12 dot 0 slash 24 now we see C I and R. So if there's a subnet that's being
advertised out in the SD-WAN space and I'm expecting that I'm going to be
learning it at this site then I would expect to look at this OMP table and see
C comma I comma R. That's what I'm expecting to see. Conversely if I have a
route that's downstream of me and I should be advertising it into the SD-WAN
space then we should see C comma red comma R like what we have right here. So
from here we want to take a look at some other aspects of this table. Specifically
let's take a look at the subnet for site 12 and notice we have this from peer
column. So this is saying that we're learning this subnet from two different
peers and notice they have the same system IP address. So a couple of things
here. First of all this is a system IP address not an IP address tied to the
TLOCs. So when I look at all of these routes that I'm learning from the SD-WAN
space a lot from you know really two subnets from VPN 10 and then I'm only
learning of one subnet from VPN 20 down here. But I'm learning it all from the
same peer. So this is an edge device. So what is my peer? Edge is only peer with
vSmart or SD-WAN controllers. So my SD-WAN controller in my lab environment
here is 3.3.3.3. So this is the one that I'm learning it from. Good to know that.
If I have multiple SD-WAN controllers then this IP address might vary
depending on how I'm deciding which SD-WAN controller to learn the routes
from. So from here we notice that again I've got two different paths. So what are
those two paths? Because saying it's learned from the SD-WAN controller or
the vSmart doesn't really help me out a whole lot in terms of getting to that
subnet. Instead what we see is all the way over here we see a TLOC IP as well
as a color and an encapsulation. So remember this is the three tuple
that exists inside of a TLOC. If I scroll a little bit to... I can't actually
scroll that so that's fine. We can see that we've got the color encapsulations
over on the right. It actually just says IPsec for all of these. And by the way be
sure to run this command in your own lab environment so you can follow along. It's
probably a much better resolution. But in the end we see that we've got a TLOC IP
address. So for example I'm learning of site 12 subnet from edge 12 and that
makes sense that I'm learning from both or both of these routes I'm learning
from the same edge. And then from here we can see the B for bizinternet and the M
for MPLS and so we're learning it on two different colors. So that makes sense. Now
edge 13 is advertising a site as is edge 14. So remember our topology. Once
again edges 13 and 14 are at one site. Site 13 there's a subnet over here that
we are both advertising. And so what that subnet is 10.10.13.0.24 and because I'm
learning of it from two different peers on two different TLOCs I actually have
whoops four different advertised paths. So I see that all of them are getting
installed. They're all chosen installed and resolved. And now I notice that I'm
getting two routes from edge 14 and two routes from edge 13. If I look at the two
routes from edge 14 I see that this top one is MPLS this bottom one is biz
internet. And likewise when I look at the two for edge 13 I see that one is from
MPLS and one is from biz internet. So that's expected. When I look at my
topology here I'm looking at this from edge 11's perspective and edge 11 is
trying to get to this subnet that's shared behind edges 13 and 14. So I know
I can go through the internet to edge 13. I can go through the MPLS to get to edge
13. Remember that does take this path as a TLOC extension but from an overlay
perspective it really is just this connection right here that we can pay
attention to. Whoops and like that. And then it can also go through the
internet to get to edge 14 as well as MPLS to get to edge 14. So those are my
four different paths and I see those four different paths right here being
advertised with two coming from 14 and two coming from 13. So that is doing
exactly what we expect it to do. And so let's go ahead and see how this ends up
applying to the routing table. So I'm gonna do a show IP route. Now keep in
mind if I do show IP route and I hit enter we're gonna get really confused
really fast. I don't see any of those subnets in here and the reason for that
is because the default VRF matches to VPN 0. So I'm not going to see any of my
service VPN subnets listed in the default routing table. Instead I need to
say show IP route VRF and then the VPN number. So in my case VPN 10 is VRF 10. So
I hit enter and now this is very interesting. So reading the iOS XE
routing table first of all little m means OMP. It's right here now listed. So
that's good we've got OMP routes. We've got OMP routes to the subnets. So 10.10.12
and 10.10.13 both of them are listed right there. But what do we notice here?
This is kind of interesting. So first of all we'll notice that we've got the
administrative distance that we've talked about. OMP gets a AD of 251 on
iOS XE devices. Viptela had it at 250 on their devices but 250 was already taken
by Cisco and so they had to use 251. So there wouldn't be a tie. Meanwhile the
via address. This is normally a next hop that tells me how to get to where I'm
going. In fact it's supposed to give me the next IP address so I can run an ARP
or possibly send it across a serial link. But either way I should know where I'm
sending it based on this information. This information is an unroutable IP
address that's used as the system ID. This is basically just inserting the
Tlock IP address which is very interesting. And then I also see that
this is via a SD-WAN system interface. So that's some sort of internal marker
in there rather than a physical interface like GigEthernet3. It's this
system interface for SD-WAN. And the big thing we probably have noticed by now is
that we had said that we have two paths to this subnet yet I only have one entry
in the routing table. And we said that we had four paths going to this subnet
and I only have two. So what is going on here? Why do I have half the number of
routes? I have one where I should have two and I have two where I should have
four. Well this has to do with the fact that iOS XE is sort of running a bolted
on version of SD-WAN, the SD-WAN code. So SD-WAN code is running and so is iOS XE.
And iOS XE is trying to make sense of what it's getting from the SD-WAN side
and yet it doesn't exactly know what to do with the fact that I'm getting two
routes to the same next hop. If a router or an iOS XE device like a Layer 3
switch were to get two paths to the exact same next hop, well that's the same
route. I mean I'm not, I can't load balance across that. I'm just going to
put one entry into the routing table because it's a duplicate route at that
point. And so that's what iOS XE is saying here. It's saying, hey I got two
routes to 14.14.14.14 which is edge 14 but because the next hop is the same and
the subnets the same and everything else is the same it's a duplicate entry. So
I'm not going to put two routes in the routing table to edge 14. I'm gonna put
one. I'm not gonna put two routes to edge 13. I'm gonna put one and same with
edge 12 in fact. So rather than getting the two paths to edge 12 subnet I'm just
going to insert one route into the routing table because the two routes
that I'm getting are identical. So what exactly happens once we try to send
traffic? Well believe it or not, we scroll up here, this OMP table is the
authoritative source for OMP routes. So when my routing table gives an OMP route
and says that it's trying to send it, let's say to 10.10.13.0 via edge 14,
maybe it picks the edge 14 path while it's load balancing. Well the OMP table
says I actually have two paths to edge 14 and it's going to further load
balance between those paths. So OMP and SD-WAN code is still running independent
or maybe off to the side in iOS XE. We just don't see it in the iOS XE routing
table down here. So iOS XE's perspective is I'm going to send all of my traffic
to this subnet towards 12.12.12.12, hand it off to the system interface and the
system interface takes it from there and load balances to the two sites. Same
thing here, iOS XE is going to load balance between 13 and 14, edges 13 and
14, and then once it hands it off to the system interface, the system interface is
going to take it and let's say I send it to edge 14, the system interface is going
to take it, check the OMP table, and load balance between the two paths. So now
that we know how our routes look in iOS XE, both the OMP table as well as the
routing table, let's have some fun. Let's go ahead and do a little bit of
traffic engineering using TLOC preference. We're just going to get on
configure TLOC preference on one of the advertised routes and we'll see what
that ends up doing to both the OMP table as well as the iOS XE routing table.