picto statistiques Serveurs de Routes France-IX

  • Accueil »
  • Technique »
  • France-IX Route-Servers
  • A quoi servent les serveurs de routes?

    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.

     

    Serveurs de Routes France-IX

    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 :
     

    • Diminution de 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 membres

     

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

    Fonctionnalités et sécurités

    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 par 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 membres
    • 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)

     

     

    Annonces sélectives

    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 :

     

    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

     

    Features and security layout Schemas

    Des informations supplémentaires sont disponibles sur notre objet RIPE:
    whois -h whois.ripe.net as51706
    ou apps.db.ripe.net/search/lookup.html

    Sécurités

    Afin d’éviter certaines erreurs grossières, les Route-Servers FranceIX 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 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).

     

    Filtrage RPKI/ROA et IRR

     

    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.

     

    Vérification Routes serveurs France-IX

     

    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)

    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 : (tools.franceix.net/looking-glass).

    • 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/23, 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:

    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 :

    Membres présents sur les RS de Paris :

    AS51706:AS-MEMBERS:AS-PAR-RS

    Membres présents sur les RS de Marseille :

    AS51706:AS-MEMBERS:AS-MRS-RS