Routing to optimise peering between BNIX participants

The Route Server simplifies peering and avoids having to manage lateral peering sessions. BNIX (Belgian National Internet eXchange) participants can therefore peer with other networks in a single BGP session to our route server.

The BNIX provides members who wish with a Route Server, to simplify operations, exchanges and management of the control plan.

The Route Server, to respond to the BNIX’s growing traffic

Year after year, the number of BNIX participants is growing. In 2018, for the first times in its history, the BNIX saw its highest amount of participants (64). In other words, more than 60 hosts, operators and service or content providers count on the BNIX to optimise their IP traffic via the Belgian Internet exchange point.

There are two ways to exchange routes on an IXP:

  • via a central routes server, which receives announcements from everyone and redistributes them, which enables each IX participant to set up a BGP session only with the route server.
  • directly, between participants, which must set up a BGP session with each other participant.

 

Route security on the route servers

The daemon on which the route server learns and redistributes prefixes is called Bird. To learn the routes from participants, it uses BGP AS5406. It will not participate in the BGP path, but will solely redistribute the routes learned.

To ensure the routing information is correct and secure, the Bird routing daemon uses some control mechanisms:

  • RPKI support when using the Bird v2 templates;
    • Valid -> accept
    • Invalid -> drop
    • RPKI Unknown -> revert to standard IRRDB prefix filtering;
  • Full prefix filtering based on IRRDB entries;
  • Full origin ASN filtering based on IRRDB entries;
  • In all cases, prefix filtering for IPv4 and v6 based on the IANA special purpose registries (also known as bogon lists);
  • Ensuring next hop is the neighbor address to ensure no next hop hijacking;
  • Max prefix limits;
  • Large BGP communities supported;
  • Filter known transit networks.

Check your routes via our route servers using Looking Glass:

https://ixpmanager.bnix.net/lg/rsbruzavv4

https://ixpmanager.bnix.net/lg/rsbruzavv6

https://ixpmanager.bnix.net/lg/rsbruevev6

https://ixpmanager.bnix.net/lg/rsbruevev4

If you want to learn more on route security, don’t hesitate to contact us via techsupport@bnix.net.

How can you use the BNIX Route Server?

Given the growing number of BNIX participants that must exchange routes on our internet exchange point, BNIX has deployed its own route server.

Our route server enables you:

  • to set up a single BGP session between the participant and the Route Server;
  • to exchange routes with all the participants who do the same;
  • without having to negotiate or configure and set up a BGP session per peer.

Direct peering with our route server enables us to reduce operational difficulties in terms of the configuration and management of peering sessions, while increasing the number of potential peers.

Start peering via our Route Server

Frequently asked questions

Title
What is a route server?

Text

A route server is simply a device that facilitates routing. This is particularly useful when you need to maintain many peering sessions.
Instead of maintaining a peering session with each of your peering partners, it is possible to peer only with the route server and exchange your prefixes through the route server to your peering partners.

Title
What about redundancy?

Text

We have deployed two route servers. The first is located at the bruzav/Interxion PoP and the second at the brueve/CenturyLink PoP.

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

Text

Route servers will not interfere with your peering policy. It is possible to control the redistribution of your prefixes using BGP communities. It is possible to "filter" the distribution of your prefixes through the route server.

Title
How can I control the distribution of my prefixes to other participants?

Text

Here is a summary table:

Redistribution behavior via BGP communities
0:<peer-as>Do not distribute to peer-as
5406:<peer-as>Distribute only to peer-as
0:5406Do not distribute

No community → distributes to all peering policies.

Notes:
If you have a peering policy, you don't need to worry about BGP communities. There is an implicit "advertise to all" distribution action.

If you only want to distribute to a specific peer (5406:<peer-as>), you will also need to add the "do not distribute" action (0:5406) to prevent the implicit "advertise to all" action.

Title
Are there any other points of attention I should be aware of?

Text

As a safeguard, a mechanism filters all incoming prefix advertisements. This is why your prefixes must be registered in the RIPE DB. If an "as" is defined, we can filter on that "as." If not, we simply filter on the ASN.

With the community scheme, you can only influence the export policy. That said, you control which other networks will receive your prefixes. You still need to control your local import policies. If the other networks have a peering policy, you will of course receive their prefixes, even if you decide not to peer with them. Therefore, you could decide to filter these prefixes out if you don't want to peer with them.

If you are using CISCO equipment, you will probably need to configure the no bgp enforce-first-as option in the BGP session configuration.

Title
What equipment is used?

Text

There are various route server implementations available. A consensus within the community seems to indicate that BIRD is a good choice. This is also the one we have chosen. (http://bird.network.cz/)

Title
What are the configuration details to set up a BGP peering session?

Text
rs1.brueve.bnix.net
AS:5406
addr:194.53.172.2
addr62001:7f8:26::a500:5406:2
md5:supported (and encouraged)
rs1.bruzav.bnix.net
AS:5406
addr:194.53.172.1
addr62001:7f8:26::a500:5406:1
md5:supported (and encouraged)

Title
Do I need to peer with the 2 route servers?

Text

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

Title
Interesting, what to do to start?

Text

Send an email to techsupport@bnix.net so we can configure a peering session on the route server for your network. If you would like us to filter based on your assets, please include them in the email.

Note: BGP md5 authentication is available and encouraged.

Copyright © 2025 BNIX - Disclaimer - AUP