Thank you both Thomas and Nico for your replies! I believe what I am doing now is precisely the first method Nico explained. After sleeping on it a bit, I like this method because it decouples the need for keepalived to maintain state with BIRD. All keepalived needs to do is add the VIPs to the interface and all BIRD needs to do is watch said interface. If BIRD is restarted for whatever reason it won't lose the VIP advertisements as they'll remain installed on the watched interface. In the current setup with GoBGP, if gobgpd is restarted for whatever reason we need to make sure keepalived re-injects the VIPs. The stupid fix for this is if gobgpd is restarted we restart keepalived as well. I like using an interface as the advertisement "anchor" as we won't need to worry about this chicken-and-egg type scenario. It feels like the simplest solution and both daemons can focus on doing what they do best and not needing any "middleware" to manage the keepalived <-> BIRD integration.
In my case we don't want to assume IP's configured on lo are to be advertised, so I defined a dummy interface for this purpose. keepalived simply issues "/usr/bin/ip address add" and "/usr/bin/ip address delete" commands for quorum_up and quorum_down. The dummy interface is listed under protocol direct in the BIRD config and it watches the interface and reacts appropriately. Works *great*! However, the concern that comes up is the delay between when keepalived removes the VIPs from the interface to when BIRD registers this and withdraws the routes. The concern is that there will be a moment (albeit short) when the VIPs are no longer installed, but yet BGP has not reconverged. Of course in the case of machine failure it is what it is, but we want to make sure when we perform maintenance that it is as graceful as possible and prevent a situation where there is delay between when keepalived removes the VIPs from the dummy interface. Therefore, we'd need to ensure that BGP reconverges before the VIPs are removed from the dummy interface. My silly idea is to simply install the VIPs on two interfaces....lo and the dummy interface. The idea being the VIPs persist on lo so the machine always "owns" them, and keepalived dynamically adds/removes them to/from the dummy interface to "inform" BIRD what to advertise. I think this should work, but does look weird to new folks getting acclimated to the configuration. Curious if this is Not Great, and if so, if there is a more elegant solution? After typing out the above, maybe perhaps the more "elegant" solution is to use a similar method to what Thomas mentioned but instead have keepalived add/remove the routes to/from a separate kernel routing table and have BIRD import routes from it, and then only install the VIPs on lo. ~ Anthony On Thu, Aug 7, 2025 at 5:24 AM Nicolas Piatto <[email protected]> wrote: > > > > Le 07/08/2025 à 00:54, Anthony Hoppe via Bird-users a écrit : > > Hello, > > > > We are currently using GoBGP with keepalived and are looking to switch > > to BIRD. We currently have keepalived inject the VIPs into GoBGP via > > the following quorum_up and quorum_down commands: > > > > quorum_up "/usr/bin/gobgp global rib add -a ipv4 [VIP-ADDRESS]/32" > > quorum_down "/usr/bin/gobgp global rib del -a ipv4 [VIP-ADDRESS]/32" > > > > Is there a similar mechanism with BIRD? Right now what I've done is > > instead I'm having keepalived add/remove the VIPs to/from a dummy > > interface and have the dummy interface as one of the interested > > interfaces under protocol direct. > > > > quorum_up "/usr/bin/ip address add [VIP-ADDRESS]/32 dev VIPs" > > quorum_down "/usr/bin/ip address delete [VIP-ADDRESS]/32 dev VIPs" > > > > This works as expected, when keepalived adds the VIPs BIRD exports > > them and when keepalived removes the VIPs BIRD stops exporting them. > > > > However, I am still curious if there is a mechanism where I can tell > > keepalived to tell BIRD directly to advertise them? > > > > Thanks! > > > > Hi, > > Multiple solution for that. > > At least 2 that I use: > Depending on your keepalived setup, ie if it mounts the VIP on a given > interface. > > You can configure bird to listen on that interface > > ``` > protocol direct direct_ipv4 { > ipv4; > interface "lo"; # Restrict network interfaces it works with > } > ``` > > Then basically when the VIP is configured on the interface, it gets in > the BGP RIB and advertised to your peers (depending on route > policy/filter you have eventually) > If it's not configured on the interface, it's not in BGP RIB -> not > advertised. > > > Another solution could be to not link BIRD RIB with the LINUX RIB, you > you need to originate the route in bird to create the RIB entry, > then trigger the advertisement by enabling/disabling the proto. > > Another solution instead of disabling the proto to be more reboot proof, > if to still originate the route from bird, but use a function you write > on the fly then reload the config. > similar to what https://github.com/skoef/birdwatcher is doing. > > > ++ > Nico > -- This email, including its contents and any attachment(s), may contain confidential and/or proprietary information and is solely for the review and use of the intended recipient(s). If you have received this email in error, please notify the sender and permanently delete this email, its content, and any attachment(s). Any disclosure, copying, or taking of any action in reliance on an email received in error is strictly prohibited.
