iBGP config.

[Jeroen Massar]

> On 28 Jan 2026, at 17:35, Mike Neo <neomikemac at gmail.com> 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