Implementación del servidor de enrutamiento

Plataformas de servidor de enrutamiento Junos OS

Cualquier Juniper plataforma en la que se ejecute una versión adecuada de Junos puede funcionar como servidor de enrutamiento. Sin embargo, dado que la implementación del servidor de enrutamiento puede mantener un nervio local para cada cliente EBGP, como suele ser el caso, BGP tiende a requerir un poco más de memoria que una implementación normal de BGP. Como resultado, es posible que la capacidad de memoria de un enrutador normal no proporcione una solución escalable.

Figure 1muestra un diagrama de bloques de un enrutador típico de la serie Juniper MX.

Figure 1: Juniper serie MX como servidor de enrutamiento

La capacidad de memoria de un enrutador típico se encuentra a menudo acotada “para” cumplir el rol de implementación de destino de ese enrutador. Por ejemplo, una Juniper serie PTX10000 que actúa como enrutador principal’no tiene el mismo conjunto – de características y, por – lo tanto, los requisitos de memoria como servidor de enrutamiento, y no menciona el hardware adicional en forma de tarjetas de línea y motores de reenvío de paquetes que son necesarios para un enrutador principal.

Reflector de ruta virtual Junos OS (vRR)

El Junos OS reflector virtual de enrutamiento (vRR) permite implementar el Junos OS plano de control utilizando una VM de uso general que puede ejecutarse en un servidor basado en Intel de 64 bits, como la plataforma Juniper NFX o un accesorio como el Juniper JRR200. Un vRR en un servidor o dispositivo basado en Intel funciona igual que un Flector de enrutamiento en un enrutador que se ejecuta BGP, lo que proporciona una alternativa escalable y económica a una plataforma de hardware dedicada. El vRR tiene las siguientes ventajas:

• Escalabilidad Mejoras en la escalabilidad, en función del hardware de Server Core (CPU y memoria) en el que se ejecuta vRR.

• Implementación más rápida y flexible: vRR que se ejecuta en un servidor Intel, utilizando herramientas de código abierto, lo que reduce el mantenimiento típico de los enrutadores.

Figure 2: Reflector de ruta virtual Juniper (vRR)

Implementar un servidor de enrutamiento mediante una plataforma vRR permite que IXP Dimensione la CPU’del servidor y la memoria con la de la implementación de destino. Dado que las plataformas modernas de servidores tienen mucha más capacidad de computación y almacenamiento que una motor de enrutamiento tradicional, garantiza que el servidor de enrutamiento pueda escalar y funcionar bien más allá de un enrutador dedicado.

Junos OS RPD de contenedor (cRPD)

Como se muestra en los dos diagramas anteriores, el RPD es un componente básico del Junos OS y es responsable de ejecutar varios protocolos de enrutamiento (OSPF, ISIS, RIP, BGP, MPLS, etc.) para aprender y distribuir el estado de la ruta. Un RPD contenedor (cRPD) se ha diseñado para facilitar RPD como un módulo independiente que está desacoplado del Junos os base y que puede ejecutarse en entornos basados en Linux. Estos entornos pueden ser tan diversos como sistemas de host o de servidor, máquinas virtuales, contenedores y dispositivos de red con planes de reenvío físico o virtual independientes.

Las opciones adicionales para las implementaciones del servidor de enrutamiento son proporcionadas por cRPD, siendo el modelo el más simple, de manera similar al uso de un vRR. Sin embargo, cRPD proporciona muchas otras vías para explorarse mediante la creación de varias instancias de RPD detrás de un puente de acoplamiento. Por lo tanto, se presenta una sola instancia del servidor de enrutamiento a los clientes IXP, pero detrás de este puente de Docker puede ser un clúster de instancias RPD. Esto puede llevar a la mayor escalabilidad, nuevos modelos de alta disponibilidad, varias versiones de software y, en general, una nueva manera de pensar en qué es un servidor de enrutamiento. En Figure 3se muestra la instancia básica de cRPD, así como una vista de alto nivel de lo que puede parecer un servidor de enrutamiento escalado.

Figure 3: cRPD y cRPD como un servidor de ruta con escalabilidad horizontal

1. Descargar cRPD desde https://support.Juniper.net/support/downloads/:
2. Crear volumen de almacenamiento permanente para la configuración y los registros (tamaño predeterminado: 10GB):
3. Crear e iniciar contenedor:

Para limitar la cantidad de memoria y CPU asignada a un contenedor cRPD (por ejemplo, 256 MB y 1 CPU):

Para iniciar un contenedor cRPD en modo de redes de host (comparte el nombre de red espacio con host, el valor predeterminado es espacio de nombre distinto):

Basic Management of cRPD

Comprobando el estado del contenedor:

CLI de Access cRPD: Inicia JUNOs CLI:

Shell bash de Access cRPD:

PAUSE/reanude, detenga o destruya el contenedor:

Consulte el Apéndice C para obtener ejemplos y consideraciones sobre la configuración de cRPD específicos.

Configuración del servidor de enrutamiento

Los siguientes ejemplos de configuración, supervisión y solución de problemas se basan en el ejemplo de red IXP Figure 4que se muestra en la.

Figure 4: Ejemplo de red IXP

Basic Junos Route-Server Client Configuration

El servidor de enrutamiento de Junos admite la transparencia de EBGP mediante la modificación de la BGP normal de propagación de rutas, de modo que ningún atributo transitivo ni transitivo se elimine o modifique al propagar rutas. Los cambios en el comportamiento EBGP normal se controlan mediante la configuración de la CLIroute-server-client:

Servidor de enrutamiento Junos-configuración de cliente mediante una instancia de enrutamiento que no es de reenvío

Una RIB específica del cliente de servidor de ruta es una vista distintiva de una BGP Loc-RIB que puede contener rutas diferentes para el mismo destino que otras vistas. Los clientes de servidor de enrutamiento, a través de sus grupos del mismo nivel, pueden asociar una determinada vista específica del cliente o una costilla común compartida.

Para proporcionar la capacidad de anunciar distintas rutas a distintos clientes para el mismo destino, conceptualmente es necesario permitir que se produzcan varias instancias del BGP selección de ruta de acceso para el mismo destino, pero en un cliente o grupo diferente los contextos.

Junos OS implementa un control de políticas flexible con una selección de ruta por cliente/grupo, que utiliza instancias de enrutamiento que no son de reenvío para proporcionar varias instancias de la canalización de BGP, incluidas BGP selección de rutas de acceso, la ubicación de las COSTILLAs y la política. Se configurará un servidor de enrutamiento Junos para agrupar los clientes del servidor de enrutamiento dentro de BGP grupos configurados dentro de instancias separadas de enrutamiento que no son de reenvío. Este enfoque aprovecha el hecho de que BGP en ejecución dentro de una instancia de enrutamiento realiza la selección de la ruta de acceso y tiene un nervio que es independiente de BGP se ejecuta en otros casos de enrutamiento:

Ruta básica: configuración del cliente de servidor

El siguiente ejemplo de CLI muestra una configuración de enrutadores’de cliente de miembro IXP básica. Como puede ver, es’bastante sencillo, en comparación con la configuración del servidor de enrutamiento, dado que el cliente, en el sentido más básico, solo necesita etiquetar las rutas que desean anunciar en el IXP con las comunidades requeridas y el servidor de enrutamiento hace el resto:

En este ejemplo,’Supongamos que la’Directiva de C1 está abierta y permite que sus prefijos se anuncien a todos los miembros de IXP, de modo que adjunta el estándar BGP comunidad 64496:123 a todos sus prefijos anunciados:

Mientras que’las políticas de emparejamiento con C2 s establecen que sus prefijos solo se anuncian a C1, pero no a nadie más. Sus prefijos se anuncian a su vez con BGP comunidad estándar 64497:64496 que indica al servidor de enrutamiento que restrinja las importaciones’de instancias solo a la instancia de enrutamiento C1 s:

Comportamiento predeterminado EBGP la propagación de rutas sin directivas (RFC8212)

Junos OS aún no es compatible de forma nativa con RFC8212 (https://Tools.ietf.org/html/rfc8212), por lo que se dispone de una secuencia de comandos Slax, que debe utilizarse para lograr este comportamiento.

Rfc8212. Slax, es una implementación estricta que sustituye la ausencia de la implementación de RFC8212 con una instrucción deny-All si no hay ninguna política de exportación.

Puede encontrar una forma separada de la Directiva en: https://github.com/packetsource/rfc8212-Junos.

Aplicar el siguiente cambio de configuración:

Mecanismo de seguridad TTL generalizado (RFC3682)

El mecanismo de seguridad TTL generalizado (GTSM) está diseñado para proteger un’plano de control basado en IP de enrutador contra ataques basados en la utilización de 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:

Límites máximos de prefijo

El BGP prefix-limit característica le permite controlar cuántos prefijos se pueden recibir de un vecino BGP. La característica prefix-Limit es útil para garantizar que un enrutador de cliente no acepte más de un número de prefijos acordado previamente de un servidor de enrutamiento. Esto evita que un miembro IXP sobrecargue de forma intencionada o involuntariamente un servidor de enrutadores:

De manera alternativa, el servidor de enrutamiento se puede configurar para limitar el número de prefijos que se aceptan desde un miembro IXP. Esto puede ser útil o no, dependiendo de cómo se administre la validación del prefijo de entrada mediante IXP. Por ejemplo, si se descartan rutas no válidas, el número de prefijos aceptados puede ser diferente del número de prefijos anunciados:

Ejemplos de configuración de políticas de importación/exportación de COSTILLAs

Para propagar rutas entre clientes del servidor de enrutamiento, es necesario que las rutas se pierdan entre las costillas de las instancias de enrutamiento, basándose en políticas configuradas o en valores de comunidad bien definidos. Configuración de una malla completa de la pérdida de rutas entre n instancias de enrutamiento específicas del cliente mediante instance-import y la instance requiere directivas específicas de tabla, cada una con términos de directiva n-1, que expresan explícitamente el nombre de las instancias de enrutamiento de las que va a producirse la fuga. Por lo tanto, la configuración de la Directiva explota el orden de O (n ^ 2).

Como conveniencia en cuanto a la configuración, una instance-any el calificador de Directiva se proporciona para su uso con instance-import cies. El servicio instance-any el calificador tiene la funcionalidad de filtración de rutas del resto de instancias de enrutamiento en la instancia en la que instance-import está configurado. El servicio instance-import puede tener otros términos de calificación para implementar un filtrado adicional que cumpla las políticas de la comunidad global IXP.

Además, las directivas de enrutamiento de ejemplo que se describen a continuación seguirán el flujo de trabajo que se muestra en Figure 5el capítulo y lo que se describe en Internet Exchange Point Overview . El flujo de trabajo sigue las rutas anunciadas desde el cliente C1 hasta el servidor de enrutamiento y, a continuación, en el cliente C2.

Figure 5: Flujo de trabajo de ejemplo de configuración de servidor de enrutamiento

Directivas de importación de instancia de ejemplo

Echemos’un vistazo primero a cómo usar el instance-any calificador de directiva junto con un filtro de la comunidad estándar que coincida con el fin de importar rutas desde todas las instancias de enrutamiento que tengan una directiva de enrutamiento abierta.

Puede ver cómo el término de la directiva usa primero la instance-any y, a continuación, hace coincidir la comunidad 64511:111 que, para este ejemplo, representa la comunidad IXP en una directiva abierta. A continuación, esa Directiva se aplica en el routing-instance instance-import punto de conexión:

Como se ha mencionado al principio de esta sección, una forma alternativa de configurar un subconjunto de instancias consiste en utilizar la instance-list Identifier. Puede ver a continuación que, en lugar de usar la instancia: cualquier calificador que haya enumerado cada instancia de enrutamiento de cliente individual junto con un valor de comunidad de 0:100, que es la comunidad global IXP, para bloquear los anuncios de enrutamiento en clientes de servidor de enrutamiento de ruta específicos:

Directiva de importación de ejemplo

Esta política de ejemplo acepta y etiqueta prefijos con un valor comunitario válido/no válido basado en la validación del objeto TIR, tal y como se describe en la sección validación de prefijo anterior. Varios ejemplos de uso de la integración de herramientas de terceros, como se describe en una sección posterior, pueden aprovecharse para generar automáticamente elroute-filter-list y as-path-group describen. La política de ejemplo agrega aquí las etiquetas de la comunidad que se utilizarán en las políticas de importación/exportación de instancias posteriores:

Ejemplo de validación de origen de BGP (RPKI)

Una alternativa a la escritura y mantenimiento de la as-path-group y route-filter-list listas es utilizar RPKI, como se describió anteriormente en este manual. La siguiente política comprueba la base de datos de validación de RPKI y marca los destinos con la comunidad de validación devuelta; valid, invalid, o bien unknown:

El formato de las comunidades mostradas aquí es el resultado de la sección 2 de RFC8097, donde el valor del octeto de orden superior del campo de tipo extendido es 0X43, que indica que es no Transitive. El valor del octeto de orden inferior del campo de tipo extendido, tal y como lo asigna IANA, es 0x00. Y el último octeto de la comunidad extendida es un entero sin signo que ofrece el estado de’validación de ruta s con los siguientes valores:

• 0 = resultado de la búsqueda = válido

• 1 = resultado de la búsqueda = no encontrado

• 2 = resultado de búsqueda = no válido

Ejemplo de directivas de exportación de instancias

Este ejemplo de política de exportación de instancia siguiente rechaza cualquier prefijo marcado como no válido por medio de la búsqueda de la base de datos RPKI, o de una route-filter-list perdida o un as-path-group miss. A continuación, se comprueban todos los demás prefijos permitidos por medio de las políticas de importación de instancias:

Ejemplo de directiva de exportación

La mayoría de las políticas, si no todas, ya se han implementado entre la política de importación, la Directiva de exportación de instancias y la de importación de instancias. La única política restante puede ser quitar las comunidades de validación de prefijos antes de enviar los prefijos a los clientes del servidor de enrutamiento. Esto también puede incluir las RPKI válidas/no válidas/desconocidas. La Directiva RPKI de ejemplo mostrada anteriormente es una directiva bastante estricta en la que RPKI prefijos no válidos se colocan en instance-export. Puede ser la Directiva IXP para simplemente aprobar los resultados, como un servicio, para los miembros de IXP, lo que les permite decidir cómo usar los resultados de validación.