[AUDIO LOGO]
So we just saw how to do BGP filtering to filter things out
based on maybe their prefix or their AS path.
But sometimes it's not about what you're getting,
but how much of something you're getting.
If we're getting too many BGP routes,
that can definitely overwhelm our routers.
So BGP route limiting can be used
to ensure that we don't get too many prefixes
from our neighbors.
Perfect example would be on the customer side.
Maybe again, they asked for only the default route or maybe
partial routes, and the service provider instead sends them
the entire BGP table.
Their router may not be able to handle that.
It does take a large amount of RAM and CPU
to handle the internet routing table appropriately.
So we can limit how many prefixes
we'll accept from a neighbor, and that's
the premise of this video.
So let's start by taking a look at some of the details.
And then, of course, we'll jump into the command-line
and see this feature in use.
So the idea behind route limiting
is to protect the router from being overwhelmed
with too many prefixes.
Again, a good example would be the internet routing table,
or maybe there's a bigger mistake,
and somebody's sending multiple copies of the table.
And again, this would come down to the idea
that even a legitimate neighbor that I normally accept routes
from possibly got misconfigured, or the filtering
is not configured properly on it, to begin with.
So there's a couple reasons why we could
get too many prefixes here.
The real focus is, this is the amount of the routes received,
not the actual prefixes.
Again, actual prefixes would come down to prefix filtering.
This is all about how many routes.
Now, as we're configuring this, an important design point
here is, we do need to allow for growth.
And when we see some recommendations in a moment,
we'll see that we're actually going
to allow for a lot of growth.
We're not going to want to have to go change this feature.
Every time, things change just a little bit.
So for example, let's say a customer
is sending us four prefixes.
I wouldn't want to set this to 5 or 7.
I would probably set it to 30 or maybe even 40.
That way, they have plenty of room to grow.
The idea here is, I don't want them sending me 900,000.
I don't want them to accidentally feed
the entire internet routing table back to me
from a customer site.
So again, we don't have to be real close to the number
that they're actually trying to send.
So we'll, again, see some examples of this,
but let's just keep that in mind as we're
looking over how this works.
And I did just drop this number.
But as of the time of this recording,
I just looked at one of AT&T's looking glass routers earlier,
and the current routing table is just
above 900,000 prefixes for the internet.
So looking at route limiting from the service provider's
perspective, again, the idea is, let's prevent the customer
from sending too many prefixes.
But again, like I said a moment ago,
we're not going to go real close here.
We're going to go something like 10 times the amount of prefixes
that we're expecting.
So if we're expecting them to send us four prefixes,
let's set this to 40.
We're just trying to make sure they're not sending us 100,000.
We can also use this as a service provider
to make sure that other service providers don't make a mistake,
and they don't try to send us too many prefixes.
Again, given the current size of the internet
routing table, probably a good idea
to set this to about 2 million.
That way again, they can't send us three, four, seven copies
of the internet routing table.
We only want one copy.
2 million should give us plenty of room to grow,
so we don't have to come change this all the time.
Now, looking at this from the customers' perspective,
it really depends on what routes they've requested to receive.
If they've requested to receive only the default route, well,
then, maybe they would want to set this to say, 2 to 5,
and they may never grow since they're
just asking for the default. But again,
giving a little bit of overhead, not a bad idea here.
If they ask for partial updates, once again,
it should be right around 10 times the service providers'
prefixes.
Now, how would they know this?
Service providers may publish it,
or they could call in to Customer Support
and get this number, basically just ask how many prefixes
are in the partial table.
Most providers have that information available.
Worst-case scenario, of course, they
could just allow all the prefixes,
and then they could count them.
I don't mean literally count them.
I just mean, look at the BGP table.
And, of course, just like another service provider,
if they're getting full internet routes,
then we probably want to just go ahead with the 2 million
to give room to grow.
Now, this feature is enabled on IOS XR by default,
and it has some pre-built default settings.
It allows 512,000 prefixes for IPv4 unicast,
128,000 for IPv4 multicast, 128,000 for IPv6 unicast,
and 512,000 for VPNv4 unicast.
Now, chances are, these numbers probably
will not meet the criteria of your environment.
But of course, it's a place to start,
and we can always adjust these numbers, as needed.
Also, just a quick note down here.
It's not really related to route limiting but just for lack
of a better place to put this.
There's also a default maximum number
of neighbors set to 4000 by default. Once again,
this can be changed but just be aware of it.
So let's jump into the command-line.
We'll take a look at how this feature works.
Let's bring up our topology first and talk
about what we're going to be configuring,
and then we'll jump in and take a look at it.
So we do want to look at this feature on both IOS XR and IOS
XE.
So for IOS XR, we'll be focusing on router 1.
And for iOS XE, we'll be focusing on router 7.
And what we're going to do on router 10,
we're going to have it generate a whole bunch of prefixes
and send them into BGP.
And we'll see how this limiting works on our different routers.
So let's jump into the command-line.
We'll start on router 7 just to see what's already
going on in our BGP table.
So the first thing we'll note is if we do a show ip
bgp on router 7, we don't have any prefixes
coming from router 10.
This is quite simply because they are both in the same AS.
So just to get the prefixes to be accepted here on router 7,
we're just going to go ahead and allowas-in on router 7.
Let's do our show ip bgp again, and we see that now, we're
getting prefixes coming from router 10, of course,
through router 6, specifically the ones coming from 65001.
If we do a show ip bgp summary, we
can see specifically that from router 6,
we are currently getting eight prefixes.
What we're going to do is we're going to go ahead and make
that a nice even 80, which means,
we're going to make 72 loopback interfaces on router 10
and bring them all into BGP.
So let's jump over to router 10.
We'll go into configuration mode, and we'll get typing.
No, s just kidding.
We're going to use an EEM script for this,
but we are going to create the 72 loopbacks.
So we'll just paste my script in.
If you want to look over this, it's
creating a variable called L. It's starting in at 1.
It's going to increment up to 72, make a loopback interface,
and assign the subnet 10.100 dot whatever number it is dot 1
with a /24.
So since this event is set to none,
we'll just go ahead and run it manually.
If you look up top, I just called it LOOP1.
Just as a note, I do have the debug running here
for the CLI output of the EEM script
just so we can see it happening.
And in case you try to run this on your own,
also note that I have sped this up in the video.
It actually takes quite a few seconds for this to run.
I also really like doing the debug because I just
find this line rather humorous that tty is now going
through its death sequence.
All that really means is the router
is killing the CLI instance that it was using to run the script.
So we can see that all 72 interfaces have come up.
If we do a show ip interface brief,
we can see all these loopbacks, and we
see that the third octet matches up with the loopback number.
So this should be good to go.
If we do a show ip bgp, all of these
are now being injected into BGP as well.
So now, let's go back over to router 7.
We don't need to see all these prefixes.
We'll just do the summary.
Again, it's about the number of prefixes, not what they are.
And we see we now have a nice, even 80 prefixes coming in.
So now, let's implement our limit.
We'll go into configuration mode in the router BGP,
and we will say that for neighbor 50.0.167.6, which
is router 6, we're going to set the maximum prefix.
It wants to know the maximum number, let's say, 100.
Then it's going to ask what the threshold is.
We're going to say 90.
And then we have two options left.
We can either restart, or we can do a warning-only.
If we do warning-only here, it won't actually
take down the neighborship.
The default behavior is to take down the neighborship,
and that's what we're going to do here.
So we're going to tell it to restart,
which, you don't have to configure this either,
but we'll tell it to restart after, say, 2 minutes.
So let's go ahead and hit Enter.
We'll exit out of configuration.
And let's go configure the same settings on router 1.
So router 1 will go to Configuration mode.
This is router bgp 100.
Same neighbor address for the address family IPv4.
We'll set the maximum prefix.
And as we can see once again, maximum number.
We pretty much have the same options
except for the discard extra path option.
We'll just set the threshold to 90.
And again, we'll restart after 2 minutes.
Notice, warning-only is an option here as well.
Let's commit our changes and exit configuration.
So as it is right now, we're getting
80 prefixes, which is, of course, 10 below our threshold.
So let's go back over to router 10
and create 15 more loopbacks to push us over the threshold
but not reach the limit just yet.
Of course, we have another script for that.
These are going to be odd numbers
because it's going to create loopbacks 73 through 87.
So the numbers of the loopbacks themselves are going to be odd.
However, it's going to create 15 additional loopbacks.
So we can see that that's configured.
And if we go check our routers, router 7, we see here,
we already have a warning, telling us
that the number of prefixes received
has reached 91 towards our max of 100.
Now, if we do a show ip bgp summary,
we can see that it's actually 95.
We said we were adding 15, but we just
got the one message when it actually broke the threshold.
Let's see what router 1 is saying.
Router 1, we can see it's almost the exact same message
that we've now reached 91 towards the max of 100.
We've broken the threshold.
So you know what we have to do now.
We have to add more loopbacks on router 10
to push it over the maximum and make these routers actually
shut down their neighborship.
So we'll just add some more loopbacks here.
We don't need to watch it run this whole time.
We'll just jump ahead.
So now, router 10 has created more loopbacks.
Now, let's go back over to router 7.
We see that so far, it's just given us another warning.
And now, we see that it actually goes over the maximum
and resets the peer.
Let's go take a look at router 1.
We can see that router 1 here has also
hit the maximum prefixes and shut down the neighbor.
Now, we configure these devices to recover or restart
the connection after 2 minutes, but in order
to do that, we would have to get the prefixes back
below the maximum.
To do that, we're just going to go
undo everything we did on router 10
and just take out all those new loopbacks.
On router 10, we're simply going to do a configuration rollback
to the saved configuration that I have from before we started
this lab.
And here, we can see it taking down all of those interfaces.
If we do a show ip interface brief,
we see we're back to just the--
we'll call them the normal interfaces
that we normally have on router 10 in our lab environment here.
This means that router 1 and router 7
should actually recover their neighborships
when they try again.
So it's been our 2 minutes here, and we can see here on router 7
that the neighborship with router 6 has come back up.
And if we look at router 1, we see that router 6
is back up here as well.
We look at our summary, we can see that here on router 1,
it's back to just learning those eight prefixes from router 6
as it was when we started.
So in this video, we took a look at BGP route
limiting, where we can limit the number of routes
that a router will receive or accept from a neighbor
before it gives us first a warning when
we get to the threshold.
And then when it gets to the maximum,
well, we saw it will either shut down the neighborship, which
is what it does by default, by the way, if we don't configure
the other options, or we can use that option warning-only.
In which case, it will continually
yell at us, of course, but it will not actually
shut down the BGP neighborship.
We also saw that there's an option
there to restart after a certain number of minutes
we chose to do to.
I hope this has been informative for you,
and I'd like to thank you for viewing.