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

[Anthony Hoppe]

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
>

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