So one last conversation has to do with the default route. How do we get a
default route into our SD-WAN space? Now we might look at our edges and say, well
they have a default route and it points out towards the Internet, but as always
that's part of VPN 0. It allows them to communicate with their cloud controllers,
but it doesn't actually help with, for example, this host over here getting out
to the Internet. So let's create a scenario here. Let's say at site 13 that
this host is actually a firewall, and this firewall connects up to the
Internet. And so this is the Internet path that we want to use for VPN 10. So
ideally what we have is edge 13 and edge 14 both recognizing that they should
have a default route this way, and then they want to advertise that into OMP.
Meaning that edge 11 and edge 12 should both recognize that there's a default
route via those two edges. So how do we do this? Well OMP doesn't give us a
native way to inject a default route. I can't do like a default information
originate like OSPF has. Instead I'm going to have to redistribute another
type of route into OMP. Now maybe this firewall is running OSPF and I have an
OSPF adjacency here. At that point I'd redistribute the default route from OSPF
into OMP. But what if I don't have that? What if I just I'm going to use a static
route? Well that's perfectly fine. I can use a static route. In fact let's go
ahead and put static routes on edges 13 and 14, and then in order to get it into
OMP we simply need to redistribute our static routes in there. Now think about
the fact that OMP does that by default, and that's gonna make our job pretty
easy if we're going to go the static route. So let's get on to edge 13. We'll
configure this via CLI, and I'm going to make an IP route. So this is a static
route, but within the context of VRF 10. From here I'm going to specify the all
zeros for the address and mask, and then my next hop. So we've said we're gonna
make our next hop that host that has a .50 address. So I'm going to use that IP
address, and then commit the IP address from a static perspective. So if I get
out of this and do a show IP route VRF 10, then we should see that we've
got a static route. Now this asterisk always means that it's the default route,
and so we're saying that we're learning this via static, which is exactly what we
just configured. So very good it's in the routing table. I can also go over to edge
14, log back into it because I've been logged out, do a config dash T, same
command, IP route VRF 10, all zeros, all zeros, and then the host .50. All right so
I will commit this and end. So what happened here? Well we both have a
default route. If I do a show SD-WAN OMP routes, we know that OMP will
redistribute our static routes immediately without us intervening. So
all the way at the top here we have our static route in the OMP table, which is
good. That's what we'd hope for. So let's go ahead and look at edge 11, log into it,
and do a show IP route for VRF 10, and we do indeed see that we've got a
default route now. Now notice this isn't via static, I learned it via OMP, and so
that asterisk next to the M is telling me that I learned it from another OMP
edge. So this is good. I learned technically I learned it from the vSmart,
but we understand. If I want to send it to a packet via the default route, then I
have my two edges that are both equally advertising this via OMP. Now one word of
advice, or maybe even a word of warning, if you're going to do this in your lab
environment, you need to make sure one of two things. Either that you use the IP
address of a reachable host for your default gateway, or that you disable
default gateway tracking. Let me explain what we're talking about here. Let's go
over to edge 13, do a config T, and we're gonna say no IP route VRF 10, all zeros,
all zeros, 10.10.13.15. Alright, so this should clear out, let's see here, show IP
route VRF 10. That should clear out our routing table from the static, and it
does. So I'm not allowed to learn about a route via OMP from a edge that's at the
same site, so I'm not learning it from edge 14 either. So now what if I do a
config T, and let's say again I'm into my lab environment, I just want to make up
a default route. So I'm testing this out, say Jeff used the Ubuntu machine, I'm
just going to use 10.10.13.250. It's an address that's not reachable, and I
commit it, and I end. Alright, so if I do a show IP route VRF 10, we're gonna see
it in the routing table, but I'm gonna pause the video here for about a minute,
and we're gonna find that something happens to that route.
Alright, so it's only been about a minute and a half, and so let's go ahead and run
this command again. Notice what happened. The default route disappeared. Where did
the default route go? Well, this can be very frustrating, especially if we're not
used to this being on Cisco IOS XE devices. This is a configuration Cisco
inherited from Viptela, and the configuration is that we are tracking
the default gateway, and if it goes down, then I will remove it. In fact, the math
here is that every 10 seconds it'll send an ARP request, and if after 10 ARP
entries are failed, then it's going to pull the static route out of its
routing table. So it takes about 140 seconds, or well, 100 seconds, a
minute 40 is about what it takes, and so if you're just sitting here like I was
the first time looking at saying, where did my default route go? Well, again, it
has to be able to be reachable via ARP. Now, this could impact production
networks in specific ways, but it's mostly going to impact us on the lab
side because I might have a dummy address as my default gateway, and this
configuration is what's causing it. So what if I wanted to get rid of it? Well,
I can do that. I just have to get into my configuration, and then I have to get
into system configuration, and then the command down here is track default
gateway. Now, it's enabled by default, so if I wanted to, I could say no, track
default gateway, and then commit, and now I'll be able to get my static route back
into the routing table because we're no longer tracking that dummy address. So
something that we need to be aware of, mostly for our labbing, but also just in
case we do hit it in production, it's really good that we understand what this
mechanism is and how it's configured.