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 servicedesk@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 exactly is a route server?

Text

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.

Title
What about redundancy?

Text

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

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

Text

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.

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

Text

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.

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

Text

As a protection mechanism we will filter all incoming prefix announcements. Therefore 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 their 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.

Title
What engine is under hood?

Text

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/

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

Text
rs1.brueve.bnix.net
AS: 5406
addr: 194.53.172.2
addr6: 2001:7f8:26::a500:5406:2
md5: supported (and encouraged)

rs1.bruzav.bnix.net
AS: 5406
addr: 194.53.172.1
addr6: 2001:7f8:26::a500:5406:1
md5: supported (and encouraged)

Title
Should you peer with both route servers?

Text

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.

Title
Sounds great, how do I get started?

Text

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.

Copyright © 2024 BNIX - Disclaimer - AUP