Accueil/Serveurs de Routes

Serveurs de Routes

Les Route Servers HubSIX simplifient l'interconnexion entre les membres de l'IXP. Une seule session BGP pour échanger des routes avec l'ensemble des membres connectés.

Pourquoi utiliser les Route Servers HubSIX ?

Les Route Servers HubSIX simplifient considérablement l'interconnexion entre les membres de l'IXP. En établissant une seule session BGP avec les Route Servers, un participant peut automatiquement échanger des routes avec l'ensemble des membres connectés au service.

Avantages principaux :

Réduction significative du nombre de sessions BGP à maintenir
Accès rapide à un grand nombre de routes via une configuration unique
Possibilité de contrôler finement les annonces grâce aux communautés BGP
Simplification des opérations de peering sans négociation bilatérale systématique

Cette approche permet une mise en service rapide et un gain opérationnel important pour les équipes réseau.

Certains réseaux peuvent toutefois privilégier des peerings bilatéraux directs. Lorsqu'un membre n'utilise pas les Route Servers, les demandes de peering peuvent être réalisées directement via les informations disponibles sur PeeringDB.

Fonctionnement des Serveurs de Routes

Fonctionnalités techniques et sécurité

Les Route Servers HubSIX sont conçus pour assurer un échange de routes performant et sécurisé entre les participants :

Sélection et redistribution du meilleur chemin BGP pour chaque préfixe
Transparence de l'AS_PATH : l'ASN du Route Server n'est pas inséré dans les annonces
Conservation du next-hop afin que le trafic circule directement entre les membres
Transmission des communautés BGP standards sans modification
Support de la fonctionnalité ADD-PATH pour l'annonce de plusieurs chemins vers une même destination
Annonces sélectives possibles grâce aux communautés BGP HubSIX
Contrôles automatiques et filtrage des routes afin de renforcer la sécurité du routage
Support des BGP Roles (RFC 9234) pour éviter les annonces non conformes
Possibilité d'activer BFD pour une détection rapide des défaillances de session

Annonces sélectives

Par défaut, lorsqu'une route est annoncée au Route Servers, 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 :

37803:1:0 = [DEFAULT] Envoyer la route à tous les peers

37803:0:0 = N'envoyer la route à aucun peer

37803:0:peeras = Ne pas envoyer cette route à ce peer AS

37803:1:peeras = Envoyer cette route à ce peer AS (si 37803:0:0 est spécifié)

37803:101:peeras = Prepend 1x vers ce peer AS

37803:102:peeras = Prepend 2x vers ce peer AS

37803:103:peeras = Prepend 3x vers ce peer AS

37803:901:peeras = Set MED to 50 pour ce peer AS

37803:902:peeras = Set MED to 100 pour ce peer AS

37803:903:peeras = Set MED to 200 pour ce peer AS

Les communautés ci-dessous sont appliquées par les route-server HubSIX:

37803:64601 = Prefixe reçu d'un peer sur Route Serveur 1

37803:64602 = Prefixe reçu d'un peer sur Route Serveur 2

Les communautés ci-dessous sont appliquées pour donner le statut RPKI

37803:65012 = le Prefixe a un statut ROA: VALID

37803:65022 = le Prefixe a un statut ROA: INVALID (il ne sera pas ré annoncé)

37803:65023 = le Prefix a un statut ROA: UNKNOWN

37803:65011 = le Prefix est present dans un AS annoncé AS/AS-SET

37803:65021 = le Prefix n'est pas present dans un AS annoncé AS/AS-SET (il ne sera pas ré annoncé)

Sécurité

Afin d'éviter certaines erreurs grossières, les Route-Servers HubSIX 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

Toutes les communautés sont évaluées selon le principe du « premier arrivé, premier servi »

• Toutes les autres communautés BGP de la plage publique :(1-64495:x, 1-64495:x:y) et (131072-4199999999:x:y) seront conservées et transmises par les Route Servers

Liste des routes qui seront rejetées par les Route Servers :

Préfixe trop court : IPv4 : </8, IPv6 : </19 (route par défaut incluse)
Préfixe trop long : IPv4 : >/24, IPv6 : >/48
Préfixes RFC5735 pour IPv4 (incluant RFC1918, RFC6598 et autres)
Préfixes RFC5156 pour IPv6
RFC6996 - Routes contenant des ASN privés dans le chemin
Routes où next_hop different du announcing_peer
Routes où first_ASN different du peer_ASN
Routes ayant déjà l'attribut OTC (RFC9234) défini
Routes ayant des ROA, et aucun ROA ne correspond à l'annonce
IRR AS invalide - Routes dont l'origine n'est PAS dans l'ensemble AS des pairs
Origine invalide - Routes sans ROA valide et sans objet de route IRR correspondant

Nous prenons en charge :

ADD-PATHS. Si la négociation est effectuée via BGP, vous recevrez un NLRI étendu.
RFC9234 - notre rôle est RS_Server. # Nous définissons l'attribut OTC
Si vous implémentez la RFC9234, votre rôle sera RS_Client

BGP

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

whois -h whois.afrinic.net as37803

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.
Filtrez en ingress les préfixes de l'IXP :196.60.252.0/24, 2001:43f8:1750::/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
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).