Hunting down the stuck BGP routes

Re:Hunting down the stuck BGP routes by sigmonsays on Wednesday April 21, 2021 @09:28AM (#26889380)

Interesting read. Its interesting that this is a big in the specification and not implementation since bgp is so old. We must not hit this case often

[ Parent | on HN ]

Re:Hunting down the stuck BGP routes by eqvinox on Wednesday April 21, 2021 @10:54AM (#26890448)

It's actually becoming more frequent due to BGP speakers being increasingly multithreaded. In the olden days, if you were overloaded, that also meant no more keepalives being sent. With the power of multithreading you can now simultaneously be overloaded and still send keepalives! :D

[ Parent | on HN ]

Re:Hunting down the stuck BGP routes by EricE on Wednesday April 21, 2021 @02:40PM (#26893749)

> With the power of multithreading you can now simultaneously be overloaded and still send keepalives! :D

Now that's progress!

Reminds me of some of the naive comments in a few of the recent posts on HN about programming multithreading. It's not as easy as just adding more threads.

Or sending in more trains :) https://www.youtube.com/watch?v=-hyttagGsz0

[ Parent | on HN ]

Re:Hunting down the stuck BGP routes by NovemberWhiskey on Wednesday April 21, 2021 @02:10PM (#26893338)

Ah yes; that's one of my favorites - health check returning 200s instantaneously; actual service is a black hole.

[ Parent | on HN ]

Re:Hunting down the stuck BGP routes by jschwartzi on Wednesday April 21, 2021 @06:52PM (#26896405)

One of many problems that are only solvable with a software watchdog.

[ Parent | on HN ]