Le routage pour optimiser le peering entre participants du BNIX

Le Route Server (Serveur de Route) simplifie le peering et évite de devoir gérer des sessions de peering latérales. Les participants au BNIX peuvent ainsi appairer avec d'autres réseaux en une seule session BGP vers notre Route Server.

Le BNIX met à disposition des membres qui le souhaitent un Route Server, afin de simplifier les opérations et les échanges, ainsi que la gestion du plan de contrôle.

Le Serveur de Route, pour répondre au trafic croissant du BNIX

D'année en année, le nombre de participants au BNIX croît. En 2018, pour la première fois dans son histoire, le BNIX enregistrait son plus haut taux de participants (64). Autrement dit, plus de 60 hébergeurs, opérateurs et fournisseurs de service ou contenu comptent sur le BNIX pour optimiser leur trafic IP via le point d'échange internet belge.

Il y a deux manières de s'échanger des routes sur un IXP:

  • via un serveur de routes central, qui reçoit les annonces de tout le monde et les redistribue, ce qui permet à chaque participant de l'IX de monter une session BGP qu'avec le serveur de route.
  • en direct, entre participants, qui doivent monter une session BGP avec chaque autre participant.

 

La sécurité de routage sur les Serveurs de Route

Le daemon sur lequel le Serveur de Route apprend et redistribue les préfixes s'appelle Bird. Pour apprendre les routes des participants, il utilise BGP AS5406. Il ne participera pas au chemin BGP, mais redistribuera uniquement les routes apprises.

Pour s'assurer que les informations de routage sont correctes et sécurisées, le daemon de routage Bird utilise certains mécanismes de contrôle :

  • Support RPKI lors de l'utilisation des modèles Bird v2 ;
    • Valide -> accepter
    • Invalide -> déposer
    • RPKI inconnu -> revenir au filtrage standard des préfixes IRRDB ;
  • Filtrage complet des préfixes basé sur les entrées IRRDB ;
  • Filtrage ASN d'origine complet basé sur les entrées IRRDB ;
  • Dans tous les cas, filtrage des préfixes pour IPv4 et v6 sur la base des registres à usage spécial de l'IANA (également appelés listes de bogon) ;
  • S'assurer que le prochain saut est l'adresse du voisin pour garantir qu'il n'y a pas de piratage ;
  • Limitations maximales de préfixes ;
  • Prises en charge de grandes communautés BGP ;
  • Filtrage des réseaux de transit.

Vérifiez vos routes via notre route serveur à l'aide de 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

Si vous souhaitez en savoir plus sur la sécurité des routes, n'hésitez pas à nous contacter via servicedesk@bnix.net.

Comment bénéficier du Serveur de Route BNIX?

Vu le nombre croissant des participants BNIX qui doivent s'échanger des routes sur notre point d'échange internet, BNIX a déployé son propre Serveur de Route.

Notre Serveur de Route vous permet:

  • de monter une seule session BGP entre le participant et le Serveur de Route;
  • d'échanger les routes avec tous les participants qui en font autant;
  • sans avoir à négocier ni à configurer et mettre en place une session BGP par peer.

Un peering direct avec notre Serveur de Route permet donc de diminuer les difficultés opérationnelles en matière de configuration et de gestion des sessions peering, tout en augmentant le nombre de peers potentiels.

Commencez le peering via notre Serveur de Route

Questions fréquemment posées

Title
Qu'est ce qu'un serveur de route?

Text

Un serveur de route est simplement un appareil qui facilite le routage. C'est tout particulièrement intéressant lorsque vous devez maintenir de nombreuses sessions de peering.
Au lieu de maintenir une session de peering avec chacun de vos partenaires de peering, il est possible de "peerer" exclusivement avec le serveur de route et d'échanger vos préfixes via le serveur de route vers vos partenaires de peering.

Title
Qu'en est-il de la redondance?

Text

Nous avons déployé deux route servers. Le premier se trouve sur le PoP bruzav/Interxion et le second sur le PoP brueve/CenturyLink.

Title
Nous n'avons pas de politique ouverte de peering, pourquoi aurions-nous besoin d'un serveur de route?

Text

Les serveurs de route n'interfereront pas avec votre politique de peering. Il est possible de controler la redistribution de vos préfixes en utilisant les communautés BGP. Il est possible de "filtrer" la distribution de vos préfixes au travers du serveur de route.

Title
Comment puis-je contrôler la distribution de mes préfixes vers les autres participants?

Text

Voici un tableau récapitulatif:

Comportement de redistribution vers les communautés BGP
0:<peer-as>Ne pas distribuer à peer-as
5406:<peer-as>Distribuer seulement à to peer-as
0:5406Ne pas distribuer

Aucune communauté ne distribue vers toutes les politiques de peering.

Remarques:

  • Si vous avez une politique de peering, vous ne devrez pas vous préoccuper des communautés BGP. Il existe une action de distribution vers tous: "advertise to all" implicite.
  • Si vous souhaitez distribuer uniquement avec un peer en particulier (5406:<peer-as>), vous aurez aussi besoin d'ajouter l'action "ne pas distribuer" (0:5406) pour empêcher l'action implicite "advertise to all".

Title
Y a-t-il d'autres points d'attention auxquels je dois être attentif?

Text

En guise de protection, un mecanisme filtre toutes les annonces de préfixe entrantes. C'est pourquoi vos préfixes doivent être enregistrés dans la DB RIPE. Si un "as" est défini, nous pouvons filtrer sur cet "as". Si ce n'est pas le cas, nous filterons simplement sur le ASN.
Avec le schéma de communautés, vous ne pouvez influencer que la politique d'export. Celà étant, vous contrôlez quels autres réseaux recevront vos préfixes. Vous devrez toujours contrôler vos politiques locales d'import. Si les autres réseaux ont une politique de peering, vous recevrez bien sûr leurs préfixes. Même si vous décidez de ne pas "peerer" avec eux. Ainsi, vous pourriez décider de filtrer ces préfixes pour les écarter dans le cas ou vous ne souhaiteriez pas "peerer" avec eux.
Si vous utilisez un équipement CISCO, vous aurez probablement besoin de configurer l'option "no bgp enforce-first-as" dans la configuration de la session BGP.

Title
Quels équipements sont utilisés?

Text

Différentes implémentations de serveurs de route sont disponibles. Un consensus au sein de la communauté semble indiquer que BIRD est un choix judicieux. C'est celui pour lequel nous avons également opté (http://bird.network.cz/)

Title
Quels sont les détails de configuration pour mettre en place une session de peering BGP?

Text
rs1.brueve.bnix.net
AS:5406
addr:194.53.172.2
addr6:2001:7f8:26::a500:5406:2
md5:supporté (et encouragé)

rs1.bruzav.bnix.net
AS:5406
addr:194.53.172.1
addr6:2001:7f8:26::a500:5406:1
md5:supporté (et encouragé)

Title
Devriez-vous peerer avec les deux serveurs de route?

Text

Celà dépend. Si vous n'avez qu'une seule connexion avec le BNIX, c'est probablement une bonne idée de peerer avec les deux serveurs de route.
Si vous avez une connexion BNIX redondante (CenturyLink et Interxion), cela aura probablement plus de sens de peerer uniquement avec le serveur de route local. Ainsi, votre routeur de peering à Interxion ne fera du peering que avec le serveur de route de Interxion et votre routeur de peering situé à CenturyLink ne fera du peering que avec le serveur de route de CenturyLink.

Title
Intéressant, que faire pour commencer?

Text

Envoyez un mail à servicedesk@bnix.net pour que nous puissions configurer une session de peering sur le serveur de route pour votre réseau. Si vous voulez que nous filtrions sur base de vos as-set, n'oubliez pas de les inclure dans le mail. 

Rem: L'authentification BGP md5 est disponible et encouragée.

Copyright © 2024 BNIX - Conditions d'utilisation - AUP