[AUDIO LOGO]
So now that we've taken a closer look
at using AS Path prepending to influence our incoming
or return traffic, now let's take a look at one
of our other options to do that, which
is MED or, as Cisco calls it, the metric.
Now this is not very high on the BGP path selection criteria,
so keep in mind that anything like weight local preference
or AS Path prepending can certainly
be used by the neighboring AS to override whatever
we try to set with MED.
Also keep in mind that, well, MED does
have a few interesting caveats.
Now we're going to explore those caveats in this video
as we jump into the command line and start
looking at how MED works.
So we do have quite a few things to look at.
Let's, of course, start by looking at that topology,
talking about what we want to do and putting together
a game plan.
And then we'll jump onto the command line
and see MED and its caveats at work.
Once again, here, we'll be using BGP topology 1 in this video.
And one of the things we're going to be doing
is bringing in a new loopback interface on router 4.
We'll go ahead and make that 100.4.4.0/24.
We'll, of course, advertise that into BGP.
And our main focus is going to be over here on router 7.
Router 7 should ultimately have three different paths
available to it to get to that prefix.
One would be through AS 1000.
Another one would be directly to router 1.
And, finally, we should have a path to router 3 as well.
Now a few things about this.
First off, router 7 may not have all three paths to begin with.
We may actually have to do a little bit of work
for that to happen.
Router 7 might be a transit AS.
Meaning it might be learning the routes from AS 100,
passing those on to AS 1000.
And if AS 1000 is using those, it won't send them back.
So we'll have to look and see what's happening
right now in the topology.
And the other thing that's going to be
a little bit different about this demonstration
is we're not going to start off with a goal of what we're
trying to accomplish because we're going to look at MED
and its different caveats.
And depending on which caveat we're doing,
it's going to change the path selection.
So in this particular video, what we're more going to do
is play around with MED and figure out
how it chooses each of these different paths
based on how we set the MED.
So it's going to choose one of these three paths.
But, again, we're going to be looking
at the attributes of MED to figure out
which one it's going to choose.
So all of that said, let's go ahead
and jump into the command line.
Of course, we'll start on router 7
and see if it even has all three of those paths to begin with.
So let's start off with just a sh ip bgp.
And we can see right away that we do have that 100.4.4.0/24.
And we do, actually, have all three paths.
So let's get some more detailed information on that.
So if we ask for the prefix, we can
see that we do have the path from router 3,
router 6, and router 1.
And currently the path through router 1
is considered the best.
Now just so you know, we did already originate that loopback
on router 4.
Just in case you want to know what that looks like.
This is simply the code that was put in on router 4.
Simply to create a loopback 100, put the IP address on it
and then advertise it into BGP with the network statement.
So router 4 has been configured with the loopback
and router 7 has the prefix with all three paths.
So that puts us in a good position to start using MED.
So let's jump over to router 1.
So to begin with, let's go ahead and set the MED on this prefix
to 100.
So this time we'll use a prefix_set.
Let's just call it R4_LOOP.
And we'll match on the 100.4.4.0/24.
Then we'll write our policy.
We'll call this TO_R7.
And we're going to say if destination
is in our prefix set, then we're going to set the MED.
Notice here on IOS XR, it actually calls it the MED.
Now we can increase it or decrease it by a certain amount
if it already had a value, or we can--
in this case what we want to do is just set it to be 100.
Then we're going to pass the route.
And, of course, since we're not trying to filter,
we're just going to say else, pass the routes unchanged.
We'll end our if statement, and end our policy.
Then into router BGP 100 and towards the nei 50.0.167.7,
which is router 7.
Of course, for the address family IPv4 unicast,
we're going to apply our route policy.
That will, of course, be outbound.
So let's commit the change, clear BGP IPv4 all * soft out,
which will send out a reconfiguration.
Now that that's done, let's go look at router 7.
We'll simply repeat our previous command.
And what we see happening here is the path to router 1
is no longer considered the best.
Notice that it's now moved the best path selection over
to router 3.
This is because remember that Cisco
treats a missing metric or MED as the best
possible value or a zero.
Remember, lowest wins.
Now that router 1 is setting the metric to 100
as we can see here, now that's not the preferred best
path anymore.
So generally speaking, this is how MED is designed to work.
But let's take a look at some of its caveats.
So, first, let's explore what would
happen if we told router 7 to reverse that philosophy.
Don't treat the missing MED as the best,
but rather treat it as the worst.
So let's go into configuration mode, into our BGP process.
And we say bgp bestpath med missing-as-worst.
We'll go ahead and configure that, exit out
of configuration mode.
And now let's take a look at our paths again.
Now we see that this behavior has completely flipped.
The paths that do not have a Med or metric set
are now roughly 4.3 billion maximum value
in a 32-bit field, of course.
While the path from router 1 is, well, it's still 100
because we're setting that one.
But the 100 is now best so the path through router 1
is back to being considered the best path again.
So we're not going to leave this feature in here,
but I just wanted you to see how it works
if you do MED missing as worst.
So let's go ahead and take this back out.
So we'll simply turn that back off under the bgp process.
And if we look at this again, it hasn't hyperconverged back just
yet but the metrics are gone.
Let's give it a second to do it again.
And then we can see it is now switched back
to using router 3 as the preferred path
because it does not have a MED set on it.
So now let's talk about some of the caveats of MED.
We'll start with deterministic MED.
If we take a look at the prefixes and their paths
as we have them right now, they are in chronological order
from the newest to the oldest as they
were learned by the router.
Now the problem with this is when BGP chooses its best path,
it's going to put the paths together into pairs,
starting from the top down.
So it's going to start with these two paths.
And it's going to see that one is from AS 100
and one is from AS 1000, and it's not
going to compare the MED because they're from different ASes.
Now depending on the winner out of that pair,
if it's the path from AS 1000 that were to win,
when that gets compared to the route below,
MED would not be considered again.
Which means that MED would have no say in this decision
whatsoever.
Now if the winner happens to be the path from AS 100,
and then the AS 100 gets compared to AS 100,
well, then the MED does count.
So as in this example, the first pair, the route from AS 100
one because of the shortest AS path.
Then when the 100 is compared to the 100 router 3 to router 1,
then it takes the metric into account.
So in this case, the metric was counted.
But here's the thing, we don't really
want to rely on a situation where MED may or may not
count as part of our path selection,
especially when it has to do with something
we can't control.
This is based on when the routes were learned,
which in most environments it's something
that's out of our control.
We have no control over that.
Hence the term deterministic MED.
It means that MED will always be considered in the path
selection as long as the routes are coming from the same AS.
We do that by grouping the updates together by AS
rather than based on the time in which they were learned.
So if we turn on deterministic MED, what we're going to see
is the order of these prefixes is going to change
and, therefore, the order in which they're compared
is going to change.
Will that ultimately change the final decision as far
as the best path?
Maybe, maybe not.
That depends on a lot of other factors.
But at least MED will get a say when
we compare the ASes as groups rather
than having them split apart by the order in which they
were learned.
Let's go ahead and turn this feature on,
and we'll see what happens to the order of our path selection
here.
All we have to do is turn on BGP deterministic MED.
We'll exit out of configuration mode.
And let's take a look at our prefixes again.
And we see that now the pairs are ordered by the AS number.
So as we said, that ensures that in the first pair,
MED is going to be considered.
And then when the winner of that gets
compared to the other AS, well, of course,
it won't be considered there.
But that's just because they're from two different ASes.
Again, it doesn't mean that the final decision is
going to change, but MED, at least, got a chance.
Now speaking of things that we can't control,
we don't really know if our neighboring ASes are
going to be doing MED missing as worst or MED
missing as best, which is the default on Cisco.
If they're using another vendor, it very well could
have a different default. So since we don't know
and we don't want to have to rely on what the neighbor is
doing in order for our routing choices to happen,
we're probably going to want to set the MED on all the devices
towards that neighbor.
So the best practice would not be
to let router 3 be sending this with no MED.
So let's update this in such a way
that our best path goes back to router 1.
Let's change router 3 to have a MED of 200.
So, again, we'll go into configuration mode.
We'll do a prefix-set.
We'll put in our prefix.
And then we'll write our policy.
We'll just call it the same thing.
Once, again, if the destination is in PS_R4_LOOP,
then we're going to set the MED to 200,
pass the route through else, just pass the route and the if
statement and then the policy.
And then, of course, we'll apply this to our neighbor.
In this case it's nei 10.7.7.7.
And, again, it's outbound.
Commit the change.
Notice we're getting an error here.
And it might be a little bit tricky
to see we have a typo on the route policy here.
I called it PR instead of RP, therefore, it's the wrong name.
And, of course, IOS XR is saying,
I don't know what you're talking about.
So there we go.
Now it's committed now that we fixed our typo.
Let's do our clear.
Let's go back over to router 7 and make sure
that's taken effect.
So we see now that it's back to choosing
router 1 as the best with the metric of 100,
where the metric of 200 is not being chosen any longer.
So this is MED working properly with a neighboring AS.
But here's an interesting proposition.
What if we go over to router 6 now and make it's MED 50?
Can we make it choose router 6 as the best path using MED?
Now the answer is a little tricky.
We're going to have to do some other things first.
We can do it, but we're going to have a couple of bumps
along the way.
Let's go ahead and take a look.
So first, of course, we have to configure
the policy on router 6 itself.
So configuration mode, of course,
we're going to use the route map here on IOS XE.
We'll still call it RM_TO_R7.
Here it's called metric, so it will set the metric.
And we'll make it low.
We'll make it 50.
Then we're going to router BGP 1000.
And for the nei 50.0.167.7.
We'll apply our route map RM_TO_R7 outbound.
We'll clear our BGP session and, once again,
go back to router 7.
We'll look at our prefix again.
And a few things to note here.
First, reporter 1 is still selected as the best.
However, the prefix from router 6
now does have the metric of 50.
That's not doing anything, but it's that set and it's there.
The other thing to note is the prefix from router 6
is at the top now because it just learned it
through a new refresh.
Again, this is still sudo chronological.
Meaning it's still chronological within the AS numbers.
So even with deterministic MED on, within the AS sets,
it's still chronological.
And between the sets themselves, it's chronological.
Now what if we want that 50 to actually mean something?
Well, there's actually two things that have to happen.
The first thing that has to happen
is we're going to have to tell router 7 not
to look at the AS path length.
We're going to have to skip that rule because if we
look at this prefix, it's, of course, one AS coming
from AS 100.
And it's, of course, two ASes going
through as 1000 and AS 100.
So no matter what we do with MED,
it's not going to make any difference here as
long as one of them has the shorter AS path.
So step one is we're going to have to tell router 7 not
to look at the AS path.
I wouldn't generally recommend doing this
unless you have a very specific reason for doing it.
However, this is a lab environment
and we're trying to look at MED specifically
so I call that a pretty good reason for doing it.
So, again, we go into our BGP process.
And here is going to be a fun one.
If we say BGP best path, and we ask for context sensitive help
here, notice there is no option that
says anything about AS path.
This is because Cisco doesn't want you to turn it off either.
However, it's still there.
If we just type as-path, it's not
going to give us any further help.
In fact, it's going to tell us it's an unrecognized command.
It has no idea what I'm talking about.
But if I actually say ignore, it takes the command.
If you're not familiar with this,
this is simply what we call a hidden command.
There aren't many of them.
Cisco hides them for a variety of reasons.
We're not going to get into all of that here.
It's probably a philosophical discussion.
However, in this case, I think-- and I
don't have any inside Cisco information--
but I think they hide it because you really
shouldn't use it unless you know what you're doing and why.
And if you know what you're doing and why,
then you probably know the command.
So that's just my opinion as to why they hide it.
But, nonetheless, that's the command.
Let's go ahead and look at our BGP path again.
Now nothing's changed yet because even though we're not
looking at the AS path length anymore,
these MEDs are still coming from different ASes.
So if we really want this whole thing to work,
we're going to have to say bgp always-compare-med.
Which tells it to compare the MED regardless of what
neighboring AS it comes from.
Once again, a command we really probably
shouldn't use most of the time, unless we
know that those neighboring ASes are using compatible metrics.
So, for example, here in our lab we
have control over these two different ASes, AS 100
and AS 1000.
So we know in this case that we want
to compare MED between them.
But make sure you understand the consequences of this
if your neighboring service providers use
radically different MEDs.
This could not work out well if that's the case.
So make sure that this is what you want before you
turn this feature on.
So once we turn it on, if we look at our prefixes again,
we had to give it just a second there to run the BGP scanner.
But we can see that now that path through router 6
is now the best with the lowest metric of 50.
So this is how MED works with all of its features
and all of its caveats.
Again, we did some things here in this lab
I would not recommend doing in a production environment,
just so we're very clear on that.
We did some things here for educational purposes.
Make sure you know what you're doing in the real world
and why you're doing it.
So in this video, we took a rather detailed look
at the MED or metric attribute in BGP,
how it works with many of its different caveats,
such as deterministic MED.
Always compare MED and how missing MED can either
be the minimum or maximum value, depending on the vendor.
I hope this has been informative for you.
And I'd like to thank you for viewing.