> On 8 Dec 2025, at 17:41, Mike Neo <[email protected]> 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
