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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 >>
