nanog mailing list archives
Re: BGP prefix filter list
From: Blake Hudson <blake () ispn net>
Date: Mon, 20 May 2019 10:35:23 -0500
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): http://w4.labs.lacnic.net/site/BGP-network-size-filtersThat's it, my two cents. Alejandro, On 5/15/19 7:43 AM, Baldur Norddahl wrote:HelloThis 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
Current thread:
- Re: BGP prefix filter list, (continued)
- Re: BGP prefix filter list Mike Hammett (May 15)
- Re: BGP prefix filter list Ahad Aboss (May 16)
- Re: BGP prefix filter list Karsten Elfenbein (May 17)
- Re: BGP prefix filter list Jon Lewis (May 15)
- Re: BGP prefix filter list Karsten Elfenbein (May 15)
- Re: BGP prefix filter list Radu-Adrian Feurdean (May 15)
- Re: BGP prefix filter list Tom Beecher (May 15)
- Re: BGP prefix filter list Alejandro Acosta (May 18)
- Re: BGP prefix filter list Amir Herzberg (May 18)
- Re: BGP prefix filter list Alejandro Acosta (May 18)
- Re: BGP prefix filter list Blake Hudson (May 20)
- RE: BGP prefix filter list adamv0025 (May 22)
- Re: BGP prefix filter list Blake Hudson (May 22)
- Re: BGP prefix filter list Amir Herzberg (May 18)
- Re: BGP prefix filter list Jared Brown (May 17)
- Re: BGP prefix filter list Jörg Kost (May 17)
- Re: BGP prefix filter list Scott Weeks (May 30)
- Re: BGP prefix filter list Valdis Klētnieks (May 30)
- Re: BGP prefix filter list Scott Weeks (May 30)