Safeguarding BGP advertisments
Hello, I am currently working on handling edge cases of BGP advertisements malfunctions in my network. I am writing to this mailing list to confirm that I haven’t missed BIRD native solution. Issue in question is when BGP router loses its connectivity to rest of the internal mesh and still advertise routes to upstreams (I use manual aggregates, because my internal routes have very long prefixes and address space is non continuous). AFAIK (these were my ideas how to implement safeguards): - I can’t use BFD to guard advertisement of static blackhole route, - I can’t use BFD to guard pipe protocol. As I understand my only solutions are to use external monitoring tooling to disable advertisements to upstreams or restructure BGP configuration in a way that externally advertised prefixes come to BIRD routers through channel that is dependent on connection to internal mesh. Have I missed something? Best regards, Lukasz Jarosz
Hi Lukasz, How do you distinguish that the router loses connectivity to the rest of the mesh? I mean if your mesh is split in parts because of connectivity problems, which part is "the rest of the mesh"? AFAIK, bird does not have conditional announces based on presense of other announces. So I would think about some external daemon, that would monitor, for example, availability of some route/s in bird or kernel table, and enable/disable some pipe protocols based on that. Regards, Alexander Zubkov On Mon, Jan 5, 2026 at 11:15 AM Lukasz Jarosz <lukasz@jarosz.in> wrote:
Hello, I am currently working on handling edge cases of BGP advertisements malfunctions in my network. I am writing to this mailing list to confirm that I haven’t missed BIRD native solution. Issue in question is when BGP router loses its connectivity to rest of the internal mesh and still advertise routes to upstreams (I use manual aggregates, because my internal routes have very long prefixes and address space is non continuous). AFAIK (these were my ideas how to implement safeguards): - I can’t use BFD to guard advertisement of static blackhole route, - I can’t use BFD to guard pipe protocol. As I understand my only solutions are to use external monitoring tooling to disable advertisements to upstreams or restructure BGP configuration in a way that externally advertised prefixes come to BIRD routers through channel that is dependent on connection to internal mesh. Have I missed something?
Best regards, Lukasz Jarosz
Hello,
How do you distinguish that the router loses connectivity to the rest of the mesh? I mean if your mesh is split in parts because of connectivity problems, which part is "the rest of the mesh"?
I have N edge routers, which all of them announces exactly the same prefixes to different upstreams. They are interconnected to downstream segments and between each other with common switching fabric that backs up „edge router mesh” (in iBGP sense obviously). If edge router loses connectivity to upstreams it just stops advertising to downstreams and other neighbors. Case of losing connectivity to either downstreams or other neighbors only causes suboptimal routing, but when edge router loses connectivity to switching fabric it would become kind of zombie - advertising aggregated routes to prefixes that it does not have access. This is also condition in which router ends up when is sole survivor of failure, but I don’t think this would be recoverable remotely. Also I know this might seem far fetched for some, but jackasses with excavators already ruined many days of my life ;)
AFAIK, bird does not have conditional announces based on presense of other announces. So I would think about some external daemon, that would monitor, for example, availability of some route/s in bird or kernel table, and enable/disable some pipe protocols based on that.
That was my conclusion too, but last time I read BIRD doc thoroughly was quite a lot of years ago, so I rather wanted to consult. As feature suggestion I would have opted for adding bfd stanza to pipe protocol so it can be automagically disabled when selected bfd session is in failed state. Best regards, Lukasz Jarosz
Wiadomość napisana przez Alexander Zubkov <green@qrator.net> w dniu 05.01.2026, o godz. 11:44:
Hi Lukasz,
How do you distinguish that the router loses connectivity to the rest of the mesh? I mean if your mesh is split in parts because of connectivity problems, which part is "the rest of the mesh"?
AFAIK, bird does not have conditional announces based on presense of other announces. So I would think about some external daemon, that would monitor, for example, availability of some route/s in bird or kernel table, and enable/disable some pipe protocols based on that.
Regards, Alexander Zubkov
On Mon, Jan 5, 2026 at 11:15 AM Lukasz Jarosz <lukasz@jarosz.in <mailto:lukasz@jarosz.in>> wrote:
Hello, I am currently working on handling edge cases of BGP advertisements malfunctions in my network. I am writing to this mailing list to confirm that I haven’t missed BIRD native solution. Issue in question is when BGP router loses its connectivity to rest of the internal mesh and still advertise routes to upstreams (I use manual aggregates, because my internal routes have very long prefixes and address space is non continuous). AFAIK (these were my ideas how to implement safeguards): - I can’t use BFD to guard advertisement of static blackhole route, - I can’t use BFD to guard pipe protocol. As I understand my only solutions are to use external monitoring tooling to disable advertisements to upstreams or restructure BGP configuration in a way that externally advertised prefixes come to BIRD routers through channel that is dependent on connection to internal mesh. Have I missed something?
Best regards, Lukasz Jarosz
On Mon 05 Jan 2026 23:44:25 GMT, Lukasz Jarosz wrote:
I have N edge routers, which all of them announces exactly the same prefixes to different upstreams. They are interconnected to downstream segments and between each other with common switching fabric that backs up „edge router mesh” (in iBGP sense obviously). If edge router loses connectivity to upstreams it just stops advertising to downstreams and other neighbors. Case of losing connectivity to either downstreams or other neighbors only causes suboptimal routing, but when edge router loses connectivity to switching fabric it would become kind of zombie - advertising aggregated routes to prefixes that it does not have access. This is also condition in which router ends up when is sole survivor of failure, but I don’t think this would be recoverable remotely. Also I know this might seem far fetched for some, but jackasses with excavators already ruined many days of my life ;)
I avoid announcing the routes directly from the edge routers. I originate them from RRs, so when the edge looses the connnection to the backbone, the announcement is naturally withdrawn. -- Alarig
participants (3)
-
Alarig Le Lay -
Alexander Zubkov -
Lukasz Jarosz