> On 28 Jan 2026, at 17:35, Mike Neo <[email protected]> wrote:
>
> Hello,
>
> Thank you very much for all the responses and insights to my previous
> question — I really appreciate the feedback.
>
> At the moment, I am running a very simple Bird v1 setup based on a single
> physical router, with:
> - one BGP session to my ISP, and
> - two BGP sessions to IX route servers.
>
> I'm attaching the current configuration for reference.
>
> I'm now considering migrating to Bird v2 and deploying two routers, and I am
> thinking about one of the following designs:
>
> 1) Two routers with iBGP
That is the correct model: let BGP handle the failover
> In this model:
> - the BGP session to the ISP would be established on r1,
> - one BGP session to the IX would be on r1, and another one on r2,
Note that this requires two ports from the IX; often at a separate charge, but
depends on the IX.
> - r1 and r2 would be connected via iBGP,
> - in case of an r1 failure, VRRP would move the IP address to r2 and the BGP
> session to the ISP would be established on r2.
I would not do so. Why not have two transit connections to the upstream ISP?
> What I'm not fully sure about in this scenario is whether splitting the IX
> BGP sessions across two routers could cause any issues, such as asymmetric
> routing or other unexpected behavior.
One problem can be if you lose iBGP and your internal network is not fully
meshed and thus r1 cannot talk to r2 anymore.
That can result in traffic arriving at r1 for something needing to go to r2 to
not arrive properly.
Thus ensure that r1 <-> r2 has multiple physical paths.
alternative: stop announcing your prefix from one of the two disconnected
routers so that you know where to send traffic.
The other possible problem is related to state tracking: do not do state
tracking on routers, as packets might one point come from one link and the next
from the other, or over r2 instead of r1.
If you build state, then those states from the other interface won't work.
Hence state tracking on routers is a no-go unless you become really creative,
but still state == bad, thus just avoid it.
If you have something that needs to be firewalled, do it either on-device; or
separately on a VRRP'd and thus state-synced firewall; but not on something
that directly speaks BGP with many ports. (a firewall with just a upstream +
downstream port makes such a setup a bit more doable; but still state-sync is
tricky for active-active; noting that with active-passive and state you break
all connections when failover does happen).
> For this option, I have prepared a Bird v2 configuration — I would be very
> grateful for any comments or suggestions.
>
> 2) Two routers without iBGP
>
> In this option, I would go with classic active/passive redundancy:
> - only one router has BGP sessions to the ISP and IXs (similar to the current
> setup),
> - in case of an r1 failure, IP addresses are moved to r2 and BGP sessions to
> the ISP and IXs are established on r2 by birdc enable protocol ISP.
Avoid this. There are no live BGP state-sharing implementations at the moment
unfortunately and thus session re-establishment would happen and other such
things. The complexity is not worth it and can only cause issues.
It would require doing some trickery with either connecting a switch or a
bridge to the IX which is likely frowned upon.
It would also mean you have to spoof/borrow MAC addresses for VRRP, as most IXs
do single-MAC per port.
Better to have two separate ports (but for most IXes that means paying for
separate port) and do BGP from each, identically (minus the MAC + IP addresses
and loopbacks involved).
Your example configuration is very very minimal, thus hard to comment but the
following:
First off I suggest generating the configuration, every body has their own
choice of tools for that, many use ansible, others use a bunch of bash scripts.
See for many good examples for instance: https://github.com/coloclue/kees/
And of course https://bgpfilterguide.nlnog.net
<https://bgpfilterguide.nlnog.net/> which contains snippets for many router
platforms.
Using OTC to indicate customer/transport peerings, generating prefix filters
from bgpq4 (IRR data), using ASPA validation, ROA checks (use stayrtr), max
prefix limits based on peeringdb.com <http://peeringdb.com/> data and many
other things should be included in a configuration.
Greets,
Jeroen
