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.
