Add/Remove advertisements via birdc (or other mecanism)?

[Pete Heist]

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 at 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
> >