Monitoreo CFM entre dispositivos CE y PE

La notificación asíncrona basada en CFM permite la sincronización del estado del vínculo entre dos dispositivos CE conectados entre sí a través de un pseudocable que se origina en sus respectivos dispositivos PE Emula el escenario como si dos dispositivos CE estuvieran conectados directamente. CFM proporciona señalización de extremo a extremo incluso si PE1 y PE2 no están conectados a través de una sola red, sino a través de un conjunto de redes.

La figura 1 es un ejemplo de escenario de despliegue en el que se puede usar la notificación asincrónica basada en CFM para sincronizar el estado del vínculo entre CE1 y CE2. Los siguientes dos requisitos se pueden cumplir con la configuración de notificación asíncrona.

• Cuando el vínculo entre PE2 y CE2 disminuye, el vínculo entre PE1 y CE1 también se reduce. Cuando se restaura el enlace, también debe restaurar el estado del enlace PE1 a CE1. El cambio de estado del vínculo entre PE1 y CE1 debería funcionar de la misma manera.

• Cuando hay un problema de conectividad entre PE1 y PE2, se activa un vínculo entre PE1 y CE1 y PE2 a CE2. Si se restaura el estado de la conexión, debería restaurar el estado del vínculo en ambos extremos

Puede configurar la supervisión de CFM mediante cualquiera de las dos opciones siguientes:

• TLV de estado de la interfaz (tipo, longitud y valor): puede habilitar la supervisión de la administración de errores de conectividad (CFM) entre los dispositivos perimetrales del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo perimetral del cliente no es un dispositivo Juniper mediante el TLV de estado de la interfaz. Cuando la interfaz está inactiva, CFM propaga el estado de la interfaz utilizando el TLV de estado de la interfaz. El TLV Estado de la interfaz indica el estado de la interfaz en la que está configurado el MEP que transmite el MCP, o la interfaz siguiente inferior en el IETF RFC 2863 IF-MIB. Por lo tanto, el dispositivo perimetral del cliente es consciente de que el dispositivo perimetral del proveedor está inactivo. Para configurar la supervisión de CFM mediante el TLV de estado de interfaz, utilice la interface-status-tlv instrucción en el nivel de [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check jerarquía. Esta es la opción estándar.

• RDI (indicación remota de defectos): a partir de Junos OS versión 17.3R1, puede habilitar la supervisión de la administración de errores de conectividad (CFM) entre los dispositivos perimetrales del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo perimetral del cliente no es un dispositivo Juniper mediante el bit de indicación remota de defectos (RDI). Cuando se habilita la supervisión de CFM, CFM propaga el estado del dispositivo perimetral del proveedor a través del bit de indicación remota de defectos (RDI) en los mensajes CC. Por lo tanto, el dispositivo perimetral del cliente es consciente de que el dispositivo perimetral del proveedor está inactivo. El bit RDI se borra cuando se realiza una copia de seguridad del servicio. Para configurar la supervisión de CFM mediante el bit RDI, utilice la interface-status-send-rdi instrucción en el nivel de [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check jerarquía. Esta opción es necesaria si el dispositivo perimetral del cliente no admite el TLV de estado de interfaz.

• Caso de uso de multi-homing activo único con bit RDI
• Multihoming activo/activo Caso de uso con bit RDI

En la versión 16.1R2 y posteriores, puede configurar Junos OS para enviar el ID de remitente TLV junto con los paquetes. El TLV de ID de remitente es un TLV opcional que se envía en mensajes de comprobación de continuidad (CCM), mensajes de circuito cerrado y mensajes de seguimiento de vínculos (LTM), como se especifica en el estándar IEEE 802.1ag. El TLV del ID de remitente contiene el ID del chasis, que es la dirección MAC única basada en CFM del dispositivo, y la dirección IP de administración, que es una dirección IPv4 o IPv6.

El valor del length campo en el TLV indica si el TLV contiene o no la información del ID del chasis. Los valores posibles para el length campo son cero (0) o cualquier número válido, lo que indica la ausencia o presencia de información de ID de chasis en el TLV, respectivamente.

Puede habilitar Junos OS para que envíe el ID de remitente TLV al nivel global mediante el set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv comando. Si el TLV del ID de remitente está configurado en el nivel global, el dominio de mantenimiento predeterminado, la asociación de mantenimiento y la mitad de la función de punto intermedio de asociación de mantenimiento (MIP) heredan esta configuración.

También puede configurar el TLV de ID de remitente en los siguientes niveles jerárquicos:

• [edit protocols oam ethernet connectivity-fault-management].

• [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check].

La configuración de TLV del ID de remitente en el nivel de asociación de mantenimiento tiene prioridad sobre la configuración de nivel global.

Para VPLS no hay conectividad de extremo a extremo monitoreada. Los anillos de acceso se supervisan de forma independiente mediante la ejecución de CFM en múltiples puntos finales (MEP) en las rutas de trabajo y protección para cada uno de los servicios entre los dispositivos de dominio electrónico y los enrutadores PE de la serie MX, y entre los dispositivos de dominio A y los enrutadores PE de la serie MX, el IWF alojado por los dispositivos A-4100 de Nokia Siemens Networks. Cuando hay un fallo de conectividad en la ruta de trabajo, los dispositivos Nokia Siemens Networks Ax200 realizan un cambio a la ruta de protección, activando una notificación de cambio de topología (en forma de TLV transportados en CCM) que se enviará en la ruta activa.

Figura 1: Topología de base dual interoperacional CET

Figura 1 describe la topología de base dual en los enrutadores PE de la serie MX conectados al dominio A. Cuando un dispositivo de dominio A activa un cambio, comienza a cambiar el tráfico de servicio a la nueva ruta activa. Este cambio se comunica en las unidades de datos del protocolo HELLO (PDU) enviadas por ese dispositivo de dominio A en las rutas de trabajo y protección. Cuando el IWF en el A4100 recibe estas PDU HELLO, las convierte en mensajes CCM estándar y también inserta un TLV de protección de conexión. El campo "Protección en uso" de la TLV de protección de conexión está codificado con la ruta actualmente activa y se incluye en el mensaje del MCP. Los mensajes CCM son recibidos por los enrutadores PE de la serie MX a través del radio VLAN en A4100. En el escenario de base dual anterior, un enrutador de PE de la serie MX supervisa la ruta de trabajo y el otro enrutador de PE de la serie MX supervisa la ruta de protección.

Un vaciado de MAC se produce cuando la sesión de CFM que supervisa la ruta de trabajo detecta que el tráfico de servicio se ha movido a la ruta de protección o cuando la sesión de CFM que supervisa la ruta de protección detecta que el tráfico de servicio se ha movido a la ruta de trabajo.

Figura 2: Topología de conexión dual interoperacional CET

Figura 2 describe la topología de conexión dual en los enrutadores PE de la serie MX conectados al dominio A. El mecanismo de vaciado de MAC utilizado en este caso también es el mismo que el utilizado para el dominio A en el escenario de base dual (Figura 1). Sin embargo, en este caso, ambas sesiones de CFM están alojadas por un solo enrutador PE de la serie MX. Cuando el Ax100 en el dominio A detecta cambios en la topología, el enrutador PE de la serie MX recibe el TLV de protección de conexión en el mensaje CCM para las rutas de trabajo y protección con el valor de "Protección en uso" que indica qué ruta es la activa. Según el evento que se genere para la sesión CFM, el enrutador PE de la serie MX desplegará la interfaz adecuada que activará un vaciado de MAC local.

[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
    event {
        # If a connection protection TLV with a “Protection-in-use” value of SET is received */
        connection-protection-tlv <using-protection-path>;
        # If a connection protection TLV with a “Protection-in-use” value of RESET is received */
        connection-protection-tlv <using-working-path>;
    }
    action {
        # Bring the interface down */
        interface-down;
    }
}

En este ejemplo se muestra cómo configurar un perfil de acción basado en la TLV de protección de conexión con el fin de desencadenar vaciados de MAC basados en cambios de topología en una red CET.