BGP prefix filter list

Blake Hudson blake at
Mon May 20 15:35:23 UTC 2019

Gracias Alejandro, I had never considered anti-hijack, anti-DoS, or RTBH 
advertisements in this equation. Another knock against filtering based 
on prefix size is that it may not have the intended outcome on some 
platforms. As I recall reading about one vendor's platform (the ASR9k 
perhaps?) and its TCAM organization process, it stored /32 routes in a 
dedicated area for faster lookups and did the same for /24 routes. If 
one were to remove just the /24 routes from their RIB, the result would 
free up space in the storage area dedicated for /24's, but would 
consequently put more pressure on the areas reserved for prefixes 
between /0 and /23 as covering routes are installed into FIB. The result 
of removing /24's from the RIB on this platform would, unintuitively, 
put the user in a worse position with regard to TCAM utilization - not a 
better one.

If one is going to filter routes from his or her router's RIB, doing so 
based on subnet size seems to be a poor way. Doing so based on AS depth 
(your second solution) has fewer disadvantages in my opinion. As others 
have mentioned, there are even more intelligent ways of filtering but 
they rely on outside knowledge like cost, bandwidth, delay, or the 
importance to your customers of reaching a given destination - stuff not 
normally known to BGP.

Alejandro Acosta wrote on 5/18/2019 10:35 AM:
> Hello,
>    As a comment, after receiving several complains and after looking 
> many cases, we evaluated what is better, to cut the table size 
> filtering "big" network or "small" networks.  Of course this is a 
> difficult scenario and I guess there are mix thinking about this, 
> however, we concluded that the people (networks) that is less affected 
> are those who learn small network prefixes (such as /24, /23, /22, /21 
> in the v4 world).
>   If you learn, let's say, up to /22 (v4), and someone hijacks one /21 
> you will learn the legitimate prefix and the hijacked prefix. Now, the 
> owner of the legitimate prefix wants to defends their routes 
> announcing /23 or /24, of course those prefixes won't be learnt if 
> they are filtered.
>   We published this some time ago (sorry, in Spanish): 
> That's it, my two cents.
> Alejandro,
> On 5/15/19 7:43 AM, Baldur Norddahl wrote:
>> Hello
>> This morning we apparently had a problem with our routers not 
>> handling the full table. So I am looking into culling the least 
>> useful prefixes from our tables. I can hardly be the first one to 
>> take on that kind of project, and I am wondering if there is a ready 
>> made prefix list or similar?
>> Or maybe we have a list of worst offenders? I am looking for ASN that 
>> announces a lot of unnecessary /24 prefixes and which happens to be 
>> far away from us? I would filter those to something like /20 and then 
>> just have a default route to catch all.
>> Thanks,
>> Baldur

More information about the NANOG mailing list