J'ai entendu le terme "serveur de route" et "miroir" jeté par ici. Quels sont-ils et pourquoi devrais-je m'en soucier?
(Notez que ces deux termes sont souvent utilisés de manière interchangeable, ce qui peut entraîner une certaine confusion.)
Un miroir est généralement un site Web (le plus souvent CGI) qui s'interface avec des routeurs détenus et exploités par un seul FAI ou un autre opérateur de réseau. La plupart du temps, ceux-ci sont accessibles au public, mais il peut y avoir des cas où ils ne le sont pas. Le miroir fournit une vue (sous forme de site Web) dans une table BGP d'un routeur particulier dans le réseau d'un opérateur. Souvent, les implémentations de type miroir comprendront également d'autres utilitaires, tels que la possibilité d'exécuter un traceroute vers une destination comme s'il était exécuté à partir du routeur de l'opérateur réseau lui-même. Les miroirs sont utiles car ils fournissent une perspective sur la table BGP en amont. Level3, un transporteur de premier rang bien connu aux États-Unis, a un miroir disponible ici. Ce sont des outils de dépannage largement utilisés.
Le terme "serveur de routage" a évolué pour signifier deux choses différentes, qui seront toutes deux expliquées. Je définis ici deux "sous-types" de serveurs de routage qui devraient rendre la distinction plus claire. Ces définitions sont les miennes et ne sont utilisées que pour essayer de dissiper toute confusion possible. En réalité, le serveur de routes publiques est aussi communément appelé «collecteur de routes» ou «serveur de vues de routes» (ce dernier provenant du projet Route Views de l' Université de l'Oregon ).
Ce sont des systèmes (généralement des routeurs, mais certains existent qui exécutent des démons de routage open source) qui sont accessibles au public, souvent via Telnet, et on peut également exécuter des pings, des traceroutes et "show ip bgp" (il y a aussi quelques Juniper routez les serveurs, ne vous inquiétez pas!). La différence entre un serveur de route public et un miroir (à part un LG ayant un CGI astucieux) est qu’une grande variété de réseaux (y compris certains opérateurs de niveau 1) sont homologues avec un serveur de route, donc il y a une image plus globale "globale" de quels préfixes proviennent de quels ASN. La politique d'autorisation de commande variera d'un serveur de routage à un serveur de routage. Voici une liste de serveurs de routage IPv4 . Ils ont également une page séparée avec les serveurs de routage IPv6.serveur de routage , on peut considérer le miroir comme une interface avec un serveur de routage, que le serveur de routage lui-même soit accessible publiquement ou en privé.
Vous ne pouvez pas exécuter un miroir sur un serveur de route public?
Vous pouvez le faire, mais généralement les personnes qui gèrent des lunettes sont celles qui peuvent se permettre d'exploiter et d'entretenir les serveurs sur lesquels ces lunettes fonctionnent. Avec un serveur de route public, tout ce dont vous avez besoin est un routeur (ou un serveur exécutant un démon de routage open source), une bonne politique AAA et certaines personnes qui sont disposées à vous fournir des flux BGP. Il est également pertinent de noter que certains opérateurs de réseau hébergent également des serveurs de routage accessibles au public, et vous pouvez même rencontrer des opérateurs qui exécutent un serveur de routage en plus d'un miroir.
Cette version du serveur de route est un peu différente. Sur les tissus de peering partagés chez IXP, la barrière d'entrée pour une organisation pour commencer le peering est plus faible. Vous avez un seul port (que l'IXP vous vend) connecté au LAN homologue IXP et vous obtenez une adresse IP par l'IXP. Vous pouvez maintenant regarder avec n'importe qui d'autre sur le tissu; contrastez cela avec un PNI, qui implique une connexion physique dédiée distincte entre vous et une autre entité. Avec une connexion au LAN d'appairage d'un IXP, en plus de votre port unique étant le goulot d'étranglement, vous devez configurer manuellement les sessions eBGP avec qui vous souhaitez pairer. C'est ce qu'on appelle l' interconnexion bilatérale- il y a une session entre vous et le pair, et seulement vous et les annonces d'échange de pairs. Si l'IXP compte de nombreux membres, cela peut devenir lourd. Dans ce cas, un serveur de routage est généralement déployé sur l'IXP afin d'être le "guichet unique" pour une organisation avec laquelle configurer une session eBGP afin de recevoir des préfixes de la part de qui d'autre est pairé avec le serveur de routage. C'est ce qu'on appelle l' interconnexion multilatérale . Une session BGP entre vous et le serveur de routage, et vous obtenez les annonces de tous les autres qui sont également homologues avec le serveur de routage.
Certaines organisations s'appuieront sur les sessions eBGP du serveur de routage, tandis que d'autres l'utiliseront comme sauvegarde de leurs homologues eBGP existantes sur la structure IXP. La plupart des IXP auront des serveurs de routage redondants et suggèrent que les organisations se lient aux deux si elles se connectent aux serveurs de routage.
Le peering multilatéral utilisant des serveurs de routage pose des défis intéressants en ce qui concerne BGP. Un serveur de routage lui-même est un haut-parleur eBGP, mais il doit y avoir des considérations spécifiques pour un serveur de routage et une homologation BGP multilatérale. Certaines de ces règles rappelleront la réflexion de l'itinéraire iBGP, et il existe en effet de nombreuses similitudes. Il y a eu des travaux récents pour normaliser les comportements d'un serveur de routage en ce qui concerne ces fonctionnalités spécifiques. Les mises en garde suivantes méritent d'être notées ici:
Il est important de se rappeler deux distinctions en ce qui concerne l'implémentation du serveur de routage IXP:
En règle générale, les opérateurs IXP déploieront des démons de routage open source comme serveurs de routage. Il existe trois options populaires:
Quagga, spécifiquement bgpd . Fonctionne sur Linux et BSD. Il existe depuis plus longtemps et possède probablement le plus d'informations disponibles. Il y a eu plusieurs fourches de Quagga au fil des ans, y compris un train avec le développement sponsorisé par EuroIX , un train développé par le groupe de routage Open Source (qui vise davantage à améliorer la fonctionnalité IGP avec OSPF et ISIS), et le Quagga-RE (Release Engineering) qui possède des caractéristiques expérimentales. Google a également créé sa propre fourchette de Quagga. Quagga bgpd prend en charge à la fois IPv6 et IPv4, cependant la plupart des opérateurs IXP (et même certains responsables de Quagga) déconseilleront d'utiliser le train Quagga "principal" pour exploiter un serveur de route sur un IXP.
OISEAU . Fonctionne sur Linux et BSD. BIRD a gagné un peu de popularité en raison de sa stabilité et de son puissant langage de filtrage et de ses capacités, en plus de son très bon système de planification. Il y a eu quelques comparaisons et tests d'échelle publiés entre Quagga et BIRD. Dans l'ensemble, BIRD a tendance à être plus stable et n'est pas aussi sensible au taux de désabonnement du processeur et de la mémoire que Quagga. Cependant, BIRD et Quagga sont à un seul fil, mais c'est intentionnel. De plus, bien que BIRD prenne en charge IPv4 et IPv6, il nécessite deux processus différents (binaires compilés) pour IPv4 et IPv6.
OpenBGPD . BSD uniquement . OpenBGPD est le seul démon BGP open source multithread disponible. Il est connu pour être assez stable sous charge, mais le support TCP MD5 est quelque peu médiocre.
En plus des démons open source, Cisco propose également une implémentation de serveur de routage pour IOS-XE , qui s'exécute sur la plate-forme ASR. Au moment d'écrire ces lignes, Juniper ne propose pas d'implémentation de serveur de routage sur leur matériel ou système d'exploitation, mais cela pourrait changer à l'avenir.
En termes d'évaluation d'un démon de routage open source, en ce qui concerne la gestion et l'architecture de la mémoire, on peut supposer en toute sécurité que BIRD> OpenBGPD> Quagga, mais la plate-forme ASR et IOS-XE seraient également beaucoup plus capables à l'échelle par rapport à l'open options de démon source disponibles.
J'espère que cela jette un peu de lumière sur les serveurs de route / les lunettes en général.