Hi all, I’m looking for best practices and design recommendations for using Keepalived (VRRP) in a setup with two BIRD-based routers running iBGP between each other. Setup overview - Two routers (R1 and R2), both running BIRD based on debian repo - Direct interconnection via eno1 (1GE Base-T) used for iBGP session - Each router has its own uplink and independent eBGP session - There is a single IX service currently connected to R1 - Goal: ensure failover to R2 (via Keepalived/VRRP) if R1 goes down Questions 1. VRRP traffic design What is the recommended approach for VRRP packets in this kind of setup? - Should VRRP run over a dedicated VLAN on the inter-router link (eno1)? - Or is it better to run VRRP on the same interface where the VIP is configured (e.g., gateway interface for downstream hosts), possibly using a separate VLAN there? I’m trying to understand what is considered cleaner and more robust in production environments. 2. Track scripts – best practices What are the best practices when using track_script in Keepalived? - What should be monitored in a BGP/BIRD context? - BGP session state? - Reachability (e.g., upstream via ping)? - Interface/link state? - IX availability? - How do you typically avoid false positives / flapping? - Any recommended patterns for integrating BIRD state with Keepalived? 3. Failover strategy for IX service Given that: - Only R1 is physically connected to the IX - Both routers participate in BGP and exchange routes via iBGP What is the recommended way to ensure that: • Traffic and VIP failover cleanly to R2 • And ideally, the IX connectivity (logically) follows to R2 during failure? Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used? Any real-world examples, configuration snippets, or design insights would be greatly appreciated. Thanks! Mike
Il giorno 26 mar 2026, alle ore 10:55, Mike Neo <neomikemac@gmail.com> ha scritto:
Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used?
I would scrap the VRRP idea at all; imo it is best to connect both of your routers to your peer (IX).
On 26 Mar 2026, at 09:51, Alexander Javoronkov <nmi@nmi.ru> wrote:
Il giorno 26 mar 2026, alle ore 10:55, Mike Neo <neomikemac@gmail.com> ha scritto:
Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used?
I would scrap the VRRP idea at all; imo it is best to connect both of your routers to your peer (IX).
What Alexander says. When a node can speak BGP use that, possibly along with BFD. When a node on a subnet cannot speak VRRP, then let two routers do VRRP so that the MAC&IP remain stable for the nodes on that subnet. But IMHO, where possible, just speak BGP; much easier to see state of everything. The situations where one has to do "failover" on an IX are often maintenance, eg hardware or software upgrades. Broken hardware is often rare (knock on wood :) ) And as such, if you do not want to connect twice to the same IX (as then one has to also tell peers what router to prefer so one can load balance traffic a little bit over the two router connections); it is often better to see if you can connect to multiple IX. As that gives you proper redundancy. Regards, Jeroen
On Thu 26 Mar 2026 10:38:54 GMT, Jeroen Massar via Bird-users wrote:
On 26 Mar 2026, at 09:51, Alexander Javoronkov <nmi@nmi.ru> wrote:
Il giorno 26 mar 2026, alle ore 10:55, Mike Neo <neomikemac@gmail.com> ha scritto:
Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used?
I would scrap the VRRP idea at all; imo it is best to connect both of your routers to your peer (IX).
What Alexander says.
When a node can speak BGP use that, possibly along with BFD.
When a node on a subnet cannot speak VRRP, then let two routers do VRRP so that the MAC&IP remain stable for the nodes on that subnet.
But IMHO, where possible, just speak BGP; much easier to see state of everything.
The situations where one has to do "failover" on an IX are often maintenance, eg hardware or software upgrades. Broken hardware is often rare (knock on wood :) )
And as such, if you do not want to connect twice to the same IX (as then one has to also tell peers what router to prefer so one can load balance traffic a little bit over the two router connections); it is often better to see if you can connect to multiple IX. As that gives you proper redundancy.
And given that you have a transit on the other router, loosing an IX isn’t a big deal. Also, I doubt that the IXP will be happy about having VRRP on its peering LAN, it will very probably lead to your port being shut. (and if it’s not, quit the IXP) -- Alarig
participants (4)
-
Alarig Le Lay -
Alexander Javoronkov -
Jeroen Massar -
Mike Neo