A quoi servent les serveurs de routes ?

Les serveurs de routes, aussi connus sous le nom de RS (route servers) permettent aux clients de réduire le nombre de sessions BGP à configurer et donc le temps de gestion de leur réseau IP. En effet, par défaut toutes les routes des clients 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 clients connectés, et seules les informations BGP sont échangées avec le RS. Par exemple, si deux clients établissent une session BGP avec les RS, seules les informations de routages seront échangées par les Route-Serveurs (Control-plane), et le flux de données sera direct entre leurs routeurs (Data-plane) du fait d'être dans le même LAN.

Comme vous pouvez le constater sur ce diagramme, le Control-plane et le Data-plane sont différents.

Bénéfices

• Diminution du nombre de sessions BGP à configurer
• Méthode facile et rapide pour récupérer une multitude de routes
• Filtrage des annonces possible grâce à l’usage de communautés BGP
• Évite la négociation d’accords de peering avec chacun des clients

Cette approche « une session pour apprendre toutes les routes » permet de gagner un temps précieux !

Toutefois, un certain nombre de 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 clients France-IX est indiquée sur la liste des clients France-IX. En cas d’absence sur les RS, l’alternative est d’envoyer une demande de peering, les contacts peuvent être trouvés dans www.peeringdb.com.

Fonctionnalités et sécurité

Voici les fonctionnalités présentes sur les serveurs de routes France-IX :

• Sélection et ré-annonce du meilleur chemin BGP pour chaque route ;
• Ne modifie pas l’AS_PATH (l’ASN des RS n’est pas ajouté dans l’AS_PATH) ;
• Ne modifie pas l’adresse IP de next-hop (le trafic est échangé directement entre les routeurs) ;
• N’interprète pas les communautés BGP “well-known” : (NO-EXPORT, NO_ADVERTISE, etc.), ces communautés sont ré-annoncées aux clients ;
• Supporte ADD-PATH (Tx-only), votre routeur recevra plusieurs routes pour le même réseau de destination s’il supporte cette fonctionnalité ;
• Possibilité de faire des annonces sélectives (à l’aide de communautés BGP) ;
• Filtrages et vérifications des annonces (expliqué ci-dessous) ;
• Support des BGP Roles (RFC9234), les routes avec l’attribut “Only to Customer” sont rejetées ;
• BFD (Bidirectional Forwarding Detection) peut être activé sur demande.

Annonces sélectives

Par défaut, lorsqu’une route est annoncée au RS, chaque client reçoit cette route.

Il est possible de choisir d’annoncer (ou pas) cette route à certains clients à l’aide de communautés BGP :

Paris Route-servers : 

Marseille Route-servers : 

Lyon

Lille

Toulouse

Des informations supplémentaires sont disponibles sur notre objet RIPE :

Paris :
whois -h whois.ripe.net as51706
ou https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS51706&type=aut-num

Marseille :
whois -h whois.ripe.net as42064
ou https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS42064&type=aut-num

Lyon :
whois -h whois.ripe.net as43100
ou https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS43100&type=aut-num

Lille :
whois -h whois.ripe.net as62228
ou https://apps.db.ripe.net/db-web-ui/lookup?source=RIPE&type=aut-num&key=AS62228

Toulouse :
whois -h whois.ripe.net as47184
ou https://apps.db.ripe.net/db-web-ui/lookup?source=RIPE&type=aut-num&key=AS47184

Sécurité

Afin d’éviter certaines erreurs grossières, les Route-Servers France-IX réalisent systématiquement ces vérifications :

• Filtrages des « Martian’s prefixes » : (BOGONS VIA HTTP) ;
• Max-prefix : limitation du nombre de préfixes appris par peer (coupure de la session BGP si le seuil est atteint) ;
• Longueur du préfixe : en IPv4 le masque de sous-réseau doit être ≥ /8 et ≤ /24,
  en IPv6 le masque de sous-réseau doit être ≥ /19 et ≤ /48 ;
• ASN privé : pas de numéro d’AS privé dans l’AS_PATH ;
• Addresse NEXT_HOP : vérification que l’IP next-hop dans l’annonce BGP est aussi la source du paquet IP ;
• Peer AS : vérification que l’ASN le plus à gauche dans l’AS_PATH est l’ASN du peer BGP.
  

Toute route ne respectant pas ces critères sera rejetée.

Blackholing

Afin d’aider les clients à réduire le trafic provenant d’attaques DDoS (Distributed Denial of Service), une fonctionnalité de Blackholing, incluse dans le service de peering France-IX, permet aux clients d’annoncer des routes avec une communauté BGP spécifique afin de bloquer ce trafic.

Toute route taggée avec la communauté Blackholing mais ne passant pas les vérifications IRR est rejetée par défaut (voir section suivante).

Filtrage RPKI / ROA et IRR

Il existe des bases de données (appelées IRR) qui sont gérées par les RIRs (Registres 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 client connecté à France-IX, un algorithme recherche l’objet AS-SET associé à l’ASN du client. L’AS-SET est recherché en premier lieu dans le champ « IRR Record » de PeeringDB. Si ce champ est vide, l’algorithme tente alors 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).

Bonnes pratiques

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).

• Si vous souhaitez filtrer la longueur des préfixes, sachez que les préfixes avec la communauté BLACKHOLE sont acceptés jusqu’à /32 en IPv4 et /128 en IPv6 sur nos RS.
• Filtrez en ingress les préfixes de l’IXP : 37.49.232.0/24, 37.49.236.0/22, 2001:7f8:54::/48 (et plus spécifiques) depuis tous vos peers BGP et transitaires. Cela vous protègera si quelqu’un annonce accidentellement ces préfixes.
• Créez les ROA pour vos préfixes sur votre portail LIR (https://my.ripe.net/#/rpki pour les réseaux européens).
• Complétez et maintenez à jour vos objets (ASN/AUT-NUM et éventuellement AS-SET) dans les IRR. Voici quelques exemples de macro (ASxxxx peut-être votre numéro d’AS ou le nom de votre AS-SET) :

Pour les familles d’adresses IPv4 et IPv6:

ou

Pour IPv4 uniquement:

ou

Pour IPv6 uniquement:

ou

Si vous souhaitez filtrer les routes collectées depuis les RS, vous pouvez filtrer les préfixes en utilisant les AS-SET suivants :

Liste des ASN des clients présents sur les RS de Paris :

AS51706:AS-MEMBERS:AS-PAR-RS

AS-Set de tous les clients présents sur les RS de Paris (y compris leurs clients) :

AS51706:AS-MEMBERS

Liste des ASN des clients présents sur les RS de Marseille :

AS42064:AS-MEMBERS:AS-MRS-RS

AS-Set de tous les clients présents sur les RS de Marseille (y compris leurs clients) :

AS42064:AS-MEMBERS