BGP prefix filter list
Blake Hudson
blake at ispn.net
Fri May 17 20:43:16 UTC 2019
>
> I would argue that one can generally safely add information to his
> or her router's RIB (such as adding a local preference, weight, or
> advertising with prepends to direct traffic toward a better
> performing, less utilized, or lower cost peer), but that removing
> information from a router's RIB always comes at some cost (and
> some may find this cost perfectly acceptable).
>
>
> One needs to remember that removing information from RIB is how BGP
> works. If you have the common setup of two BGP edge routers, each with
> a directly connected transit provider link, the routers will only tell
> the other one about the routes it actually uses. Neither router has a
> complete view.
>
>
I manage a network like you describe: Two BGP edge routers, both routers
accept a full eBGP feed from transit, both share routing information via
iBGP. Both edge routers in my network have a complete view. If one
transit provider is down or there is an upstream peering change, both
still have a complete view. The only time they wouldn't have a complete
view is during convergence or when there is a simultaneous outage of
both transit providers at different physical facilities.
I could certainly use a default route (configured statically or received
via BGP) instead, but that reduces my network's ability to make informed
decisions. When one of my upstream transit providers is performing
maintenance and loses a peer, I want that to be reflected in my routing
so that traffic can be directed via the shortest path. When my transit
provider's edge router loses upstream connectivity, but maintains
connectivity to my equipment, I want that reflected in my routing so
that traffic doesn't go towards the path that leads to the bit bucket. I
can't detect those conditions and route around them if my router only
has a default route.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190517/835f18b7/attachment.html>
More information about the NANOG
mailing list