On 8 Dec 2025, at 17:41, Mike Neo <neomikemac@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