iBGP config.

[Mike Neo]

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

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

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.

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.

In this model, I fully accept that there will be a traffic interruption
during failover, including BGP session establishment and table download.

For this approach, I am attaching a migrated configuration from Bird v1 to
Bird v2. I would also appreciate any feedback on this setup.

Which approach would you recommend in practice? Are there any obvious
pitfalls or best practices I should consider for either design?

Thank you in advance for your advice.

Best regards,
Mike

wt., 9 gru 2025 o 09:43 Jeroen Massar <jeroen at massar.ch> napisał(a):

>
>
> > On 8 Dec 2025, at 17:41, Mike Neo <neomikemac at gmail.com> wrote:
> >
> > Hi,
> >
> > I have one operator with a full BGP table (one BGP session) and one IX
> (two BGP sessions, one BGP session each, to two different ISP routers).
> >
> > I need to configure two BGP routers based on Ubuntu + Bird 2/3 with iBGP.
> >
> > Could someone share this configuration and point out what to watch out
> for when traffic is ~1-2 Gbps?
>
> The exact configuration comes mostly down to taste. You can get
> inspiration from https://github.com/coloclue/kees which has a good set of
> examples.
> And yes, automate from day 1, you and others will thank yourself in the
> years ahead ;)
>
> If you have specific questions do not hesitate to ask, many folks started
> either from scratch or build up their configs over the years.
>
>
> Most defaults will mostly just work given you have enough CPU, some memory
> and decent NIC(s).
>
> You could for fun look at Pim's VPP setup (
> https://ipng.ch/s/articles/2023/12/17/debian-on-ipngs-vpp-routers/ and
> other articles he wrote about it), though that is not needed unless you
> want to squeeze latency to a minimum.
>
> But without VPP one could also dedicate CPUs to interupts (avoid
> irqbalance for that matter) and to NIC queues.
>
> At 1-2 Gbps, it will mostly help you with latency/jitter though, not much
> with speed.
>
>
> Definitely look at https://bgpfilterguide.nlnog.net <
> https://bgpfilterguide.nlnog.net/> and implement the policies that make
> sense for you.
>
> Signup for peeringdb.com <http://peeringdb.com/> so that your contacts
> can be found easily and others can peer better with you.
>
> Use bgpq4 for generating BGP prefix lists.
> Use RPKI ROV and per bgpfilterguide filter these + ensure you got ROA for
> your own prefixes.
> Use OTC attribute to avoid accidental route leaks from/to peers/transits.
>
> For BCP38 if you can setup a Spoofer node:
> https://www.caida.org/projects/spoofer/
> and then sign up for https://www.manrs.org/
>
> Note that with nftables, if you have full table you can do something like:
> ```
> # Drop when the source route is incorrect
> fib saddr . iif oif eq 0 log prefix "RPF: " counter drop
> ```
> But be aware the moment you have multiple interfaces where the packets can
> come from/to and only 1 route is installed, that would cause issues with
> the other interface.
>
>
> Sign up for https://bgp.tools/ so that you get monitoring from the
> outside and one can publish BGP Communities there and in NLNOG Ring:
> https://github.com/NLNOG/lg.ring.nlnog.net
> and when you send BGP updates there it will nicely show up in their
> interace: https://lg.ring.nlnog.net <https://lg.ring.nlnog.net/>
>
> RIPE Atlas and RIS clients in your network will also allow one to easily
> spot-check connectivity, or even set up permanent alerts (by having nodes
> in your network you earn credits, thus you can automate queries with those
> earned credits)
>
>
>
> Do not forget monitoring, bgp.tools helps there, but definitely check that
> all your peers are in a happy state with a monitoring tool. Exposing a
> looking glass web interface can be useful. I wrote a custom one
> https://lg.as57777.net <https://lg.as57777.net/> but pre-packaged ones
> are available and allow easy debugging (I need to publish the code for mine
> properly one day though).
> A quick 'connectivity check from multiple points' like I have for
> https://debug.massars.net <https://debug.massars.net/> can also be useful
> to spot check if things are working, yes, just some javascript polling a
> few distributed http servers, but that allows one to quickly see what works
> and what does not from your client vantage point. Smokeping and alike can
> be great too for figuring out which links might be showing issues.
>
>
> See https://massars.net/details/ for a long list of things I have done
> with links to the projects involved. Also https://massars.net/design/ has
> some more details on how/what I did.
>
> Regards,
>  Jeroen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260128/989f3ed4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_ibgp_bird_v1.conf
Type: application/octet-stream
Size: 954 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260128/989f3ed4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_ibgp_bird_v2.conf
Type: application/octet-stream
Size: 1069 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260128/989f3ed4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ibgp_r2_bird_v2.conf
Type: application/octet-stream
Size: 1095 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260128/989f3ed4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ibgp_r1_bird_v2.conf
Type: application/octet-stream
Size: 1081 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20260128/989f3ed4/attachment-0003.obj>