"What exactly is a route server?"

"What about redundancy?"

"We don't have an open peering policy, why would we need a route server?"

"So, how can I control the distribution of my prefixes towards other participants?"

"OK, any (other) points of attention that I should be aware of?"

"What engine is under the hood?"

"What are the configuration details to setup a bgp peering session"

"Should you peer with both route servers?"

"Sounds great, how do we get started"



What exactly is a route server?

Simply put a route server is a device that facilitates routing. It's especially interesting when you have to maintain a lot of peering sessions. Instead of maintaining a peering session with each of your peering partners, it's possible to peer exclusively with the route server and to exchange your prefixes via the route server towards your peering partners.

got to top


What about redundancy?

We've deployed two route servers. One on the bruzav/Interxion PoP the other one on the brueve/Level(3) PoP.

got to top


We don't have an open peering policy, why would we need a route server?

Route servers won't interfere with your peering policy. It is possible to control the redistribution of your prefixes by using BGP communities. It is possible to 'filter' the distribution of your prefixes through the route server.

Go to top


So, how can I control the distribution of my prefixes towards other participants?

Here's an overview table:

BGP community redistribution behavior
0:<peer-as> Don't advertise to peer-as
5406:<peer-as> Advertise only to peer-as
0:5406 Don't advertise


no communities advertise to all, open peering policy

Some remarks:

  • If you have an open peering policy, there's no need to fiddle with BGP communities. We have an implicit "advertise to all" action.
  • If you want to advertise to a specific peer only (5406:<peer-as>) you also need to add the "don't advertise" (0:5406) community to negate the implicit "advertise to all" action.


Go to top


OK, any (other) points of attention that I should be aware of?

As a protection mechanism we will filter all incoming prefix announcements. Therefor your prefixes must be registered in the RIPE who is DB. If you have an as-set we can filter on that as-set. If not we'll filter simply on the ASN. With the BGP communities scheme you can only influence your export policy. That is, you control which other networks will receive your prefixes. You will still need to control your import policy locally. If another network has an open peering policy you will of course receive there prefixes. Even when you decide not to peer with them. So you might decide to filter those out if you decide not to peer with them. If you use Cisco equipment you will probably need to set the "no bgp enforce-first-as" option on the BGP session configuration.

got to top


What engine is under hood?

There's a variety of different route server implementations available. Community consensus seems to indicate that BIRD is a sound choice. So, that's what we've settled for. http://bird.network.cz/

got to top


What are the configuration details to setup a bgp peering session?

AS: 5406
addr6: 2001:7f8:26::a500:5406:2
md5: supported (and encouraged)

AS: 5406
addr6: 2001:7f8:26::a500:5406:1
md5: supported (and encouraged)

got to top


Should you peer with both route servers?

It depends. If you have only one connection with the BNIX, it's probably a good idea to peer with both route servers. If you have redundant BNIX connections (Level3 and Interxion) it probably makes more sense to peer only with the local route server. So your peering router at Interxion only peers with the route server at Interxion and your peering router at Level(3) only peers with the Level(3) route server.

got to top


Sounds great, how do I get started?

Just drop us a mail at <servicedesk@bnix.net> we'll configure a peering session for your network on the route server. If you want us to filter on your as-set, please include it in your mail. BGP md5 authentication is available and encouraged.

got to top


BNIX Networking Event 2019: the registrations are open!
21 Aug 2019
Belnet /BNIX is moving to the WTC III building
11 Mar 2019
Traffic on Belgian Internet Exchange BNIX grew by 14 percent in 2018
18 Jan 2019