|
0:00:13
|
In this section for BGP, we're gonna look at the multi-exit discriminator attribute.
|
|
0:00:18
|
How it can be used to affect inbound traffic flows?
|
|
0:00:22
|
And some of the caveats with it
|
|
0:00:24
|
that control how med is gonna process differently
|
|
0:00:27
|
depending on what type of peer the update is being received from.
|
|
0:00:31
|
Or even the order that the update is received that can affect what the ultimate best path selection is.
|
|
0:00:38
|
Now, when we look at the documentation for the med attribute,
|
|
0:00:43
|
under the BGP best path selection document.
|
|
0:00:46
|
It says that once we get past he origin code, which is after the AS path,
|
|
0:00:51
|
after the local preference and the weight,
|
|
0:00:54
|
it says that we're gonna look at the multi-exit discriminator.
|
|
0:00:56
|
But the problem is that first off, it says, the comparison only occurs
|
|
0:01:02
|
if the neighboring AS is the same for two paths.
|
|
0:01:07
|
And any confederation sub ASs are ignored.
|
|
0:01:09
|
So, this means that med by default is only gonna be used when we have multiple connections of the same provider.
|
|
0:01:17
|
So, if we have two peerings to AT&T,
|
|
0:01:19
|
potentially we could use the med in order to affect our inbound traffic flows.
|
|
0:01:24
|
You'll see in reality, a lot of the times, the providers don't even accept the med attribute
|
|
0:01:30
|
that they'll simply rewrite it as it comes inbound.
|
|
0:01:33
|
Because there's too many discrepancies about how it's processed differently between
|
|
0:01:38
|
different vendors implementations and the different orders.
|
|
0:01:41
|
So, a lot of the times, it's easier not to use it to begin with.
|
|
0:01:45
|
But by default, it's only gonna be compared
|
|
0:01:47
|
if the AS you're learning the prefix from is the same to begin with.
|
|
0:01:52
|
Now, in our particular case, this could be from AS 400's perspective
|
|
0:01:58
|
when it is learning prefixes from AS 100 about how to get to AS 54.
|
|
0:02:07
|
If we were to look at router 5
|
|
0:02:11
|
and look at the Show IP BGP,
|
|
0:02:17
|
to look at what are the prefixes that came from AS 54 to begin with.
|
|
0:02:23
|
It says that there's three possible paths that we have out of this autonomous sytem.
|
|
0:02:30
|
We can go to router 3, we can go to router 4 or we can go to router 1.
|
|
0:02:35
|
Now, at this point, we don't have any other attributes modified.
|
|
0:02:38
|
So, the weight is the default, the local preference is the default.
|
|
0:02:42
|
The origin code for all of these prefixes is IGP.
|
|
0:02:46
|
This then means that we're gonna prefer now the shorter AS path.
|
|
0:02:51
|
We can see if we were to router through router 3,
|
|
0:02:53
|
we have an AS path link of 3.
|
|
0:02:55
|
Whereas if we go through router 4 or router 1, we have an AS path link of 2.
|
|
0:03:00
|
So, now, the decision is gonna be between these two particular peers.
|
|
0:03:05
|
Since both of the routes are being learned from AS 100,
|
|
0:03:08
|
we could potentially look at the med value if it was set on the other side.
|
|
0:03:15
|
If we look at the details of the prefix, let's say Show IP BGP for 28.119.16.0/24,
|
|
0:03:25
|
notice that it does not say that the med value is 0.
|
|
0:03:30
|
It simply doesn't have any output anywhere what the multi-exit discriminator is.
|
|
0:03:34
|
And this output, normally, it says the metric.
|
|
0:03:38
|
Now, what this means is that the med is not 0, the med is null.
|
|
0:03:44
|
So, when the value is actually encoded in the BGP update,
|
|
0:03:47
|
there's a difference in binary to a null med versus a 0 med.
|
|
0:03:55
|
And the reason that this is significant is that some implementations of the med
|
|
0:04:02
|
says that the null value should be 0,
|
|
0:04:06
|
where other say that the null value should be the largest possible med, which is 4.2 billion.
|
|
0:04:15
|
This then means, if we are using the med attribute in order to affect the inbound traffic.
|
|
0:04:22
|
And we do not know how the remote neighbor is processing the value,
|
|
0:04:27
|
the best way to avoid this is to set the med out all of the exit points.
|
|
0:04:34
|
So, let's say for example in this topology, from router 5's perspective,
|
|
0:04:40
|
I want to route the traffic to go to router 4 as opposed to going to router 1.
|
|
0:04:49
|
Now, right now, we're routing the traffic to router 1
|
|
0:04:52
|
becasue router 1 has the lower router ID.
|
|
0:04:56
|
If we look at router 5's BGP process,
|
|
0:05:02
|
I've configured BGP best path compare router ID,
|
|
0:05:05
|
which for this particular version is not enabled by default.
|
|
0:05:09
|
So, if the router ID comparison is off, then we would simply look at what was the first route
|
|
0:05:15
|
that was received (excuse me).
|
|
0:05:19
|
The first route that was received from the neighbor.
|
|
0:05:22
|
So we're gonna look at whatever the oldest update was.
|
|
0:05:25
|
In the case that BGP best path compare router ID is on,
|
|
0:05:29
|
we're gonna look at the lower router ID first.
|
|
0:05:33
|
Then in the case that we have multiple updates from the same peer,
|
|
0:05:35
|
then we would prefer the older one.
|
|
0:05:40
|
So, if I were to prefer the exit point via router 4,
|
|
0:05:45
|
let's say that we try to implement this with using the med attribute.
|
|
0:05:50
|
I want to route this direction to get to AS 54 as opposed to using router 1's exit point.
|
|
0:05:59
|
Now, we know that the lower med value is going to be the preferred one.
|
|
0:06:05
|
Right now, the med is not being set on any of these prefixes.
|
|
0:06:10
|
Because when they came in from 54,
|
|
0:06:12
|
whatever value was received is gonna be stripped as it goes out to the EBGP neighbors.
|
|
0:06:19
|
This is because med is a non-transitive attribute. It's not gonna go multiple hops away
|
|
0:06:25
|
between different autonomous systems.
|
|
0:06:28
|
Now, it can go multiple hops between iBGP neighbors.
|
|
0:06:32
|
It just means it's not gonna go beyond one autonomous system.
|
|
0:06:36
|
So, if AS 54 is setting the med to AS 100, that's not also going to affect AS 400.
|
|
0:06:42
|
If AS 400 is gonna use the med value, AS 100 is gonna have to set it out manually.
|
|
0:06:49
|
So, if I want the traffic flow to go from router 5 to router 4,
|
|
0:06:54
|
I want to make sure that this exit point has the lower med value
|
|
0:07:00
|
as opposed to the one via router 1.
|
|
0:07:06
|
Now, to do this, let's go to router 1 and as we send the updates out to router 5,
|
|
0:07:12
|
let's set the med value to a higher value.
|
|
0:07:16
|
So, first, let's look at what is the current traffic forwarding path.
|
|
0:07:20
|
If I were to go to switch 4,
|
|
0:07:23
|
and let's advertise its loopback into BGP.
|
|
0:07:27
|
Network 150.28.10.0/24.
|
|
0:07:33
|
Then we'll trace to get to...
|
|
0:07:37
|
112.0.0.1.
|
|
0:07:43
|
112.0.0.1, and this is coming from 150.28.10.10.
|
|
0:07:52
|
So, we see from router 5, this is going to router 1.
|
|
0:07:57
|
So, I want them out of ID path selection so that it uses router 4
|
|
0:08:01
|
for this hop between AS 400 and 100 as opposed to using router 1.
|
|
0:08:05
|
So, on router 1,
|
|
0:08:11
|
we'll configure a route-map
|
|
0:08:14
|
that says, "This is gonna go out to router 5."
|
|
0:08:18
|
We will set the metric,
|
|
0:08:21
|
which is the med.
|
|
0:08:23
|
We'll set the med to 100.
|
|
0:08:27
|
Then, under the BGP process, router BGP 100.
|
|
0:08:31
|
As we're sending updates out to 155.28.0.5, use the route-map to router 5.
|
|
0:08:41
|
To router 5 out.
|
|
0:08:46
|
Now, on router 5, if we clear IP BGP * in,
|
|
0:08:49
|
so this is asking for a route refresh.
|
|
0:08:54
|
And we look at the change in the BGP table,
|
|
0:08:58
|
let's say for 112.0.0.0,
|
|
0:09:03
|
we now see that for the two paths via AS 100,
|
|
0:09:08
|
one of them has a med value of 100. The other one still has the value of null.
|
|
0:09:20
|
Now, with the default processing of the IOS commands,
|
|
0:09:25
|
it means that the value that is received that has a null med,
|
|
0:09:29
|
is automatically going to be assigned a 0 med.
|
|
0:09:34
|
So, even though it doesn't show up in the output here,
|
|
0:09:38
|
that the med via router 4 is 0,
|
|
0:09:41
|
that's what's happening here by default.
|
|
0:09:44
|
So, the higher med value via router 1 is the one that is now being the less preferred
|
|
0:09:49
|
over the null med via router 4.
|
|
0:09:53
|
If we look at the end result of this by doing the trace route,
|
|
0:09:57
|
we'll trace to 112.0.0.1 from 150.28.10.10,
|
|
0:10:05
|
we see now, we're using router 4 as the...
|
|
0:10:10
|
the exit point from our autonomous system.
|
|
0:10:20
|
Now, the only problem with this implementation
|
|
0:10:23
|
is that we're making the change from the perspective of AS 100,
|
|
0:10:28
|
trying to affect our inbound traffic flow.
|
|
0:10:32
|
So, from router 1, we're applying an outbound BGP policy that's trying to affect the inbound traffic.
|
|
0:10:39
|
From router 1's perspective, it doesn't really necessarily know
|
|
0:10:42
|
how router 5 is going to process the med value when it's actually received.
|
|
0:10:48
|
If router 5 says that by default, if a null med is assigned 0,
|
|
0:10:56
|
versus a null med being assigned the worst possible value,
|
|
0:11:01
|
this is gonna make a difference as to how the path selection actually occurs.
|
|
0:11:06
|
Because right now, from router 1 to 5, we're setting the med to be 100.
|
|
0:11:12
|
From router 4 to 5, this is null.
|
|
0:11:17
|
If the missing med, which is the null med.
|
|
0:11:21
|
If the missing med is the best, then the preferred exit point would be via router 4.
|
|
0:11:28
|
But if the missing med is the worst, then the preferred exit point would be via router 1.
|
|
0:11:35
|
Where this could potentially be a problem is let's say we're doing it from AS 100 out to AS 54.
|
|
0:11:44
|
Now, we really have no visibility as to the configuration of AS 54.
|
|
0:11:48
|
Because in the actual exam, you're not gonna have access to the backbone routers.
|
|
0:11:52
|
So, if we have a question that says, "We wanna change the path selection based on the med",
|
|
0:11:56
|
sometimes it may work depending on the value that we set.
|
|
0:12:00
|
Sometimes it won't.
|
|
0:12:02
|
Ultimately depending on how they are processing the med value.
|
|
0:12:07
|
Now, we can see this change if we were to go to router 5.
|
|
0:12:11
|
And change the default behavior.
|
|
0:12:13
|
Instead to say that in the best path selection, for the med, the missing value is the worst.
|
|
0:12:22
|
When we now look at the Show IP BGP Output,
|
|
0:12:25
|
we can see that the path learned from router 4, now has the worst possible med value.
|
|
0:12:33
|
The end result of this is gonna be that now, the best path is via router 1,
|
|
0:12:40
|
once the process actually converges.
|
|
0:12:47
|
Now, we could clear the BGP table in order to get this to change.
|
|
0:12:52
|
Otherwise, we're gonna have to wait for whatever the default BGP scan time is
|
|
0:12:56
|
to figure out if the attribute has actually changed.
|
|
0:13:01
|
So, on router 5, let's say Clear IP BGP * In.
|
|
0:13:05
|
That's gonna force us to rerun the best path selection.
|
|
0:13:20
|
And we should see that it's gonna change from...
|
|
0:13:26
|
router 4 to router 1 here.
|
|
0:13:28
|
Let's look at the Debug IP BGP Updates.
|
|
0:13:34
|
Then Clear IP BGP 100 Inbound.
|
|
0:14:02
|
So, when logging on... Logging console 7, then let's say Clear IP BGP 100 Inbound.
|
|
0:14:25
|
And it looks like now it's updating.
|
|
0:14:30
|
So, let's now look at the Show IP BGP Output again.
|
|
0:14:39
|
And now, it's using router 1 as the best path.
|
|
0:14:42
|
So, you'll see for some of these changes with policy, it's gonna take BGP a little while to converge.
|
|
0:14:47
|
Because it's generally not meant for really fast, high availability.
|
|
0:14:56
|
Now, if we look at the result of the ultimate traffic flow.
|
|
0:15:00
|
Let's do the trace that goes to 112.0.0.1
|
|
0:15:06
|
From our loopback,
|
|
0:15:08
|
we now see what basically the same policy applied in AS 100.
|
|
0:15:13
|
Since AS 400 is processing the attribute differently,
|
|
0:15:17
|
it's ending up in a different unexpected path selection.
|
|
0:15:21
|
So, the keypoint being here, when you're using the med attribute,
|
|
0:15:25
|
since you don't necessarily know how the remote neighbor is going to process it,
|
|
0:15:30
|
the more correct way to implement this would be to simply set the value out on all exit points.
|
|
0:15:38
|
This means that if I were to go to router 4 manually and set this to be 50,
|
|
0:15:44
|
versus router 1's med of 100,
|
|
0:15:48
|
then regardless of how router 5 is processing it.
|
|
0:15:50
|
Whether the missing is the best or the missing is the worst,
|
|
0:15:53
|
we should always prefere the path via router 4 as opposed to the path via router 1.
|
|
0:16:10
|
Some of the additional exceptions here,
|
|
0:16:12
|
we could say BGP always compare med so this would be regardless of the AS path.
|
|
0:16:17
|
Even if the routes are learned from different autonomous systems,
|
|
0:16:20
|
we would be able to compare the med between them.
|
|
0:16:23
|
The med confed, it says that for past that consist only of the AS confed sequence.
|
|
0:16:30
|
So, it means, these are the ones that came from your own confederation to begin with.
|
|
0:16:36
|
Then you would compare the med value between them.
|
|
0:16:38
|
The reason why is it basically is looking at your IGP metric to your own internal routes.
|
|
0:16:45
|
Because remember the IGP metric copied to the BGP med by default
|
|
0:16:51
|
when we are originating the prefix.
|
|
0:16:54
|
Whether we're originating it with the network statement or with the distribution.
|
|
0:16:59
|
Now, there's also another option that is the deterministic med.
|
|
0:17:04
|
Which is a very specific design case
|
|
0:17:07
|
that it's gonna make a difference whether the med is deterministic
|
|
0:17:11
|
or non-deterministic, which is the default.
|
|
0:17:16
|
So, you can see, there's a link here that you may wanna take a look at.
|
|
0:17:18
|
It says how BGP neighbors use the med value for the best path selection.
|
|
0:17:23
|
There's also one that is, what's the difference between always compare med and deterministic med.
|
|
0:17:33
|
Which I believe is linked from...
|
|
0:17:38
|
linked from this document somewhere.
|
