Hi,
I’m doing a research on BGP route optimisation and the performance metrics used by commercial route optimizer appliances to select better path to a prefix.
I would appreciate any information about the performance metrics used in commercial BGP route optimizers, white papers or any other document that describes how these metrics are measured and collected by commercial route optimizers.
Thanks
The answers which you seek would be considered secret sauce to these vendors.
But you can start at running MTRs through a VRF per carrier only containing a default route, and looking at the results.
Ryan
The most important metric for a BGP optimizer is how much it physically weighs. That way you’ll know if you can carry it to the trash pile yourself, or need to get help so you don’t hurt your back.
You may have discovered that already during your research, but just in case: basically, using those optimizers at full throttle is a bad practice and is generally discouraged.
A research into the deep-juju of BGP optimization is roughly equivalent to a research about how alcohol may make you a faster driver. I.e. it’s fine in academy but you certainly may want to emphasize security considerations in your paper.
Most of which are bunk if you and your upstream have appropriate filters.
True, and, while we’re at it, it’s okay to drink and drive a car if the manufacturer has built enough driver assistance systems in it.
More like do whatever you want in your own house as long as you don’t infringe upon others.
The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such.
So I got this from BGPmon, earlier today:
More like do whatever you want in your own house as long as you don’t infringe upon others.
That’s where the rub is; when using “BGP optimisers” to influence public Internet routing, you cannot guarantee you won’t infringe upon others.
The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such.
The argument against “BGP optimizers” is that we cannot assume appropriate ingress or egress filters. It appears to me like fallacy to suggest a line of reasoning ala “if you do things correctly, things won’t go wrong”. Clearly we’ve observed many times over that things do go wrong.
Some examples: almost every year one of the major BGP vendors has a serious bug related to the functionality to NO_EXPORT in some release. Also, routinely we observe there are software defects that cause a device to behave different (read ‘leak’) than how the operator had explicitly configured the device. These are facts, not religious statements.
Perhaps in a bug-free world there is room for dangerous activities, but there is no such thing as bug-free. And I haven’t even covered the human error angle. We must robustly architect our networks to mitigate or dampen the negative effects of issues at all layers of the stack.
I consider it wholly inappropriate to write-off the countless hours spend dealing with fallout from “BGP optimizers” and the significant financial damages we’ve sustained as “religious arguments”.
Kind regards,
Job
Tom Beecher wrote :
The most important metric for a BGP optimizer is how much it physically weighs. That way you'll know
if you can carry it to the trash pile yourself, or need to get help so you don't hurt your back.
Please dispose of it in an environment friendly way. In the city I live and many other ones we have programs to get rid of such garbage in a proper way.
https://www.roseville.ca.us/residents/utility_exploration_center/e-waste
Stop the pollution of the routing table and the planet !
Mark Tinka wrote :
So I got this from BGPmon, earlier today:
Oh yeah, a /32 sourced from a private ASN without no-export.
Michel
TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
it would be interesting to see research into the financial losses experienced by people and organisations across the internet caused by routing outages relating to bgp optimisers.
Nick
Nowhere near the number as an engineer fat fingering a route. There are ISPs that accept routes all the way to /32 or /128, for traffic engineering with ease, and/or RTBH.
Ryan
This assumption itself is a good start for the aforementioned “security considerations” chapter, b/c this is the assumption most of us make but only few routinely check.
Nowhere near the number as an engineer fat fingering a route.
How are you able to make that assertion?
There are ISPs that accept routes all the way to /32 or /128, for traffic engineering with ease, and/or RTBH.
This strikes me as a bit of a red herring. Aren't the damaging effects
of "BGP optimisers" *amplified* (not caused!) by ISPs who accept "all
routes"? An ISP accepting incorrect routing information still is a
step below entities actively generating and distributing incorrect
routing information.
Kind regards,
Job
All of the same tragedy can happen without BGP optimizers, and does.
BGP optimizers only harm the global Internet when route filters don’t do their job. (Un)Fortunately, many other things also harm the global Internet when route filters don’t do their job. Things other than BGP optimizers harm the global Internet more frequently via the same vector (lack of proper route filters).
A given set of bugs are unlikely to affect both Optimizer edge egress filters and upstream ingress filters. If so, the Internet as a whole has much graver things to worry about.
Peace,
All of the same tragedy can happen without BGP optimizers, and does.
I disagree. You are skipping over crucial distinction we should make
between common 'route leaks' (incorrect propagation of valid routing
information), and the poison that is 'bgp optimiser hijacks'
(propagating of invalid/nonexistent routing information).
In the first case, a simple leak of existing real routing information,
you'll often see that the outcomes of the leak have a longer AS_PATH,
and that the leaking ASN has an actual path towards the destination. In
the best case the leaked routes are ignored because they don't become
the best path, in the worst case anyone using those leaked paths suffers
from congestion.
In the second case, leaked routes that came from a so-called 'bgp
optimiser', during the leak there is no forwarding path to the actual
destination. The packets circulate in a loop and never arrive at the
intended destination. This is hard downtime for the affected prefixes.
We also often see that the AS_PATH is entirely fabricated by "BGP
optimisers", further increasing the risk of the hijacked route
announcements being used.
BGP optimizers only harm the global Internet when route filters don't
do their job. (Un)Fortunately, many other things also harm the global
Internet when route filters don't do their job. Things other than BGP
optimizers harm the global Internet more frequently via the same
vector (lack of proper route filters).A given set of bugs are unlikely to affect both Optimizer edge egress
filters and upstream ingress filters. If so, the Internet as a whole
has much graver things to worry about.
I believe it is a fallacy to state that "because other things can harm
the Internet" it would be somehow become OK to use a BGP optimiser. It
is not, it is extremely dangerous for those networks whose prefixes are
being 'optimised' (n�e hijacked).
Every day we see negative effects as a result from "bgp optimizers". We
also have observed that some of the 'bgp optimizers' have consciously
chosen to not apply even the most basic of harm reduction methods, see
https://twitter.com/JobSnijders/status/1143205986787831819
We can't stop people from deploying this type of software, the Internet
simply doesn't provide that kind of regulatory environment, but one
should be fully aware of the terrible risks involved when doing so.
Networks should be cognizant of peers they suspect are using such
software to steer traffic.
Kind regards,
Job
Oh I don't know about that. There's been a pile of high profile incidents which have been associated with "BGP optimisers", affecting connectivity to huge chunks of the internet, world-wide.
It's not unusual for a single incident to have widespread or even global effect, and what with the Internet playing such an important part of the world's economies, it's hard not to be curious about the overall financial impact of this sort of thing.
Nick
How many, exactly and with a pointer/reference, have been 'not an optimizer' ?
I almost made the same post as Mr Hammett ~4 messages (his messages)
back made: "Err, all of these problems are possible without an
optimizer", except I don't really believe that it's helpful:
"All my friends failed out, but I just got D's..."
isn't really selling this as a great plan.
I suppose if your (not nick's) story is:
"Well, I know what I'm doing, my upstreams filter me, I'd NEVER leak..."
ok, but really no, not ok... someone 'not you' will eventually operate
part of your network and fail where you hadn't.
-chris
There is a difference between BGP optimizers and route optimizers. When was the last time you heard a complain about Akamai screwing up the global routing table over the past 12 years:
https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html
-Hank