Hunting down the stuck BGP routes • Hacker News Board

Re: Hunting down the stuck BGP routes

#31

Post by toast0 » Wed, Apr 21, 2021, 11:44 PM UTC

vlovich123 wrote: post #14

I wonder if a robust consensus algorithm might be a better investment than a timeout. I would imagine there are other bugs in BGP implementations so having a routing table that's going to trend towards eventual consistency regardless of the starting point might be a more robust solution than just focusing on this one corner case. Might be a more intrusive change though & hard to get middleware to roll out such a chan…

The goal of BGP or other routing protocol isn't consensus though. Each router really just wants to find a next hop for every destination, and there are lots of reasons for differences.

In the case where there are multiple next hops to choose from, it might be nice to have some sort of quality metric to decide, but that's really tricky to measure and integrate. It's really outside the scope of BGP.

You would need to instrument packet loss or transfer speed or something like that by destination path on your application servers (or load balancers), and be able to adjust the proportion of traffic through various paths; keeping in mind that you can't really influence the path beyond your routers or the return path.

It's a lot of work, and I don't think the tools are built for it, but I would love to work on it for someone though. I did something similar for SMS routing, but that's a ton easier, fewer choices, less traffic, clearer success, etc.

Re: Hunting down the stuck BGP routes

#32

Post by Twirrim » Thu, Apr 22, 2021, 6:12 AM UTC

teh_klev wrote: post #13

From the article: > With the current “default free zone” containing around 1,000,000 routes Back in ~1998 I was tasked with building a route collector/looking glass machine for an internet exchange point (sadly defunct). I remember the day we switched the collector on and acquired "all the routes", there were ~98,000 of them, you could've knocked me over with a feather. It was like looking into the Total Perspective…

I remember back in 2008 when we reached 256k prefixes, the then limit of Cisco 6500 and 7600 routers, which were kind of the workhorses for a bunch of ISPs. Lots of places were buying memory expansion for those devices to cope. 6 years later, 512k day occurred.

Re: Hunting down the stuck BGP routes

#33

Post by nickjohnthan » Thu, Apr 22, 2021, 6:24 AM UTC

As a thrifty traveler, I never want to pay the higher price on flight ticket booking or also don’t want to compromise with the pleasure during the journey. But by booking a flight through Cathay Pacific Online Reservation process, I can easily save around 40% on my whole booking. https://www.flightinfodesk.com/flights/Cathay-Pacific-Airway...

Re: Hunting down the stuck BGP routes

#34

Post by pas » Thu, Apr 22, 2021, 10:33 PM UTC

michaelbuckbee wrote: post #21

So I keep coming into situations where I think this is the problem that's occurring (a stuck route). While I'd certainly love to be able to diagnosis this, would it even matter? There's no recourse that I can take as an end user is there?

there's the NANOG mailing list

Re: Hunting down the stuck BGP routes

#35

Post by pas » Thu, Apr 22, 2021, 10:37 PM UTC

... hm, how come withdraw (and announce) messages are not ACKed in-band? or maybe they are, but due to explicit demonic of certain routers (and/or ASes) they still don't take effect?