He escuchado el término "servidor de ruta" y "espejo" por aquí. ¿Qué son y por qué debería importarme?
(Tenga en cuenta que estos dos términos a menudo se usan indistintamente, lo que puede generar cierta confusión).
Un espejo generalmente es un sitio web (generalmente CGI) que interactúa con enrutadores que son propiedad y están operados por un solo ISP u otro operador de red. La mayoría de las veces estos son de acceso público, pero puede haber casos en los que no lo sean. El espejo proporciona una vista (en forma de sitio web) en una tabla BGP de un enrutador particular en la red de un operador. A menudo, las implementaciones de espejo también incluirán otras utilidades, como la capacidad de ejecutar un traceroute a un destino como si se ejecutara desde el enrutador del operador de red. Los espejos son útiles porque proporcionan una perspectiva de la tabla BGP de una cadena ascendente. Level3, un conocido operador de primer nivel en los EE. UU. Tiene un espejo disponible aquí. Estas son herramientas de solución de problemas ampliamente utilizadas.
El término "servidor de ruta" ha evolucionado para significar dos cosas diferentes, las cuales serán explicadas. Aquí estoy definiendo dos "subtipos" de servidor de ruta que deberían aclarar más la distinción. Estas definiciones son mías y solo se usan para tratar de disipar cualquier posible confusión. En realidad, el servidor de ruta público también se conoce comúnmente como un "recopilador de ruta" o un "servidor de vistas de ruta" (este último originario del Proyecto de Vistas de Ruta de la Universidad de Oregon ).
Estos son sistemas (generalmente enrutadores, pero existen algunos que ejecutan demonios de enrutamiento de código abierto) que son de acceso público, a menudo a través de Telnet, y uno también puede ejecutar pings, traceroutes y "show ip bgp" (también hay un par de enebros enrutar servidores por ahí, ¡no te preocupes!) comandos. La diferencia entre un servidor de ruta público y un espejo (aparte de un LG que tiene un CGI ingenioso) es que una amplia variedad de redes (incluidas algunas operadoras de nivel uno) se emparejan con un servidor de ruta, por lo que hay una imagen más amplia "general" de qué prefijos provienen de qué ASN. La política de autorización de comandos variará de un servidor de ruta a otro. Aquí hay una lista de servidores de ruta IPv4 . También tienen una página separada con servidores de ruta IPv6.servidor de ruta , uno puede pensar en el espejo como una interfaz para un servidor de ruta, ya sea que el servidor de ruta sea de acceso público o privado.
¿No puede ejecutar un espejo en un servidor de ruta pública?
Puede hacerlo, pero generalmente las personas que usan espejos son las que pueden permitirse operar y mantener los servidores en los que funcionan los espejos. Con un servidor de ruta pública, todo lo que necesita es un enrutador (o un servidor que ejecute un daemon de enrutamiento de código abierto), una buena política AAA y algunas personas que estén dispuestas a proporcionarle información de BGP. También es importante tener en cuenta que algunos operadores de red también alojan servidores de ruta de acceso público, e incluso puede encontrar algunos operadores que ejecutan un servidor de ruta además de un espejo.
Esta versión del servidor de ruta es un poco diferente. En las telas de emparejamiento compartidas en IXP, la barrera de entrada para que una organización comience a emparejar es menor. Tiene un solo puerto (que el IXP le vende) conectado a la LAN de interconexión IXP, y el IXP le da una dirección IP. Ahora puedes ver a alguien más en la tela; contraste esto con un PNI, que implica una conexión física dedicada separada entre usted y otra entidad. Con una conexión a una LAN de emparejamiento de IXP, además de que su único puerto es el cuello de botella, debe configurar manualmente las sesiones de eBGP con quien quiera emparejar. Esto se llama interconexión bilateral.- hay una sesión entre usted y el par, y solo usted y los anuncios de intercambio de pares. Si el IXP tiene muchos miembros, esto puede volverse engorroso. En este caso, un servidor de ruta generalmente se implementa en el IXP para que sea la "ventanilla única" para que una organización configure una sesión eBGP con el fin de recibir los prefijos de cualquier otra persona que esté emparejada con el servidor de ruta. Esto se llama interconexión multilateral . Una sesión de BGP entre usted y el servidor de ruta, y obtiene los anuncios de todos los demás que también se relacionan con el servidor de ruta.
Algunas organizaciones se basarán en la (s) sesión (es) de eBGP del servidor de ruta, mientras que otras lo usarán como respaldo de sus pares eBGP existentes en la estructura IXP. La mayoría de los IXP tendrán servidores de ruta redundantes y sugerirán que las organizaciones se relacionen con ambos si se relacionan con los servidores de ruta.
El emparejamiento multilateral con servidores de ruta presenta desafíos interesantes en lo que respecta a BGP. Un servidor de ruta en sí mismo es un orador de eBGP, sin embargo, debe haber consideraciones específicas para un servidor de ruta y un par de BGP multilateral. Algunas de estas reglas recordarán la reflexión de ruta iBGP, y de hecho hay muchas similitudes. Ha habido un trabajo reciente para estandarizar los comportamientos de un servidor de ruta cuando se trata de estas características específicas. Vale la pena señalar las siguientes advertencias aquí:
Es importante recordar dos distinciones con respecto a la implementación del servidor de ruta IXP:
Normalmente, los operadores IXP implementarán demonios de enrutamiento de código abierto como servidores de ruta. Hay tres opciones populares:
Quagga, específicamente bgpd . Se ejecuta en Linux y BSD. Ha sido el más largo y probablemente tiene la mayor cantidad de información disponible. Ha habido múltiples tenedores de Quagga a lo largo de los años, incluido un tren con desarrollo patrocinado por EuroIX , un tren desarrollado por el grupo Open Source Routing (que tiene como objetivo mejorar la funcionalidad de IGP con OSPF e ISIS), y Quagga-RE (Release Ingeniería) tren que tiene características experimentales. Google también ha creado su propio tenedor de Quagga. Quagga bgpd es compatible con IPv6 e IPv4, sin embargo, la mayoría de los operadores IXP (e incluso algunos mantenedores de Quagga) desaconsejan el uso del tren Quagga "principal" para operar un servidor de ruta en un IXP.
AVE . Se ejecuta en Linux y BSD. BIRD ha ganado bastante popularidad debido a su estabilidad y su potente lenguaje y capacidades de filtrado, además de su muy buen sistema de programación. Ha habido un par de comparaciones publicadas y pruebas de escala entre Quagga y BIRD. En general, BIRD tiende a ser más estable y no es tan susceptible a la CPU y la pérdida de memoria como lo es Quagga. Sin embargo, tanto BIRD como Quagga son de un solo subproceso, pero esto es intencional. Además, aunque BIRD admite IPv4 e IPv6, requiere dos procesos diferentes (binarios compilados) para IPv4 e IPv6.
OpenBGPD . BSD solamente . OpenBGPD es el único demonio BGP de código abierto multihilo disponible. Se sabe que es bastante estable bajo carga, sin embargo, el soporte TCP MD5 es algo pobre.
Además de los demonios de código abierto, Cisco también ofrece una implementación de servidor de ruta para IOS-XE , que se ejecuta en la plataforma ASR. Al momento de escribir esto, Juniper no ofrece una implementación de servidor de ruta en su hardware o sistema operativo, pero esto puede cambiar en el futuro.
En términos de evaluación de un demonio de enrutamiento de código abierto, en lo que respecta al manejo de la memoria y la arquitectura, uno puede asumir con seguridad que BIRD> OpenBGPD> Quagga, sin embargo, la plataforma ASR y IOS-XE también son mucho más capaces a escala en comparación con el abierto Opciones de daemon fuente disponibles.
Espero que esto arroje algo de luz sobre los servidores de ruta / lentes en general.