Les serveurs de routes, aussi connus sous le nom de RS (route servers) permettent aux membres de réduire le nombre de sessions BGP à configurer et donc le temps de gestion de son réseau IP. En effet, par défaut toutes les routes des membres connectés aux RS sont redistribuées.
Un serveur de routes n’est pas un routeur, le flux de données est directement échangé entre les participants, seules les informations BGP sont échangées avec le RS. Par exemple, si deux membres établissent une session BGP avec les RS, seules les informations de routages seront échangées par les Route-Serveurs (Control-plane), le flux de donnée sera direct entre leur routeur (Data-plane) car ils sont dans le même LAN.
Comme vous pouvez le constater sur ce diagramme, le Control-plane et Data-plane sont différents.
Les principaux avantages pour les membres se connectant aux RS sont :
Cette approche « une session pour apprendre toutes les routes » permet de gagner beaucoup de temps !
N’oubliez pas que certains réseaux préfèrent établir des accords de peering directs et ne sont donc pas présents sur les RS. L’adoption des RS par les membres France-IX est indiquée sur la liste des membres France-IX. En cas d’absence sur les RS, l’alternative est d’envoyer une demande de peering à chaque réseau par email en s’adressant au contact de peering affiché.
Voici les fonctionnalités présentes sur les serveurs de routes France-IX :
Par défaut, lorsqu’une route est annoncée au RS, chaque membre reçoit cette route.
Il est possible de choisir d’annoncer (ou pas) cette route à certains membres à l’aide de communautés BGP :
Paris :
0:peer-as = Ne pas envoyer cette route à peer-as
51706:peer-as = Envoyer cette route à peer-as
0:51706 = N’envoyer cette route à aucun peer
51706:51706 = Envoyer cette route à tous les peers
Marseille :
0:peer-as = Ne pas envoyer cette route à peer-as
42064:peer-as = Envoyer cette route à peer-as
0:42064 = N’envoyer cette route à aucun peer
42064:42064 = Envoyer cette route à tous les peers
Des informations supplémentaires sont disponibles sur notre objet RIPE:
Paris :
whois -h whois.ripe.net as51706
ou apps.db.ripe.net/search/lookup.html?source=ripe&key=AS51706&type=aut-num
Marseille :
whois -h whois.ripe.net as42064
ou apps.db.ripe.net/search/lookup.html?source=ripe&key=AS42064&type=aut-num
Afin d’éviter certaines erreurs grossières, les Route-Servers FranceIX réalisent systématiquement ces vérifications :
Toute route ne respectant pas ces critères sera rejetée.
Afin d’aider les membres à réduire le trafic provenant d’attaques DDoS (Distributed Denial of Service), nous avons déployé un service de BLACKHOLING. Ce service permet aux membres d’annoncer des routes avec une communauté BGP spécifique afin de bloquer ce trafic.
Vous trouverez plus d’information sur notre page dédiée au service BLACKHOLING.
Toute route taggée avec la communauté BLACKHOLING mais ne passant pas les vérification IRR sera rejetée (voir section suivante).
Il existe des bases de données (appelées IRR) qui sont gérées par les RIRs (Registre Internet Régionaux) mais aussi par d’autres entités pour enregistrer des plages d’adresses IP allouées. De plus, une infrastructure RPKI permet aux réseaux IP de vérifier l’origine des annonces BGP grâce aux ROAs (Route Origin Autorisation).
Les ROA et l’enregistrement des préfixes sont expliqués sur la page de certification de ressources du RIPE.
Les serveurs de routes France-IX marquent les routes avec des communautés BGP en fonction de leurs états de validation IRR et RPKI / ROA. Nous utilisons plusieurs IRR dont la base de données du RIPE, ainsi qu’une instance locale du RIPE RPKI validator afin de garantir les données les plus fiables possibles.
Comment une route est identifiée « IRR NOT FOUND » ou « ROA INVALID » par les RS de France-IX ?
« IRR NOT FOUND »: pour tout membre connecté à France-IX, un algorithme recherche l’objet AS-SET associé à l’ASN du membre. L’AS-SET est recherché premièrement dans le champ « IRR Record » de PeeringDB. Si ce champ est vide, l’algorithme va tenter de trouver un AS-SET dans l’objet « AUT-NUM » à travers les lignes « export » (syntaxe RPSL). Il est donc primordial que le champ « IRR Record » de PeeringDB soit bien renseigné avec l’AS-SET s’il existe ou l’AUT-NUM à défaut.
Une fois l’objet AS-SET trouvé (ou AUT-NUM), l’algorithme recherche et établit la liste des objets ROUTE définis pour les AUT-NUM présents dans cet AS-SET (ou AUT-NUM). L’outil bgpq3 est utilisé pour faire cette recherche récursive avec comme paramètres la base IRR de NTT (rr.ntt.net) et les sources suivantes : RIPE, APNIC, AFRINIC, ARIN, LACNIC, NTTCOM, ALTDB, BBOI, BELL, GT, JPIRR, LEVEL3, RADB, RGNET, SAVVIS et TC.
Cette liste d’entrées IRR est stockée dans notre système d’information puis répliquée en local sur le RS. Lors d’une annonce de route, le RS va rechercher si la route se trouve dans cette liste « IRR FOUND » pour l’AS qui annonce le préfixe (first-AS). Si c’est le cas, alors elle sera marquée par le RS avec la communauté BGP « 51706:65011 ». Sinon la communauté BGP « 51706:65021 » sera ajoutée à la route puis elle sera rejetée par défaut.
« ROA INVALID »: une instance du RPKI validator du RIPE est installée dans l’infrastructure France-IX. Cette instance permet d’avoir une copie des entrées ROA et de générer ainsi une liste stockée sur notre système d’information puis répliqué en local sur le RS, de la même façon que pour les entrées IRR. Lors d’une annonce de route, le RS va rechercher l’état de la route pour l’AS d’origine. Si l’état ROA est « VALID » ou « UNKNOWN » la route sera marquée avec les communautés respectives « « 51706:65012 » ou « 51706:65023 » puis acceptée. Si l’état ROA de la route est « INVALID » la communauté « 51706:65022 » sera ajoutée puis elle sera rejetée par défaut. Il est donc essentiel que les déclarations ROA auprès des RIR soient réalisées correctement ( RIPE.NET)
Spécifier "no bgp enforce-first-as” (IOS et IOS-XE) ou “bgp enforce-first-as disable” (IOS-XR) lors de la configuration de la session BGP avec les serveurs de routes (uniquement si vous utilisez du matériel Cisco). Sans cette commande, la session BGP n’arrivera pas à s’établir avec nos RS.
Configurer votre limite max-prefix à un seuil adéquat (pensez à augmenter ce seuil ponctuellement car le nombre de routes présentes sur les RS est en constante augmentation : (https://tools.franceix.net/birdlg/par/rs1/v4).
Pour les familles d’adresses IPv4 et IPv6:
export-via: afi ipv4.unicast AS51706 to AS-ANY announce ASxxxx |
| ou |
mp-export: afi ipv4.unicast to AS51706 announce ASxxxx |
Pour IPv4 uniquement:
export-via: afi ipv6.unicast AS51706 to AS-ANY announce ASxxxx |
| ou |
mp-export: ipv6.unicast to AS51706 announce ASxxxx |
Pour IPv6 uniquement:
export-via: afi ipv6.unicast AS51706 to AS-ANY announce ASxxxx |
| ou |
mp-export: ipv6.unicast to AS51706 announce ASxxxx |
Si vous souhaitez filtrer les routes collectées depuis les RS, vous pouvez filter les préfixes en utilisant les AS-SET suivants :
Liste des ASN des membres présents sur les RS de Paris :
AS51706:AS-MEMBERS:AS-PAR-RS
AS-Set de tous les membres présents sur les RS de Paris (y compris leurs clients) :
AS51706:AS-MEMBERS
Liste des ASN des membres présents sur les RS de Marseille :
AS42064:AS-MEMBERS:AS-MRS-RS
AS-Set de tous les membres présents sur les RS de Marseille (y compris leurs clients) :
AS42064:AS-MEMBERS
Portail France-IX
Serveurs de Routes France-IX