[AUDIO LOGO]
So now let's jump in and look at some methods
we can use to increase BGP's performance as far
as decreasing the convergence time.
But keep in mind as we jump in here,
BGP is designed to be slow on purpose.
This is because it's designed to carry a large quantity
of routes into the millions.
And in doing so, that does mean that we
have to sacrifice a little bit of performance
to get stability, the main focus being on stability.
So as we talk about increasing performance,
we do have to have a very careful balance
to make sure that we're not going
to overwhelm our equipment while we're trying
to increase BGP's performance.
So one of the things that we're going
to be looking at in this video is
how to monitor that performance as we increase
BGP's performance to make sure that we have that good balance
and that we're not overwhelming BGP.
So let's go ahead and jump in and get
started looking at some of these details.
So again, keep in mind as we jump in here
that BGP convergence specifically improving
its performance is a balance, again,
between making it faster and not overwhelming
the routers, in other words, stability versus performance.
We have to keep this in mind when
we're talking about tweaking and modifying BGP's timers.
So what is converged from a BGP perspective?
Well, first it means that all the routes have been received.
It also means that the appropriate routes,
and of course, by this, we mean the routes that
have been selected as best have a valid next hop,
pass the synchronization rule if that's enabled.
But as long as they're the best or the appropriate routes,
they are then placed into the routing and forwarding tables
meaning, of course, the RIB and the FIB on the device.
And also that the input and output queues are empty.
If these queues are not empty, it
means that you're either waiting to send information
to a neighbor or you're still processing updates that you've
received from a neighbor.
Either way, this indicates that you
have a problem sending and receiving updates
to your neighbors.
Now, keep in mind when you're looking at this,
if you just do one show command and you see some packets
or updates in the input and output queues, that's
nothing to panic about.
It can happen on occasion depending
on exactly which millisecond you happen
to look at that show command.
Repeat the command a few times.
Just make sure that it's not staying that way.
Now, there are a few major components
that affect BGP convergence.
The first of these are the BGP keepalives.
Why is this important?
Well, this is how we detect a failure, how we detect
if a neighborship goes down.
So by default, these are only sent every 60 seconds.
And the issue with that, of course,
is we have to miss three in order
to declare a neighbor down.
That means it's going to be 180 seconds to detect a neighbor's
failure.
Now oftentimes, this is OK because this can actually
help BGP.
If there is a failure on the underlying network,
our IGP may converge fast enough that BGP never even
knows the neighbors down.
That's the plus side.
The negative side is if the neighbor is down,
and there is no other path to get there,
it's going to take three minutes until BGP figures this out.
So again, we don't necessarily want
to go incredibly aggressive here,
but we do probably want to speed it
up a little bit in most environments.
Now this can, of course, be supplemented
by BFD or bidirectional forwarding detection,
and we can detect failures much quicker.
The second component is the BGP scanner.
The job of the BGP scanner is it looks
at the unicast routing table or the RIB
to verify next hop reachability.
If the next hop is not reachable, of course,
we can't install the route into the routing table.
Now by default, this runs every 60 seconds.
That means that when I receive an update, depending
on exactly the last time the BGP scanner ran,
it could take up to 59.9 seconds before that route can actually
be installed into the routing table
because we have to verify that next hop.
Now the big concern with speeding this up
is it can take a lot of CPU, particularly
if we have a large BGP table.
So once again, do we probably want
to speed it up from 60 seconds on most of today's platforms?
Yeah probably.
But once again, we have to be careful.
And we'll see in just a moment how
to watch our components to make sure that we're not
overwhelming the router.
Our final component is the BGP update pacing.
By default, we limit sending updates
to eBGP peers to only 30 seconds.
Now, this does not limit updates going to iBGP.
So this is just for external peers.
And we've mentioned this a few times previously.
But BGP will by default only send updates
after 30 seconds to eBGP peers.
So that's just something else that we want to be aware of.
Now as we've mentioned, one of the biggest things
we need to be concerned about before we start modifying
and updating these timers and these settings is we
need to make sure we're keeping track
of the performance of our routers,
making sure they're not getting overwhelmed.
So before we jump into things we can and should
change or possibly modify, let's take a look at the command line
and take a look at some of the good commands
that we want to keep an eye on.
So let's start on iOS XE.
We'll just use router 7 here.
And one of the first things you want to watch
is a show proc CPU.
And a good filter I like to use with this
is to say, include BGP or from the beginning of the line
PID, which is your process ID.
The reason I'm using this regular expression
is when we look at it, it's nice because we
get the header up at the top to tell us what
each of these columns means.
So of course, the big things we want to watch here
is for any process in BGP running away with our CPU.
Now we can, of course, see here in our lab,
it's taking 0% of our CPU.
But we would not see it this way in a large production
environment.
Another command that I like to use is show proc CPU history.
This actually gives us an ASCII chart
to show us over the last 60 seconds.
And if we scroll down, it'll show us 60 minutes.
And if we scroll down further, it shows us the last 72 hours.
Since this is the only one that's really populated,
we can see that this is giving us
a history of where the CPU has been on this device
over the last three days.
As far as memory, we can actually
repeat this last command here, but instead
of saying show proc CPU, we can say show proc memory.
This is going to show us the same basic information.
Once again, we get the headers, and we
can see if memory is being consumed
by any of our BGP processes.
Of course, if we do a show proc memory without the filter,
we can also find out at the top the total amount that's used
and how much is free because we would also want to make sure,
of course, that we're not running out of free memory
either.
And the last major thing we want to watch if we do a show IP BGP
summary, we want to watch these input and output
queues going to our neighbors.
Again, if you happen to do this show command
and you see a couple of things in the queue,
it's not really a big deal.
Just repeat the command.
We just want to make sure that there's not things sitting
in those queues regularly.
Again, once in a while, if you happen to cat it, that's fine.
So those are good things to watch on iOS XE.
Let's jump over to iOS XR.
We'll just use router 1.
So here we can do a show proc CPU.
The filtering here is a little bit different though.
We're just going to say include bgp.
It's lowercase.
And here we can see our BGP processes
and what they're currently using.
Now unfortunately on iOS XR, if we just do a show proc CPU,
we can see here that the top looks about the same as far
as the headers like the PID.
However, if we were to go back to our filter
and say BGP or PID, iOS XR doesn't actually
like using the or regular expression in the output
of the show command.
So unfortunately, we would just have
to do it with and without the filter
and happen to know what the headers are.
Another good one to watch here is the show proc blocked.
This will show us any applications
that have actually been blocked from using the CPU.
We would not want to see BGP on this list.
Another good one, show watchdog memory state.
We can see here that our current memory state is normal.
So again, we would want to make sure that our free memory is
not getting too low.
We could do a show memory compare start.
We see what it's doing is actually
storing a memory snapshot.
So this would be like the beginning of our baselining.
Then when we were done, you would think it would be stop--
start and stop.
No, its end.
That's OK.
But this makes the end.
And then you can ask for the report.
Now the report is going to be fairly long.
As we can see, it's going to go on for a bit here.
So what we might want to do is, again filter that output
and just say to include BGP.
So we can see that this way it only
returns the BGP information.
In this video, we took a look at some of the things
that we might want to change in relation to BGP convergence
and speeding it up a little bit to make it a little bit faster.
We also took a look at the command line
to see things that we need to watch for on the router
before we start making those changes,
and after we make those changes, to make sure that we're not
overwhelming the router.
I hope this has been informative for you.
And I'd like to thank you for viewing.