Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP validación de origen

Descripción de la validación de origen para BGP

La validación de origen ayuda a evitar el anuncio involuntario de rutas. En ocasiones, los administradores de red anuncian erróneamente las rutas a las redes que no controlan. Puede resolver este problema de seguridad si configura la validación de origen (también conocida como enrutamiento de interdominio seguro). 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 usa uno o más servidores de caché de infraestructura de claves públicas (RPKI) de recursos para realizar la autenticación de los prefijos especificados de BGP. Para autenticar un prefijo, el enrutador (anunciador BGP) consulta a la base de datos de las asignaciones validadas de prefijo, que se descargan desde el servidor de caché, y garantiza que el prefijo se originó a partir de lo esperado.

Nota:

Cuando habilita la autenticación RPKI, Junos OS abre automáticamente el puerto TCP 2222 sin previo aviso. Puede aplicar un filtro para bloquear y proteger este puerto.

Junos OS admite la validación de origen para los prefijos IPv4 e IPv6.

Figura 1muestra una topología de ejemplo.

Figura 1: Topología de ejemplo para la validación de origenTopología de ejemplo para la validación de origen

Estándares compatibles

La Junos OS implementación de validación de origen admite las siguientes RFC y borradores:

  • RFC 6810, la infraestructura de clave pública de recursos (RPKI) para el protocolo de enrutador

  • RFC 6811, BGP validación de origen de prefijo

  • Borrador de Internet draft-ietf-Sidr-Origin-Validation-Signaling-00, BGP del prefijo de origen estado de validación comunidad amplia (soporte parcial)

    La comunidad extendida (estado de validación de origen) se admite en Junos OS Directiva de enrutamiento. No se admite el cambio especificado en el procedimiento de selección de ruta.

Cómo funciona la validación de origen

La validación de RPKI y de origen usa certificados X. 509 con extensiones especificadas en RFC 3779, extensiones x. 509 para direcciones IP y identificadores de as.

El RPKI está formado por una recopilació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 conforman un conjunto completo de información que está disponible para todos los servidores de caché RPKI.

Cada servidor de caché RPKI mantiene una caché local de toda la colección de repositorios distribuidos, sincronizando regularmente cada elemento en la caché local con el punto de publicación del repositorio original.

En el enrutador, las entradas de la base de datos se formatean como registros de validación de ruta (RV). Un registro RV es un (prefijo, longitud máxima, origen como) triple. Coincide con cualquier ruta cuyo prefijo coincida con el prefijo RV, cuya longitud de prefijo no supera la longitud máxima proporcionada en el registro RV y cuyo origen es igual al origen que el registro RV.

Un registro 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 de comprobar que un titular de bloque de dirección IP ha autorizado rutas de AS para originarlas a uno o más prefijos dentro del bloque de direcciones. ROAs no se utilizan directamente en la validación de ruta. El servidor de caché exporta al enrutador una versión simplificada de ROA como registro 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 en la familia de direcciones (32 para IPv4 y 128 para IPv6). La longitud máxima define el prefijo de dirección IP que el ya está autorizado a 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 anunciarse 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 sólo está autorizado para anunciar exactamente el prefijo especificado en RV.

Otro ejemplo sería 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. Esta RV autoriza al AS para que anuncie 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 se representa por el número de la parte más a la derecha del atributo AS_PATH. La validación de origen funciona comparando el origen como en una actualización de enrutamiento con el origen autorizado tal como se publica en los registros de RV.

La seguridad proporcionada por la validación de origen solo se sabe que es débil frente a un agresor determinado, ya que no hay protección frente a este atacante que suplantase al origen como. Dicho esto, la validación de origen ofrece 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 un uso intensivo de recursos (ya que muchas operaciones de cifrado de clave pública son necesarias para validar los datos de RPKI) así como de manera operativo gran cantidad de espacio para configurar 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 asignaciones de prefijo a AS. La base de datos validada se descarga en un enrutador de cliente a través de una conexión TCP segura. Por lo tanto, el enrutador requiere poca información acerca de la infraestructura de RPKI y no tiene ningún requisito de criptografía de clave pública, aparte de la contraseña de transporte cifrada. El enrutador utiliza posteriormente los datos descargados para validar las actualizaciones de ruta recibidas.

Cuando configure las sesiones del servidor, puede agrupar las sesiones y configurar los parámetros de sesión para cada sesión del grupo. El enrutador intenta establecer periódicamente un número máximo configurable de conexiones a los servidores de caché. Si falla la configuración de la conexión, se realiza periódicamente un nuevo intento de conexión.

Mientras tanto, una vez aplicada la Directiva de importación de validación a la sesión BGP, la validación de ruta se realiza independientemente de que el estado de la sesión de caché (arriba o abajo) y la base de datos RV (vacías o no vacías). Si la base de datos 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, porque no existe ningún registro RV para evaluar un prefijo de BGP recibido.

El periodo de reintentos de intentos es configurable. Después de conectarse correctamente a un servidor de caché, el enrutador consulta el número de serie de la base de datos más reciente y solicita que la memoria caché de RPKI transmita todas las entradas RV que pertenecen a esa versión de la base de datos.

Cada mensaje entrante restablece un temporizador liveliness para el servidor de caché RPKI. Una vez que se han aprendido todas las actualizaciones, el enrutador realiza comprobaciones periódicas liveliness basándose en un intervalo configurable. Esto se hace mediante el envío de una unidad de datos de protocolo de consulta serie (PDU) con el mismo número de serie que el servidor de caché en su PDU de notificación más reciente. 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 liveliness del servidor de caché y restablece un temporizador de duración de registro.

Cuando se recibe un prefijo de un BGP externo (EBGP) del mismo nivel, lo examina la Directiva de importación y lo marca como válido, no válido, desconocido o sin verificar:

  • Válido: indica que el prefijo y el par de AS se encuentran en la base de datos.

  • No válido: 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 la longitud del prefijo en el mensaje de actualización de 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 los intervalos de prefijo en la base de datos.

  • Sin verificar (Unverified): indica que el origen del prefijo no se comprueba en la base de datos. Esto se debe a que la base de datos se llenó y no se llama a la validación de la Directiva de importación BGP, aunque está habilitada la validación de origen o a que la validación de origen no está habilitada para el BGP iguales del mismo nivel.

Si existe alguna coincidencia potencial para la ruta en la base de datos de validación, la ruta tiene que coincidir con una de ellas para que sea válida. De lo contrario, no es válido. Cualquier coincidencia es adecuada para que la ruta sea válida. No es necesario que sea la mejor coincidencia. La ruta considerada como desconocida sólo si no hay coincidencias potenciales. 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, BGP validación del prefijo de origen.

Nota:

La validación de RPKI solo está disponible en la instancia principal. Si configura la validación de RPKI para una instancia de enrutamiento, la validación del RPKI fallará por el RV instance is not runningsiguiente mensaje de error.

BGP interacción con la base de datos de validación de ruta

La base de datos de validación de rutas (RV) contiene una colección de registros RV que descarga el enrutador del servidor de caché de RPKI. Después de que la base de datos RV se haya llenado con registros de RV, la base de datos RV explorará la tabla RIB – encaminamiento local para determinar si existe algún prefijo en RIB-local que pueda verse afectado por los registros RV de la base de datos. (RIB-local contiene las rutas IPv4 e IPv6 que se muestran en la salida show route protocol bgp del comando.)

Este proceso activa una BGP reevaluación de BGP políticas de importación (no de las políticas de exportación).

Figura 2muestra el proceso.

Figura 2: Validación de BGP y rutas

Las políticas de importación se aplican a los SALIENTEs. Otra forma de comprender esto es que las directivas de importación se aplican a las rutas que se muestran en el show route receive-protocol bgp resultado del comando, mientras que las políticas de exportación se aplican a show route advertising-protocol bgp las rutas que muestra el comando.

Tal y como Figura 3se muestra en la, puede utilizar la importación de políticas de enrutamiento para controlar qué rutas BGP lugares en la tabla de enrutamiento y exportar las políticas de enrutamiento para controlar qué rutas BGP anuncia desde la tabla de enrutamiento a sus vecinos.

Figura 3: Importación y exportación de directivas de enrutamientoImportación y exportación de directivas de enrutamiento

Cuando configura una directiva de importación de validación de ruta, la configuración de la validation-database directiva utiliza una condición de coincidencia. Esta condición de coincidencia desencadena una consulta en la base de datos 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 a la instancia principal.

En el siguiente BGP política de importación, la from validation-database condición desencadena una búsqueda en la base de datos 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 definir el validation-state de la tabla de enrutamiento como válido.

Atributo Community para anunciar el estado de validación de RPKI a vecinos IBGP

El prefijo de validación solo se realiza para las actualizaciones de BGP externas (EBGP). Dentro de un AS, es probable que no desee que se ejecute una sesión de RPKI en cada enrutador interno de BGP (IBGP). En su lugar, necesitará una manera de llevar el estado de validación a través de la malla IBGP para que todos los altavoces de la IBGP tengan información coherente. Esto se logra llevando el estado de validación en una comunidad no transitiva extendida. El atributo Community anuncia y recibe el estado de validación de un prefijo comprendido entre IBGP vecinos.

Junos OS admite las siguientes comunidades extendidas conocidas para la validación de rutas:

  • Estado de validación de origen-válido

  • Estado de validación de origen-no válido

  • Estado-de-validación-origen-desconocido

El siguiente ejemplo BGP Directiva de importación se configura en el enrutador que tiene una sesión con un servidor RPKI.

Enrutador con sesión RPKI

El siguiente ejemplo BGP Directiva de importación está configurado en un enrutador de IBGP interlocutor que no tiene una sesión con un servidor RPKI.

Enrutador de IBGP peer sin sesión de RPKI

Validación de origen y enrutamiento activo no detenido

Cuando configure la validación de origen en un enrutador que tenga dos motores de enrutamiento y enrutamiento activo sin desoír está habilitado, tanto los motores de enrutamiento principal como el en espera tienen una copia de la base de datos del RV. Estas dos bases de datos RV permanecen sincronizadas entre sí.

El enrutador no mantiene dos sesiones idénticas con el servidor RPKI. El protocolo RPKI-RTR se ejecuta solo en la motor de enrutamiento principal. En el motor de enrutamiento en espera, la sesión del servidor de caché RPKI está siempre inactiva.

La base de datos de RV se mantiene activamente mediante el motor de enrutamiento principal durante su sesión con el servidor RPKI. Esta base de datos está replicada en el motor de enrutamiento en espera. Aunque la sesión está inactiva en el motor de enrutamiento de reserva, la base de datos replicada RV sí contiene registros de RV. Cuando el servidor motor de enrutamiento activa 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 show validation database comandos show validation replication database y.

Marcar un intervalo de prefijo como nunca permitido

El modelo de validación de ruta tiene una lagunas principales: Solo proporciona actualizaciones positivas. Puede declarar cuál 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 en cierta medida mediante el uso de una solución AS 0.

La implementación de Junos OS no intenta restringir sus entradas de la caché. Por ejemplo, un registro RV con origen como 0 se instala y se asocia al igual que cualquier otro. Esto habilita una solución para marcar un intervalo de prefijo como nunca autorizado para ser anunciado porque 0 no es un AS válido. El como en el registro RV nunca coincide con el AS recibido desde el igual de EBGP. Por lo tanto, cualquier prefijo coincidente se marca como no válido.

Caso de uso y ventajas de la validación de origen para BGP

Si un administrador de un sistema autónomo comienza a anunciar toda o parte de la red asignada a otra compañía, BGP no dispone de un método integrado para reconocer el error y responder de un modo que permita evitar interrupciones de servicio.

Suponga, por ejemplo, que un administrador de una red de clientes anuncia erróneamente una ruta (por ejemplo, 10.65.153.0/24) que dirige el tráfico al proveedor de servicios del cliente AS 1. 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 a AS 2. Debido a la forma en que los enrutadores funcionan, la mayoría de los enrutadores seleccionan la ruta más específica y envían tráfico a AS 1 en lugar de AS 2.

El prefijo secuestrado se ve ampliamente en Internet como si los enrutadores de tránsito propaguen la información de ruta actualizada. Las rutas no válidas pueden distribuirse a lo largo de Internet, ya que los enrutadores de la zona libre predeterminada (DFZ) transportan la ruta secuestrada. Finalmente, se restaura la ruta de acceso "correcto como" en BGP iguales, pero mientras tanto se esperarán interrupciones del servicio.

Dado que BGP se basa en un modelo de confianza transitiva, es importante la validación entre el cliente y el proveedor. En el ejemplo anterior, el proveedor de servicios AS 1 no validó el anuncio defectuoso para 10.65.153.0/24. Aceptando este anuncio y volver a anunciarlo a sus colegas y proveedores a medida que 1 se propagó con una ruta equivocada. Los enrutadores que recibieron esta ruta desde el 1 lo seleccionaron porque fue una ruta más específica. El proveedor de contenido real fue 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 rutas BGP,/24 se ha elegido, por lo que completa de forma eficaz el secuestro.

Incluso con la rápida detección y reacción del proveedor de contenidos y la cooperación con otros proveedores, se puede interrumpir el servicio por su prefijo durante muchos minutos, hasta varias horas. La duración exacta de la interrupción depende de su punto de Vantage en Internet. Cuando se produce este tipo de eventos, se renuevan los intereses de las soluciones a esta vulnerabilidad. BGP es fundamental para las relaciones con los proveedores y no estará en el futuro. Este ejemplo muestra una solución que utiliza validación de origen. Esta solución se basa en las extensiones criptográficas que BGP y un modelo cliente-servidor para evitar la sobreutilización de las CPU de enrutadores.

La validación de origen ayuda a superar la vulnerabilidad de la confianza transitiva al permitir a un proveedor limitar los anuncios que acepta de un cliente. Los mecanismos implican la comunicación de las políticas de enrutamiento basadas en un atributo de la comunidad BGP extendido.

Ejemplo Configuración de validación de origen para BGP

En este ejemplo se muestra cómo configurar la validación de origen entre BGP elementos del mismo nivel asegurándose de que se envían (se originan) los anuncios de ruta recibidos del sistema autónomo esperado (AS). Si el origen es el mismo que el que se valida, una Directiva puede especificar que los prefijos se anuncien, a su vez, a.

Aplicables

Este ejemplo tiene los siguientes requisitos de hardware y software:

  • Servidor de caché de infraestructura de claves públicas (RPKI) de recursos, que utiliza software de terceros para autenticar BGP prefijos.

  • Junos OS versión 12,2 o posterior que 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 un error del operador. Para evitar este problema de seguridad, puede configurar BGP para validar los datos de AS y rechazar estos anuncios no válidos. Esta característica utiliza un servidor de caché para autenticar prefijos o intervalos de prefijos.

Las siguientes declaraciones de configuración permiten el origen como validación:

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:

El [edit routing-options validation static] nivel de jerarquía permite configurar registros estáticos en un dispositivo de enrutamiento, con lo que se sobrescriben los registros recibidos de un servidor de caché RPKI.

Por ejemplo:

Puede configurar una directiva de enrutamiento que funcione en función del 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 los pares de BGP externos (EBGP) e internos BGP (IBGP). Puede ser más conveniente utilizar una directiva de enrutamiento en algunos enrutadores que la configuración de una sesión con un servidor RPKI. En este ejemplo se muestra el uso del atributo Community de estado de validación entre IBGP homólogos.

Figura 4muestra la topología de ejemplo.

Figura 4: Topología para validación de origenTopología para validación de origen

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, el protocolo de RPKI/enrutador para enviar los registros de RV. El protocolo de RPKI de enrutadores se ejecuta sobre TCP. Los registros RV se utilizan en el dispositivo R0 para generar una base de datos RV local. En el dispositivo R1, el estado de validación se establece en función de la comunidad BGP denominada estado de validación, que se recibe con la ruta.

Automática

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y [edit] pegue los comandos en la CLI en el nivel de jerarquía.

Dispositivo R0

Dispositivo R1

Dispositivo R2

Configurando el dispositivo R0

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre 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 CLI de Junos os.

Para configurar R0 de dispositivos:

  1. Configure las interfaces.

  2. Configure BGP.

    Aplique la send-direct Directiva de exportación para que las rutas directas se exporten desde la tabla de enrutamiento hasta BGP.

    Aplique la validation política de importación para establecer los atributos de estado de validación y BGP comunidad para todas las rutas importadas (o recibidas) desde los pares de dispositivos R0'S EBGP.

    Configure una sesión IBGP con el dispositivo R1. Configure una sesión EBGP con el dispositivo R2.

  3. Configure OSPF (u otro protocolo de puerta de enlace interior [IGP]) en la interfaz que enfrenta el IBGP igual y en la interfaz de bucle invertido.

    Nota:

    Si utiliza la dirección de interfaz de bucle invertido en neighbor la instrucción IBGP, debe activar una IGP en la interfaz de bucle invertido. De lo contrario, no se establece la sesión IBGP.

  4. Configure la Directiva de enrutamiento que exporta rutas directas de la tabla de enrutamiento a BGP.

  5. Configure la Directiva de enrutamiento que especifique los atributos que se modificarán en función del estado de validación de cada ruta BGP.

  6. Configure la sesión con el servidor de caché RPKI.

  7. Configure el sistema autónomo (AS) como número.

Resultados

Desde el modo de configuración, para confirmar la configuración show interfaces, show protocolsescriba show policy-optionslos comandos show routing-options ,, y. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Configuración del dispositivo R1

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre 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 CLI de Junos os.

Para configurar el dispositivo R1:

  1. Configure las interfaces.

  2. Configure BGP.

    Aplique la validation-ibgp política de importación para establecer los atributos de estado de validación y BGP comunidad para todas las rutas recibidas del dispositivo R1'S IBGP los pares.

    Configure una sesión de IBGP con el dispositivo R0.

  3. Configure OSPF.

  4. Configure la Directiva de enrutamiento que especifique los atributos que se deben modificar en función del estado de validación BGP atributo Community del BGP rutas recibidas del dispositivo R0.

  5. Configure el sistema autónomo (AS) como número.

Resultados

Desde el modo de configuración, para confirmar la configuración show interfaces, show protocolsescriba show policy-optionslos comandos show routing-options ,, y. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Configurando el dispositivo R2

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre 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 CLI de Junos os.

Para configurar el dispositivo R2:

  1. Configure las interfaces.

    Se configuran varias direcciones en la interfaz de bucle de retroceso para que sirvan como rutas a efectos de demostración.

  2. Configure BGP.

  3. Configure la Directiva de enrutamiento.

  4. Configure el sistema autónomo (AS) como número.

Resultados

Desde el modo de configuración, para confirmar la configuración show interfaces, show protocolsescriba show policy-optionslos comandos show routing-options ,, y. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Verificación de que los atributos modificados se muestran en las tablas de enrutamiento

Purpose

Compruebe que las rutas BGP en los R0 de dispositivo y que el dispositivo R1 tienen los Estados de validación esperados y las preferencias locales esperadas.

Intervención

En modo operativo, escriba el show route comando.

Efectos

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

Purpose

Configure operaciones de seguimiento para la validación de origen y supervise los resultados de una ruta recién anunciada.

Intervención
  • En R0 del dispositivo, configure el seguimiento.

  • En el dispositivo R2, agregue una ruta agregando otra dirección a la interfaz de bucle invertido.

  • En R0 de dispositivo, compruebe el archivo de seguimiento.

Efectos

La validación de ruta funciona como se esperaba.

Mostrar información de validación

Purpose

Ejecute los distintos comandos de validación.

Intervención