Filter Inbound BGP Prefixes: Summary

I got plenty of responses to the How could we filter extraneous BGP prefixes post, some of them referring to emerging technologies and clean-slate ideas, others describing down-to-earth approaches. Thank you all, you’re fantastic!

Almost everyone in the “down-to-earth” category suggested a more or less aggressive inbound filter combined with default routing toward upstream ISPs. Ideally the upstream ISPs would send you responsibly generated default route, or you could use static default routes toward well-known critical infrastructure destinations (like root name servers).

2020-11-18: Removed links to Cisco-hosted prefix filter, added links to MANRS and Team Cymru.

The best overall solution came from Killian – find a prefix filter that throws away most of the unnecessary garbage. Cisco was maintaining one a while ago (and now it’s gone); you might find something similar on MANRS web site or Team Cymru Github repository.

Someone else also suggested (in an e-mail) dropping all prefixes that are more than three AS away. His reasoning – you’re probably not more than three autonomous systems away from a tier-1 ISP, and it doesn’t make too much sense second-guessing them.

When implementing this idea, make sure you’re matching three distinct AS numbers (using a regular expression like this one), not AS paths up to three entries long. AS paths could be longer due to AS-path prepending.

If you want to achieve more balanced traffic load, you could combine this idea with the one from Octavio – accept all prefixes from “near” autonomous systems and all prefixes larger than /18 (or whatever would still fit into your TCAM) from the rest of the Internet.

In any case, you should start your contemplation with the business side of the problem: what’s the true business need for full Internet routing table? Or, as Pete put it, “If you have traffic to justify the peerings, then you can presumably afford the router that can take full Internet BGP routing table.


  1. Hey Ivan, Curious here on your recommendation to ensure that your regex matches distinct ASNs vs ones that may have been prepended. IMHO it seems this defeats the purpose of honoring the metric. If someone has prepended these routes, it may be for good reason.

    Just my 2p -- Curious to hear your side of why you would do that. :-D
  2. Let's say you slightly prefer ISP-A over ISP-B (less load on ISP-B, but not strictly a primary/backup setup).

    So (according to the three-AS-numbers) idea, you have a default route to ISP-A, and filter anything that's either (1) more than three AS numbers away or (2) has more than three AS numbers in the AS path.

    Assume your neighbor also uses ISP-A and ISP-B in the same setup. He advertises his prefix to ISP-A with AS-path X and to ISP-B with AS-path X X X X X. Now assume his link to ISP-A goes down.

    You'll still receive his prefix, but if you follow rule (2), you'll drop the prefix (because AS-path length is more than three) and send the traffic through ISP-A. If you follow rule (1), you'll accept his prefix from ISP-B (and potentially from ISP-A, but AS-path would be longer anyway) and use it.

    There is no "right" answer here - you have to understand what happens if you use rule (1) or (2) and decide what suits you better ... but people do have to understand that "being 3 AS numbers away" is NOT the same as "having AS-path length = 3"
    1. How would one implement this kind of filtering in ios?
Add comment