BGP prefix filter list

Fri May 17 15:03:20 UTC 2019

Radu-Adrian Feurdean wrote on 5/17/2019 9:15 AM:
> On Fri, May 17, 2019, at 15:28, Blake Hudson 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). For example, with static default routes one can
> For me, routing table and available routing protocols are not the only things needed for intelligent routing. And the router is not the only component involved in "intelligent routing". Not these days/not anymore.
>
> One thing that can help immensely in an internet environment is knowing where the data goes and where it comes from. Knowing your "important" traffic source/destinations is part of it.
>
> You can say "I can no longer keep all the routes in FIB, so I'll drop the /24s", then come to a conclusion that that you have loads of traffic towards an anycast node located in a /24 or that you exchange voice with a VoIP provider that announces /24. you just lost the ability to do something proper with your important destination. On the other hand, you may easily leave via default (in extreme cases even drop) traffic to several /16s from Mulgazanzar Telecom which which you barely exchange a few packets per day except the quarterly wave of DDoS/spam/scans/[name your favorite abuse]. Or you may just drop a few hundred more-specific routes for a destination that you do care about, but you cannot do much because network-wise it is too far away.
>
> Of course, such an approach involves human intervention, either for selecting the important and non-important destinations or for writing the code that does it automagically. Or both. There is no magic potion. (as a friday afternoon remark, there used to be such a potion in France, the "green powder", but they permanently ran out of stock in 2004 - see http://poudreverte.org/ - site in fr_FR).
>

Radu, you're absolutely correct that BGP does not include the metrics 
often needed to make the best routing decisions. I mentioned metrics 
like bandwidth, delay, and loss (which some other routing protocols do 
consider); and you mentioned metrics like importance (I assume for 
business continuity or happy eyeballs) or the amount or frequency of 
data exchanged with a given remote AS/IP network. BGP addresses some 
problems (namely routing redundancy), but it has some intentional 
shortcomings when choosing the cheapest path, best performing path, or 
load balancing (not to mention its security shortcomings). Some folks 
choose to improve upon BGP by using BGP "optimizers", manual local pref 
adjustments, or similar configurations. And as this discussion has 
shown, other folks choose to introduce their own additional shortcomings 
by ignoring part of what BGP does have to offer. Perhaps in the future 
we will be able to agree on a replacement to (or improvements upon) BGP 
that addresses some of these shortcomings; we may also find that 
technology solves the limitations that currently force some folks to 
discard potentially valuable routing information.