Hi Anthony, For what it's worth, we also use dummy interfaces that can have dynamic addresses, not from VRRP (those are on another interface), but from DNS-Anycast. We use a direct protocol only on the dummy interface, not on lo as that doesn't have our VIPs. But IMO, this is the right point of integration between BIRD and any external service that manages VIPs. BIRD itself should not need to manage the IPs. As you say, this way BIRD and keepalived (or whatever service) are decoupled. BIRD sees the addresses get added and removed immediately, and it doesn't matter what order services are started or stopped in, or if they fail, etc... Pete On Thu, 2025-08-07 at 08:40 -0400, Anthony Hoppe via Bird-users wrote:

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 <nico@lodpp.net> 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