ON THIS PAGE
Introducción a punto de intercambio de Internet
Un punto de intercambio de Internet (IXP) es una red de capa 2, por ejemplo, un servicio basado en la capa 2 MPLS, como VPLS o EVPN, que facilita la interconexión entre proveedores de servicios de Internet (ISP) utilizando el protocolo de Protocolo de puerta de enlace de borde (BGP) para el enrutamiento de Exchange información.
En esencia, un IXP es esencialmente una o más ubicaciones físicas que contienen conmutadores interconectados que mueven el tráfico entre las diferentes redes conectadas (generalmente se denominan miembros en un contexto IXP). Se hace referencia a la red como la LAN IXP LAN o de emparejamiento. Consulte Figure 1la.
Los miembros comparten los costos de mantener la infraestructura física y los servicios asociados mediante varios sistemas de carga, pero en casi todos los casos los costos de suscripción son una cuota mensual fija, en función de la velocidad del puerto y el número de puertos que utiliza un miembro.
El intercambio de tráfico entre dos miembros de una IXP es fácil gracias a la BGP configuraciones de enrutamiento entre ellos (sesión de interconexión). Los miembros optan por anunciar las rutas a través – de la relación de interconexión o bien se dirigen a sus propias direcciones, o bien, rutas a direcciones de otras redes a las que se conectan (por ejemplo, clientes).
La otra parte de la relación de interconexión a nivel puede aplicar el filtrado de rutas, donde decide aceptar esas rutas y enrutar el tráfico en consecuencia, o bien omitir las rutas y usar otras rutas para llegar a esas direcciones.
Las rutas a anunciar, o avisos que se aceptan o filtran de un miembro, se describen con mayor detalle en el primer día: Implementación de la seguridadde enrutamiento de BGP (consulte: https://www.juniper.net/us/en/training/jnbooks/day-one/deploying-bgp-routing-security/).
La economía de un punto de intercambio de Internet
Puede decir que el objetivo de IXP es reducir la parte de tráfico que un ISP entregará a través de sus proveedores de tránsito ascendente, por lo que, entre otras cosas, puede reducir el costo promedio de entrega por bit del tráfico. Además, el aumento del número de paths disponibles mejora la eficacia de enrutamiento y la tolerancia a errores. Además, y otras veces lo más importante, los objetivos podrían ser reducir la latencia, proporcionar rutas de red más cortas, y aumentar o proporcionar redundancia.
IXPs muestran las características de lo que Economists llamar al efecto de externalización de red (https://en.wikipedia.org/wiki/Network_effect) o, el valor del producto o servicio es proporcional al número de usuarios del producto o servicio. Los intercambios de Internet son un caso especial de este efecto; el valor de un punto de intercambio no es únicamente el número de participantes, sino un cálculo ligeramente más complejo, en el que se incluye el número y la exclusividad de las rutas y el volumen del tráfico de igual nivel. Dado que el valor de IXP a un ISP es proporcional a la cantidad de tráfico que el ISP puede intercambiar en relaciones de emparejamiento en el IXP, el valor de IXP para el rellenador de emparejamiento sigue el gráfico de externalización de Figure 2red tal y como se muestra en la.
Figure 2. ilustra un trazado del valor de IXP (VCAP) como una función del número de participantes. A medida que más participantes se conectan al punto de Exchange, más participantes pueden ser interlocutores entre sí. Desde el punto de vista de los participantes, el valor del punto de intercambio aumenta con cada uno de los interlocutores potenciales.
Relaciones de intercambio de tráfico
Mientras que las sesiones de emparejamiento bilateral (negociadas y establecidas entre dos miembros exactamente) eran anteriormente las formas más comunes de intercambiar rutas, la sobrecarga asociada a una interconexión densa puede ocasionar problemas de escalabilidad operativos importantes para miembros de IXPS mayores.
Interconexión multilateral es un método para interconectar miembros mediante un “” sistema externo de intermediario, al que se suele hacer referencia como servidor de enrutamiento y que normalmente se administra mediante IXP. Cada participante multilateral de interconexión (denominado cliente de servidor de enrutamiento) anuncia sus rutas al servidor de enrutamiento mediante protocolo de puerta de enlace de borde externos (EBGP). El servidor de enrutamiento, a su vez, reenvía de manera transparente esta información a cada cliente de servidor de enrutamiento que esté conectado a la misma.
¿Qué es un servidor de enrutamiento?
La barrera de entrada de una organización para convertirse en miembro y comenzar el emparejamiento de un IXP suele ser bastante baja. Se necesita al menos un único puerto físico o remoto (retorno) conectado a la LAN de emparejamiento de IXP y una dirección IP asignada de la subred LAN IX. A continuación, es posible configurar BGP emparejamiento con cualquier otro usuario de la LAN de emparejamiento que esté dispuesta a los interlocutores.
Para ello, debe configurar manualmente estas sesiones de interconexión BGP con quien desee. Esto se denomina interconexión bilateral, lo que significa que hay una sesión entre usted y el interlocutor, y solo usted y los anuncios de ruta de intercambios de homólogos específicos.
Imagine un gran IXP con varios (100 +) miembros. Esto puede llegar a ser engorroso de una manera muy rápida. En particular, al filtrar por interlocutor en los anuncios de ruta correctos (por ejemplo, en función de un registro de enrutamiento de Internet: https://en.wikipedia.org/wiki/Internet_Routing_Registry), prefijos, as-Path, etc., que debe hacer. Es un no más detratante usar una solución más fácil cuando hay una disponible.
Para evitar la configuración y el mantenimiento de 10s o 100S (algunos de los IXPs de mayor tamaño tienen más de 500 miembros o miembros con varias conexiones) de sesiones EBGP individuales con cada miembro, la opción más inteligente donde solo se necesitan un par de sesiones, consiste en utilizar los servidores de enrutamiento. Los servidores de enrutamiento generalmente son ofrecidos por IXP como servicio a sus miembros.
Una BGP sesión entre el enrutador del ISP’y el servidor de enrutamiento es la que se requiere para anunciar y recibir rutas de todos los demás miembros de IXP (como se muestra Figure 4en). Obviamente, solo podrá intercambiar información de enrutamiento con miembros que tengan una sesión BGP con los servidores de enrutamiento. Por lo tanto, proporciona una alternativa a un emparejamiento completo de la malla entre los miembros que tienen una presencia en IXP.
Algunos ISP se basarán únicamente en las sesiones del servidor de enrutamiento, mientras que otras lo usarán como backup en sus EBGP existentes en la estructura IXP. La mayoría de los IXPs tendrán servidores de enrutamiento redundantes y sugerimos que los miembros del mismo nivel con ambos.
El emparejamiento de los servidores’de enrutamiento IXP s podría ofrecer ventajas adicionales a los miembros, como las comunidades para filtrar. Por ejemplo, su país de origen o el centro de datos de origen.
El servidor de enrutamiento proporciona:
EBGP el reflejo de ruta con soporte de políticas personalizadas para cada proveedor de servicios en IXP.
Reducción de la complejidad de la configuración (de este modo, mantener solo unas pocas sesiones BGP en lugar de centenares).
Los requisitos de CPU y memoria reducidos en cada enrutador miembro; seguirá recibiendo todos los prefijos, pero ganará’la necesidad de todas las sesiones de interconexión a varios BGP independientes.
Reducción de gastos generales administrativos incurridos por acuerdos de interconexión individualizados.
Opciones adicionales de filtro (IRRdb, RPKI, predefinidas BGP las comunidades) sin necesidad de implementarlas usted mismo.
Capacidad para enviar y recibir tráfico a través de IXP desde el primer día (no es necesario esperar a que estén organizados todos los interlocutores individuales).
Una posible ruta de copia de seguridad; Cuando la sesión de BGP a otro miembro quede inactiva, existe la posibilidad de que pueda seguir llegando a la red de los miembros mediante las rutas aprendidas desde los servidores de enrutamiento.
El propio servidor de enrutamiento no participa en el reenvío de tráfico real, sino que sólo proporciona información de enrutador (como rutas de, rutas, comunidades, próximos saltos, etc.). Desde esa perspectiva, dado que no se necesita hardware de reenvío, un servidor de enrutamiento puede ser fácilmente una máquina virtual (VM) o un contenedor en lugar de un cuadro físico. Además, el emparejamiento con un servidor de enrutamiento no significa que tenga que aceptar todas las rutas de todos los demás participantes del servidor de enrutamiento o que haya anunciado todas las rutas a todos los demás miembros. ¿Cómo lo configuro? Leer en…
Base de información de enrutamiento de BGP (RIB)
A lo largo de este libro se mencionan diferentes tipos de bases de información de enrutamiento (costillas). Este párrafo lo prepara para los usuarios. En general, una costilla incluye la información de enrutamiento, pero hay tres costillas dentro de una anunciador BGP relevantes:
Ajuste de la costilla.: Almacena información de enrutamiento aprendida de mensajes de actualización de BGP entrantes. Contiene rutas que se encuentran disponibles como entrada para el BGP proceso de toma de decisiones.
Loc-RIB: Contiene información de enrutamiento después de aplicar las directivas de importación a la información de enrutamiento almacenada en las costillas.
Salida de ajust: Almacena en los pares la información que se selecciona para el anuncio. La información de enrutamiento almacenada en las COSTILLAs-out se utilizará en los mensajes de actualización de salida y se anunciará a sus iguales.
En Resumen, el ajuste de la RIB contiene información de enrutamiento sin procesar que se ha recibido de los homólogos. Loc-RIB contiene las rutas seleccionadas por el proceso de toma de decisiones’local anunciador BGP s, y la costilla-out contiene las rutas para el anuncio a los interlocutores específicos mediante mensajes de actualización.
Redondear reflector frente a servidor de enrutamiento frente a recopilador de ruta
Solo para mayor claridad y para asegurarse de que se encuentra en la misma página que en este manual, deje que’se defina un reflector de ruta, un servidor de rutas y un selector de ruta. La diferencia principal entre los reflectores de ruta y los servidores de enrutamiento radica en la semántica IBGP de los reflectores de ruta frente a la semántica de EBGP necesaria para los servidores de enrutamiento. El selector de ruta es un caso único.
Route Reflector
Un reflector de ruta se utiliza con frecuencia para eliminar la necesidad de una malla completa de sesiones entre los altavoces IBGP. El reflector de enrutamiento debe saber cuándo reflejar un anuncio’del mismo nivel con otro igual con el fin de preservar la semántica IBGP. El reflector envía la mejor ruta en su ubicación a todos los clientes (excepto en la que aprendió las rutas). El reflector de ruta no suele modificar los atributos, a menos que se indique estableciendo la next-hop-self Directiva configurada local, pero que es el comportamiento predeterminado de IBGP.
Route Server
Un servidor de rutas desempeña un papel similar, de forma transparente (los atributos no se modifican), pero en este caso para altavoces EBGP, debe ser capaz de suprimir su propio ASN (posiblemente privado) precedido a las rutas anunciadas.
También mantiene un nervio exclusivo para cada uno de sus clientes (por nervio de cliente), cuya política específica de ese cliente puede aplicarse. El cliente obtiene las actualizaciones de ese nervio, no de la ubicación global.
Route Collector
El extraño de nuestro mitad es el selector Route, ya que no reenvía paquetes y tampoco anuncia prefijos a nadie. Su propósito, como su nombre es más o menos revela, es recopilar información de enrutamiento. Al hacerlo, el selector de ruta y sus herramientas de accesorios actúan como un vidrio de aspecto (en la mayoría de los casos), una ‘vista pública’ de la ‘información de enrutamiento conocida en’un punto de la red. En un contexto IXP, la información proporcionada por un recopilador de rutas proporcionaría información útil para:
Miembros de IXP para comprobar la funcionalidad de filtros BGPs
Posibles miembros para evaluar el valor de unirse al IXP
La comunidad de operaciones con fines de solución de problemas.
En el futuro, cubrimos los servidores de enrutamiento de este libro.
Transparencia de atributo de servidor de enrutamiento
Como un servidor de enrutamiento realiza principalmente un servicio de intermediario, la modificación de atributos podría hacer que los clientes de servidores de enrutamiento modificaran su BGP proceso de toma de decisiones para obtener información de accesibilidad de prefijos recibidas, lo que cambiará las políticas de enrutamiento previstas de Exchange demás. (Consulte el Juniper TechLibrary para obtener más detalles: https://www.Juniper.net/Documentation/en_US/Junos/topics/Reference/general/Routing-Protocols-Address-Representation.html.)
En oposición a las reglas ordinarias de manejo de rutas EBGP, los servidores de enrutamiento no actualizan de forma predeterminada los atributos BGP conocidos, (a menos que se configuren explícitamente) (https://ftp.APNIC.net/APNIC/Training/eLearningHandouts/2017/20171025/eROU04_BGP_Attributes.pdf
Next_Hop atributo
AS_Path atributo
Multi_Exit_Descriminator
Comunitarios
Ruta de acceso ocultar mitigación en implementaciones de servidor de rutas
En el modelo tradicional de interconexión bilateral, el control de la Directiva por cliente de un participante de otro fabricante de Exchange se consigue al no participar en una interconexión bilateral con dicho participante o implementar el filtrado de salida en el BGP sesión hacia ese participante. Sin embargo, en un entorno multilateral de interconexión, sólo el servidor de enrutamiento puede realizar el filtrado de salida en la dirección del cliente del servidor de enrutamiento; los clientes de servidores de enrutamiento dependen del servidor de enrutamiento para que realicen el filtrado saliente para ellos.
Suponiendo que se siga el proceso de decisión predeterminado BGP, cuando se anuncie el mismo prefijo a un servidor de enrutamiento desde varios clientes de servidor de enrutamiento, el servidor de enrutamiento seleccionará una ruta de acceso única para la propagación a todos los clientes conectados. Sin embargo, si el servidor de enrutamiento se ha configurado para filtrar la mejor ruta de acceso calculada para que no llegue a un cliente de servidor de enrutamiento determinado, dicho cliente no recibirá una ruta de acceso para ese prefijo, aunque es posible que haya haber sido directiva la que reciben las rutas alternativas compatible para ese cliente. Este fenómeno se denomina ocultación de rutas de acceso.
Con el ejemplo mostrado en Figure 5, enrutadores de cuatro clientes, representados por C [1-4] en cuatro BGP diferentes sistemas autónomos (as) de Exchange. C1 en AS64496 no cambia directamente la información de prefijo con C2 en AS644967, o C3 en AS64498 en IXP, pero solo interconexiones con C4 en AS64499. Las líneas entre AS64496, AS64497, AS64498 y AS64499 representan relaciones de interconexión, ya sea mediante sesiones EBGP directas (bilaterales) o mediante el servidor de enrutamiento (multilateral).
’Supongamos que se anuncia un prefijo a los servidores de enrutamiento desde AS64497 y AS64499, y que la ruta a través de AS64497 era la preferida de acuerdo con el BGP proceso de toma de decisiones en el servidor de enrutamiento. Todos serían correctos y el prefijo es alcanzable. La excepción se produce cuando’la Directiva AS64497 s impide que el servidor de rutas envíe la ruta a AS64496, por lo que AS64496 nunca recibirá una ruta de acceso a este prefijo, aunque el servidor de enrutamiento también haya recibido una ruta alternativa válida a través de AS64499. Esto sucede porque el BGP proceso de decisión se realiza una sola vez en el servidor de enrutamiento para todos los clientes
Aunque hay varias opciones disponibles para mitigar la ocultación de rutas de acceso (https://Tools.ietf.org/html/rfc7947#section-2.3.2) en los entornos de servidor de enrutamiento, Junos os emplea varias costillas del cliente de servidor (vea Figure 6 y https://Tools.ietf.org/html/rfc7947#section-2.3.2.1). La implementación del servidor de enrutamiento de Juniper BGP realiza el mejor cálculo de la ruta de acceso por cliente para cada conjunto de rutas hacia un prefijo, mediante las costillas por cliente, con el filtrado de ruta implementado entre la función de ajuste de variable y el valor de in-out por cliente. Más adelante, en este mismo libro, se proporcionan más detalles a este respecto.
Arquitectura de una implementación de servidor de enrutamiento
Esta sección proporciona algunas ideas conceptuales sobre cómo configurar y operar servidores de enrutamiento en un entorno IXP.
Por directiva de cliente de servidor de enrutamiento mediante el uso de comunidades de BGP
El control de políticas se controla normalmente mediante el uso de comunidades de BGP. Los prefijos enviados al servidor de enrutamiento se etiquetan con atributos Standard BGP Communities (https://Tools.ietf.org/html/RFC1997), comunidades extendidas (https://Tools.ietf.org/html/rfc4360) o comunidades grandes (https://Tools.ietf.org/html/rfc8092) específicos, basados en los valores predefinidos acordados entre el IXP y todos los miembros de IXP. En la actualidad, no se contratan mutuamente los estándares de IXPs para uso de la comunidad, aunque se ha hecho algún trabajo para definir un estándar, por ejemplo: https://tools.ietf.org/html/draft-adkp-grow-ixpcommunities-00.
En este caso, utilizamos comunidades estándar con el fin de explicarlos. El uso de comunidades ampliadas o grandes puede tener ventajas.
Las rutas BGP se pueden propagar a todos los demás clientes, un subconjunto de clientes o ningún cliente, en función de los valores de las comunidades. Este mecanismo permite a los clientes de servidor de enrutamiento instruir al servidor de enrutamiento para que implemente políticas de enrutamiento de exportación por cliente. A modo de ejemplo, los miembros de IXP pueden etiquetar sus rutas Table 1 con las que se muestran en para controlar la Directiva a través del servidor de enrutamiento.
Table 1: Ejemplo de comunidades de BGP estándar para controlar la Directiva por cliente
Descripción de la Directiva | BGP comunidad |
|---|---|
Notificación de bloque de una ruta a cierto interlocutor | 0:<peer-as> |
Anuncio de una ruta a un determinado interlocutor | < RS-as >: < peer-as > |
Bloquear el anuncio de una ruta a todos los homólogos | 0:<rs-as> |
Anuncio de una ruta a todos los homólogos | < RS-as >: < RS-as > |
Redundancia
El propósito de una implementación de servidor de enrutamiento IXP es proporcionar un servicio de intermediabilidad de accesibilidad confiable, por lo que los operadores IXP Figure 7generalmente implementan varios servidores de enrutamiento (consulte).
Puede ser una buena idea anunciar las rutas entre los servidores de enrutamiento para garantizar la accesibilidad incluso si las sesiones BGP están inactivas para enrutadores de miembro IXP específicos en servidores de rutas específicos, pero no para otras. Aunque es probable que este evento sea bastante raro,’vale la pena considerarlo al ofrecer un servicio basado en servidor de enrutamiento.
Sin embargo, las implementaciones de servidor de rutas redundantes de este estilo pueden producir un poco más de complejidad en términos de administración de sesión entre servidores de enrutamiento, así como directivas de importación/exportación de instancias asociadas con Junos OS técnicas de mitigación de rutas de acceso. En Figure 7, el lado derecho representa esta complejidad adicional en forma de instancia de enrutamiento de no reenvío (NFRI) BGP sesiones y políticas. Por lo tanto, debe evaluarse detenidamente. La mayoría de los IXPs utilizan un conjunto de dos servidores de enrutamiento independientes, ya que esto parece tener como resultado un equilibrio óptimo entre la redundancia y la complejidad.
Consideraciones de seguridad del servidor de enrutamiento
Las siguientes recomendaciones de EBGP básicas son para sus consideraciones de seguridad.
Generalized TTL Security Mechanism (RFC3682)
GTSM está diseñado para proteger un plano’de control s de enrutador de ataques basados en la CPU. GTSM se basa en el hecho de que la inmensa mayoría de protocolos del mismo nivel se establecen entre enrutadores adyacentes, como en el caso de EBGP interlocutores en una LAN IX. Dado que la suplantación de TTL se considera casi imposible, un mecanismo basado en un valor TTL esperado puede proporcionar una defensa sencilla y razonablemente sólida de los ataques de infraestructura basados en paquetes de protocolo falsificados externos a la red.
Session Authentication (RFC2385)
Una red LAN de emparejamiento IXP típica está formada por varios conmutadores que forman una estructura grande de capa 2. La desventaja de esta arquitectura es que es bastante fácil secuestrar ‘’ a otros miembros’BGP sesión mediante suplantación en Mac o direcciones IP. Esto’es una buena práctica para que IXP implemente filtros en puertos de acceso, por ejemplo, para restringir un miembro a usar solo un dirección Mac específico.
Securing BGP Sessions (MD5/TCP-AO)
La protección de la propia sesión de BGP se considera un nivel adicional de seguridad, asegurándose de que usted se pone a su punto con quién piensa que está interconexión.
MD5 es una extensión TCP para mejorar la seguridad de BGP. Define una nueva opción de TCP para transportar un resumen MD5 (https://Tools.ietf.org/html/rfc1321) en un segmento TCP. Este compendio actúa como una firma para ese segmento, incorporando la información que sólo conocen los puntos finales de conexión (del mismo nivel). Dado que BGP utiliza TCP como transporte, el uso de MD5 reduce significativamente el peligro de ciertos ataques de seguridad en BGP.
Sin embargo, en 1996 se encontró un error en el diseño de MD5, y en 2004 se mostró que MD5 no es resistente a los colisiones. Por lo tanto, MD5 no se considera adecuado, ya que está en desuso y no es seguro (https://en.wikipedia.org/wiki/MD5#Security), pero se sigue usando ampliamente. Hoy en día existen mejores alternativas disponibles, por ejemplo, la opción de autenticación de TCP (RFC5925; https://Tools.ietf.org/html/rfc5925). Desafortunadamente, esto no lo han llevado a cabo muchos proveedores de red, hasta ahora.
Maximum Prefix Limits
El establecimiento de un límite en el número de prefijos aceptados de un homólogo es una de las operaciones más sencillas que se pueden llevar a cabo para proteger el servidor de enrutamiento para que no se sobrecargue intencionada o accidentalmente debido a errores de directivas o enrutamiento por parte de los IX miembros. El objetivo de este límite es servir como un último error a la seguridad. Si se produce un error en una política de importación, al desconectar la sesión de EBGP, se “enviará una alerta de que ha sucedido algo incorrecto” .
Existen varias escuelas de pensar en definir cuál debe ser el “número máximo” de prefijos. ¿Se trata de la cantidad máxima de prefijos recibidos, antes de importar políticas o BGP best-path se realiza, o es el número máximo de prefijos aceptados después de aplicar la Directiva de importación y una BGP best-path ¿se calcula?
Además, hay varias recomendaciones para lo que debería ser el valor máximo, por ejemplo, el diez por ciento del número de prefijos que se espera de un enrutador de miembro IX es’el mismo. El problema es que, cuando se establecen estos límites duros, es fácil olvidarse de que están en su lugar, por lo que, por equivocación, provocan que se restablezcan las sesiones si se produce un salto repentino en los prefijos.
Por lo tanto, el valor máximo debe ser lo suficientemente alto como para evitar que pueda acusarse accidentalmente, pero también lo es lo suficientemente bajo como para no aceptarlo ciegamente y, posiblemente, aceptar de forma accidental una tabla de enrutamiento completa. Algunas sugerencias pueden ser:
Multiplique el número de rutas esperadas y multiplique por 10.
Utilice una escala logarítmica para derivar un límite adecuado.
Aproveche una aplicación o controlador externo para supervisar, aprender y modificar los máximos por sesión. Esta solución se examinará con más detalle en Using a cRPD-based Route Server en el mismo nivel.
Table 2: Ejemplo de valor de prefijo máximo
Número esperado de rutas | Valores máximos de (x10) | Log (n) valores máximos |
|---|---|---|
10 | 100 | 100 |
1,000 | 10,000 | 3,000 |
50,000 | 500,000 | 234,500 |
Aplicación de’filtros de límite máximos de salida no obstante, en la actualidad, es una técnica de uso generalizado, “pero podría ayudar” a evitar “la pérdida de una tabla completa debido a los dedos de grasas.”
Al igual que con el filtrado de entrada, el prefijo “máximo se considera un” último error ‘seguro en caso’ de que el otro lado cometa un error, por lo que puede considerar que esto impide dañar a otros.
En la actualidad, IETF está trabajando en “un borrador llamado” BGP límites máximos de prefijos para normalizar los límites máximos prefijos pre/post en salida: https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/.
Los límites máximos de prefijo, entre otros parámetros, es algo que normalmente desearía automatizar, ya que puede cambiar con rapidez y frecuencia. Por ejemplo, cuando un miembro compra otro miembro o conecta un cliente nuevo a su red, dispone de muchos filtros para actualizar. Es’una buena práctica como red operativa en la zona franca predeterminada (DFZ) (consulte: https://en.wikipedia.org/wiki/default-free_zone) mantener un perfil actualizado de PeeringDB (https://www.peeringdb.com/). Muchas redes ya utilizan la información de PeeringDB para generar automáticamente sus filtros. Aquí se puede encontrar un ejemplo para empezar a usar Python para automatizar partes del proceso de emparejamiento: https://github.com/coloclue/Kees y en https://github.com/coloclue/Kees/BLOB/Master/peering_filters.
Default EBGP Route Propagation Behavior Without Policies (RFC8212)
De forma predeterminada, muchos BGP los altavoces (enrutadores) anuncian y aceptan todos los anuncios de ruta entre sus vecinos. Esta fecha de regreso a los primeros días de Internet, cuando los operadores eran permisivos para enviar información de enrutamiento para permitir que todas las redes llegaran entre sí. A medida que la interconexión de Internet se ha vuelto más densa, la probabilidad de un perdedor anunciador BGP representa riesgos significativos para la tabla de enrutamiento global y también para Internet.
RFC8212 (https://Tools.ietf.org/html/rfc8212 ) resuelve esta situación, ya que requiere la configuración explícita de BGP políticas de importación y exportación para cualquier sesión EBGP, como clientes o colegas. BGP altavoces que siguen esta especificación no utilizan ni envían rutas en sesiones de EBGP a menos que se configuren específicamente para ello. En otras palabras, existe una política en vigor para anunciar de forma explícita información de enrutamiento a un vecino.
Validación de prefijo de cliente por servidor de ruta
Muchas IXPs validan los prefijos en la entrada de todos los servidores de enrutamiento. La validación se basa en la presencia de objetos del registro de Internet Routing (TIR) o de la autorización de objetos de la ruta (ROA). Una lista de ASNs de origen válidos y los prefijos válidos basados en objetos de ruta se construye en forma de listas de filtros de ruta o prefijos con listas de rutas de acceso. A menudo se rechazan anuncios más específicos de rutas válidas debido a la falta de ROAs. Se busca un conjunto de AS definido en los miembros de IXP PeeringDB registro. Si no se encuentra ningún conjunto tal y como, a menudo solo se utiliza ASN del miembro.
Table 3a continuación se muestra un ejemplo del etiquetado estándar en la comunidad de entrada basado en los resultados de la validación de entrada.
Table 3: Ejemplo de etiquetas de entrada estándar basadas en la comunidad
Descripción de la Directiva | BGP comunidad |
|---|---|
El prefijo está presente en’un as s anunciado como/as-set | <rs-as>:650010 |
El prefijo no está presente en’un as s anunciado como/as-set | <rs-as>:650010 |
El prefijo tiene un origen válido como en el valor | <rs-as>:650012 |
El prefijo no tiene un origen válido como en | <rs-as>:650013 |
La validación del prefijo se suele producir, y los miembros de IXP pueden comprobar las comunidades que se establecen en sus prefijos y ver los resultados de las comprobaciones de validación a través de un servidor de rutas o un recolector de rutas que busca un cristal. En el tiempo de salida, se rechazan los prefijos filtrados que no han superado la validación. Algunos IXPs ofrecen a los miembros que prefieren recibir un conjunto de prefijos sin filtrar para no participar en él. Esto no es aconsejable por razones obvias; no’hay una buena razón para conservar la información de enrutamiento no válida en sus tablas de enrutamiento.
Validación de origen para BGP utilizando RPKI
Una parte sustancial de los anuncios de ruta vistos en la tabla de enrutamiento global no es válida o no se encontraron autorizaciones de origen de ruta (ROAs) (https://www.RIPE.net/Manage-IPS-and-ASNs/Resource-Management/certifi-cation/Resource-Roa-management---# de origende enrutamiento-de-RPKI-Authorization--Routing-autorizaciones--ROAS-), tal como se puede ver en este monitoreador del NIST: https://rpki-monitor.antd.nist.gov/. Al escribir este libro a comienzos de junio de 2019, el 0,74% de las rutas no eran válidos y no se encontró el 86,32% del ROAs de la tabla de enrutamiento global. Obviamente, estas cifras tienen que avanzar lo más rápido posible.
El error de enrutamiento más común es la pérdida accidental de ruta debido a un error de la Directiva o un origen indebido de un prefijo (dedos de grasas), lo que significa que alguien anuncia accidentalmente un prefijo IP del que no es propietario o que anuncia una ruta más específica sin un objeto de enrutamiento válido en una base de datos RIR. El último haría que los enrutadores de BGP declararan una ruta “determinada mejor” y prefieren que estuvieran encima de la ruta correcta. Es probable que esto no esté pensado ya que no conduce a la red del verdadero propietario del espacio IP. Como respuesta (parcial) a este problema, la validación de origen, que utiliza la infraestructura de clave pública de recursos (RPKI), ofrece BGP validación de origen. La pregunta a la que intenta responder es: “¿Está autorizado este anuncio de ruta en particular por el titular legítimo del espacio de dirección?”
RPKI permite a los operadores crear declaraciones criptográficamente firmadas acerca de sus anuncios de rutas. Estas instrucciones se denominan autorización de origen de ruta (ROAs). Un ROA Estados que está autorizado a originar (anunciar) un prefijo IP determinado. Además, puede determinar la longitud máxima del prefijo que el AS está autorizado a anunciar. Basándose en esta información, otras redes que han implementado la validación de origen en sus enrutadores pueden, a continuación, validar si los anuncios que reciben son válidos o no válidos, y utilizar esa información para tomar decisiones de enrutamiento.
Además de conectar redes, una IXP tiene la responsabilidad de mantener Internet a salvo y estable. Desde ese punto de vista, la implementación de la validación de origen en los servidores de rutas debe ser un poco decisivo, aunque en qué dirección (entrante o saliente) es conveniente implementar RPKI. Idealmente, la eliminación de anuncios maliciosos se produce cuando entran en la red o, en este caso, en el servidor de enrutamiento. Sin embargo, esto hará que la solución de problemas sea más difícil, ya que no podrá ver qué rutas se anuncian en el servidor de enrutamiento.
Si su cliente quiere usar su cristal de mirar para comprobar si el servidor de enrutamiento ha recibido el prefijo, por ejemplo, no obtendría un resultado cuando se’filtra entre "ADJ-in y Loc-Rib".
Por lo tanto, en la práctica, es posible que desee aceptar los anuncios para especificar las COSTILLAs y filtrarlas cuando inserte-COSTILLAs, para evitar que el servidor de rutas anuncie las rutas no válidas a sus clientes.
La cobertura de RPKI en detalle queda fuera del alcance de este manual. Se trata en gran detalle en el primer día del libro: Implementación de seguridad de enrutamiento de BGP en https://www.Juniper.net/US/en/Training/jnbooks/Day-One/Deploying-BGP-Routing-Security/.
Cómo configurar el enrutador o servidor de enrutamiento de Junos OS para realizar la validación de origen se describe a continuación: https://www.juniper.net/documentation/en_US/Junos/topics/topic-map/bgp-origin-as-validation.html.
Consideraciones de implementación de políticas
Antes de saltarse los detalles de implementación de la Directiva de un’servidor de enrutamiento, merece la pena revisar algunas nascent consideraciones de implementación BGP. Cualquier anunciador BGP Reciba actualizaciones de enrutamiento de otros equipos del mismo nivel procesa la información para su uso local y, a continuación, anuncia las rutas seleccionadas a los distintos interlocutores según las políticas predefinidas. Para que BGP pueda llevar a cabo esta función, almacena esta información en un tipo especial de base de datos denominada base de información BGP enrutamiento.
Una BGP base de información de enrutamiento consta de tres partes:
El ajuste de la costilla.: BGP RIB-en los almacenes BGP información de enrutamiento recibida de los distintos interlocutores. La información almacenada se utiliza como entrada de la BGP proceso de toma de decisiones. En otras palabras, ésta es la información recibida de los interlocutores antes de aplicar cualquier modificación de atributo o de filtrado de ruta.
El rib local: La base de información de enrutamiento local almacena la información de la política post después de procesar la información de nervio. Estas son las rutas que se utilizan localmente después de aplicar las políticas de BGP y el proceso de toma de decisiones.
Las costillas: Este único almacena la información de enrutamiento seleccionada por el enrutador local BGP para anunciarse a sus homólogos a través de mensajes de actualización BGP.
Scaling, Troubleshooting, and Monitoring Considerations proporciona ejemplos detallados de CLI para monitorear cada uno de los tres componentes de BGP costillas.
Este flujo básico de información de enrutamiento, desde el cliente al servidor de enrutamiento y de vuelta al cliente Figure 8, se representa en. La figura también muestra dónde se pueden aplicar políticas específicas para administrar las distintas políticas de la BGP IXP y general descritas.
Las bases de datos descritas aquí no deben confundirse con la tabla de enrutamiento, ya que son sólo las tablas utilizadas por el BGP proceso y nunca por el enrutador para el reenvío de paquetes. Solo el conjunto de rutas que existen en la costilla local se instala en la tabla de enrutamiento basándose en un criterio especificado por el anunciador BGP local (dependiendo de la implementación del proveedor y de la preferencia de los protocolos de enrutamiento).