[AUDIO LOGO]
Now that we've talked about some of the things
that we can modify in BGP to help improve its convergence,
and at the same time, monitoring our routers
to make sure they don't get overwhelmed, now let's
talk about what we should actually set these things to.
Plus, we're going to look at another feature
we haven't really discussed yet, prefix independent convergence
or PIC.
This allows BGP to actually keep a backup route
that we can use in the event that it detects a failure.
And then, of course, we're going to jump onto the command line
and see these things in action.
So let's go ahead and get started with these details.
Now that we know how to monitor our routers
and make sure they don't get overloaded,
what are some of the things that we can or should
or may want to optimize?
Well, the first is to configure a lower BGP scan time.
Now, on a lot of hardware, it will yell at you
if you try to go too low.
But probably cutting it in half, drop it down to 30 seconds
is probably going to be fine on almost all of today's equipment
even with large BGP tables.
We can also configure a lower advertisement interval.
In fact, we may even want to drop this to zero,
let BGP send its updates right away,
particularly if we're doing other things
to protect our devices such as BGP route dampening.
So we may not need this buffer on the advertisement interval.
And of course, we can also configure lower keepalive
and hold timers.
Keep in mind as we're discussing this,
we really don't want BGP to converge as fast as our IGP.
So we probably don't want to go down to really, really
fast timers here.
But maybe a keepalive every 5 seconds and the hold time being
maybe 15 might be some good numbers at least to start with.
Because, again, part of the idea is
if there is a failure in our network,
hopefully our IGP converges, finds another path
to get to that BGP neighbor, and the BGP process never
even knows the neighbor went down.
Now that would, of course, be assuming
we're talking about peering on something like loopbacks
that there would be another path to get to.
If you're peering on physical interfaces
and there would be no other path,
well, maybe you want to make these timers even lower
than that.
In that case, yes, maybe we want to go
with even faster timers and maybe even something like BFD.
And again, some of those things I just mentioned
are right here that again, maybe we want to use BFD instead
or maybe fast reroute or again the IGP itself.
Tweaking the IGP to converge faster
might be the better answer.
Just keep these things in mind before we
jump right in to saying, how can we make BGP faster?
You may not want to.
But faster than the default is probably not a bad idea.
Now another really cool feature we
have in BGP that will definitely help improve its performance
is something called prefix independent convergence or PIC.
This is actually very similar to like OSPF fast reroute
or if you're familiar with it, the EIGRP feasible successor.
This is a backup path.
This backup path is stored in the BGP table,
in the routing information base, and in the forwarding
information base, so the RIB and the FIB.
It's ready to go in the event that we detect a failure.
So basically what this is doing is
it's storing that back up in BGP.
So BGP's already gone through the best path algorithm,
it chose a best path, and it chose a backup.
Now we are still going to have to detect the failure.
So the stuff we just discussed above
is still going to come into play because our backup path won't
kick in until we've actually detected the failure.
But once we do, this backup path is going
to be already ready to go.
So we're going to jump into the command line
and tweak some of these timers and configure PIC.
But let's look at our topology first.
So we know what we're going to be configuring.
So again, for this demonstration,
we'll be using BGP topology 1.
And we'll just look at the same routers
that we looked at their performance on.
So again, we'll see how this gets configured on R1,
and we'll take a look at R7.
This way, we get to see iOS XR and iOS XE.
And we're going to be looking at devices
that actually have multiple paths so they
can have a backup.
We're going to focus on a default
route that's actually being injected into BGP on router 9.
So both router 1 and router 7 should
have multiple paths to get to this default.
That's what we'll focus on when we're looking at our tables.
So let's jump into the command line.
We'll start on router 1.
Let's start with creating a route policy.
We'll simply call this RP_pick.
We're going to use this to enable the feature.
We're going to say set path-selection,
configure it for a backup, and say to install it.
We're just going to do this for the entire table.
So we don't have to match or anything like that.
We'll just end the policy.
Next, we go into our BGP process for address family
IPv4 unicast.
And we're going to configure additional paths
for the selection in our route policy RP_pick.
So we're going to tell it to choose
additional paths from the selection from our route
policy.
So that will enable PIC on the device.
The next thing we want to do is tweak
some of those timers we talked about.
So for example, we could say BGP scan time, and notice
we can set this from 5 to 3,600 seconds.
We'll just go ahead and set it to 30.
Then we'll configure our neighbor 50.1.167.7.
And we're going to modify our timers.
The first timer's the keepalive.
We'll drop that down to 5 seconds.
And then, of course, is the hold time we'll set it to 15.
We'll also change our advertisement interval.
And again, this can be from 0 to 600.
We'll just turn it off.
We'll say zero-- send the updates right away.
We'll commit our changes and exit configuration.
So again, those are some very common changes
we would make on iOS XR.
Let's take a look at iOS XE.
So we'll make the same basic changes here.
So we're going into configuration mode.
And we don't have to be so fancy on iOS XE.
We can just go right into router BGP and say,
BGP additional-paths install.
And that'll just turn on PIC.
We can also do our BGP scan time.
I believe this platform will yell at us
if we try to set it too low.
There we go.
It's actually telling us that, hey, doing this
below 15 seconds may not be the best plan.
Well, it's sort of interesting by the way,
is notice how it's a console message
and not like an error on the command
because it's not an error.
I mean, you can do 5 seconds.
It's just telling you that might not be the best plan.
Well, we'll be consistent.
We'll set it the same way we did iOS XR.
So we'll set it to 30 seconds.
And then, of course, we tweak our neighbor the same way.
So 50.0.167.1 timers 5 and 15.
Again, notice it also yells about this one.
It doesn't like the hold time of less than 20 seconds.
It says it increases the chance of peer flapping.
It certainly does.
But the flip side of that is I'm really
hoping that our underlying IGP is going to converge faster
than 15 seconds.
So on most of today's networks, that really
shouldn't be a problem.
And then, of course, the other thing we want to change
is the advertisement interval.
Once again, same timers.
We'll just say 0, and turn it off.
And then we'll exit configuration.
So now that we have everything set,
let's do some verification.
We might as well just start back on router 1.
So first thing we'll look at is the show IP BGP neighbor
for the 50.0.167.7.
Big thing, of course, we want to see
here is the configured hold time is set to 15
and the keepalive is set to 5.
So that's good.
If we do a show BGP summary, we see
we have nothing stuck in the input output
queues, which again, in this environment,
we wouldn't expect to.
But now let's check to see if our PIC is working.
Let's look at that default route.
What we see is we have this path from router 2
that is actually configured as a backup.
If we do a show route IPv4 unicast for the prefix,
we see here that it's also listing the route to router 2
as a BGP backup path.
So this is shown in the routing table as well.
And if we do a show CEF for the default,
it's showing us the host route because I
didn't put the slash 0.
So if we look at the actual default,
we can see here that once again, it has that route
through router 2 as a backup.
So we're seeing that it's stored as a backup in the BGP table,
in the RIB, and in the FIB.
So it's gone through all three.
So now let's go ahead and check out iOS XE.
So we'll start with looking at our BGP neighborship
to router 1.
Once again, we see the hold time and the keepalive time
are both set correctly.
If we do a show IP BGP on this platform,
it actually shows you that there are backup paths
right in the status code in the BGP table.
Now, of course, we can get more detail
by asking for the actual route itself.
And we can see that, in this case,
it's actually using the route through router 3,
and the route from router 1 is the one that's configured
as a backup or repair path.
Now, one interesting thing here, if I do a show IP
route for the prefix, notice that the RIB here on iOS XE
doesn't really indicate that there's a backup path.
But what's interesting is even though the RIB doesn't show it,
let's check out the FIB.
And I just did the same thing again.
But if we do the show IP SEF, notice that in the SEF table
or in the forwarding table, it knows there's a repair path.
So even though BGP not showing it in the RIB,
it's clearly in the FIB, which is the important part when
it comes to switching over in the event of a failure.
In this video, we took a look at how
to increase BGP's performance from a convergence standpoint.
So don't forget that we can change things
such as the scan time, our keepalives,
our hold down timers, how often or how quickly it sends updates
to eBGP peers, and we can turn on PIC so that we actually
have backup paths ready to go in the event BGP
does find or detect a failure.
Just keep in mind while you're doing all of this
to keep a very close eye on your router's performance
so that we don't overwhelm our router
and well, risk stability in BGP just because we're
trying to make it faster.
I hope this has been informative for you.
And I'd like to thank you for viewing.