Partial vs Full tables

Fri Jun 5 07:45:36 UTC 2020

* James Breeden

> I come to NANOG to get feedback from others who may be doing this. We
> have 3 upstream transit providers and PNI and public peers in 2
> locations. It'd obviously be easy to transition to doing partial
> routes for just the peers, etc, but I'm not sure where to draw the
> line on the transit providers. I've thought of straight preferencing
> one over another. I've thought of using BGP filtering and community
> magic to basically allow Transit AS + 1 additional AS (Transit direct
> customer) as specific routes, with summarization to default for the
> rest. I'm sure there are other thoughts that I haven't had about this
> as well....

We started taking defaults from our transits and filtering most of the
DFZ over three years ago. No regrets, it's one of the best decisions we
ever made. Vastly reduced both convergence time and CapEx.

Transit providers worth their salt typically include BGP communities
you can use to selectively accept more-specific routes that you are
interested in. You could, for example, accept routes learned by your
transits from IX-es in in your geographic vicinity.

Here's a PoC where we used communities to filter out all routes except
for any routes learned by our primary transit provider anywhere in
Scandinavia, while using defaults for everything else:

https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html

(Note that we went away from the RIB->FIB filtering approach described
in the post, what we have in production is traditional filtering on the
BGP sessions.)

Tore