<div dir="ltr">Hello,<br><br>Thank you very much for all the responses and insights to my previous question — I really appreciate the feedback.<br><br>At the moment, I am running a very simple Bird v1 setup based on a single physical router, with:<br>- one BGP session to my ISP, and  <br>- two BGP sessions to IX route servers.  <br><br>I'm attaching the current configuration for reference.<br><br>I'm now considering migrating to Bird v2 and deploying two routers, and I am thinking about one of the following designs:<br><br>1) Two routers with iBGP<br><br>In this model:<br>- the BGP session to the ISP would be established on r1,  <br>- one BGP session to the IX would be on r1, and another one on r2,  <br>- r1 and r2 would be connected via iBGP,  <br>- 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.<br><br>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.<br><br>For this option, I have prepared a Bird v2 configuration — I would be very grateful for any comments or suggestions.<br><br>2) Two routers without iBGP<br><br>In this option, I would go with classic active/passive redundancy:<br>- only one router has BGP sessions to the ISP and IXs (similar to the current setup),  <br>- 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.<br><br>In this model, I fully accept that there will be a traffic interruption during failover, including BGP session establishment and table download.<br><br>For this approach, I am attaching a migrated configuration from Bird v1 to Bird v2. I would also appreciate any feedback on this setup.<br><br>Which approach would you recommend in practice? Are there any obvious pitfalls or best practices I should consider for either design?<br><br>Thank you in advance for your advice.<br><br>Best regards,<div>Mike</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">wt., 9 gru 2025 o 09:43 Jeroen Massar <<a href="mailto:jeroen@massar.ch">jeroen@massar.ch</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 8 Dec 2025, at 17:41, Mike Neo <<a href="mailto:neomikemac@gmail.com" target="_blank">neomikemac@gmail.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> 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).<br>
> <br>
> I need to configure two BGP routers based on Ubuntu + Bird 2/3 with iBGP.<br>
> <br>
> Could someone share this configuration and point out what to watch out for when traffic is ~1-2 Gbps?<br>
<br>
The exact configuration comes mostly down to taste. You can get inspiration from <a href="https://github.com/coloclue/kees" rel="noreferrer" target="_blank">https://github.com/coloclue/kees</a> which has a good set of examples.<br>
And yes, automate from day 1, you and others will thank yourself in the years ahead ;)<br>
<br>
If you have specific questions do not hesitate to ask, many folks started either from scratch or build up their configs over the years.<br>
<br>
<br>
Most defaults will mostly just work given you have enough CPU, some memory and decent NIC(s).<br>
<br>
You could for fun look at Pim's VPP setup (<a href="https://ipng.ch/s/articles/2023/12/17/debian-on-ipngs-vpp-routers/" rel="noreferrer" target="_blank">https://ipng.ch/s/articles/2023/12/17/debian-on-ipngs-vpp-routers/</a> and other articles he wrote about it), though that is not needed unless you want to squeeze latency to a minimum.<br>
<br>
But without VPP one could also dedicate CPUs to interupts (avoid irqbalance for that matter) and to NIC queues.<br>
<br>
At 1-2 Gbps, it will mostly help you with latency/jitter though, not much with speed.<br>
<br>
<br>
Definitely look at <a href="https://bgpfilterguide.nlnog.net" rel="noreferrer" target="_blank">https://bgpfilterguide.nlnog.net</a> <<a href="https://bgpfilterguide.nlnog.net/" rel="noreferrer" target="_blank">https://bgpfilterguide.nlnog.net/</a>> and implement the policies that make sense for you.<br>
<br>
Signup for <a href="http://peeringdb.com" rel="noreferrer" target="_blank">peeringdb.com</a> <<a href="http://peeringdb.com/" rel="noreferrer" target="_blank">http://peeringdb.com/</a>> so that your contacts can be found easily and others can peer better with you.<br>
<br>
Use bgpq4 for generating BGP prefix lists.<br>
Use RPKI ROV and per bgpfilterguide filter these + ensure you got ROA for your own prefixes.<br>
Use OTC attribute to avoid accidental route leaks from/to peers/transits.<br>
<br>
For BCP38 if you can setup a Spoofer node: <a href="https://www.caida.org/projects/spoofer/" rel="noreferrer" target="_blank">https://www.caida.org/projects/spoofer/</a><br>
and then sign up for <a href="https://www.manrs.org/" rel="noreferrer" target="_blank">https://www.manrs.org/</a><br>
<br>
Note that with nftables, if you have full table you can do something like:<br>
```<br>
# Drop when the source route is incorrect<br>
fib saddr . iif oif eq 0 log prefix "RPF: " counter drop<br>
```<br>
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.<br>
<br>
<br>
Sign up for <a href="https://bgp.tools/" rel="noreferrer" target="_blank">https://bgp.tools/</a> so that you get monitoring from the outside and one can publish BGP Communities there and in NLNOG Ring: <a href="https://github.com/NLNOG/lg.ring.nlnog.net" rel="noreferrer" target="_blank">https://github.com/NLNOG/lg.ring.nlnog.net</a><br>
and when you send BGP updates there it will nicely show up in their interace: <a href="https://lg.ring.nlnog.net" rel="noreferrer" target="_blank">https://lg.ring.nlnog.net</a> <<a href="https://lg.ring.nlnog.net/" rel="noreferrer" target="_blank">https://lg.ring.nlnog.net/</a>><br>
<br>
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)<br>
<br>
<br>
<br>
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 <a href="https://lg.as57777.net" rel="noreferrer" target="_blank">https://lg.as57777.net</a> <<a href="https://lg.as57777.net/" rel="noreferrer" target="_blank">https://lg.as57777.net/</a>> but pre-packaged ones are available and allow easy debugging (I need to publish the code for mine properly one day though).<br>
A quick 'connectivity check from multiple points' like I have for <a href="https://debug.massars.net" rel="noreferrer" target="_blank">https://debug.massars.net</a> <<a href="https://debug.massars.net/" rel="noreferrer" target="_blank">https://debug.massars.net/</a>> 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.<br>
<br>
<br>
See <a href="https://massars.net/details/" rel="noreferrer" target="_blank">https://massars.net/details/</a> for a long list of things I have done with links to the projects involved. Also <a href="https://massars.net/design/" rel="noreferrer" target="_blank">https://massars.net/design/</a> has some more details on how/what I did.<br>
<br>
Regards,<br>
 Jeroen<br>
<br>
</blockquote></div>