Le réseau d'HOPUS est entièrement routé, les traceroutes affichent tous les sauts.
Nous honorons la MED: si vous êtes interconnectés sur plusieurs POPs, nous choisirons la route avec la MED la plus basse. Nous annonçons nos routes avec une MED égale à notre cost IGP vers le next-hop BGP (les costs IGP sont fixés à partir de la latence entre nos POPs).
Nous acceptons et honorons la communauté BGP Graceful Shutdown (RFC8326). Lorsque vous annoncez cette communauté nous ajustons notre LocalPref à 0, ce qui garantira l'utilisation de chemins alternatifs s'ils existent. Pendant les maintenances planifiées nous signalerons toujours cette communauté.
Les routes suivantes sont filtrées sur HOPUS:
Limite maximum-prefix : Nous définissons une limite maximum de prefixes appris sur toutes les sessions eBGP. La limite max-pref recommandée à configurer de votre côté est fournie sur notre page PeeringDB.
Il est possible de déclencher certaines actions à partir de communautés BGP (44530:0 ou 65535:666 pour RTBH, 44530:65281 pour etre réannoncé avec NO_EXPORT).
Les prefixes annoncés avec une communauté RTBH doivent être acceptés par le filtrage IRR mais peuvent avoir un état de validation RPKI/ROA invalide (par exemple les annonces RTBH /32 IPv4 ou /128 IPv6 sont acceptées).
La session BGP avec le Route Serveur est optionnelle, nous disposons d'un RS par POP.
Le RS apprend les routes via sa session iBGP avec notre routeur PE et annonce toutes les routes disponibles sur HOPUS sans l'AS44530 (HOPUS ASN) dans l'AS_PATH.
BGP n'est pas réciproque, par conséquent chaque membre HOPUS doit établir une session avec son RS local s'il ne veut pas voir AS44530 (HOPUS ASN) dans AS_PATH.
Pour établir la session BGP avec le RS, vous devez activer le multihop sur cette session (2 hops) et de préférence ajouter une route statique vers le RS via le PE.
Les utilisateurs de Cisco doivent 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 avec le RS (puisque RS n'ajoute pas son ASN dans l'AS_PATH)
Nous filtrons les annonces BGP recues à partir la base IRR de NTT (rr.ntt.net avec bgpq4) celle-ci agrège les données des autres IRR en vérifiant leur pertinance (IRR Lockdown).
La liste des prefixes acceptés est mise à jour quotidiennement sur nos équipements en se basant sur votre AS-SET si vous nous en avez indiqué un (voir page membres).
Vous pouvez vérifier la listes des préfixes acceptés sur notre Looking Glass. En faisant un "BGP summary" sur le routeur de votre POP, vous verrez le nombre (et la liste, en suivant le lien) des PfxRcd et PfxAcc pour votre session.
Les routes ayant un état de validation RPKI/ROA invalide sont rejetées.
Les réseaux européens peuvent créer et modifier leurs ROA via la page https://my.ripe.net/#/rpki, en suivant ces explications détaillées (en anglais).
Il est possible de vérifier les annonces BGP et la validité des ROA sur le site du RIPE RPKI Validator ou le RPKI Portal de Cloudflare. Le lien "received-routes" depuis la colonne PfxRcd de notre Looking Glass indique aussi le status de validation.
Nous utilisons un certain nombre de communautés BGP afin de marquer l'origine des routes apprises (POP, Pays...), toute route que nous recevrons de votre part avec ces communautés sera refusée.
Il vous est possible de déclencher certaines actions à partir de communautés BGP (44530:0 ou 65535:666 pour RTBH, 44530:65281 pour etre réannoncé avec NO_EXPORT). Il n’est par contre pas possible de restreindre les annonces via des communautés BGP.
La liste complète des communautés est consultable sur notre objet AUT-NUM AS44530.