Validación de origen del BGP
Descripción de la validación de origen para BGP
La validación de origen ayuda a evitar la publicidad no intencional de rutas. A veces, los administradores de red anuncian por error rutas a las redes que no controlan. Puede resolver este problema de seguridad configurando la validación de origen (también conocido como enrutamiento seguro entre dominios). La validación de origen es un mecanismo mediante el cual los anuncios de ruta se pueden autenticar como originados en un sistema autónomo (AS) esperado. La validación de origen usa uno o más servidores de caché de infraestructura de clave pública de recursos (RPKI) para realizar la autenticación de prefijos BGP especificados. Para autenticar un prefijo, el enrutador (altavoz BGP) consulta la base de datos de asignaciones validadas de prefijo a AS, que se descargan del servidor de caché, y se asegura de que el prefijo se originó a partir de un AS esperado.
Cuando habilita la autenticación RPKI, Junos OS abre el puerto TCP 2222 automáticamente sin previo aviso. Puede aplicar un filtro para bloquear y proteger este puerto.
Junos OS admite la validación de origen para prefijos IPv4 e IPv6.
Figura 1 muestra una topología de ejemplo.
- Estándares compatibles
- Cómo funciona la validación de origen
- Interacción del BGP con la base de datos de validación de ruta
- Atributo de la comunidad para anunciar el estado de validación de RPKI a los vecinos del IBGP
- Enrutamiento activo y validación de origen sin interrupciones
- Marcar un rango de prefijo como nunca permitido
Estándares compatibles
La validación de origen de la implementación de Junos OS admite las siguientes RFC y borrador:
RFC 6810, La infraestructura de clave pública de recursos (RPKI) al protocolo de enrutador
RFC 6811, Validación de origen del prefijo BGP
Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Prefijo BGP Validación de origen Estado de Comunidad extendida (apoyo parcial)
La comunidad extendida (estado de validación de origen) se admite en la política de enrutamiento de Junos OS. No se admite el cambio especificado en el procedimiento de selección de ruta.
Cómo funciona la validación de origen
La RPKI y la validación de origen utilizan certificados X.509 con extensiones especificadas en RFC 3779, Extensiones X.509 para direcciones IP e identificadores de AS.
El RPKI consiste en una recopilación distribuida de información. Cada autoridad de certificación publica sus certificados de entidad final (EE), listas de revocación de certificados (CRL) y objetos firmados en una ubicación determinada. Todos estos repositorios forman un conjunto completo de información disponible para cada servidor de caché RPKI.
Cada servidor de caché RPKI mantiene una caché local de toda la colección de repositorio distribuido mediante la sincronización regular de cada elemento de la caché local con el punto de publicación del repositorio original.
En el enrutador, las entradas de la base de datos se formatearán como registros de validación de ruta (RV). Un registro de RV es un triple (prefijo, longitud máxima, AS de origen). Coincide con cualquier ruta cuyo prefijo coincide con el prefijo del RV, cuya longitud del prefijo no supera la longitud máxima dada en el registro del RV, y cuyo AS de origen es igual al AS de origen dado en el registro de RV.
Un registro de RV es una versión simplificada de una autorización de origen de ruta (ROA). Una ROA es un objeto firmado digitalmente que proporciona un medio para verificar que el titular del bloque de dirección IP haya autorizado un AS para originar rutas a uno o más prefijos dentro del bloque de direcciones. Las ROA no se utilizan directamente en la validación de rutas. El servidor de caché exporta una versión simplificada de la ROA al enrutador como un registro de RV.
El valor de longitud máxima debe ser mayor o igual que la longitud del prefijo autorizado y menor o igual que la longitud (en bits) de una dirección IP de la familia de direcciones (32 para IPv4 y 128 para IPv6). La longitud máxima define el prefijo de dirección IP que el AS está autorizado para anunciar.
Por ejemplo, si el prefijo de dirección IP es 200.4.66/24, y la longitud máxima es 26, el AS está autorizado a anunciar 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 y 200.4.66.192/26. Cuando la longitud máxima no está presente, el AS solo está autorizado para anunciar exactamente el prefijo especificado en el RV.
Como otro ejemplo, un RV puede contener el prefijo 200.4.66/24 con una longitud máxima de 26, así como el prefijo 200.4.66.0/28 con una longitud máxima de 28. Este RV autorizaría al AS a anunciar cualquier prefijo a partir de 200.4.66 con una longitud de al menos 24 y no mayor que 26, así como el prefijo específico 200.4.66.0/28.
El origen de una ruta está representado por el número del AS de la derecha en el atributo AS_PATH. La validación de origen funciona comparando el AS de origen en una actualización de enrutamiento con el AS de origen autorizado publicado en los registros del RV.
Se sabe que la seguridad proporcionada por la validación de origen sola es débil frente a un atacante determinado, ya que no hay protección contra un atacante que suplanta el AS de origen. Dicho esto, la validación de origen proporciona una protección útil contra anuncios accidentales.
Aunque la validación de origen se podría implementar haciendo que cada enrutador participe directamente en el RPKI, esto se considera que requiere demasiados recursos (porque se requieren muchas operaciones de criptografía de clave pública para validar los datos de RPKI) así como operacionalmente intensivo para configurar y mantener una configuración RPKI en cada enrutador. Por esta razón, un servidor de caché RPKI independiente realiza validaciones de clave pública y genera una base de datos validada de asignaciones de prefijo a AS. La base de datos validada se descarga a un enrutador del cliente mediante una conexión TCP segura. Por lo tanto, el enrutador requiere poca información sobre la infraestructura de RPKI y no tiene requisitos de criptografía de clave pública, aparte de la contraseña de transporte cifrado. Posteriormente, el enrutador utiliza los datos descargados para validar las actualizaciones de rutas recibidas.
Cuando configure sesiones de servidor, puede agrupar las sesiones y configurar los parámetros de sesión para cada sesión del grupo. El enrutador intenta configurar periódicamente un número máximo configurable de conexiones a los servidores de caché. Si se produce un error en la configuración de la conexión, se realiza un nuevo intento de conexión periódicamente.
Mientras tanto, después de aplicar la política de importación de validación a la sesión del BGP, la validación de ruta se realiza independientemente del estado de la sesión de la caché (arriba o abajo) y de la base de datos de RV (vacía o no). Si la base de datos de RV está vacía o ninguna de las sesiones del servidor de caché está activa, el estado de validación de cada ruta se establece en desconocido, ya que no existe ningún registro de RV para evaluar un prefijo BGP recibido.
El período de intento de reintento es configurable. Después de conectarse correctamente a un servidor de caché, el enrutador consulta el número de serie más reciente de la base de datos y solicita que la caché rpki transmita todas las entradas de RV que pertenecen a esa versión de la base de datos.
Cada mensaje entrante restablece un temporizador de liveliness para el servidor de caché RPKI. Después de aprender todas las actualizaciones, el enrutador realiza comprobaciones periódicas de liveliness basadas en un intervalo configurable. Esto se hace mediante el envío de una unidad de datos de protocolo de consulta en serie (PDU) con el mismo número de serie que el servidor de caché informó en su última PDU de notificación. El servidor de caché responde con cero o más actualizaciones y un PDU de fin de datos (EOD), que también actualiza el estado de liveliness del servidor de caché y restablece un temporizador de registro de vida útil.
Cuando se recibe un prefijo de un par de BGP externo (EBGP), una política de importación lo examina y se marca como Válido, No válido, desconocido o no verificado:
Válido— Indica que el prefijo y el par de AS se encuentran en la base de datos.
No válido: indica que se encuentra el prefijo, pero el AS correspondiente recibido del par del EBGP no es el AS que aparece en la base de datos o que la longitud del prefijo en el mensaje de actualización del BGP es más larga que la longitud máxima permitida en la base de datos.
Desconocido— Indica que el prefijo no se encuentra entre los prefijos o intervalos de prefijos de la base de datos.
No verificado: indica que el origen del prefijo no se verifica en la base de datos. Esto se debe a que la base de datos se rellena y no se pide la validación en la política de importación del BGP, aunque la validación de origen está habilitada o la validación de origen no está habilitada para los pares del BGP.
Si hay posibles coincidencias para la ruta en la base de datos de validación, la ruta tiene que coincidir con una de ellas para ser válida. De lo contrario, no es válido. Cualquier coincidencia es adecuada para que la ruta sea válida. No tiene por qué ser la mejor combinación. Solo si no hay posibles coincidencias se considera que la ruta es desconocida. Para obtener más información acerca de la lógica de base de datos de asignación de prefijo a AS, consulte la sección 2 del borrador de Internet draft-ietf-sidr-pfx-validate-01, validación de origen del prefijo BGP.
La validación de RPKI solo está disponible en la instancia principal. Si configura la validación de RPKI para una instancia de enrutamiento, se produce un error en la validación de RPKI con el siguiente mensaje RV instance is not runningde error.
Interacción del BGP con la base de datos de validación de ruta
La base de datos de validación de ruta (RV) contiene una colección de registros de RV que el enrutador descarga del servidor de caché RPKI. Después de completar la base de datos de RV con registros RV, la base de datos de RV analiza la tabla de enrutamiento RIB-Local para determinar si hay prefijos en RIB-Local que puedan verse afectados por los registros de RV en la base de datos. (RIB-Local contiene las rutas IPv4 e IPv6 que se muestran en la salida del show route protocol bgp comando.)
Este proceso activa una reevaluación del BGP de las políticas de importación del BGP (no de exportación).
Figura 2 muestra el proceso.
Las políticas de importación se aplican al RIB-In. Otra forma de entender esto es que las políticas de importación se aplican a las rutas que se muestran en la salida del comando, mientras que las show route receive-protocol bgp políticas de exportación se aplican a las rutas que el show route advertising-protocol bgp comando muestra.
Como se muestra en Figura 3, se usan políticas de importación de enrutamiento para controlar las rutas que el BGP coloca en la tabla de enrutamiento y exportar políticas de enrutamiento para controlar las rutas que el BGP anuncia de la tabla de enrutamiento a sus vecinos.
Cuando se configura una política de importación de validación de ruta, la configuración de política usa una validation-database condición de coincidencia. Esta condición de coincidencia activa una consulta en la base de datos de RV para el estado de validación de un prefijo en una instancia de enrutamiento determinada. La operación predeterminada es consultar la base de datos de validación que coincide con la instancia de enrutamiento. Si no se encuentra ninguna instancia de validación de ruta, se consulta la instancia principal.
En la siguiente política de importación del BGP, la from validation-database condición activa una búsqueda en la base de datos de RV del enrutador. Se realiza una acción si el estado de validación es válido. La acción es aceptar la ruta y establecer la validation-state en la tabla de enrutamiento como válida.
[edit protocols bgp] import validation;
[edit policy-options]
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid; # Triggers a lookup in the RV database
}
then {
validation-state valid; # Sets the validation state in the routing table
accept;
}
}
}
Atributo de la comunidad para anunciar el estado de validación de RPKI a los vecinos del IBGP
La validación del prefijo solo se realiza para actualizaciones externas de BGP (EBGP). Dentro de un AS, es probable que no desee que se ejecute una sesión RPKI en cada enrutador BGP interno (IBGP). En su lugar, necesita una forma de llevar el estado de validación a través de la malla del IBGP para que todos los altavoces del IBGP tengan información consistente. Esto se logra llevando el estado de validación en una comunidad extendida no transitiva. El atributo de comunidad anuncia y recibe el estado de validación de un prefijo entre vecinos del IBGP.
Junos OS admite las siguientes comunidades extendidas conocidas para la validación de rutas:
origen-validación-estado-válido
origen-validación-estado-no válido
origen-validación-estado-desconocido
La siguiente política de importación de BGP de ejemplo se configura en el enrutador que tiene una sesión con un servidor RPKI.
Enrutador con sesión de RPKI
policy-statement validation-1 {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
}
La siguiente política de importación de BGP de ejemplo está configurada en un enrutador par de IBGP que no tiene una sesión con un servidor RPKI.
Enrutador par IBGP sin sesión RPKI
policy-statement validation-2 {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
}
Enrutamiento activo y validación de origen sin interrupciones
Cuando configure la validación de origen en un enrutador que tenga motores de enrutamiento dual y el enrutamiento activo sin interrupciones está habilitado, tanto los motores de enrutamiento principal como los motores de enrutamiento en espera tienen una copia de la base de datos de RV. Estas dos bases de datos de RV permanecen sincronizadas entre sí.
El enrutador no mantiene dos sesiones idénticas con el servidor RPKI. El protocolo RPKI-RTR solo se ejecuta en el motor de enrutamiento principal. En el motor de enrutamiento en espera, la sesión del servidor de caché de RPKI siempre está desactivada.
El motor de enrutamiento principal mantiene activamente la base de datos de RV a través de su sesión con el servidor RPKI. Esta base de datos se replica en el motor de enrutamiento en espera. Aunque la sesión está desactivada en el motor de enrutamiento en espera, la base de datos de RV replicada contiene registros de RV. Cuando el motor de enrutamiento en espera pasa a pasar a ser el motor de enrutamiento principal, ya tiene una base de datos de RV completa.
Para ver el contenido de las dos bases de datos, utilice los show validation database comandos y show validation replication database .
Marcar un rango de prefijo como nunca permitido
El modelo de validación de ruta tiene una deficiencia importante: Solo proporciona actualizaciones positivas. Puede declarar qué AS es el propietario legítimo de un prefijo. Sin embargo, no puede transmitir explícitamente una actualización negativa, como en: Este prefijo nunca se origina en un AS dado. Esta funcionalidad se puede proporcionar hasta cierto punto mediante una solución del AS 0.
La implementación de Junos OS no intenta restringir sus entradas de la caché. Por ejemplo, un registro del RV con el AS de origen 0 se instala y se hace coincidir como cualquier otro. Esto permite que una solución alternativa marque un rango de prefijo como nunca se permite anunciar, ya que el AS 0 no es un AS válido. El AS del registro del RV nunca coincide con el AS recibido del par del EBGP. Por lo tanto, cualquier prefijo coincidente se marca como no válido.
Consulte también
Validación de caso de uso y beneficio de origen para BGP
Si un administrador de un sistema autónomo (AS) comienza a anunciar toda o parte de la red asignada de otra empresa, el BGP no tiene ningún método integrado para reconocer el error y responder de una manera que evite interrupciones del servicio.
Supongamos, por ejemplo, que un administrador de una red de cliente anuncia por error una ruta (digamos 10.65.153.0/24) que dirige el tráfico al AS 1 del proveedor de servicios del cliente. Esta ruta /24 es una ruta más específica que la utilizada por el proveedor de contenido real (10.65.152.0/22) que dirige el tráfico al AS 2. Debido a la forma en que funcionan los enrutadores, la mayoría de los enrutadores seleccionan la ruta más específica y envían tráfico al AS 1 en lugar del AS 2.
El prefijo secuestrado se ve ampliamente en Internet a medida que los enrutadores de tránsito propagan la información de ruta actualizada. Las rutas no válidas se pueden distribuir ampliamente a través de Internet a medida que los enrutadores en la zona libre predeterminada (DFZ) llevan la ruta secuestrada. Con el tiempo, la ruta del AS correcta se restaura a los pares del BGP, pero mientras tanto se esperan interrupciones del servicio.
Dado que el BGP depende de un modelo de confianza transitivo, la validación entre el cliente y el proveedor es importante. En el ejemplo anterior, el proveedor de servicios del AS 1 no validó el anuncio defectuoso para 10.65.153.0/24. Al aceptar este anuncio y revertirlo a sus pares y proveedores, el AS 1 estaba propagando la ruta incorrecta. Los enrutadores que recibieron esta ruta del AS 1 la seleccionaron porque era una ruta más específica. El proveedor de contenido real estaba anunciando 10.65.152.0/22 antes de que se produjera el error. El /24 era un anuncio más pequeño (y más específico). De acuerdo con el proceso habitual de selección de ruta del BGP, el /24 fue elegido, completando efectivamente el secuestro.
Incluso con la detección y reacción rápidas del proveedor de contenido y la cooperación con otros proveedores, el servicio para su prefijo puede interrumpirse durante muchos minutos hasta varias horas. La duración exacta de la interrupción depende de su punto de vista en Internet. Cuando ocurren este tipo de eventos, se renueva el interés en las soluciones a esta vulnerabilidad. El BGP es fundamental para las relaciones con los proveedores y no desaparecerá pronto. En este ejemplo, se muestra una solución que usa validación de origen. Esta solución se basa en extensiones criptográficas del BGP y un modelo de cliente-servidor distribuido que evita sobrecargar las CPU del enrutador.
La validación de origen ayuda a superar la vulnerabilidad de la confianza transitiva al permitir que un proveedor limite los anuncios que acepta de un cliente. La mecánica implica la comunicación de políticas de enrutamiento basadas en un atributo de comunidad BGP extendido.
Consulte también
Ejemplo: Configuración de validación de origen para BGP
En este ejemplo, se muestra cómo configurar la validación de origen entre los pares del BGP garantizando que los anuncios de ruta recibidos se envíen (originados) desde el sistema autónomo (AS) esperado. Si se valida el AS de origen, una política puede especificar que los prefijos se anuncien, a su vez.
Requisitos
En este ejemplo, se tienen los siguientes requisitos de hardware y software:
-
Servidor de caché de infraestructura de clave pública de recursos (RPKI) mediante software de terceros para autenticar prefijos del BGP.
-
Junos OS versión 12.2 o posterior se ejecuta en el dispositivo de enrutamiento que se comunica con el servidor de caché a través de una conexión TCP.
Descripción general
A veces, las rutas se anuncian involuntariamente debido a errores del operador. Para evitar este problema de seguridad, puede configurar el BGP para validar el AS de origen y rechazar estos anuncios no válidos. Esta función usa un servidor de caché para autenticar prefijos o intervalos de prefijos.
Las siguientes instrucciones de configuración habilitan la validación del AS de origen:
[edit routing-options] validation { group group-name { max-sessions number; session address { hold-time seconds; local-address local-ip-address; port port-number; preference number; record-lifetime seconds; refresh-time seconds; traceoptions { file filename <files number> <size size> <(world-readable | no-world-readable)>; flag flag { disable; flag-modifier; } } } static { record destination { maximum-length prefix-length { origin-autonomous-system as-number { validation-state (invalid | valid); } } } } traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag { disable; flag-modifier; } } }
En este ejemplo, se utiliza la configuración predeterminada para los parámetros de validación.
La mayoría de las instrucciones de configuración disponibles son opcionales. La configuración requerida es la siguiente:
validation { group group-name { session address { } } }
El [edit routing-options validation static] nivel de jerarquía le permite configurar registros estáticos en un dispositivo de enrutamiento, por lo tanto, sobrescribir los registros recibidos de un servidor de caché RPKI.
Por ejemplo:
[edit routing-options validation] user@R0# set static record 10.0.0.0/16 maximum-length 24 origin-autonomous-system 200 validation-state valid
Puede configurar una política de enrutamiento que funcione según el estado de validación de un prefijo de ruta. Puede usar un atributo de comunidad para anunciar y recibir el estado de validación de un prefijo entre BGP externo (EBGP) y BGP interno (IBGP). En algunos enrutadores, puede ser más conveniente usar una política de enrutamiento que configurar una sesión con un servidor RPKI. En este ejemplo, se muestra el uso del atributo de comunidad de estado de validación entre los pares del IBGP.
Figura 4 muestra la topología de ejemplo.
En este ejemplo, el dispositivo R0 tiene una conexión IBGP al dispositivo R1 y una conexión EBGP al dispositivo R2. El dispositivo R0 recibe registros de validación de ruta (RV) del servidor de caché mediante el protocolo definido en Internet draft-ietf-sidr-rpki-rtr-19, el RPKI/protocolo de enrutador para enviar los registros de RV. El protocolo de enrutador RPKI se ejecuta sobre TCP. El dispositivo R0 utiliza los registros de RV para crear una base de datos local de RV. En el dispositivo R1, el estado de validación se establece según la comunidad BGP llamada validación-estado, que se recibe con la ruta.
Configuración
- Configuración rápida de CLI
- Configuración del dispositivo R0
- Configuración del dispositivo R1
- Configuración del dispositivo R2
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
Dispositivo R0
set interfaces ge-1/2/0 unit 2 description to-R1 set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.2/30 set interfaces ge-1/2/1 unit 0 description to-R2 set interfaces ge-1/2/1 unit 0 family inet address 10.0.0.5/30 set interfaces ge-1/2/2 unit 0 description to-cache set interfaces ge-1/2/2 unit 0 family inet address 10.0.0.9/30 set interfaces lo0 unit 0 family inet address 10.0.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.0.1.1 set protocols bgp group int export send-direct set protocols bgp group int neighbor 10.1.1.1 set protocols bgp group ext type external set protocols bgp group ext import validation set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65200 set protocols bgp group ext neighbor 10.0.0.6 set protocols ospf area 0.0.0.0 interface ge-1/2/0.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set policy-options policy-statement validation term valid from protocol bgp set policy-options policy-statement validation term valid from validation-database valid set policy-options policy-statement validation term valid then validation-state valid set policy-options policy-statement validation term valid then community add origin-validation-state-valid set policy-options policy-statement validation term valid then accept set policy-options policy-statement validation term invalid from protocol bgp set policy-options policy-statement validation term invalid from validation-database invalid set policy-options policy-statement validation term invalid then validation-state invalid set policy-options policy-statement validation term invalid then community add origin-validation-state-invalid set policy-options policy-statement validation term invalid then reject set policy-options policy-statement validation term unknown from protocol bgp set policy-options policy-statement validation term unknown then validation-state unknown set policy-options policy-statement validation term unknown then community add origin-validation-state-unknown set policy-options policy-statement validation term unknown then accept set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100 set routing-options validation group test session 10.0.0.10
Dispositivo R1
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.1/30 set interfaces lo0 unit 0 family inet address 10.1.1.1/32 set protocols bgp group int type internal set protocols bgp group int local-address 10.1.1.1 set protocols bgp group int import validation-ibgp set protocols bgp group int neighbor 10.0.1.1 set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set policy-options policy-statement validation-ibgp term valid from community origin-validation-state-valid set policy-options policy-statement validation-ibgp term valid then validation-state valid set policy-options policy-statement validation-ibgp term invalid from community origin-validation-state-invalid set policy-options policy-statement validation-ibgp term invalid then validation-state invalid set policy-options policy-statement validation-ibgp term unknown from community origin-validation-state-unknown set policy-options policy-statement validation-ibgp term unknown then validation-state unknown set policy-options community origin-validation-state-invalid members 0x4300:0.0.0.0:2 set policy-options community origin-validation-state-unknown members 0x4300:0.0.0.0:1 set policy-options community origin-validation-state-valid members 0x4300:0.0.0.0:0 set routing-options autonomous-system 65100
Dispositivo R2
set interfaces ge-1/2/0 unit 0 family inet address 10.0.0.6/30 set interfaces lo0 unit 0 family inet address 172.16.1.1/32 set interfaces lo0 unit 0 family inet address 192.168.2.3/32 set protocols bgp group ext export send-direct set protocols bgp group ext peer-as 65100 set protocols bgp group ext neighbor 10.0.0.5 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct from protocol local set policy-options policy-statement send-direct then accept set routing-options autonomous-system 65200
Configuración del dispositivo R0
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.
Para configurar el dispositivo R0:
-
Configure las interfaces.
[edit interfaces] user@R0# set ge-1/2/0 unit 0 description to-R1 user@R0# set ge-1/2/0 unit 0 family inet address 10.0.0.2/30 user@R0# set ge-1/2/1 unit 0 description to-R2 user@R0# set ge-1/2/1 unit 0 family inet address 10.0.0.5/30 user@R0# set ge-1/2/2 unit 0 description to-cache user@R0# set ge-1/2/2 unit 0 family inet address 10.0.0.9/30 user@R0# set lo0 unit 0 family inet address 10.0.1.1/32
-
Configure BGP.
Aplique la
send-directpolítica de exportación para que las rutas directas se exporten desde la tabla de enrutamiento al BGP.Aplique la
validationpolítica de importación para establecer el estado de validación y los atributos de comunidad del BGP para todas las rutas importados (o recibidas) desde los pares de EBGP del dispositivo R0.Configure una sesión de IBGP con el dispositivo R1. Configure una sesión de EBGP con el dispositivo R2.
[edit protocols bgp] user@R0# set group int type internal user@R0# set group int local-address 10.0.1.1 user@R0# set group int export send-direct user@R0# set group int neighbor 10.1.1.1 user@R0# set group ext type external user@R0# set group ext import validation user@R0# set group ext export send-direct user@R0# set group ext peer-as 65200 user@R0# set group ext neighbor 10.0.0.6
-
Configure el OSPF (u otro protocolo de puerta de enlace interior [IGP]) en la interfaz frente al par del IBGP y en la interfaz de circuito cerrado.
Nota:Si utiliza la dirección de interfaz de circuito cerrado en la instrucción IBGP
neighbor, debe habilitar un IGP en la interfaz de circuito cerrado. De lo contrario, la sesión del IBGP no se establece.[edit protocols ospf area 0.0.0.0] user@R0# set interface ge-1/2/0.0 user@R0# set interface lo0.0 passive
-
Configure la política de enrutamiento que exporta rutas directas de la tabla de enrutamiento al BGP.
[edit policy-options policy-statement send-direct] user@R0# set from protocol direct user@R0# set then accept
-
Configure la política de enrutamiento que especifica los atributos que se modificarán según el estado de validación de cada ruta del BGP.
[edit policy-options policy-statement validation] user@R0# set term valid from protocol bgp user@R0# set term valid from validation-database valid user@R0# set term valid then validation-state valid user@R0# set term valid then community add origin-validation-state-valid user@R0# set term valid then accept user@R0# set term invalid from protocol bgp user@R0# set term invalid from validation-database invalid user@R0# set term invalid then validation-state invalid user@R0# set term invalid then community add origin-validation-state-invalid user@R0# set term invalid then reject user@R0# set term unknown from protocol bgp user@R0# set term unknown then validation-state unknown user@R0# set term unknown then community add origin-validation-state-unknown user@R0# set term unknown then accept [edit policy-options] user@R0# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R0# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R0# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Configure la sesión con el servidor de caché RPKI.
[edit routing-options validation] user@R0# set group test session 10.0.0.10
-
Configure el número de sistema autónomo (AS).
[edit routing-options] user@R0# set autonomous-system 65100
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R0# show interfaces
ge-1/2/0 {
unit 0 {
description to-R1;
family inet {
address 10.0.0.2/30;
}
}
}
ge-1/2/1 {
unit 0 {
description to-R2;
family inet {
address 10.0.0.5/30;
}
}
}
ge-1/2/2 {
unit 0 {
description to-cache;
family inet {
address 10.0.0.9/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.1.1/32;
}
}
}
user@R0# show protocols
bgp {
group int {
type internal;
local-address 10.0.1.1;
export send-direct;
neighbor 10.1.1.1;
}
group ext {
type external;
import validation;
export send-direct;
peer-as 65200;
neighbor 10.0.0.6;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R0# show policy-options
policy-statement send-direct {
from protocol direct;
then accept;
}
policy-statement validation {
term valid {
from {
protocol bgp;
validation-database valid;
}
then {
validation-state valid;
community add origin-validation-state-valid;
accept;
}
}
term invalid {
from {
protocol bgp;
validation-database invalid;
}
then {
validation-state invalid;
community add origin-validation-state-invalid;
reject;
}
}
term unknown {
from protocol bgp;
then {
validation-state unknown;
community add origin-validation-state-unknown;
accept;
}
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R0# show routing-options
autonomous-system 65100;
validation {
group test {
session 10.0.0.10;
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Configuración del dispositivo R1
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.
Para configurar el dispositivo R1:
-
Configure las interfaces.
[edit interfaces] user@R1# set ge-1/2/0 unit 0 family inet address 10.0.0.1/30 user@R1# set lo0 unit 0 family inet address 10.1.1.1/32
-
Configure BGP.
Aplique la
validation-ibgppolítica de importación para establecer el estado de validación y los atributos de comunidad del BGP para todas las rutas recibidas de los pares del IBGP del dispositivo R1.Configure una sesión de IBGP con el dispositivo R0.
[edit protocols bgp group int] user@R1# set type internal user@R1# set local-address 10.1.1.1 user@R1# set import validation-ibgp user@R1# set neighbor 10.0.1.1
-
Configure OSPF.
[edit protocols ospf area 0.0.0.0] user@R1# set interface ge-1/2/0.0 user@R1# set interface lo0.0 passive
-
Configure la política de enrutamiento que especifica los atributos que se modificarán según el atributo de comunidad del BGP de estado de validación de las rutas del BGP recibidas del dispositivo R0.
[edit policy-options policy-statement validation-ibgp] user@R1# set term valid from community origin-validation-state-valid user@R1# set term valid then validation-state valid user@R1# set term invalid from community origin-validation-state-invalid user@R1# set term invalid then validation-state invalid user@R1# set term unknown from community origin-validation-state-unknown user@R1# set term unknown then validation-state unknown [edit policy-options] user@R1# set community origin-validation-state-invalid members 0x4300:0.0.0.0:2 user@R1# set community origin-validation-state-unknown members 0x4300:0.0.0.0:1 user@R1# set community origin-validation-state-valid members 0x4300:0.0.0.0:0
-
Configure el número de sistema autónomo (AS).
[edit routing-options] user@R1# set autonomous-system 65100
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R1# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.1.1/32;
}
}
}
user@R1# show protocols
bgp {
group int {
type internal;
local-address 10.1.1.1;
import validation-ibgp;
neighbor 10.0.1.1;
}
}
ospf {
area 0.0.0.0 {
interface ge-1/2/0.0;
interface lo0.0 {
passive;
}
}
}
user@R1# show policy-options
policy-statement validation-ibgp {
term valid {
from community origin-validation-state-valid;
then validation-state valid;
}
term invalid {
from community origin-validation-state-invalid;
then validation-state invalid;
}
term unknown {
from community origin-validation-state-unknown;
then validation-state unknown;
}
}
community origin-validation-state-invalid members 0x4300:0.0.0.0:2;
community origin-validation-state-unknown members 0x4300:0.0.0.0:1;
community origin-validation-state-valid members 0x4300:0.0.0.0:0;
}
user@R1# show routing-options autonomous-system 65100;
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Configuración del dispositivo R2
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.
Para configurar el dispositivo R2:
-
Configure las interfaces.
Varias direcciones se configuran en la interfaz de circuito cerrado para que sirvan como rutas con fines de demostración.
[edit interfaces] user@R2# set ge-1/2/0 unit 0 family inet address 10.0.0.6/30 user@R2# set lo0 unit 0 family inet address 172.16.1.1/32 user@R2# set lo0 unit 0 family inet address 192.168.2.3/32
-
Configure BGP.
[edit protocols bgp] user@R2# set group ext export send-direct user@R2# set group ext peer-as 65100 user@R2# set group ext neighbor 10.0.0.5
-
Configure la política de enrutamiento.
[edit policy-options policy-statement send-direct] user@R2# set from protocol direct user@R2# set from protocol local user@R2# set then accept
-
Configure el número de sistema autónomo (AS).
[edit routing-options] user@R2# set autonomous-system 65200
Resultados
Desde el modo de configuración, ingrese los comandos , show protocols, show policy-optionsy show routing-options para confirmar la show interfacesconfiguración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R2# show interfaces
ge-1/2/0 {
unit 0 {
family inet {
address 10.0.0.6/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 172.16.1.1/32;
address 192.168.2.3/32;
}
}
}
user@R2# show protocols
bgp {
group ext {
export send-direct;
peer-as 65100;
neighbor 10.0.0.5;
}
}
user@R2# show policy-options
policy-statement send-direct {
from protocol [ direct local ];
then accept;
}
user@R2# show routing-options autonomous-system 65200;
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
- Verificar que los atributos modificados se muestren en las tablas de enrutamiento
- Uso de operaciones de seguimiento
- Mostrar información de validación
Verificar que los atributos modificados se muestren en las tablas de enrutamiento
Propósito
Verifique que las rutas del BGP en los dispositivos R0 y R1 tengan los estados de validación esperados y las preferencias locales esperadas.
Acción
Desde el modo operativo, ingrese el show route comando.
user@R0> show route
inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.1.1/32 *[Direct/0] 04:53:39
> via lo0.1
10.1.1.1/32 *[OSPF/10] 04:50:53, metric 1
> to 10.0.0.1 via lt-1/2/0.2
10.0.0.0/30 *[Direct/0] 04:51:44
> via lt-1/2/0.2
10.0.0.2/32 *[Local/0] 04:51:45
Local via lt-1/2/0.2
10.0.0.4/30 *[Direct/0] 04:51:44
> via lt-1/2/0.5
[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: valid
> to 10.0.0.6 via lt-1/2/0.5
10.0.0.5/32 *[Local/0] 04:51:45
Local via lt-1/2/0.5
10.0.0.8/30 *[Direct/0] 03:01:28
> via lt-1/2/0.9
10.0.0.9/32 *[Local/0] 04:51:45
Local via lt-1/2/0.9
172.16.1.1/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: invalid
> to 10.0.0.6 via lt-1/2/0.5
192.168.2.3/32 *[BGP/170] 02:24:57, localpref 100
AS path: 65200 I, validation-state: validation-state: unknown
> to 10.0.0.6 via lt-1/2/0.5
224.0.0.5/32 *[OSPF/10] 04:53:46, metric 1
MultiRecvuser@R1> show route
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.1.1/32 *[BGP/170] 00:40:52, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: invalid
> to 10.0.0.2 via lt-1/2/0.1
192.168.2.3/32 *[BGP/170] 01:06:58, localpref 100, from 1.0.1.1
AS path: 65200 I, validation-state: unknown
> to 10.0.0.2 via lt-1/2/0.1
224.0.0.5/32 *[OSPF/10] 04:57:09, metric 1
MultiRecvSignificado
Las rutas tienen los estados de validación esperados y los valores de preferencia local, basados en la información recibida del servidor de caché RPKI.
Uso de operaciones de seguimiento
Propósito
Configure operaciones de seguimiento para la validación de origen y supervise los resultados de una ruta recién anunciada.
Acción
-
En el dispositivo R0, configure el seguimiento.
[edit routing-options validation traceoptions] user@R0# set file rv-tracing user@R0# set flag all user@R0# commit
-
En el dispositivo R2, agregue otra dirección en la interfaz de circuito cerrado.
[edit interfaces lo0 unit 0 family inet] user@R2# set address 10.4.4.4/32 user@R2# commit
-
En el dispositivo R0, compruebe el archivo de seguimiento.
user@R0> file show /var/log/rv-tracing Jan 27 11:27:43.804803 rv_get_policy_state: rt 10.4.4.4/32 origin-as 65200, validation result valid Jan 27 11:27:43.944037 task_job_create_background: create prio 7 job Route-validation GC for task Route Validation Jan 27 11:27:43.986580 background dispatch running job Route-validation GC for task Route Validation Jan 27 11:27:43.987374 task_job_delete: delete background job Route-validation GC for task Route Validation Jan 27 11:27:43.987463 background dispatch completed job Route-validation GC for task Route Validation
Significado
La validación de ruta funciona como se esperaba.
Mostrar información de validación
Propósito
Ejecute los distintos comandos de validación.
Acción
user@R0> show validation statistics Total RV records: 2 Total Replication RV records: 2 Prefix entries: 2 Origin-AS entries: 2 Memory utilization: 9789 bytes Policy origin-validation requests: 114 Valid: 32 Invalid: 54 Unknown: 28 BGP import policy reevaluation notifications: 156 inet.0, 156 inet6.0, 0
user@R0> show validation database RV database for instance master Prefix Origin-AS Session State Mismatch 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation replication database RRV replication database for instance master Prefix Origin-AS Session State 10.0.0.0/8-32 65200 10.0.0.10 valid 172.0.0.0/8-12 65200 10.0.0.10 invalid IPv4 records: 2 IPv6 records: 0
user@R0> show validation group
master
Group: test, Maximum sessions: 2
Session 10.0.0.10, State: Connect, Preference: 100user@R0> show validation session Session State Flaps Uptime #IPv4/IPv6 records 10.0.0.10 Up 0 00:02:28 1/0
user@R0> request validation policy Enqueued 2 IPv4 records Enqueued 0 IPv6 records