[AUDIO LOGO]
Next, let's talk about the Multiexit Discriminator,
or the MED.
Now, in most of their outputs and even in their commands
to set this, Cisco refers to this as metric
quite frequently both on IOS XE and IOS XR.
Now, in the scheme of BGP attributes,
this one is definitely not the strongest.
We're getting pretty far down the path
selection criteria by the time we get to MED.
So most of the other attributes that we've
discussed in other videos and skills come before MED.
So again, not the strongest metric here,
but it is still something we can use.
It also comes with, well, honestly, quite a few caveats.
So there's some things we can adjust.
There's actually situations that can
occur that MED can be set but yet
not actually be considered in part of the path selection
process.
So we'll be taking a look at those details in this video.
So let's jump in and take a look at the details
and the caveats of using MED in our path selection process.
So let's begin talking about some
of the basic attributes of MED before we get to the caveats.
First, this is going to be handled by BGP rule number six,
and we are going to prefer the path with the lowest Multiexit
Discriminator, or MED.
So this is an example where lowest value wins.
Again, this is going to be used to affect the return
traffic or the inbound traffic between two neighboring ASes.
This is an important concept to realize with MED is the default
behavior is this only works between two neighboring AS
numbers.
The reason for this is our first point here.
We only compare the MED if those paths
are from the same neighboring AS number.
So this is only going to be between two directly connected
ASes with multiple paths between them.
So MED is actually only passed to that neighboring AS
and within the neighboring AS, but it doesn't go any further.
We'll see in just a moment that this
is something we refer to as a nontransitive attribute.
The way this is enforced is if the MED is learned via iBGP,
it will not be propagated to eBGP neighbors.
That's going to prevent it from leaving the current AS.
What happens instead?
Well, we set it back to zero when we send it
to these eBGP neighbors.
Therefore, it's not being propagated.
Now, we can change whether it sets it to zero
or not, so that part can be modified.
We can simply have it set it to a different value using
default-metric.
Now, we did mention part of this, that it is nontransitive,
meaning it does not get sent to other ASes
beyond your neighboring AS.
But it's also optional, which technically
means it does not have to be supported
by a router in order for that router
to say that it's BGP compliant.
Now, that said, I'm personally not aware of any vendors
out there that do not support the MED attribute.
As far as I've seen, every router
that I've ever run BGP on fully supports this attribute.
Now, the behaviors that Cisco chooses to implement with MED
may not be the same on other vendors.
But they do generally at least understand
the attribute itself.
But remember, the fact that it's optional
means they technically don't have to.
So when you're using MED, you may
have to verify whether your neighboring devices actually
understand this attribute or not.
It's not necessarily a given.
Next is one of the points we sort of already discussed,
and that is that Cisco refers to the MED
as the metric in most commands.
Now, this is going to be the show and the debug commands
as well as configuration commands.
But just be aware we are very carefully using that word most.
There are a few places where they actually call it the MED.
However, there are more places where they refer
to it as the metric than they do the MED.
In fact, I would say probably 90% of the time,
they're referring to it as the metric.
Also, be aware that this is a 32-bit number.
It's important that this is a 32-bit number,
not necessarily because we need that number of values in a MED
field.
It's important because one of the default
behaviors that we'll see when we implement
this is when we redistribute routes into BGP, if they have
an IGP metric on them already, that metric will be brought
into the MED or the Metric field.
And some of our IGPs actually have a 32-bit metric
on those routes.
So the nice thing here is it's large enough
to cover the metrics in all of our IGPs.
Now, of course, not all of them do.
If you were to take something like RIP,
it only has 16 possible values, 0 through 15.
So that would certainly not apply.
But things like EIGRP do have 32-bit metrics
that we can fit here into BGP.
So we actually have that on this point
here, that the MED is copied from the IGP.
So again, this is why it needs to be 32 bits.
This again is going to happen whether we bring it
in with the network command or through redistribution.
No matter which method you use, that MED
is still going to be copied from the IGP metric.
Now, once again, if that's not your desired behavior,
first, you can of course overwrite it here
with the default-metric command again.
But also keep in mind that when you redistribute those routes,
you can always run that redistribution through a route
map or routing policy language.
And you can modify the metric or the MED in that policy as well.
So you could set it on individual prefixes
when you're doing that redistribution using
a route map or an RPL.
So now we need to start talking about some of the caveats.
So the first thing we have is an option
called bgp always-compare-med.
And just a quick note on the commands
that we're showing here in this video--
these are the commands for IOS XE.
They are very similar on IOS XR.
However, some of them may vary just a little bit.
We'll get into that a little bit more in our skills
on implementation of these different attributes.
But what this command actually causes
is it causes the MED to be compared for all paths.
Remember that the default behavior
is we only compare MEDs if the two paths are
from the same neighboring AS.
This would actually allow us to compare the MEDs
even if they're coming from different ASes.
And just another quick note here on this feature--
this can be of course very useful
if this is what you want to do.
This would be commonly done if maybe you're
in administrative control of multiple different ASes,
maybe in a large corporation or a service provider core,
and you want to use MED for your own purposes
between those different ASes.
Where this gets a little bit tricky
is if it's two completely different service providers
that you're partnering with.
They may be using MED completely differently.
One of them might have MEDs in the ranges of the hundreds
or maybe thousands.
And maybe the other service provider
has MEDs that are in the ranges of the millions.
Since there's not necessarily an industry standard
on how to use and implement the MED,
you can't really count on your neighboring ASes
using MED in a similar fashion.
Again, they could be using completely different ranges
of values that aren't compatible with each other or comparable
to each other.
So you really need to make sure that those neighboring ASes are
using some sort of comparable metrics
before you decide to use this feature.
Again, it's a great feature to have when we need it.
But I'm sure we can sort of understand,
at least hopefully at this point,
why that's not enabled by default.
And one other thing to remember about this option is
whether you're going to-- we say disable here--
but enable it, disable it, the point
is you must have a consistent policy
on this over the entire AS.
Otherwise, you could theoretically
get routing loops.
And of course, we sure as heck don't want routing loops.
So be consistent with this policy,
whether we're going to enable it or disable it.
Next up, we have another feature--
bgp bestpath med confed.
This option is only going to apply
when we have confederations, because this is
based on the confed sequence.
So what this feature does is it allows
us to compare the MEDs between the different ASes
in the confederation.
Remember, the idea behind the confederation
is we're going to have multiple internal AS numbers.
These are AS numbers that are going to be
local to the confederation.
So we may want to use MED between those AS numbers
since they are considered internal or local
to the confederation but maybe not from external ASes.
That's the difference between these two commands.
The bgp always-compare-med will compare all ASes
with each other.
Bgp bestpath med confed will only
do it for routes within the local confederation.
So the next thing we want to discuss are received paths.
Now, if we receive a path with no MED on it,
we're going to assign that a MED of zero.
That's the default behavior on Cisco.
And that's very important to understand
because where this starts to change
is we have another feature here called bgp bestpath med
missing-as-worst.
And if we enable that feature, what happens
is instead of the paths being assigned a zero,
they are instead assigned the maximum value.
Keep in mind that's the maximum value in a 32-bit field.
So what is this feature all about?
Well, remember we said previously
that there's really no industry standard
or consistency in the industry as far as what to do with MED?
Well, this is one of those situations where
Cisco, when they decided how to implement
BGP on their platforms, they said, well,
if there's no MED there, then, well, it
should be the same number of things that I have in my hand
right now--
zero.
It should be nothing because if it's not there, then it's zero.
The problem with that, though, from a logic standpoint--
or at least a lot of other vendors believe this--
that if it's missing, it shouldn't
be the preferred value, because remember, lowest wins.
Well, if the lowest MED is going to win, then zero is the best.
Other vendors looked at this and said,
well, that doesn't really make any sense.
If the MED is not purposefully set by the administrator
or by the device, it shouldn't be the best value.
It should be the worst value.
Now, either way you want to go here is fine.
You just have to understand what they're doing.
A lot of times we'll change this to be
consistent with other vendors' equipment.
Just to let you know, in my experience,
what I usually do is just make sure if you're using MED,
set it on all the paths.
So maybe on the path that you want to use,
set the MED to 100.
And the one that you don't want to use, set the med to 200.
What you don't want to do, most likely,
is set the MED on one path to 100
and leave the other one blank, because again, there's
that inconsistency.
What's the other side going to do?
If I don't set the MED, they may treat that as the best value.
They may treat that as the worst value.
And that's going to completely flip
the logic of what I'm trying to do by setting
the other path to 100.
That 100 then might be the best path
or it might be the worst path.
I mean, I guess I'll find out when
I see how the traffic comes back into my network, right?
But we don't generally want to use guesswork here.
So the best practice is to set the MED on all the paths.
And set it so that the one that you want to use
has the lower or the better MED.
The last feature here we need to discuss
is one called bgp deterministic-med.
This one is a little bit interesting
to understand what it does.
It actually groups our routes by the autonomous system number
rather than the order in which they were learned.
The best way to understand this is
going to be to look at an actual example.
And we'll do exactly that in the next video.
So in this video, we jumped into MED.
And as you just saw, there's actually a lot to MED.
The basic overall rules, not so bad.
But all the little caveats, as far as
always-compare-med and deterministic-med,
these things get a little bit more complicated.
So the biggest thing to remember here
is that by default, MED is only considered
if the paths are coming from the same neighboring AS.
And deterministic-med-- make sure that MED is always
at least considered.
I hope this has been informative for you,
and I'd like to thank you for viewing.