BGP prefix filter list
blake at ispn.net
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
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:
> 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.
> On 5/15/19 7:43 AM, Baldur Norddahl wrote:
>> 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.
More information about the NANOG