Validación de origen BGP
Descripción de la validación de origen para BGP
La validación de origen ayuda a evitar la publicidad involuntaria de rutas. A veces, los administradores de red anuncian erróneamente rutas a redes que no controlan. Puede resolver este problema de seguridad configurando la validación de origen (también conocida como enrutamiento seguro entre dominios). La validación de origen es un mecanismo mediante el que los anuncios de ruta se pueden autenticar como originados en un sistema autónomo (AS) esperado. La validación de origen utiliza uno o más servidores de caché de infraestructura de clave pública de recursos (RPKI) para autenticar los 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 se 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 de BGP con la base de datos de validación de rutas
- Atributo de comunidad para anunciar el estado de validación de RPKI a los vecinos de IBGP
- Enrutamiento activo sin interrupciones y validación de origen
- Marcar un intervalo de prefijos como nunca permitido
Estándares compatibles
La implementación de validación de origen de Junos OS admite las siguientes RFC y borradores:
RFC 6810, La infraestructura de clave pública de recursos (RPKI) para el protocolo de enrutador
RFC 6811, Validación de origen del prefijo BGP
Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Estado de validación de origen del prefijo BGP Comunidad extendida (soporte 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 AS.
El RPKI consiste en una colección distribuida de información. Cada entidad 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 que está disponible para cada servidor de caché RPKI.
Cada servidor de caché RPKI mantiene una memoria caché local de toda la colección de repositorios distribuidos sincronizando regularmente cada elemento de la memoria caché local con el punto de publicación del repositorio original.
En el enrutador, las entradas de la base de datos tienen el formato de registros de validación de ruta (RV). Un registro de RV es un triple (prefijo, longitud máxima, origen de AS). Hace coincidir cualquier ruta cuyo prefijo coincida con el prefijo del RV, cuya longitud de prefijo no exceda la longitud máxima indicada en el registro del RV y cuyo AS de origen sea igual al AS de origen dado en el registro del RV.
Un registro de RV es una versión simplificada de una autorización de origen de ruta (ROA). Un ROA es un objeto firmado digitalmente que proporciona un medio para comprobar que un holder de bloque de dirección IP autorizó un AS para originar enrutadores a uno o más prefijos dentro del bloque de direcciones. Los ROA no se utilizan directamente en la validación de rutas. El servidor de caché exporta una versión simplificada del ROA al enrutador como un registro de RV.
El valor máximo de longitud 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 la dirección IP para que el AS esté autorizado para anunciar.
Por ejemplo, si el prefijo de la 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 a 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 que comience con 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 extremo derecho del atributo AS_PATH. La validación de origen funciona mediante la comparación del 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 que ofrece solo la validación de origen es débil frente a un agresor determinado porque no hay protección frente a un atacante que suplantase al AS de origen. Dicho esto, la validación de origen proporciona una protección útil contra anuncios accidentales.
Aunque la validación de origen podría implementarse haciendo que cada enrutador participe directamente en el RPKI, esto se considera demasiado intensivo en recursos (porque se requieren muchas operaciones de criptografía de clave pública para validar los datos de RPKI), así como operacionalmente intensivo para establecer y mantener una configuración RPKI en cada enrutador. Por esta razón, un servidor de caché de RPKI independiente realiza validaciones de claves públicas y genera una base de datos validada de mapeos de prefijo a AS. La base de datos validada se descarga en un enrutador cliente a través de una conexión TCP segura. Por lo tanto, el enrutador requiere poca información sobre la infraestructura RPKI y no tiene requisitos de criptografía de clave pública, aparte de la contraseña de transporte cifrada. Posteriormente, el enrutador utiliza los datos descargados para validar las actualizaciones de rutas recibidas.
Al configurar sesiones de servidor, puede agruparlas y configurar los parámetros de sesión para cada sesión del grupo. El enrutador intenta periódicamente establecer un número máximo configurable de conexiones a los servidores de caché. Si la configuración de la conexión falla, periódicamente se realiza un nuevo intento de conexión.
Mientras tanto, después de aplicar la política de importación de validación a la sesión BGP, la validación de la ruta se realiza independientemente del estado de la sesión de caché (arriba o abajo) y de la base de datos de RV (vacía o no vacía). 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 último número de serie 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 vivacidad para el servidor de caché RPKI. Después de aprender todas las actualizaciones, el enrutador realiza comprobaciones periódicas de vivacidad basadas en un intervalo configurable. Esto se hace enviando una unidad de datos de protocolo de consulta 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 una PDU de fin de datos (EOD), que también actualiza el estado de vivacidad del servidor de caché y restablece un temporizador de duración de registro.
Cuando se recibe un prefijo de un par BGP externo (EBGP), se examina mediante una política de importación y se marca como válido, no válido, desconocido o no verificado:
Válido: indica que el prefijo y el par AS se encuentran en la base de datos.
Invalid: indica que se encontró el prefijo, pero que el AS correspondiente recibido del par 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 mayor 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.
Sin verificar: indica que el origen del prefijo no se verifica en la base de datos. Esto se debe a que la base de datos se rellenó y la validación no se requiere en la directiva de importación de BGP, aunque la validación de origen está habilitada o la validación de origen no está habilitada para los pares BGP.
Si hay posibles coincidencias para la ruta en la base de datos de validación, la ruta debe 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 una mejor combinación. Solo si no hay coincidencias potenciales 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 RPKI para una instancia de enrutamiento, se producirá un error en la validación RPKI con el siguiente mensaje de error.RV instance is not running
Interacción de BGP con la base de datos de validación de rutas
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 llenar la base de datos de RV con registros de RV, la base de datos de RV examina la tabla de enrutamiento RIB-Local para determinar si hay algún prefijo en RIB-Local que pueda verse afectado por los registros de RV en la base de datos. (RIB-Local contiene las rutas IPv4 e IPv6 que se muestran en el resultado del comando).show route protocol bgp
Este proceso desencadena una reevaluación BGP de las políticas de importación de BGP (no de las políticas de exportación).
Figura 2 muestra el proceso.
Las políticas de importación se aplican a RIB-In. Otra forma de entender esto es que las directivas de importación se aplican a las rutas que se muestran en la salida del comando, mientras que las directivas de exportación se aplican a las rutas que muestra el comando.show route receive-protocol bgpshow route advertising-protocol bgp
Como se muestra en , se usan políticas de enrutamiento de importación para controlar qué rutas coloca BGP en la tabla de enrutamiento y directivas de enrutamiento de exportación para controlar qué rutas anuncia BGP desde la tabla de enrutamiento a sus vecinos.Figura 3
Cuando se configura una directiva de importación de validación de ruta, la configuración de la directiva utiliza una condición de coincidencia.validation-database Esta condición de coincidencia desencadena 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 coincida 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 de BGP, la condición desencadena una búsqueda en la base de datos de RV del enrutador.from validation-database Se realiza una acción si el estado de validación es válido. La acción consiste en aceptar la ruta y establecer el valor de la tabla de enrutamiento en válido.validation-state
[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 comunidad para anunciar el estado de validación de RPKI a los vecinos de IBGP
La validación del prefijo solo se realiza para actualizaciones de BGP externas (EBGP). Dentro de un AS, es probable que no desee que se ejecute ninguna sesión de RPKI en cada enrutador interno de BGP (IBGP). En su lugar, necesita una forma de llevar el estado de validación a través de la malla de IBGP para que todos los hablantes de IBGP tengan información coherente. Esto se logra llevando el estado de validación en una comunidad extendida no transitiva. El atributo community anuncia y recibe el estado de validación de un prefijo entre vecinos de IBGP.
Junos OS admite las siguientes comunidades extendidas conocidas para la validación de rutas:
origin-validation-state-valid
origin-validation-state-invalid
origin-validation-state-unknown
La siguiente directiva 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 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 directiva de importación de BGP de ejemplo se configura en un enrutador par 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 sin interrupciones y validación de origen
Cuando se configura la validación de origen en un enrutador que tiene dos motores de enrutamiento y se habilita el enrutamiento activo sin interrupciones, tanto el motor de enrutamiento principal como el motor 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 router 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é RPKI siempre está inactiva.
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á inactiva 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 cambia y se convierte en el motor de enrutamiento principal, ya tiene una base de datos de RV completamente llena.
Para ver el contenido de las dos bases de datos, utilice los comandos y .show validation databaseshow validation replication database
Marcar un intervalo de prefijos como nunca permitido
El modelo de validación de rutas tiene una deficiencia importante: Solo proporciona actualizaciones positivas. Puede anunciar cuál 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 originó en un AS dado. Esta funcionalidad se puede proporcionar hasta cierto punto mediante una solución alternativa de AS 0.
La implementación de Junos OS no intenta restringir sus entradas desde la memoria caché. Por ejemplo, un registro del RV con un AS de origen 0 se instala y se hace coincidir al igual que cualquier otro. Esto habilita una solución para marcar un intervalo de prefijos como jamás autorizados para anunciarse porque el AS 0 no es válido. El AS en el registro del RV nunca coincide con el AS recibido del par EBGP. Por lo tanto, cualquier prefijo coincidente se marca como no válido.
Consulte también
Caso de uso y beneficio de la validación de origen para BGP
Si un administrador de un sistema autónomo (AS) comienza a anunciar la totalidad o parte de la red asignada de otra empresa, 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 clientes 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, ya que los enrutadores de la zona franca predeterminada (DFZ) llevan la ruta secuestrada. A la larga se restaura la ruta del AS correcta a los pares del BGP, pero, mientras tanto, se esperan interrupciones del servicio.
Dado que BGP se basa en un modelo de confianza transitivo, la validación entre el cliente y el proveedor es importante. En el ejemplo anterior, el operador de telecomunicaciones del AS 1 no validó el anuncio defectuoso para 10.65.153.0/24. Mediante la aceptación de este anuncio y el volver a anunciarlo a sus pares y proveedores, el AS 1 propagaba la ruta equivocada. Los enrutadores que recibieron esta ruta del AS 1 lo seleccionaron porque era una ruta más específica. El proveedor de contenido real estaba anunciando 10.65.152.0/22 antes de que ocurriera 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 BGP, se eligió el /24, 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, hay un renovado interés en las soluciones a esta vulnerabilidad. BGP es fundamental para las relaciones con los proveedores y no desaparecerá pronto. En este ejemplo se muestra una solución que usa la validación de origen. Esta solución se basa en extensiones criptográficas para BGP y un modelo 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 la validación de origen para BGP
En este ejemplo se muestra cómo configurar la validación de origen entre pares BGP garantizando que los anuncios de ruta recibidos se envían (originan) desde el sistema autónomo (AS) esperado. Si el AS de origen se valida, una política puede especificar que los prefijos, a su vez, se anuncien.
Requisitos
Este ejemplo tiene los siguientes requisitos de hardware y software:
-
Servidor de caché de infraestructura de clave pública de recursos (RPKI), que utiliza software de terceros para autenticar los prefijos BGP.
-
Junos OS versión 12.2 o posterior ejecutándose 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 un error 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 característica utiliza un servidor de caché para autenticar prefijos o rangos 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 usa la configuración predeterminada de los parámetros de validación.
La mayoría de las instrucciones de configuración disponibles son opcionales. La configuración necesaria es la siguiente:
validation { group group-name { session address { } } }
El nivel de jerarquía le permite configurar registros estáticos en un dispositivo de enrutamiento, sobrescribiendo así los registros recibidos de un servidor de caché RPKI.[edit routing-options validation static]
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 directiva de enrutamiento que funcione en función del estado de validación de un prefijo de ruta. Puede utilizar un atributo community para anunciar y recibir el estado de validación de un prefijo entre pares BGP externos (EBGP) y BGP internos (IBGP). El uso de una política de enrutamiento puede ser más conveniente en algunos enrutadores que configurar una sesión con un servidor RPKI. En este ejemplo se muestra el uso del atributo validation-state community entre pares de 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 el borrador de Internet draft-ietf-sidr-rpki-rtr-19, The RPKI/Router Protocol para enviar los registros de RV. El protocolo RPKI-Router se ejecuta sobre TCP. El dispositivo R0 utiliza los registros de RV para crear una base de datos de RV local. En el dispositivo R1, el estado de validación se establece en función de la comunidad BGP denominada validation-state, 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, a continuación, copie y pegue los comandos en la CLI en el nivel de jerarquía.[edit]
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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 política de exportación para que las rutas directas se exporten desde la tabla de enrutamiento a BGP.
send-directAplique la política de importación para establecer el estado de validación y los atributos de comunidad BGP para todas las rutas importadas (o recibidas) desde los pares EBGP del dispositivo R0.
validationConfigure 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 OSPF (u otro protocolo de puerta de enlace interior [IGP]) en la interfaz orientada 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 , debe habilitar una IGP en la interfaz de circuito cerrado.
neighborDe lo contrario, la sesión de IBGP no está establecida.[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 van a modificar en función del estado de validación de cada ruta 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
}
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Configuración del dispositivo R1
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
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 política de importación para establecer el estado de validación y los atributos de comunidad BGP para todas las rutas recibidas de los pares de IBGP del dispositivo R1.
validation-ibgpConfigure 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 directiva de enrutamiento que especifica los atributos que se van a modificar en función del atributo de comunidad BGP de estado de validación de las rutas 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Configuración del dispositivo R2
Procedimiento paso a paso
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar el dispositivo R2:
-
Configure las interfaces.
Se configuran varias direcciones 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 directiva 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 interfaces, show protocols, show policy-options y show routing-options para confirmar la configuració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;
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación de que los atributos modificados se muestran en las tablas de enrutamiento
- Uso de operaciones de seguimiento
- Visualización de la información de validación
Comprobación de que los atributos modificados se muestran en las tablas de enrutamiento
Propósito
Compruebe que las rutas 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 comando show route.
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, según 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 una ruta agregando 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.
Visualización de la 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