Here we go.
Quiz number two, question number one.
Which routing protocol is used to directly exchange routes
with the SD-WAN controller?
So it's all of our conversations
about different routing protocols.
We just got done with this whole quiz on OMP.
It's very important for us to recognize
that the only routing protocol we're using
to exchange routes with the controller is OMP.
Yes, I might exchange routes on the service side
using something like OSPF.
And for that matter, I might actually have
to exchange routes with my service provider using BGP.
Although SD-WAN does tend to remove a lot of the need
for transport side routing,
we might still have a requirement
depending on the service provider and the scenario
where we might actually have to run
a routing protocol that way.
But when it comes to the controller,
this is where we're going to run OMP.
And as always, we don't form OMP peerings between edges.
It's only ever between an edge and a controller,
or possibly if we have multiple controllers
that we would run it from controller to controller.
Question number two, when a route is sent via OMP,
what is listed as the next hop?
Well, the answer here is going to be the T-lock.
Usually we're going to have some kind of IP address
as the next hop.
But in our case, if I have an edge
and I've got my own T-locks
and I've just received a route that says,
hey, the next hop is this T-lock over here.
Let's say it's this T-lock that's part of an edge
and it has other T-locks on there.
The question that this router has to answer is,
can I get there from either or both of my existing T-locks?
This is why this is the next hop.
Now, yes, in order to send that traffic,
I'm going to have to insert it into the tunnel mechanism.
And at that point,
I'll know what my destination IP address is.
But this is why we use T-locks as the next hop
because I might not be able to access it
from one of my T-locks.
I might not even be able to access it
from either of my T-locks.
Hopefully I can at least access it from one of the T-locks.
But this is the decision-making process
that this edge is going to go through
to decide how to send traffic towards a destination.
And that's why the T-hop or the T-lock
ends up being the next hop.
Question number three,
which dynamic routing protocol routes
are shared into OMP by default?
So we just said, we might have the transport on this side,
but I might have a service side set of routing protocols.
So I might be sharing routes via something here.
And some of these are going to be automatically sent,
really, to the controller up here via OMP.
So Viptela, when they created OMP originally,
they wanted this to be a seamless process.
And so they included, for example, OSPF internal routes,
as well as, by the way, static and connected,
which aren't dynamic routing protocols,
which is why they're not answer choices,
dynamic routing protocol.
But they wanted to include these three,
so A would be our answer here, automatically,
so we wouldn't have to go to great lengths
in order to get this to work.
Naturally, Viptela didn't have access to EIGRP,
but given that OSPF external and BGP routes
might not necessarily be part of a typical environment,
they didn't want to directly inject those into OMP.
But the OSPF internal routes, more often than not,
probably in over 99% of our situations,
we would want those to be injected into OMP
so other routers and other edges
could know how to get over here
to these subnets that are being advertised.
Question four, an SD-WAN tech wants to share routes
learned via OSPF as part of VPN 5.
A remote edge installs the routes, but pings aren't working.
What additional configuration would resolve the issue?
All right, so we're going to need to diagram this out
so we know that we've got an edge
and it's learning routes via OSPF,
meaning that we have some kind of downstream connection,
which means we probably have subnet A over here.
And so I am learning these routes via OSPF
and we are automatically, keep in mind,
automatically passing OSPF internal routes.
So I'm sending that via OMP through the controller
to other edge devices,
which means that I know where subnet A lives.
In fact, we've have that confirmed.
We say that the remote edge is installing the routes.
That tells us a lot of information, by the way.
First and foremost, that this redistribution into OMP
is successfully happening.
And then we have some subnet downstream.
We have another host here
and pings are not working between these hosts.
We'll call this subnet B over on the right.
So as we look at these options,
we can say that, first of all,
A is not going to be a good option
because internal routes not only get advertised by default,
but the fact that this is getting installed
means that we didn't mess with that,
that it is still happening.
Now, redistributing OMP into OSPF,
we're gonna come back to this.
This is possibly what we're talking about here
because we're talking about the propagation of routes.
But let's look at our other answer choices real quick.
First of all, adding a static route to the T-lock.
If the router on the right doesn't know
how to get to the T-lock that's advertising it,
it wouldn't have installed these routes.
So that's a very important consideration,
that tells us that C is wrong.
We wouldn't need a static route to the T-lock
if we already are installing the routes
and therefore know how to get to that T-lock.
And lastly, RFC 1583,
this is that backward compatibility concept.
If this wasn't working,
if this was required in some fashion,
then again, we wouldn't have installed the routes over here.
Wouldn't have even possibly made it
over to our originating edge.
So that is certainly not going to be a concern.
So really does leave B by process of elimination,
but what do we think is happening here?
Well, if I'm looking at this,
we know that this router here has a path to subnet A,
but pinging between subnets A and B isn't working.
So what could be the problem?
Well, if OMP is working correctly,
the router on the left knows how to get to subnet B
and it knows how to get to subnet A.
So we've got full routes there.
We are learning A via OSPF
and we're learning B via OMP.
So what's the other layer three device
that could be causing the problem?
Well, it's this one right here.
It certainly knows where A is,
it's directly connected and it passed that information up
in some fashion via OSPF and the database.
So how exactly does it know though where subnet B lives?
That would be the question.
This is why we need to redistribute OMP into OSPF.
I need to take the routes I learned from OMP
and inject them into OSPF
so that now this router actually knows where subnet B lives.
That's supposed to be an exclamation point, by the way.
So anytime we're having a routing conversation,
always keep in mind if pings aren't working,
it doesn't necessarily mean that it maybe,
well, maybe I should draw it the other way.
It doesn't mean that the ping isn't getting there.
It might mean that the ping is getting there, no problem,
but then it actually gets dropped on the way back.
It's a bidirectional conversation.
Anytime we're talking about routing,
we need to think of it from both directions.
And this is a great example of where OSPF
can be injected into OMP just fine.
And we're learning routes via the SD-WAN
and that seems great,
but never forget that we have to turn around
and re-advertise those back into an environment
where that environment has a dynamic routing protocol in use.
All right, question number five.
What CLI command is required for EIGRP
to activate on an SD-WAN edge?
Well, this is a pretty straightforward question.
Usually we either know this or we're not gonna know it.
We're gonna look at these commands
and hopefully we've recognized
that this C topology base command
as we demonstrated in the lab environment is required.
I'm not going to be able to commit
my EIGRP configuration without it.
Fortunately, the graphical user interface
for manager does apply it.
The main concern is whether we remember to apply it
via the CLI if that's our configuration method choice.
So when we configure EIGRP,
there are definitely some syntax things to be aware of.
I would highly recommend making sure
that we just log into our SD-WAN edges
and know how to manually configure EIGRP
as well as OSPF and BGP.
All of our dynamic routing protocols,
we should be able to configure
and feel comfortable doing so.
All right, next question.
What determines whether BGP peers form an IBGP
or EBGP relationship?
This doesn't have much to do with SD-WAN,
but it is very important for us
if we're going to take an edge
and form a BGP peering with another router.
Because whether it's EBGP,
which has a very low administrative distance,
which means it's very much preferred,
or an IBGP peering,
which has a very high administrative distance
and is not preferred over things like OSPF and EIGRP,
this is going to affect our routing environment.
So what affects whether it's IBGP or EBGP?
It is 100% whether the autonomous system numbers
match or not.
If they match, it's going to be an internal BGP peering.
If it doesn't match, then it's going to be EBGP
because we're communicating
from one autonomous system number to another.
Question number seven.
An OMP route exists in the OMP database,
but it isn't getting installed
into the routing table on an edge.
This is the opposite problem
where now it isn't getting installed.
What could be the cause?
So there could be a lot of causes.
So we have to kind of look at the answer choices here
and try to figure out
which one of these could actually cause that problem.
The key here is seeing that it isn't getting installed
and yet it does exist in the OMP database on that device.
So when we look at the remote TLOC being unreachable,
that actually is going to be our answer choice.
So we'll come back to that in a moment.
When we look at these other answer choices,
we say the controller isn't advertising the route.
That wouldn't be the case or can't be the case
because it exists in the database.
If I'm looking at the edge OMP database
and I'm seeing OMP routes,
those could only be coming from the SD-WAN controller.
The origin protocol is telling me
how the remote edge learned about something.
So if it says it learned it via OSPF,
I might not be running OSPF myself.
It just means that the other side is running OSPF.
So that wouldn't be a factor.
The origin metric being too high.
Again, that might be a tiebreaker concept,
but if the route is not getting installed,
we're not comparing it to nothing or to something else.
We're only comparing it to other routes.
So at least one route should be getting installed,
even if the metric is high.
So that does leave A by default.
But again, keep in mind what we said,
a T-lock is considered the next hop.
If the remote T-lock can't be reached,
that is the same thing as saying
that the next hop can't be reached.
And if the next hop can't be reached,
we don't actually have a way to get to that route.
So that would be the same as saying
I can't reach a next hop IP address
if I can't reach the next hop T-lock.
So A, that is absolutely something
that we should keep in mind
if a route is not showing up in the routing table,
but it is in that database
that show SD-WAN OMP routes command,
then at that point we should be considering
whether or not I can reach the T-lock.
Okay, just two more questions here.
This is a configuration question.
A tech installs a static default route on an SD-WAN edge.
So static default route,
we're talking about the default route now.
After a couple minutes,
the route no longer shows up in the routing table.
What configuration is causing this?
We actually spent a little bit of time
talking about this primarily,
I might just want to propagate a default route
that I made up.
And again, it's a lab environment, so it's fine.
I just want to see it propagate.
But when we configure a static default route
that isn't actually available,
well, SD-WAN environment is going to actually pull that
from the routing table.
This is a way that Viptela had to automatically deal
with the fact that a default gateway maybe goes down,
and therefore I should probably pull out the static route.
Cisco devices don't do that for us.
We have plenty of ways to make it happen on our own,
but they decided that if we've got a static default route,
whether that next hop is reachable or not,
we're going to stick with it.
That's the Cisco side.
Well, on the Viptela side,
which is now how we're running our Cisco edges,
we are going to be using that track default gateway command.
It is configured by default.
And if you're in a lab environment
and your default route keeps disappearing,
you might want to take a look at this.
Now, naturally, this could still apply to us
in real world scenarios.
It's not just a lab situation.
This might really puzzle us in the real world.
We might not even realize our default route is down
or maybe we misconfigured it.
And so if it keeps disappearing from the routing table,
now we know that we can either disable it using this command
or maybe more preferably go and check out
and see why our default route is,
the next hop is not available.
All right, last question.
And it's an open-ended question.
A service side route is being advertised by three edges,
each with two T-locks.
All six paths are equal cost.
What two commands will ensure
that a remote edge installs all six paths?
So there are two commands that we have to worry about here.
We see that we've got an edge with a service side route
and we actually have three edges that all have this.
Maybe it's directly connected.
Maybe it's through a routing protocol.
And each one of these has two T-locks.
And furthermore, they all have equal costs.
So we are going to advertise all six of these
to the SD-WAN controller.
And now we need to worry about,
number one, making sure that all six of these get propagated
and number two, that all six of these get installed.
So what are those two commands?
Well, we're going to have to get into our OMP process.
Actually, let's write it over here.
So for the controller, the controller needs to send six.
The default is four.
So I'm gonna get onto the OMP process
and configure the send path limit to be six.
That would be my command here.
On the SD-WAN edge side,
I'm also going to get onto my OMP process.
And this time it's going to be the ECMP limit command,
which I'm also going to set to six.
Once I commit both of these,
we should be good to go with installing all six paths.
So that brings us to the end of our routing quiz.
So between OMP and routing,
tell that we're kind of integrating the two.
I mean, it's really hard to talk about routing
without OMP, for example,
and OMP without routing for that matter.
But at the same time, at this point,
we should be very comfortable with both concepts
and really generally speaking with the routing
across the SD-WAN environment.
From here, we're going to do some scenario quizzes,
so to speak, where we look at a scenario
and we need to follow that path selection criteria set
that is used by OMP in order to figure out
which routes would get propagated.