|
0:00:13
|
In our next section here for BGP, we're gonna talk about the BGP best path selection algorithm
|
|
0:00:19
|
that's used to determine which path are we gonna install in the routing table,
|
|
0:00:23
|
and also which prefixes are candidate to be advertised to other BGP peers.
|
|
0:00:28
|
Now, one of the key points that we'll see about the path selection
|
|
0:00:32
|
is that once the router chooses its best path,
|
|
0:00:34
|
that is the only one that can be advertised.
|
|
0:00:38
|
Even when we look at situations that we are doing BGP multipath to do load balancing,
|
|
0:00:42
|
technically, only the single best path is the one that is gonna be advertised.
|
|
0:00:47
|
So, we'll see, in certain circumstances, when we're doing route reflection, or confederation,
|
|
0:00:52
|
where certain portions of the topology do not have all possible routes out of the network,
|
|
0:00:57
|
based on how the path selection works,
|
|
0:01:00
|
it's gonna determine what particular exit points
|
|
0:01:03
|
the different iBGP routers we'll see out of the topology.
|
|
0:01:08
|
Now, as a general rule, the path selection is going to be standardized.
|
|
0:01:12
|
You can see in the BGP RFC, there's a section that talks about the decision process.
|
|
0:01:17
|
However, there are some vendor specific attributes that are different in implementations
|
|
0:01:21
|
of Cisco versus Junifer versus other routing vendors.
|
|
0:01:26
|
So, specifically, we wanna take a look at the Cisco BGP best path selection algorithm.
|
|
0:01:32
|
Now, the problem with this,
|
|
0:01:34
|
this page that we're gonna look at will not be available for us in the exam, in the documentation.
|
|
0:01:39
|
So, in general, you should understand the order of the best path selection,
|
|
0:01:43
|
and if we're trying to manipulate the attributes in order to apply a routing policy,
|
|
0:01:48
|
we should have a pretty good idea as to which attributes can be changed in which direction
|
|
0:01:53
|
in order to implement the particular traffic engineering policy that we want.
|
|
0:01:58
|
So, let's take a look at Cisco's website,
|
|
0:02:02
|
and if you simply search for the BGP best path selection,
|
|
0:02:11
|
this document here
|
|
0:02:14
|
is part of the technology documentation for BGP.
|
|
0:02:17
|
So, if you went through on the main documentation page, went to Technologies,
|
|
0:02:21
|
then, IP Routing and BGP,
|
|
0:02:23
|
you would eventually get here.
|
|
0:02:25
|
But the key is that this is not part of the Configuration Guide or the Command Reference.
|
|
0:02:29
|
So, you won't have this particular page within the scope of the actual exam.
|
|
0:02:35
|
Now, the first thing that we may want to know
|
|
0:02:38
|
before we get into the actual path selection
|
|
0:02:40
|
are what are some of the pre-requisites before we can actually run the decision process?
|
|
0:02:46
|
Now, we talked about some of these previously
|
|
0:02:49
|
when we were dealing with the basic advertisements of routes.
|
|
0:02:52
|
And first and foremost, one of the most important things
|
|
0:02:55
|
is that we have reachability to the next hop value
|
|
0:02:59
|
of the BGP prefix that is being advertised into the network.
|
|
0:03:04
|
Unless we can perform a full route recursion towards the next hop
|
|
0:03:08
|
that points us out a connected interface,
|
|
0:03:11
|
then the router would not be actually be able to encapsulate the traffic towards the particular destination.
|
|
0:03:17
|
So, this means that if the next hop value is not reachable,
|
|
0:03:20
|
the router is not gonna bother considering that path for best path selection
|
|
0:03:24
|
to make sure that it does not install a prefix that it cannot actually route traffic to.
|
|
0:03:29
|
So, this is gonna prevent traffic blackholes
|
|
0:03:32
|
in favor of other possible routes that we can perform the final route recursion to.
|
|
0:03:39
|
When we look at the Show IP BGP Output for the longer prefix,
|
|
0:03:42
|
if it says that the next hop is inaccessible,
|
|
0:03:45
|
then, it means that it did not pass this particular check,
|
|
0:03:47
|
and the prefix cannot be used for the best path selection.
|
|
0:03:53
|
Next, we have the legacy synchronization rule,
|
|
0:03:56
|
which either must be disabled,
|
|
0:03:58
|
which 99% of the time will be disable,
|
|
0:04:01
|
or we must meet the synchronization rule
|
|
0:04:04
|
by redistributing BGP routes into the IGP network.
|
|
0:04:08
|
Now, synchronization originally was a legacy blackhole prevention mechanism,
|
|
0:04:14
|
which basically wanted to fix the case
|
|
0:04:16
|
that non-BGP-speaking routers in the transit path
|
|
0:04:20
|
would not be able to deliver packets to be BGP learned destinations.
|
|
0:04:25
|
So, we'll see that in general,
|
|
0:04:27
|
there's really no reason you would want to turn synchronization on in today's networks,
|
|
0:04:32
|
but within the scope of the lab exam, technically, you could get a case that they say,
|
|
0:04:35
|
"Do, not disable the synchronization process."
|
|
0:04:39
|
So, what this means, let's say that we have...
|
|
0:04:41
|
three different ASs, where we have AS 1 that is peering with AS 2.
|
|
0:04:48
|
And being used as transit in order to reach AS 3.
|
|
0:04:55
|
And the border between AS 1 and 2,
|
|
0:04:58
|
we have router 1.
|
|
0:05:00
|
Between AS 2 and AS 3, we have router 2.
|
|
0:05:04
|
Then, we have multiple routers in AS 2 that are running IGP.
|
|
0:05:11
|
The original design problem here was that not all routers actually supported the BGP code,
|
|
0:05:16
|
and that they didn't have enough resources to actually maintain the BGP table.
|
|
0:05:21
|
So, instead of running BGP,
|
|
0:05:23
|
the logic was that we could just receive the routes on the network edge
|
|
0:05:27
|
for the devices that are running BGP,
|
|
0:05:30
|
and peering with each other.
|
|
0:05:33
|
Then, simply redistribute this into the IGP domain.
|
|
0:05:40
|
Now, as we know in today's networks, this is not gonna be feasible simply based
|
|
0:05:43
|
on the size of the current global BGP table,
|
|
0:05:47
|
which in certain cases is upwards of 400,000 or more routes
|
|
0:05:51
|
depending on your individual view of the topology.
|
|
0:05:55
|
So, this means that if we are running OSPF in the middle, or EIGRP in the middle,
|
|
0:05:59
|
then, we would be redistributing 300+, 400+ thousand routes into the topology,
|
|
0:06:04
|
which is simply not feasible.
|
|
0:06:07
|
But originally, the logic for this was
|
|
0:06:09
|
that if we can assume that everyone in the network was running IGP,
|
|
0:06:14
|
and we cannot assume that everyone in the network was running BGP,
|
|
0:06:18
|
what router 2 would say
|
|
0:06:20
|
is that "When I receive a route from my iBGP neighbor,
|
|
0:06:25
|
I will check the IGP table
|
|
0:06:28
|
to see if I have an equal match already installed in the routing table.
|
|
0:06:33
|
If I do, then I can consider the BGP route for the best path selection."
|
|
0:06:39
|
So, it's kind of a backwards logic where for every BGP route,
|
|
0:06:43
|
you would already have to have a matching IGP route for it,
|
|
0:06:46
|
which essentially means that you're performing redistribution the two processes.
|
|
0:06:52
|
Now, the easier way to fix this
|
|
0:06:53
|
is simply to either run BGP everywhere in the transit path,
|
|
0:06:59
|
or to use some sort of tunneling mechanism like MPLS, or GRE, or an IP and IP tunnel.
|
|
0:07:10
|
Now, we will revisit this problem when we get to our Layer 3 MPLS VPNs,
|
|
0:07:14
|
and talk about how the logic of MPLS tunnels
|
|
0:07:16
|
can be used to obtain what's known as the BGP free core,
|
|
0:07:20
|
where essentially, the devices in the transit path
|
|
0:07:23
|
do not need to install the particular destinations that they are actually routing the traffic towards.
|
|
0:07:29
|
But in the case of the legacy IGP design,
|
|
0:07:32
|
the problem is that if AS 1 was advertising prefix A,
|
|
0:07:36
|
then, it was advertised to router 1,
|
|
0:07:38
|
from 1 to 2,
|
|
0:07:40
|
and then, 2 out to AS 3.
|
|
0:07:43
|
If traffic is transiting someone in the IGP network that doesn't actually have prefix A installed,
|
|
0:07:49
|
then, they're not gonna be able to route the traffic towards that.
|
|
0:07:53
|
Now, the reason that this is significant to mention in the first place
|
|
0:07:56
|
is that it's part of the best path selection pre-requisites.
|
|
0:08:00
|
It says, "Paths that are marked as not synchronized in the Show IP BGP longer prefix output
|
|
0:08:06
|
are going to be ignored from being installed as best paths,
|
|
0:08:11
|
which means then they cannot be installed in the routing table,
|
|
0:08:14
|
or advertised to other routers.
|
|
0:08:16
|
Now, we can also see it says, "Synchronization is disabled by default as of 12.2(8)T.
|
|
0:08:22
|
So, within the scope of the lab exam, unless they are manually putting synchronization on,
|
|
0:08:29
|
then, we would not need to worry about this.
|
|
0:08:32
|
So, as long as in the transit path,
|
|
0:08:34
|
all of the routers do have a route to that particular destination,
|
|
0:08:38
|
then, it's fine to disable the synchronization process.
|
|
0:08:41
|
If for some reason, synchronization is required to be on,
|
|
0:08:44
|
then, you would need to redistribute from BGP into IGP in order to meet the rule.
|
|
0:08:51
|
And as we see here, it says that "If synchronization is enabled,
|
|
0:08:54
|
there must be a match for the prefix in the routing table
|
|
0:08:57
|
in order for an iBGP path to be considered a valid path."
|
|
0:09:02
|
Additionally, if the route is learned from an OSPF neighbor,
|
|
0:09:06
|
it's OSPF router ID must match the BGP router ID of the iBGP neighbor.
|
|
0:09:12
|
So, in these legacy designs, you can end up in some really strange behaviors
|
|
0:09:16
|
in the case that your IGP neighbor you're learning the prefix from
|
|
0:09:20
|
is not the same as your BGP neighbor,
|
|
0:09:21
|
and then, eventually cause a traffic loop.
|
|
0:09:25
|
You'll see that there also are some legacy RFCs that define this type of behavior.
|
|
0:09:30
|
If you look for the BGP and OSPF interaction,
|
|
0:09:34
|
RFC,
|
|
0:09:36
|
originally, there was a specific behavior that OSPF was supposed to use with BGP,
|
|
0:09:43
|
and you can see, this is marked as "HISTORIC",
|
|
0:09:45
|
where essentially, you are allowed to redistribute from BGP into OSPF.
|
|
0:09:49
|
OSPF could encode specific BGP attributes,
|
|
0:09:53
|
then, when the route is redistributed from OSPF back into BGP,
|
|
0:09:58
|
those attributes would be able to go back into BGP update.
|
|
0:10:02
|
But then problem is in today's networks, you're going out of the way in order to solve a much simpler problem.
|
|
0:10:07
|
Either run BGP everywhere in the transit path,
|
|
0:10:10
|
or use some sort of tunneling like MPLS.
|
|
0:10:13
|
That's gonna make the design much simpler.
|
|
0:10:16
|
But it is important to note here what synchronization is designed to solve
|
|
0:10:20
|
with some problem of blackholing the traffic.
|
|
0:10:23
|
So, anytime we are transiting over a device
|
|
0:10:26
|
that doesn't actually have a route to the destination,
|
|
0:10:29
|
it means that they're gonna end up dropping the traffic.
|
|
0:10:33
|
Which is the normal routing paradigm that if I don't have a route to the destination,
|
|
0:10:37
|
it means that I'm not gonna be able to deliver the traffic.
|
|
0:10:40
|
So, it's a pretty straightforward logic,
|
|
0:10:42
|
but synchronization is kind of a roundabout way in order to fix the problem.
|
|
0:10:51
|
Next, we have the case that the AS path must not contain our local autonomous system,
|
|
0:10:57
|
which would be considered our normal EBGP loop prevention mechanism.
|
|
0:11:01
|
So, if my autonomous system number is 100,
|
|
0:11:03
|
everytime I receive an update from my EBGP neighbors,
|
|
0:11:07
|
I'm gonna check to make sure that the AS path does not contain 100.
|
|
0:11:12
|
We'll see later, there are some certain cases where you may want to override this
|
|
0:11:17
|
with either the Allow AS In command, or the AS Override.
|
|
0:11:21
|
But in the vast majority of cases,
|
|
0:11:22
|
your EBGP updates are not valid if they are containing your own autonomous system number.
|
|
0:11:33
|
Then lastly, once we receive the update from the EBGP neighbors,
|
|
0:11:37
|
the router is gonna do a basic logic check that says, "The first autonomous system number in the path
|
|
0:11:42
|
should be the same value that I am using as the remote AS for that neighbor."
|
|
0:11:48
|
This is controlled with the BGP Enforce First AS command, which is on by default.
|
|
0:11:53
|
So essentially, this means if we were to look at out topology here,
|
|
0:11:57
|
when router 1 receives an update in from AS 1,
|
|
0:12:03
|
it should say that the first number in the path should be 1.
|
|
0:12:07
|
Which in reality, there should never be a case where 1 is not the first number in the path.
|
|
0:12:13
|
Most likely, the only time that that's gonna happen is if someone is trying to do some sort of BGP injection attack,
|
|
0:12:20
|
where they're sending random path information,
|
|
0:12:24
|
and trying to do some sort of TCP man-in-the-middle attack against the BGP process
|
|
0:12:30
|
in which case, that is not valid.
|
|
0:12:33
|
If this situation does occur,
|
|
0:12:35
|
it says that...
|
|
0:12:38
|
"If you enable BGP Enforce First AS, the update does not contain the AS of the neighbor,
|
|
0:12:43
|
we're gonna send a notification and close the session."
|
|
0:12:47
|
So, BGP notification
|
|
0:12:48
|
is telling the remote neighbor that there's some parameter that we cannot properly negotiate.
|
|
0:12:54
|
Whether it's something like the...
|
|
0:12:57
|
remote AS number, if my AS doesn't agree with what you say your autonomous system is,
|
|
0:13:02
|
or if we have some address family mis negotiation.
|
|
0:13:06
|
Like, I wanna run IPv4 unicast, but you wanna run IPv4 multicast.
|
|
0:13:11
|
Then, we would send a notification to each other saying that this is the particular parameter that is mismatched.
|
|
0:13:17
|
But under normal legitimate cases,
|
|
0:13:19
|
you should not see the problem where the update contains the invalid AS path.
|
|
0:13:26
|
Then lastly, it says, "If the path is marked a received-only,
|
|
0:13:30
|
it's because you're doing BGP software configuration inbound and the prefix has been filtered out
|
|
0:13:36
|
like some sort of policy that you are manually defining.
|
|
0:13:40
|
Now, we will look at software configuration a little bit later.
|
|
0:13:43
|
There's not really a reason that you would need to use this,
|
|
0:13:45
|
because it's been replaced by the standardized route refresh feature,
|
|
0:13:50
|
which is a better memory optimization that the software configuration was originally designed to solve.
|
|
0:13:57
|
So, we can do the same thing automatically with the new route refresh feature.
|
|
0:14:01
|
We don't need to manually say for this neighbor, Enable Software Configuration Inbound.
|
|
0:14:07
|
So, once we go through these checks,
|
|
0:14:09
|
and we make sure that either synchronization rule is met or disable,
|
|
0:14:13
|
the next hop is reachable via IGP,
|
|
0:14:18
|
the AS path doesn't contain our own AS,
|
|
0:14:21
|
and the AS path is not invalid,
|
|
0:14:24
|
then, we're gonna go out into the actual path selection.
|
|
0:14:32
|
For the majority of the attributes in the path selection, you should this off the top of your head what the order is,
|
|
0:14:38
|
because that is ultimately gonna control
|
|
0:14:40
|
which attributes you can change in order to implement a specific
|
|
0:14:44
|
either outbound routing policy, or inbound routing policy.
|
|
0:14:50
|
Some of these value, you don't necessarily need to memorize
|
|
0:14:53
|
because they're more tie breakers for the process.
|
|
0:14:55
|
Things like the older route, router ID, the cluster ID length,
|
|
0:15:00
|
or the cluster list length.
|
|
0:15:02
|
That stuff is kind of a last ditch effort
|
|
0:15:04
|
to make sure that something can be chosen as the best path in the process.
|
|
0:15:09
|
But in general, we need to make sure that we know at least...
|
|
0:15:14
|
I would say, the first...
|
|
0:15:16
|
6,
|
|
0:15:18
|
or 7 values here that are part of the best path selection.
|
|
0:15:22
|
So, first and foremost, we're using the weight,
|
|
0:15:26
|
which is a locally significant value that is not exchanges in any update.
|
|
0:15:32
|
Weight is not defined by the RFC, it's only a local value that Cisco IOS is using.
|
|
0:15:38
|
Now, we'll see, when we actually do the implementation of changing the best path selection,
|
|
0:15:43
|
weight is not really a great choice to use
|
|
0:15:46
|
because it's only locally significant to the router,
|
|
0:15:49
|
which means we can end up in some unpredictable forwarding patterns,
|
|
0:15:55
|
where we don't actually get the end result that we're trying to look for.
|
|
0:16:00
|
Now, there's actually an interesting turn for this when you're applying
|
|
0:16:03
|
some sort of routing policy and you end up in an unpredictable result,
|
|
0:16:07
|
it's called a "BGP Wedgy".
|
|
0:16:10
|
And there's actually an RFC that defines it.
|
|
0:16:13
|
If you search for "BGP Wedgies",
|
|
0:16:23
|
RFC 4264 BGP Wedgies.
|
|
0:16:26
|
And this is actually a pretty interesting read, you may wanna take a look at this.
|
|
0:16:29
|
In general, what it says is that...
|
|
0:16:32
|
normally, the BGP best path selection is supposed to be deterministic.
|
|
0:16:37
|
Which means that based on your configuration,
|
|
0:16:40
|
you should be able to figure out which traffic path that you're gonna follow.
|
|
0:16:43
|
Whether it's for you inbound traffic flows, or for you outbound traffic flows.
|
|
0:16:49
|
It says that, "Sometimes, you can end up in a stable state for the path selection,
|
|
0:16:53
|
where BGP converges in a non-deterministic manner."
|
|
0:16:56
|
These stable, but unintended, BGP states are termed here "BGP Wedgies".
|
|
0:17:02
|
So essentially, this document defines cases that you're trying to affect the best path selection,
|
|
0:17:07
|
but you end up in a result that you didn't predict in the first place.
|
|
0:17:10
|
So, they do go through some interesting examples here where they,
|
|
0:17:15
|
they draw out the topology.
|
|
0:17:16
|
It says, "We're AS 1, we're trying to affect the path selection, we're going to AS 3 and AS 4."
|
|
0:17:22
|
And it goes through some different cases where
|
|
0:17:24
|
based on upstream path selections,
|
|
0:17:27
|
As 1 is not able to properly implement either its outbound routing policy,
|
|
0:17:32
|
or its inbound routing policy.
|
|
0:17:36
|
Now, there are some ways today on the global BGP table to fix this.
|
|
0:17:41
|
And when look at how to do this specifically with an implementation of the BGP community attribute,
|
|
0:17:47
|
and how we can use this to influence the BGP best path selection.
|
|
0:17:54
|
So, getting back to the order here,
|
|
0:17:57
|
first, we have weight, that's gonna be the highest value.
|
|
0:18:00
|
Followed by the higher local preference, which is a non-transitive attribute,
|
|
0:18:06
|
which means that it's not gonna be advertised between EBGP peers.
|
|
0:18:11
|
In general, local preference is going to be your best option
|
|
0:18:14
|
for influencing your outbound traffic flow.
|
|
0:18:19
|
Local preference is gonna be set inbound as we receive updates from our EBGP peers,
|
|
0:18:24
|
the exchange from all of our iBGP peerings,
|
|
0:18:28
|
and then ultimately influence how the traffic is going to leave our network.
|
|
0:18:36
|
The router would then prefer any route that it is locally originating
|
|
0:18:39
|
either with the network statement, redistribution, aggregation, or conditional route injection.
|
|
0:18:46
|
So, if I'm originating an aggregate, and you're originating the same aggregate,
|
|
0:18:50
|
I would prefer my origination over yours.
|
|
0:18:55
|
Then, we look at the shorter AS path, the lower origin code where we prefer
|
|
0:19:00
|
routes that were originated by the network statement
|
|
0:19:03
|
that is the origin code IGP.
|
|
0:19:05
|
The actual protocol EGP,
|
|
0:19:09
|
which is the legacy precursor to the EGP protocol.
|
|
0:19:13
|
Then, the incomplete origin code,
|
|
0:19:15
|
which is generally either for the redistribution or the conditional route injection.
|
|
0:19:20
|
So, that's the one we saw before with the question mark
|
|
0:19:23
|
in the Show IP BGP Output, that's the origin incomplete.
|
|
0:19:28
|
Then, we have the multi-exit discriminator, or the metric value where the lower value is preferred.
|
|
0:19:35
|
We'll see, there's a lot of strange exceptions to this attribute, the med,
|
|
0:19:39
|
which is why in reality, a lot of the times, it's not even used for the path selection.
|
|
0:19:45
|
Vast majority of cases in the global Internet
|
|
0:19:47
|
are gonna be chosen based on either the local preference or the AS path.
|
|
0:19:52
|
Where the local preference is gonna be for some manual policy that we're trying to implement.
|
|
0:19:56
|
If we don't define the policy, vast majority of the time,
|
|
0:20:00
|
it's automatically gonna choose the best path based on the shorter AS path.
|
|
0:20:05
|
Then, we would choose our EBGP routes over our iBGP routes.
|
|
0:20:10
|
Again, this is different than the administrative distance,
|
|
0:20:13
|
where in this case, this is happening inside the BGP table before it gets installed in the routing table.
|
|
0:20:21
|
Then, we're gonna look at the IGP metric to the next hop value.
|
|
0:20:25
|
Now, once we get passed the sixth bullet point here, which is the external over the internal routes,
|
|
0:20:30
|
then, the BGP process can do load balancing
|
|
0:20:34
|
for equal cost paths and in newer versions also for unequal cost paths.
|
|
0:20:41
|
Where do the actual load balancing is gonna occur
|
|
0:20:44
|
is dependent on whether we have the maximum path's feature
|
|
0:20:47
|
configured under the BGP process.
|
|
0:20:51
|
We'll see, there's some very strict
|
|
0:20:54
|
requirements in order to do the BGP multipath.
|
|
0:20:57
|
Then, not only the AS path link has to be the same,
|
|
0:21:00
|
but the entire AS path has to be identical.
|
|
0:21:05
|
So, in cases where we have multiple paths via the same provider,
|
|
0:21:10
|
then, we're learning these multiple paths via our iBGP peers,
|
|
0:21:14
|
we could use these for multipath,
|
|
0:21:17
|
then, the actual ratio of it we're gonna use is based on the IGP metric to the next hop.
|
|
0:21:23
|
Once we get passed that, then, we're mainly gonna look at tie breakers.
|
|
0:21:26
|
Like, what's the oldest route, what's the lowest router ID,
|
|
0:21:29
|
the shortest cluster list would basically mean, the minimum amount of route reflectors
|
|
0:21:36
|
that the route is advertised from.
|
|
0:21:38
|
Then, our very last ditch effort is whoever has the lower neighbor address.
|
|
0:21:44
|
Now, a lot of the time, we're never gonna get passed the IGP metric to the next hop.
|
|
0:21:49
|
And just like an access list or a route map,
|
|
0:21:52
|
the best path selection is processed in a top-down manner.
|
|
0:21:57
|
So, this means that if the decision occurs based on a difference in the local preference,
|
|
0:22:02
|
we're never gonna look at the AS path information
|
|
0:22:05
|
or the multi-exit discriminator in order to make the selection.
|
|
0:22:11
|
Now, what this means
|
|
0:22:13
|
is that when we are affecting our routing policy,
|
|
0:22:17
|
we have more control over our outbound traffic flows than we do our inbound traffic flows.
|
|
0:22:25
|
Because in general, the two attributes that are used to affect our outbound traffic
|
|
0:22:30
|
will be weight and local preference.
|
|
0:22:33
|
If we were to look at this from the perspective of our topology,
|
|
0:22:37
|
let's say that in AS 100,
|
|
0:22:40
|
we want to affect how traffic is leaving the network as it goes out to AS 54.
|
|
0:22:47
|
If we look at the direction of the data plane,
|
|
0:22:50
|
which is the actual packet forwarding.
|
|
0:22:53
|
The data plane is always gonna be the opposite direction of the control plane.
|
|
0:22:57
|
It means that if router 1 is gonna be forwarding traffic out Fast Ethernet 0/0,
|
|
0:23:03
|
it's because there's a route that's installed via that interface.
|
|
0:23:09
|
So, there's some control plane routing information that's coming in the router 1
|
|
0:23:13
|
that's affecting its process of how it routes packets out.
|
|
0:23:18
|
This means that if we wanted to change how traffic leaves as it goes out to AS 54,
|
|
0:23:24
|
we would wanna change the attributes
|
|
0:23:25
|
as the routes are received inbound.
|
|
0:23:30
|
On router 4 or router 6, we could change either the weight or the local preference as the route is coming in,
|
|
0:23:36
|
this is then going to affect our path selection for the outbound traffic flow.
|
|
0:23:42
|
On the reverse direction, if we wanted to control how traffic is being received from AS 54,
|
|
0:23:48
|
it means that we would change attributes as we are sending our advertisements out,
|
|
0:23:54
|
which is general would be either AS path prepending
|
|
0:23:58
|
to change the length of AS path,
|
|
0:24:01
|
or use the multi-exit discriminator if we have multiple connections to the same provider.
|
|
0:24:07
|
So, AS path and med are gonna be set outbound to affect the inbound traffic,
|
|
0:24:12
|
where weight and local preference will be set inbound in order to affect the outbound traffic.
|
|
0:24:19
|
Now, if we compare these four attributes to the order of the best path selection,
|
|
0:24:24
|
since weight and local preference are higher than AS path and med,
|
|
0:24:29
|
it means in general, we have more control over how traffic leave the autonomous system,
|
|
0:24:35
|
then how traffic enters the autonomous system.
|
|
0:24:39
|
So, in a real world design, a lot of times, it's very difficult or nearly impossible
|
|
0:24:44
|
to do load distribution for inbound traffic flows.
|
|
0:24:48
|
Outbound flows is really easy because it's based on whatever information we're receiving in,
|
|
0:24:53
|
we can change those attributes to affect our local outbound traffic.
|
|
0:24:58
|
But to affect out inbound traffic flows,
|
|
0:25:01
|
it means that we need to make an attributes change that's going to affect someone else's autonomous system.
|
|
0:25:09
|
Now, on the actual global BGP table on the Internet,
|
|
0:25:12
|
when we apply a policy outbound,
|
|
0:25:15
|
the problem is that from the local router,
|
|
0:25:17
|
there's no way to check what the result of the policy is once we set the attributes out.
|
|
0:25:23
|
So, if I were to do AS path prepending or set the med value as it goes out to my provider,
|
|
0:25:28
|
I really have no visibility as to what the provider's decision is.
|
|
0:25:33
|
This is what the route servers are for or the BGP Looking Glass
|
|
0:25:38
|
that gives us a view of what the public BGP table looks like from difference service providers.
|
|
0:25:46
|
Now you can find a list of these if you search for...
|
|
0:25:50
|
the BGP Looking Glass or BGP Route Servers.
|
|
0:25:57
|
In general, most of these are IOS-based routers that you can just telnet to on the Internet
|
|
0:26:02
|
in order to run basic BGP commands into the table.
|
|
0:26:06
|
Like Show IP BGP for ARP prefixes.
|
|
0:26:09
|
Traceroute to figure out how traffic goes back to a particular destination.
|
|
0:26:14
|
So, let's say for example, we wanna see how is traffic
|
|
0:26:18
|
routed towards...
|
|
0:26:19
|
let's say, Cisco's website.
|
|
0:26:23
|
So, if I were to ping www.cisco.com,
|
|
0:26:28
|
it says, this is their particular...
|
|
0:26:31
|
address.
|
|
0:26:33
|
Now, if I wanna see how traffic is routed to that
|
|
0:26:37
|
from the perspective of different providers,
|
|
0:26:39
|
I then need to look at what is their view of the BGP table.
|
|
0:26:44
|
The vast majority of the time, you can telnet to route-server
|
|
0:26:49
|
followed by the provider's domain name.
|
|
0:26:53
|
Like route-server.ip.att.net would be ATNT.
|
|
0:26:57
|
Or global crossing for Hurricane Electric.
|
|
0:27:00
|
Pretty much any of the Tier 1 or Tier 2 providers
|
|
0:27:03
|
should host these route servers so you could see what the BGP view looks like.
|
|
0:27:09
|
In this case, this is one of the BGP route servers for ATNT.
|
|
0:27:14
|
If we look at the Show IP BGP Summary,
|
|
0:27:20
|
it says that currently, their view is about 350,000 networks.
|
|
0:27:27
|
But overall, we have almost 6 and a half million paths to them.
|
|
0:27:33
|
So, in reality, we have 6 and a half million routes,
|
|
0:27:37
|
but out of those 6 and a half million, only 350,000 are unique.
|
|
0:27:42
|
So, when the router is running its best path selection,
|
|
0:27:44
|
it means it comes up with 350,208 individual best paths.
|
|
0:27:52
|
Now, if were to look at a very specific route, let's look at that address...
|
|
0:28:00
|
here for Cisco's website. Let's say Show IP BGP...
|
|
0:28:04
|
and that address.
|
|
0:28:05
|
From this particular router's perspective, their longest match is a /21.
|
|
0:28:10
|
It says there's 18 possible paths and the best path is number 7 out of this.
|
|
0:28:16
|
Now, this is not being advertised to any peer
|
|
0:28:18
|
because this router is not actually used for routing traffic in the data plane.
|
|
0:28:23
|
It's just used for our view of the control plane to see how the BGP policy is working.
|
|
0:28:29
|
So, it's not actually routing traffic. It's just used to hold the BGP table.
|
|
0:28:33
|
Now, if we were to compare these on a top-down manner,
|
|
0:28:37
|
it says, "Eventually, you get the path number 7, which is the best path."
|
|
0:28:42
|
We would then need to look at the weight value,
|
|
0:28:45
|
the local preference, whether this is a local route,
|
|
0:28:49
|
the origin code, the AS path, the multi-exit discriminator,
|
|
0:28:53
|
down, and down, and down
|
|
0:28:55
|
until we eventually end up in a tie breaker.
|
|
0:28:59
|
Now, from this particular router's perspective, it looks like these neighbors who it is learning the routes from,
|
|
0:29:04
|
these are all directly connected routes.
|
|
0:29:08
|
And I can tell this because it doesn't give me a metric value towards the next hop.
|
|
0:29:14
|
If the next hop is a directly connected link,
|
|
0:29:16
|
then, the cost is gonna be zero.
|
|
0:29:19
|
So, most likely, what's happening here is that
|
|
0:29:22
|
this decision is based on some tie breaker like the lowest router ID
|
|
0:29:26
|
or the lowest peer address or possibly just all those routes that is installed in the table.
|
|
0:29:33
|
Now, if we were to look at other views,
|
|
0:29:36
|
let's say we look at some other route server...
|
|
0:29:40
|
routeviews.org.
|
|
0:29:48
|
And generally, you'll see that these routers are pretty slow
|
|
0:29:51
|
because there may be a bunch of different users that are logging at the same time to do the views of the table.
|
|
0:30:00
|
But we can see that this particular router has pretty well diverse AS path information.
|
|
0:30:06
|
We could tell, the first different values here, these are all the different autonomous system that it is peering with.
|
|
0:30:11
|
So, it's taking peaks from a lot of different providers.
|
|
0:30:14
|
We look at Show IP BGP Summary,
|
|
0:30:19
|
probably, this view is gonna be a little bit bigger than ATNT.
|
|
0:30:23
|
So, this has 385,000 networks.
|
|
0:30:26
|
And it has over 12 million paths to reach them.
|
|
0:30:32
|
So, you'll see, depending on what your view on the global table is,
|
|
0:30:37
|
you may have more or less routes than other peers.
|
|
0:30:40
|
It depends on things like your aggregation policy,
|
|
0:30:43
|
how strict your providers are whether they're gonna say,
|
|
0:30:46
|
"I won't accept anything that's larger than /21",
|
|
0:30:49
|
or "I'm not gonna accept anything with an AS path that is greater than this."
|
|
0:30:55
|
So, it's up to your individual provider
|
|
0:30:57
|
to determine what their policy is gonna be when you peer with them through BGP.
|
|
0:31:03
|
But we'll see, this route service can be useful for some of our practice for BGP.
|
|
0:31:10
|
For things like testing the logic of the regular expressions
|
|
0:31:12
|
or to see how the BGP community policies can be used
|
|
0:31:16
|
for influencing the path selection
|
|
0:31:18
|
because this is the actual data that's used for public forwarding on the Internet.
|
|
0:31:26
|
Now, we'll also see that there's a bunch of minor exceptions
|
|
0:31:30
|
to the best path selection process.
|
|
0:31:33
|
We could technically tell the router to just skip over the autonomous system path completely,
|
|
0:31:39
|
which in that case, it doesn't matter what the length is we would be looking at any other attribute besides that.
|
|
0:31:44
|
Also, the multi-exit discriminator or med has a bunch of different exceptions
|
|
0:31:50
|
that are gonna control whether the med value is even used,
|
|
0:31:53
|
or if it is, what is the order that the path selection is going to be using.
|
|
0:32:01
|
Now, by default, all of these values,
|
|
0:32:05
|
or all of these commands, I believe they're off by default.
|
|
0:32:08
|
So, BGP does not always compare med.
|
|
0:32:11
|
It does not compare the med between confederation peers.
|
|
0:32:16
|
if the med value is null when we receive it from an external peer,
|
|
0:32:21
|
we're gonna set the null med to be zero
|
|
0:32:24
|
as opposed to the maximum,
|
|
0:32:26
|
which is 4.2 billion.
|
|
0:32:29
|
Now, the problem with this...
|
|
0:32:31
|
is that the different vendors
|
|
0:32:36
|
implement the default values of the path selection a little bit differently.
|
|
0:32:39
|
So, if you have a multi-vendor environment in your BGP network,
|
|
0:32:43
|
you might end up in a case where the routers don't agree on the path selection.
|
|
0:32:47
|
So, this is why IOS has these different switches that you can set
|
|
0:32:51
|
to make sure that everyone in the network does agree on whether the med
|
|
0:32:55
|
value is gonna be deterministic or not,
|
|
0:32:57
|
or whether the null value or equal the best med or whether it equal the worst med,
|
|
0:33:04
|
because we wanna make sure everyone agrees on what the same best path is gonna be.
|
|
0:33:10
|
Now, in the case that the routers don't run the same order for the path selection,
|
|
0:33:14
|
it generally is not gonna matter anyways.
|
|
0:33:17
|
We could just simply end up in an inefficient traffic flow
|
|
0:33:21
|
as opposed to a traffic loop, or a traffic black hole.
|
|
0:33:25
|
And the reason why is that the router will only advertise its best path to begin with.
|
|
0:33:34
|
So, we'll see cases that if router 1 is routing through router 2,
|
|
0:33:39
|
then, router 1 is not gonna advertise a path back to router 2...
|
|
0:33:46
|
because it cannot advertise anything else besides its best path.
|
|
0:33:50
|
So, this principle of advertising only your best path,
|
|
0:33:53
|
it actually has two uses:
|
|
0:33:55
|
one of them is gonna keep the size of the BGP table down,
|
|
0:33:59
|
because when we look at that size of the routing table, it says, "This particular router has 12 million routes."
|
|
0:34:06
|
So, I wouldn't wanna take 12 million routes and then advertise it back to this peer.
|
|
0:34:10
|
And then, back to the second peer.
|
|
0:34:12
|
So, when the advertisements go outbound,
|
|
0:34:14
|
it's only gonna be the subset of what is the best paths,
|
|
0:34:18
|
which is 385,000 in this case.
|
|
0:34:24
|
Additionally, it's also gonna be a loop prevention mechanism.
|
|
0:34:28
|
So, if I am routing through you, it means that I should not advertise any other path to you.
|
|
0:34:38
|
So, let's take a look at this on...
|
|
0:34:41
|
our particular topology.
|
|
0:34:43
|
And what the default behavior inside AS 100,
|
|
0:34:47
|
we'll see, in which direction are we choosing the route out to AS 54,
|
|
0:34:52
|
and based on the default values exactly why that's happening.
|
|
0:34:56
|
Now, for those exceptions that I mentioned in the decision process, things like the...
|
|
0:35:01
|
the always compare med versus the missing its worst deterministic med,
|
|
0:35:05
|
I am gonna come back and do some examples of these.
|
|
0:35:06
|
So, I'll go back over these in more detail a little bit.
|
|
0:35:14
|
Now, the way the peerings are set up inside AS 100,
|
|
0:35:18
|
there's a full mesh of peerings between router 4 and 6,
|
|
0:35:22
|
6 and 1, and 1 and 4.
|
|
0:35:25
|
These are all of the IBGP peerings.
|
|
0:35:29
|
Then, between the ASs, we have peerings between 4 and 5,
|
|
0:35:32
|
1 and 5, 1 and 3, and 6 and switch 1.
|
|
0:35:38
|
So, this means that when the prefixes are received in from AS 54,
|
|
0:35:45
|
router 6 is gonna receive the external route.
|
|
0:35:49
|
It's gonna advertise it to these two internal neighbors.
|
|
0:35:53
|
If router 1 chooses this as the best path,
|
|
0:35:58
|
this would then be the route that's advertised to router 3 and to router 5.
|
|
0:36:05
|
Since we're not doing route reflection inside AS 100,
|
|
0:36:08
|
router 1 will not advertise the path to router 4.
|
|
0:36:12
|
So, it's the automatic loop prevention of IBGP
|
|
0:36:16
|
that says, "When I receive a route from an IBGP neighbor,
|
|
0:36:18
|
I cannot advertise it to any other IBGP neighbors."
|
|
0:36:23
|
Now, from router 4's perspective, it's also gonna be receiving a route in from BB3.
|
|
0:36:28
|
If it chooses this as the best path,
|
|
0:36:31
|
then, this is the prefix that's gonna be advertised down to router 1.
|
|
0:36:36
|
So, with the default behavior,
|
|
0:36:39
|
in general in the network edge,
|
|
0:36:41
|
those routers would prefer the routes via their EBGP neighbors
|
|
0:36:46
|
versus the other IBGP paths.
|
|
0:36:49
|
So, if everything else is equal,
|
|
0:36:51
|
the weight, local preference, AS path, origin, and the med,
|
|
0:36:55
|
then, we're gonna choose the external routes over the internal routes.
|
|
0:37:00
|
Which makes sense because in general, if we're learning a prefix from BGP,
|
|
0:37:04
|
it means that it's a route that is not inside of our own network.
|
|
0:37:10
|
And the reason why is that iBGP
|
|
0:37:13
|
has the worst administrative distance of all the dynamic protocols.
|
|
0:37:18
|
So, if I'm learning a route from OSPF and iBGP,
|
|
0:37:23
|
it would mean that that route is internal to my network,
|
|
0:37:26
|
and I would prefer my IGP route.
|
|
0:37:30
|
If I was learning a route from EBGP,
|
|
0:37:33
|
it means it is then external to my network.
|
|
0:37:36
|
So, I should have an IGP route to it.
|
|
0:37:39
|
So, I would prefer to forward the traffic outside of the network as opposed to back in.
|
|
0:37:47
|
So, let's take a look at router 6 here.
|
|
0:37:50
|
And first, we'll look at the Show IP BGP.
|
|
0:37:54
|
We see that we have two possible routes
|
|
0:37:58
|
to all of the prefixes that are being learned from AS 54.
|
|
0:38:03
|
One of them is via our connected neighbor.
|
|
0:38:05
|
One of them is via the link between router 4 and BB3.
|
|
0:38:10
|
Now, simply based on the fact that router 6 has multiple routes to this particular destination,
|
|
0:38:16
|
I can make some basic assumptions about what the rest of the BGP table inside my network looks like.
|
|
0:38:24
|
If router 6 is learning about the route from router 4,
|
|
0:38:30
|
so, 6 is learning the route from BB1.
|
|
0:38:33
|
It's also learning the route from router 4.
|
|
0:38:37
|
I could the infer that router 4 is not using router 6 as the exit point.
|
|
0:38:44
|
Because if router 4's best path was through router 6 to begin with,
|
|
0:38:48
|
it would not be able to advertise it any alternate paths.
|
|
0:38:52
|
Likewise, if we were to look at router 4,
|
|
0:38:55
|
and do the same thing.
|
|
0:38:57
|
Say, Show IP BGP.
|
|
0:39:00
|
Based on the fact that I'm learning multiple routes out to AS 54,
|
|
0:39:05
|
it means that the other exit points are using their external peers as their best paths.
|
|
0:39:14
|
So, let's look at our first prefix here, we'll Show IP BGP 28.119.16.0/24.
|
|
0:39:22
|
And we'll go through the attributes on a top-down basis.
|
|
0:39:26
|
Now, anytime we look at the Show IP BGP longer prefix output,
|
|
0:39:29
|
and the weight attribute does not show up,
|
|
0:39:32
|
it means that the weight is not set.
|
|
0:39:35
|
So, the weight will be zero by default
|
|
0:39:38
|
unless the prefix is locally originated under the BGP process.
|
|
0:39:44
|
So, if I do the network statement under BGP,
|
|
0:39:47
|
that prefix is gonna get a default weight of 32768.
|
|
0:39:52
|
So, therefore, the router would always prefer its local origination as opposed to anyone else's equal route.
|
|
0:40:00
|
But here, we see that the weight value is not set.
|
|
0:40:03
|
So, it means it's both zero.
|
|
0:40:06
|
We then see the local preference is 100, which is the default value.
|
|
0:40:10
|
So then, we need to continue on.
|
|
0:40:12
|
Neither of these are locally generated.
|
|
0:40:16
|
So, otherwise, we would see here the keyword local.
|
|
0:40:21
|
The origin code is IGP for both.
|
|
0:40:24
|
So, that's equal.
|
|
0:40:25
|
The AS path length is both 1 AS.
|
|
0:40:30
|
So, those are equal.
|
|
0:40:32
|
The metric value is zero for both of them.
|
|
0:40:36
|
This is the multi-exit discriminator.
|
|
0:40:41
|
Which means then, we're gonna prefer the EBGP route over the IBGP route.
|
|
0:40:46
|
So, we see, the second one that actually is the best path,
|
|
0:40:49
|
this is being learned from the external peer,
|
|
0:40:51
|
where the first one is being learned from our IBGP peers.
|
|
0:41:00
|
If we were to look at 6 for the same prefix,
|
|
0:41:03
|
we would see exact the same thing, but in the opposite direction.
|
|
0:41:08
|
So, router 6 says, "Everything is equal up to the point where I'm choosing the external route over the internal route."
|
|
0:41:17
|
Now, once these prefixes are advertised to router 1,
|
|
0:41:20
|
then, router 1 is gonna see them both as being learned from internal peers.
|
|
0:41:28
|
So, in this case for router 1, essentially, all of the prefixes' attributes are the same.
|
|
0:41:34
|
None of the have the weight set, the local preference is the same,
|
|
0:41:37
|
the origin is the same, the AS path length, the multi-exit discriminator,
|
|
0:41:41
|
even the metric to the next hop values
|
|
0:41:45
|
because under the IGP process,
|
|
0:41:48
|
router 6 is advertising the frame-relay interface into OSPF
|
|
0:41:54
|
with a network statement.
|
|
0:41:57
|
Router 4 is doing the same thing for its length to BB3.
|
|
0:42:02
|
So, router 1 is saying, I basically have an OSPF cost of 2 in order to reach those exit points.
|
|
0:42:09
|
In this particular case where all of the attributes are equal,
|
|
0:42:13
|
and multiple prefixes are being learned from the iBGP neighbors,
|
|
0:42:17
|
this is the case where we could do multipath.
|
|
0:42:21
|
So, on router 1, if we were to look at the Show IP Route for 28.119.16.0/24,
|
|
0:42:31
|
it says, "Right now, the outbound path is via router 4."
|
|
0:42:36
|
Since only one route is being installed in the RIB,
|
|
0:42:39
|
it means that BGP multipath is off by default for this version.
|
|
0:42:44
|
If we were to go under the BGP process,
|
|
0:42:46
|
and say, Maximum Paths for iBGP multipath,
|
|
0:42:52
|
let's say we have a maximum of path of two.
|
|
0:42:54
|
We should then see that router 1 is able to install
|
|
0:42:58
|
the multiple paths in the routing table.
|
|
0:43:02
|
For some of the later versions in this case on router 1, if we Show Version Include IOS,
|
|
0:43:07
|
this is running 12.4 Mainline.
|
|
0:43:09
|
If we were to go to the routers that are running 12.4T,
|
|
0:43:13
|
or anything later than this,
|
|
0:43:16
|
these versions would also support unequal cost load balancing for the iBGP multipath.
|
|
0:43:24
|
If router 4 said, Maximum Path for iBGP,
|
|
0:43:31
|
there will be a option somewhere for the multipath.
|
|
0:43:35
|
So, if you look at the Configuration Guide for BGP,
|
|
0:43:41
|
we go down to BGP Configuration.
|
|
0:43:45
|
Then, there's a separate document here, BGP multipath Load Sharing.
|
|
0:43:54
|
Then, it also should say here about unequal...
|
|
0:43:58
|
cost load sharing.
|
|
0:43:59
|
If we look at the command reference...
|
|
0:44:03
|
for BGP,
|
|
0:44:06
|
this should be under... I believe it's under Maximum Paths.
|
|
0:44:14
|
Where there's two different ways that we could do this.
|
|
0:44:17
|
One of them is gonna be specific for MPLS networks.
|
|
0:44:24
|
Maximum Path EIBGP, "To configure multipath load sharing for EBGP and IBGP routes."
|
|
0:44:31
|
Under the usage it says that "This configure load sharing in an in MPLS VPN network.
|
|
0:44:38
|
It's configured under the VRF family, the number of multipaths is configured separately for each VRF."
|
|
0:44:43
|
Okay, so this one is specifically for MPLS and BGP configs.
|
|
0:44:47
|
The second one, Maximum Path for iBGP,
|
|
0:44:54
|
it says, "Under the VRF and address family configuration mode,
|
|
0:44:56
|
there's an option that we can do unequal cost load sharing."
|
|
0:45:00
|
So, some of these features on BGP, you'll see that they're different
|
|
0:45:04
|
whether they're talking about the global IPv4 unicast process
|
|
0:45:08
|
versus the other address families whether it's IPv4 multicast,
|
|
0:45:12
|
or VPNv4 for MPLS,
|
|
0:45:16
|
IPv6 unicast, or IPv6 multicast.
|
|
0:45:18
|
Not all of the features are gonna be within our scope,
|
|
0:45:22
|
because sometimes, they refer to other protocols.
|
|
0:45:26
|
So, when you're going through the Configuration Guide in the Command Reference,
|
|
0:45:30
|
you should be able to tell in general what's gonna be within the scope of routing and switching.
|
|
0:45:35
|
So, anything that is related to like Layer 2 MPLS VPNs,
|
|
0:45:39
|
or inter-AS MPLS VPNs,
|
|
0:45:43
|
multicast VPNs over MPLS.
|
|
0:45:46
|
Those type of BGP configurations are not gonna be within our scope.
|
|
0:45:53
|
So, let's now say in AS 100,
|
|
0:45:55
|
we wanna change the path selection
|
|
0:45:57
|
so that we prefer traffic to leave via the link between router 6 to BB1
|
|
0:46:04
|
as opposed to the link from router 4 to BB3.
|
|
0:46:09
|
So, this is going to be our outbound traffic flow,
|
|
0:46:14
|
which means, to influence this, we would need to apply an inbound BGP policy.
|
|
0:46:19
|
So, in general, we would use either weight or local preference in order to do this.
|
|
0:46:25
|
Now, before we can actually test this,
|
|
0:46:27
|
we need to make sure that we're actually advertising prefixes in the BGP.
|
|
0:46:31
|
So, we could do a ping or a traceroute once the...
|
|
0:46:35
|
configuration is complete.
|
|
0:46:37
|
Because again, the IPv4 and IPv6 unicast routing,
|
|
0:46:41
|
it's always gonna be asynchronous.
|
|
0:46:45
|
Just because I have a route to you,
|
|
0:46:48
|
doesn't necessarily mean that you have a route back to me.
|
|
0:46:53
|
So, on router 1, I'm gonna go under the BGP process,
|
|
0:46:57
|
and simply advertise the...
|
|
0:47:01
|
loopback. Say, network 150.28.1.0
|
|
0:47:09
|
/24, Router 4's loopback,
|
|
0:47:12
|
and router 6's loopback.
|
|
0:47:17
|
Once these updates are sent, I should then be able to send traffic to any of these BGP learned destinations
|
|
0:47:23
|
as long as I'm sourcing the traffic from my local loopback.
|
|
0:47:27
|
If I were to look at the traceroute for this,
|
|
0:47:31
|
sourcing the traffic from my loopback,
|
|
0:47:33
|
we can see that router 1 is actually load balancing between the two destinations.
|
|
0:47:39
|
So, depending on what the switching mechanism says,
|
|
0:47:42
|
which is going to be CEF by default,
|
|
0:47:44
|
CEF is gonna take both the source and the destination
|
|
0:47:48
|
as inputs to its hashing algorithm.
|
|
0:47:51
|
Now, we can see based on the specific source and destination,
|
|
0:47:55
|
which route is actually gonna be chosen.
|
|
0:47:58
|
If we look at the Show IP CEF Exact Route,
|
|
0:48:03
|
for this particular source, let's say the loopback of router 1,
|
|
0:48:06
|
and this particular destination,
|
|
0:48:11
|
it says, "In this case, we're going to router 4."
|
|
0:48:14
|
If I were to vary the input between the source and the destination,
|
|
0:48:19
|
we can see it's switching between router 1, or router 4, and router 6,
|
|
0:48:25
|
because we're doing equal cost load distribution
|
|
0:48:29
|
based on the source and the destination pairs.
|
|
0:48:34
|
Now, in order to make sure that traffic is always gonna exit via router 6,
|
|
0:48:38
|
then, we're gonna need to change the BGP best path selection.
|
|
0:48:43
|
To do this, we would need to essentially make sure
|
|
0:48:45
|
that router 4 does not choose the route that's being learned via BB3 as the best path.
|
|
0:48:53
|
If I can get router 4 to not use this route,
|
|
0:48:58
|
it means it cannot be advertised to the other peers,
|
|
0:49:02
|
which would then in turn mean that the only possible route out of the network would be via router 6.
|
|
0:49:11
|
So, let's say in this case, we're trying to make the change based on the weight attribute.
|
|
0:49:17
|
How can I use the weight to make sure that traffic is always gonna exit via router 6
|
|
0:49:23
|
assuming that that link is up.
|
|
0:49:24
|
Now, if the link is down, we know that we're not gonna use that path.
|
|
0:49:27
|
BGP is gonna re-converge to whatever other available path there is.
|
|
0:49:34
|
So, let's look at this on router 6.
|
|
0:49:40
|
On router 6, if we Show IP BGP,
|
|
0:49:42
|
let's say for that 112 network, 112.0.0.0.
|
|
0:49:49
|
It says, "I have two possible paths: one of them is from BB1,
|
|
0:49:53
|
the other one is through BB3 via router 4."
|
|
0:49:57
|
Now, I'm already choosing my external path as the best route.
|
|
0:50:04
|
This means that if I were to change the weight on router 6,
|
|
0:50:07
|
it's not gonna affect any of the other routers in the AS.
|
|
0:50:13
|
However, if I were to go to router 4,
|
|
0:50:16
|
and change the weight so that I never install
|
|
0:50:21
|
the 112 prefix via BB3,
|
|
0:50:26
|
it would imply that this alternate route would have to be the best route
|
|
0:50:30
|
for every other neighbor inside of the iBGP topology.
|
|
0:50:38
|
So technically, even though the weight attribute is locally significant,
|
|
0:50:41
|
there are certain designs that you can set it in order to affect the entire AS.
|
|
0:50:47
|
Now, there's a couple different ways that we could do this.
|
|
0:50:49
|
We could do it selectively on a criteria that we define,
|
|
0:50:53
|
like a prefix list, or an AS path access list
|
|
0:50:56
|
under a route map,
|
|
0:50:58
|
or we could set the weight directly on to the neighbor.
|
|
0:51:01
|
If we set it on to the neighbor, it's gonna affect all paths that are being learned from them.
|
|
0:51:07
|
So, on router 4, if I were to say, "For any prefix that I'm learning from router 6,
|
|
0:51:11
|
I'll just set the weight to 1."
|
|
0:51:15
|
So, anything that's larger than the default, which is zero.
|
|
0:51:21
|
If I now do a route refresh inbound,
|
|
0:51:25
|
then, Show IP BGP,
|
|
0:51:27
|
we should see, once the new weight value is applied,
|
|
0:51:33
|
so we see, right now, the weight is still zero for everything.
|
|
0:51:40
|
Now, it's change to 1.
|
|
0:51:42
|
And each of these paths that have the weight of 1,
|
|
0:51:46
|
those are gonna be the preferred exit points.
|
|
0:51:50
|
If I were now to look at the Show IP BGP 112.0.0.0,
|
|
0:51:58
|
now, my best path is via router 6,
|
|
0:52:01
|
because the weight is higher.
|
|
0:52:04
|
But since I'm no longer using the route via BB3 as the best path,
|
|
0:52:09
|
it then implies that I cannot advertise this route.
|
|
0:52:15
|
If we look at the change on router 1,
|
|
0:52:17
|
and Show IP BGP,
|
|
0:52:19
|
we see now, router 1 only sees one possible exit point out to AS 54.
|
|
0:52:27
|
Simply based on the fact that router 4 cannot advertise a path that is not using as a best route.
|
|
0:52:36
|
So now, on router 1, if we do a traceroute to any of these destinations,
|
|
0:52:41
|
we see that the only possible path is now to exit out via router 6.
|
