BGP prefix filter list
baldur.norddahl at gmail.com
Fri May 17 16:05:15 UTC 2019
On Fri, May 17, 2019 at 3:28 PM Blake Hudson <blake at ispn.net> wrote:
> From my perspective one's ability to intelligently route IP traffic is
> directly correlated to the data they have available (their routing
> protocol and table)
One point perhaps being missed by some is that routing decisions are not
always best made in the very last moment when you have a packet and need to
decide on the destination. The culling of routing table I wanted to do is
on a full feed from my upstream providers. I am not taking a default, but I
may add a default manually.
Think about this way to save at least half the size of the FIB with two
transit providers: Find out which provider has the most prefixes going
their way. Make a default to them and a route-map that drops every route.
For the other provider, keep only the routes where they have better
routing. This way you only use FIB space for the smaller provider.
Everything else goes by default through the larger provider.
Now doing that in practice is hard because router vendors did generally not
make route-map or similar constructs flexible enough for the needed logic.
But we can do other things, some of which have already been proposed in
this thread. Like before have a default to the "best" of your transit
providers and using culling to drop routes. Are we not all doing something
like that already, with route maps to give some routes higher priority
instead of always going strict shortest AS-path? Only difference is that
you can fully drop the routes from FIB if you install defaults to handle it
Or what if I know that one of my transit providers are really good with
Asia? I just want traffic to Asia by default go to them. I can install my
own covering routes from the APNIC address space and then save a ton of FIB
space by dropping routes within that space. I can have exceptions if needed.
The above does not give you poorer routing decisions and may give you
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG