|
0:00:13
|
Our next topic here is filtering with BGP.
|
|
0:00:16
|
Where again, there's a lot of different ways that we can apply the same type of policy
|
|
0:00:21
|
on to a particular neighbor
|
|
0:00:23
|
whether we're doing this with an access list,
|
|
0:00:25
|
or an AS path access list, or prefix list, or a route map.
|
|
0:00:29
|
There's a lot of different ways to get to the same goal.
|
|
0:00:32
|
It just depends on how many steps we wanted to do in order to get there.
|
|
0:00:37
|
Now, one thing I do wanna mention here is that when you're filtering either outbound or inbound to the neighbor,
|
|
0:00:42
|
there is a set order of operations as to...
|
|
0:00:47
|
how the router is gonna be processing either an access list versus a AS path access list versus a prefix list
|
|
0:00:54
|
that is different for inbound updates versus outbound updates.
|
|
0:01:00
|
Now, you don't need to memorize what the order is,
|
|
0:01:03
|
but the key is that if I were to apply both a distribute list and a prefix list,
|
|
0:01:08
|
I don't necessarily know which one is gonna go before the other one.
|
|
0:01:12
|
So, by using a route map on the peer,
|
|
0:01:16
|
this is going to avoid any of those errors in the order of operations.
|
|
0:01:20
|
Because the order that the filter is gonna be processed
|
|
0:01:23
|
is exactly based on the line numbering that I used inside the route map.
|
|
0:01:30
|
So, since the route map is processed in a top-down fashion,
|
|
0:01:34
|
whatever I define as whether the prefix list is match first versus the AS path list,
|
|
0:01:38
|
or the distribute list, then, that ultimately is gonna be the exact order
|
|
0:01:42
|
that the configuration works in.
|
|
0:01:47
|
So, if we look under the BGP process, we'll see that there's
|
|
0:01:49
|
a lot of different options that you can apply on to the neighbor.
|
|
0:01:53
|
We say, Router BGP...
|
|
0:01:56
|
100 here on router 4.
|
|
0:01:59
|
Let's say Neighbor as we are...
|
|
0:02:03
|
sending updates out to BB3.
|
|
0:02:10
|
We could use a distribute list for filtering.
|
|
0:02:13
|
The filter list would be the application of an AS path access list directly to them.
|
|
0:02:20
|
The prefix list would be to apply prefix list directly to them.
|
|
0:02:24
|
And then, the route map would be to...
|
|
0:02:25
|
allow us to do it in a modular format.
|
|
0:02:31
|
You'll also see a lot of these other minor features in BGP.
|
|
0:02:34
|
Most of the time, if you just look up in the command reference, you can see what the usage guidelines are.
|
|
0:02:38
|
They're gonna be pretty self-explanatory as to what they do.
|
|
0:02:42
|
So, things like remove private AS.
|
|
0:02:45
|
It says "If you have...
|
|
0:02:47
|
values in a private range,
|
|
0:02:50
|
which again are the last 1024
|
|
0:02:52
|
autonomous system numbers.
|
|
0:02:54
|
When you're sending your EBGP updates out,
|
|
0:02:57
|
it would remove that from the autonomous system path."
|
|
0:03:00
|
So, this would be used for example on a provider
|
|
0:03:03
|
that has customers using private autonomous system numbers,
|
|
0:03:08
|
because they don't have their own
|
|
0:03:10
|
provider independent address space,
|
|
0:03:13
|
but they still wanna run BGP in order to implement a routing policy.
|
|
0:03:17
|
So, in order to do that, the service provider just allocates them a locally significant private AS number.
|
|
0:03:23
|
But then, we need to make sure, as the routes are advertised up to the global table
|
|
0:03:27
|
that it's not using that private AS number.
|
|
0:03:32
|
Because in the Tier 1 providers, they are gonna be filtering on the inbound updates
|
|
0:03:36
|
to make sure that the AS numbers are still in the valid range.
|
|
0:03:42
|
So, other features like the local autonomous system,
|
|
0:03:45
|
we talked about this before. This would be if we're doing a migration scenario.
|
|
0:03:50
|
And the remote neighbor has a different configuration for what your autonomous system is.
|
|
0:03:57
|
So, you can specify when I send the BGP open message,
|
|
0:04:00
|
what's the particular AS value that I give them?
|
|
0:04:03
|
You can also in newer versions, you could say,
|
|
0:04:06
|
"I want to give them AS 1,
|
|
0:04:09
|
but I also want to...
|
|
0:04:14
|
give them dual AS support,
|
|
0:04:17
|
which means I'll offer them basically two open messages.
|
|
0:04:19
|
One for my global autonomous system, and them one for my local autonomous system."
|
|
0:04:25
|
So then, this means that regardless of what their configuration is,
|
|
0:04:29
|
whether they're peering with me based on my actual autonomous system versus the
|
|
0:04:34
|
previous one, then, it's still gonna allow the session to set up.
|
|
0:04:40
|
So, these type of features, when we compare this to stuff like the confederation,
|
|
0:04:43
|
or the route reflection, or the best path selection,
|
|
0:04:45
|
there's really not a lot of technology understanding per se,
|
|
0:04:50
|
or a lot of design issues that you need yo go through.
|
|
0:04:52
|
It's more just spending time to read through the command reference,
|
|
0:04:55
|
and to simply look at the question mark in the context sensitive help
|
|
0:04:58
|
to see what are the particular features that BGP has available.
|
|
0:05:03
|
So, a lot of these, just by looking at what the question mark says,
|
|
0:05:06
|
it's self-explanatory what this does, and you probably don't even need to try it out.
|
|
0:05:11
|
Like the BGP Allow AS In.
|
|
0:05:13
|
It says, "Accept AS path with my AS present in it."
|
|
0:05:16
|
Pretty self-explanatory.
|
|
0:05:18
|
BGP advertisement interval. Minimum interval between sending BGP routing updates.
|
|
0:05:22
|
So, by decreasing this,
|
|
0:05:26
|
it means that it would speed up the convergence for that particular peer.
|
|
0:05:29
|
By decreasing it, it's gonna be less overhead for processing, but it's gonna take less,
|
|
0:05:34
|
or it's gonna take more time for us to converge for that particular neighbor.
|
|
0:05:39
|
So, I'm not gonna go through a lot of different examples with the filtering here.
|
|
0:05:42
|
If you look in the Volume 1 workbook, it pretty much goes to all the different variations of the filters.
|
|
0:05:48
|
The one other thing I do wanna mention though
|
|
0:05:50
|
is that you can use the application of an extended access list with BGP
|
|
0:05:56
|
in place of a prefix list in order to filter on a specific address and its mask at the same time.
|
|
0:06:06
|
So, let's say for example on router 4,
|
|
0:06:08
|
I wanna generate an aggregate under the BGP process.
|
|
0:06:12
|
So, let's say, under router BGP 100.
|
|
0:06:15
|
I am advertising the aggregate address
|
|
0:06:21
|
that is 155.20, or actually, 150.
|
|
0:06:26
|
150.28.4.0
|
|
0:06:35
|
slash...
|
|
0:06:41
|
Let's say, /23.
|
|
0:06:45
|
And additionally, I am advertising my local loopback.
|
|
0:06:56
|
And the reason I'm doing it this way is that I want the address values
|
|
0:06:59
|
to overlap between the subnet and the aggregate.
|
|
0:07:02
|
So now, on router 4, if we look at the Show IP BGP Regular Expression caret dollar sign (^$),
|
|
0:07:08
|
which again is our empty AS set, which means our local routes,
|
|
0:07:12
|
we see, we have the subnet which is the /24
|
|
0:07:15
|
plus the aggregate which is the /23.
|
|
0:07:19
|
Now, additionally, let's say that when I'm advertising routes out to
|
|
0:07:24
|
BB3,
|
|
0:07:26
|
I want to allow the /23, but not the /24.
|
|
0:07:33
|
If we were to use a prefix list, this application is very straightforward.
|
|
0:07:36
|
We would just say,
|
|
0:07:38
|
permit whichever one that we want,
|
|
0:07:40
|
and then, deny the other ones.
|
|
0:07:43
|
The issue is that with an access list,
|
|
0:07:45
|
normally, the access list is gonna match only on the address field,
|
|
0:07:50
|
and not on the length, which is the subnet mask.
|
|
0:07:53
|
So, if I were to say,
|
|
0:07:56
|
Access List 1 Permit 150.28.4.0,
|
|
0:08:01
|
the router is not gonna be able to distinguish between the /23 and the /24.
|
|
0:08:08
|
Which is bad if I'm trying to filter 1 versus the other.
|
|
0:08:12
|
So, as workaround to this before the prefix list was implemented,
|
|
0:08:16
|
specifically for BGP,
|
|
0:08:18
|
there's a change in the extended access list syntax.
|
|
0:08:21
|
That if we were to say, Access List 100 Deny IP Host 150.28.4.0
|
|
0:08:34
|
with a destination of 255.255.255.0,
|
|
0:08:40
|
instead of the normal source and destination,
|
|
0:08:45
|
this now changes to the prefix and the prefix length.
|
|
0:08:54
|
So, if I were now to go under the BGP process,
|
|
0:08:59
|
and say that for the neighbor 204.12.28.254,
|
|
0:09:06
|
I want to apply the Distribute List 100 Out.
|
|
0:09:12
|
Then, I Clear IP BGP Star Out. So, that's gonna affect my new policy.
|
|
0:09:19
|
Then, look at what I am advertising to that particular peer.
|
|
0:09:25
|
We can see that the /24 for that address was filtered out, but not the /23.
|
|
0:09:35
|
So, the extended access list syntax is changing for BGP
|
|
0:09:40
|
where the source is now the address,
|
|
0:09:44
|
or the network.
|
|
0:09:45
|
And the destination is the subnet mask, or the length.
|
|
0:09:51
|
Now, really, implementation-wise, there's no reason that you would wanna use this syntax as opposed to prefix list.
|
|
0:09:57
|
Just the point is that you theoretically could.
|
|
0:10:01
|
So, within the scope of the lab exam, if I had a question that said, "Don't use a prefix list",
|
|
0:10:05
|
but I need to match on both the address and the length at the same time,
|
|
0:10:08
|
then, I could technically use this extended access list syntax.
|
|
0:10:13
|
So, definitely, play around with those different type of filters that are available for BGP.
|
|
0:10:17
|
Just keep in mind that if you stick you filtering, if you stay with the route maps,
|
|
0:10:21
|
then, you're gonna avoid any of those errors in the order of operations.
|
|
0:10:25
|
So then, you would be allowed to apply both the prefix list and an AS path access list at the same time
|
|
0:10:32
|
as long as the route map is defining what exact order that they're gonna be processed in.
|
|
0:10:41
|
Now, for other optimizations of BGP,
|
|
0:10:44
|
for the convergence timers,
|
|
0:10:47
|
this is a little bit more complicated than it is in IGP convergence,
|
|
0:10:52
|
because there's a lot of factors that play in to how quickly the BGP network is gonna converge.
|
|
0:10:58
|
Now, we do have timers for the hello interval and the keepalive interval
|
|
0:11:02
|
just like we do the hello and dead timer for OSPF or for EIGRP,
|
|
0:11:07
|
but typically, the dead neighbor detection
|
|
0:11:10
|
is not going to be the end all and be all for BGP convergence.
|
|
0:11:16
|
So, that will tell us how long it's gonna take before we figure out if a neighbor is down,
|
|
0:11:22
|
but it's not gonna control how fast the normal convergence happens
|
|
0:11:26
|
when there's either a withdraw message
|
|
0:11:28
|
or whether there's a new update with an attribute change.
|
|
0:11:32
|
So, we can technically change the timers if we wanted to,
|
|
0:11:36
|
where there are negotiated value to the lower value that is configured for the peering,
|
|
0:11:42
|
but the vast majority of the times,
|
|
0:11:43
|
it's much easier to do the convergence based on a Layer 2 mechanism
|
|
0:11:49
|
as opposed to a Layer 4 keepalive timer.
|
|
0:11:55
|
Now, what I mean by this, let's say...
|
|
0:11:58
|
that in our particular topology,
|
|
0:12:01
|
we're trying to detect a failure of the link between router 4 and BB3.
|
|
0:12:09
|
So, I wanna know, if this peering goes down,
|
|
0:12:11
|
I wanna make sure I can re-route as quickly as possible.
|
|
0:12:15
|
But the problem is, the Ethernet link on router 4
|
|
0:12:19
|
is not gonna be a good indication of whether BB3's link is actually up.
|
|
0:12:25
|
So, we talked about this before in regular IGP routing,
|
|
0:12:27
|
the different solutions that we can do like the IP SLA agreement,
|
|
0:12:32
|
that could then be tied to the enhanced object tracking.
|
|
0:12:35
|
But to apply that with BGP, I guess it's a little bit more complicated.
|
|
0:12:38
|
So, we could rely on just the hello timers and the keepalive timers.
|
|
0:12:44
|
The problem is if we set those to be very low,
|
|
0:12:47
|
then, we add a lot of overhead in the control plane
|
|
0:12:50
|
and run the risk of actually dropping the TCP session
|
|
0:12:54
|
when there's no failure in the link.
|
|
0:12:58
|
So, typically, in a real design,
|
|
0:13:01
|
in cases where you're trying to converge
|
|
0:13:03
|
when there's a direct failure of the connected neighbor,
|
|
0:13:08
|
the best solution to use other than like Layer 1 sonnet protection,
|
|
0:13:13
|
which would be multiple fiber links between the neighbors.
|
|
0:13:17
|
That if one of the links physically goes down,
|
|
0:13:19
|
you're already receiving the signal in the second link.
|
|
0:13:24
|
The other option if we look under the configuration guide
|
|
0:13:27
|
would again be the bi-directional forwarding detection.
|
|
0:13:30
|
So, with BFD, this is a light-weight Layer 2 keepalive
|
|
0:13:36
|
that does have support for the BGP neighbors.
|
|
0:13:40
|
So, if we say, Neighbor, their address fall over with BFD,
|
|
0:13:44
|
it's gonna use the bi-directional forwarding detection timers
|
|
0:13:48
|
so that if this keepalive goes down,
|
|
0:13:50
|
then, it's automatically going to layer that particular neighbor down.
|
|
0:13:57
|
Now, the BGP process does already have the fast external fall-over detection on by default.
|
|
0:14:04
|
This means that for the external peering between router 4 and BB3,
|
|
0:14:08
|
if router 4's directly connected Ethernet goes down,
|
|
0:14:12
|
it's automatically going to immediately re-converge for that particular neighbor.
|
|
0:14:17
|
So, it's not gonna wait for the keepalive timer to expire
|
|
0:14:22
|
before we declare the neighbor down.
|
|
0:14:25
|
Now, we could see this on the command line, if we were to simply go to the link that router 4 has connected there.
|
|
0:14:31
|
So, if we Show IP Interface Brief,
|
|
0:14:34
|
this is router 4's Fast Ethernet 0/0,
|
|
0:14:37
|
which connects to switch 2's interface Fast Ethernet 0/4.
|
|
0:14:42
|
So, if I were ti shut this link down, we should see on router 4
|
|
0:14:46
|
that immediately, it's going to declare the neighbor down.
|
|
0:14:50
|
And I think logging is off here, so, if I did say...
|
|
0:14:55
|
Logging Console 7.
|
|
0:14:57
|
Then, we Show IP BGP Summary.
|
|
0:15:01
|
We would see that the neighbor is down already,
|
|
0:15:03
|
where the timers didn't actually expire.
|
|
0:15:07
|
So, as soon as router 4 learned about that link down event,
|
|
0:15:13
|
then, it was...
|
|
0:15:15
|
able to withdraw all of the prefixes that are being learned from the particular neighbor,
|
|
0:15:20
|
so that the rest of the network could re-converge faster.
|
|
0:15:29
|
So, let's see, once the peering comes back up
|
|
0:15:33
|
to BB3,
|
|
0:15:36
|
then, let's look at the logging here.
|
|
0:15:39
|
Now, in the mean time, there's some other timers that are related to this.
|
|
0:15:42
|
Mainly which are gonna control how often the updates are exchanged between the neighbors.
|
|
0:15:48
|
Where there is a default minimum advertisement interval
|
|
0:15:53
|
on a per-neighbor basis
|
|
0:15:55
|
that say, "Once an attribute change comes in, and I need to change the best path selection,
|
|
0:16:01
|
I'm not actually gonna advertise that change to them
|
|
0:16:03
|
until the minimum advertisement interval expires.
|
|
0:16:08
|
So, in order to speed up the convergence, we would then lower the advertisement interval for the particular neighbor.
|
|
0:16:15
|
Additionally, BGP will keep track
|
|
0:16:18
|
of the next hop values that the routes are pointing to.
|
|
0:16:22
|
So, this means that if there's a change in the IGP network,
|
|
0:16:27
|
it is going to affect the BGP convergence.
|
|
0:16:31
|
Now, I believe that the BGP next hop tracking is on by default.
|
|
0:16:36
|
So, if we were to look at the... Let's look at the command reference here
|
|
0:16:40
|
for BGP.
|
|
0:16:43
|
Then, this is the...
|
|
0:16:46
|
It's under the BGP command.
|
|
0:16:51
|
BGP next hop.
|
|
0:17:06
|
It says, "By default, BGP next hop tracking is enabled
|
|
0:17:09
|
for default IPv4 and VPNv4 address families."
|
|
0:17:13
|
So, this means that for our normal IPv4 routing,
|
|
0:17:17
|
the route is already doing this process by default.
|
|
0:17:19
|
It says that "Every 5 seconds,
|
|
0:17:22
|
you're checking the IGP table
|
|
0:17:24
|
to figure out if there was a change in the next hop recursion for BGP routes."
|
|
0:17:31
|
So, it actually has to do with the CEF adjacency.
|
|
0:17:34
|
How many dependencies go on to it.
|
|
0:17:36
|
Then, if there's a change in the CEF adjacency, it's gonna trigger a change in the BGP re-convergence.
|
|
0:17:43
|
So, we could technically set this to be 1 second.
|
|
0:17:46
|
But the problem is that at some point with BGP,
|
|
0:17:49
|
since the table is so large to begin with,
|
|
0:17:51
|
you're never really gonna get that fast of a convergence.
|
|
0:17:56
|
So ideally, you would need to optimize your underlying IGP convergence
|
|
0:18:00
|
instead of changing things like the BGP scan time
|
|
0:18:03
|
which are gonna control how often the BGP process walks through the table
|
|
0:18:09
|
to figure out if there's changes in the attributes.
|
|
0:18:13
|
So, this is why from my examples, when we were applying the new policies,
|
|
0:18:16
|
I was doing the route refresh inbound and outbound.
|
|
0:18:19
|
This avoid us having to wait for the BGP scan time to run,
|
|
0:18:23
|
and then send the new updates based on the advertisement interval,
|
|
0:18:28
|
and the delay that's applied to that particular neighbor.
|
|
0:18:35
|
Now, there's some really good write-ups on our CCIE blog that Peter put together
|
|
0:18:41
|
about convergence both for IGP and for BGP.
|
|
0:18:45
|
So, if you wanna get more information on that afterwards,
|
|
0:18:48
|
those are available for you there.
|
|
0:18:51
|
If you just go to...
|
|
0:18:55
|
blog.ine.com,
|
|
0:18:57
|
and then, search for...
|
|
0:19:01
|
like BGP convergence.
|
|
0:19:08
|
Understanding BGP Convergence.
|
|
0:19:09
|
There's a bunch of different ones that are for OSPF versus EIGRP convergence.
|
|
0:19:15
|
But a lot of this stuff is kind of outside of the scope of routing and switching,
|
|
0:19:19
|
or last the CCIE routing and switching lab exam,
|
|
0:19:22
|
because it's more of an optimization
|
|
0:19:25
|
that would really be hard to test whether it's actually working.
|
|
0:19:28
|
So, within the scope of the exam, maybe you'll get a question that says,
|
|
0:19:31
|
"Change the minimum advertisement interval."
|
|
0:19:33
|
But if you look at the Command Reference, it should be pretty straightforward to figure out
|
|
0:19:37
|
what command you need to use in order to do that.
|
|
0:19:41
|
Now, I doubt that you would see a question that says,
|
|
0:19:43
|
"Make sure that the network re-converges within 300 milliseconds regardless of any failure in the toplogy."
|
|
0:19:50
|
So, there's no way really that they're gonna be able to test that type of issue.
|
|
0:19:54
|
These type of convergence things, they would be more just of a configuration type check that they're doing.
|
|
0:20:02
|
Now, additionally, there's a couple other books that are dedicated just to these type of topics.
|
|
0:20:07
|
One of them that's really good is optimal routing design.
|
|
0:20:12
|
And I'm not sure if I mentioned this one before,
|
|
0:20:15
|
but this is by the gentlemen, that is the CCDE
|
|
0:20:21
|
program managers, the design expert exam, which is Rex White.
|
|
0:20:26
|
So, this is, it talks about large scale routing design
|
|
0:20:29
|
and different convergence type scenarios
|
|
0:20:32
|
that BGP and IGP would be related to.
|
|
0:20:37
|
But again, if you look at the Command Reference, there's really not that much configuration that goes along with this.
|
|
0:20:42
|
It's more just to figure out what are the features available,
|
|
0:20:47
|
and then, how to reference this at the actual exam time.
|
|
0:20:52
|
So, other miscellaneous features in BGP like the BGP default routing.
|
|
0:20:59
|
This is pretty self-explanatory that we could say,
|
|
0:21:02
|
"For the particular neighbor, I want to originate a default route."
|
|
0:21:06
|
It also gives you the option to tie a route map to that for conditional advertisement",
|
|
0:21:12
|
which basically says, "I wanna advertisement them a default route,
|
|
0:21:14
|
but only if this particular condition in the route map is true."
|
|
0:21:18
|
Which would be, is this particular subnet in the BGP table.
|
|
0:21:22
|
So, we could take this a step further like we looked at in IGP.
|
|
0:21:25
|
Combine this with the enhanced object tracking and the IP SLA.
|
|
0:21:29
|
To say in the edge of the network, maybe I'm only gonna originate a default route
|
|
0:21:34
|
if some particular SLA instance is true.
|
|
0:21:38
|
We could also use the network zero command,
|
|
0:21:42
|
which means that if we're learning a default route from IGP,
|
|
0:21:46
|
or if we have one in the routing table statically, we could originate it.
|
|
0:21:50
|
The default information originate command,
|
|
0:21:52
|
this is only used in conjunction with redistribution.
|
|
0:21:57
|
So, this means that if I have a default route that's learned from EIGRP,
|
|
0:22:02
|
and I redistribute EIGRP into BGP,
|
|
0:22:05
|
the default route is gonna be included only if I say, Default Information Originate.
|
|
0:22:11
|
But again, this should be pretty self-explanatory if you try these out,
|
|
0:22:14
|
then, look at the Show IP BGP, and then Show IP BGP Advertised Routes,
|
|
0:22:18
|
you'll see whether you're actually installing the default route,
|
|
0:22:21
|
and then, whether you're actually advertising it to...
|
|
0:22:24
|
your remote peers.
|
|
0:22:27
|
Now, for other miscellaneous features,
|
|
0:22:30
|
again, a lot of these just have to do with spending time reading through the Command Reference
|
|
0:22:35
|
like BGP dampening would be used to penalized routes that are tramping up and down.
|
|
0:22:41
|
Then, once they accumulate a certain penalty value, they're gonna be suppressed for a certain amount of time.
|
|
0:22:48
|
So, there's really not a lot of technology understanding, design understanding that goes behind that.
|
|
0:22:54
|
It's simply putting the feature on,
|
|
0:22:56
|
and that if you wanna change the default times, then, you could do that.
|
|
0:23:02
|
Now, in reality, the BGP dampening feature
|
|
0:23:05
|
has been unofficially deprecated,
|
|
0:23:07
|
where there's recommendations by the...
|
|
0:23:12
|
by right design documents that say, "You're actually not supposed to run BGP dampening on the Internet."
|
|
0:23:18
|
So, it actually does more harm now that it did originally.
|
|
0:23:22
|
So, it does more harm than it actually helps.
|
|
0:23:25
|
So, you're better off just leaving the process along without running dampening,
|
|
0:23:29
|
and then letting the router deal with the normal re-convergence.
|
