Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

Configuración de la administración de errores de conectividad (CFM)

Utilice este tema para configurar funciones de administración de errores de conectividad, como dominios de mantenimiento, asociaciones de mantenimiento, puntos intermedios de mantenimiento (MIP) y parámetros de comprobación de continuidad. También puede usar este tema para configurar un perfil de acción para especificar la acción CFM que se debe realizar cuando se produce un evento CFM específico.

Creación de un dominio de mantenimiento

Para habilitar la administración de errores de conectividad (CFM) en una interfaz Ethernet, primero debe configurar un dominio de mantenimiento y especificar el nombre del dominio de mantenimiento. También puede especificar el formato del nombre. Por ejemplo, si especifica el formato de nombre como formato de servicio de nombre de dominio (DNS), puede especificar el nombre del dominio de mantenimiento como www.juniper.net. El formato de nombre predeterminado es cadena de caracteres ASCII.

Nota:

Para las interfaces lógicas, el nombre de dominio de mantenimiento debe ser único en todos los sistemas lógicos. Si configura el mismo nombre de dominio de mantenimiento en sistemas lógicos, recibirá el siguiente mensaje de error: error: configuration check-out failed.

Durante la creación del dominio de mantenimiento, también puede especificar el nivel de dominio de mantenimiento. El nivel de dominio de mantenimiento indica la relación de anidamiento entre varios dominios de mantenimiento. El nivel de dominio de mantenimiento está integrado en cada una de las tramas CFM.

Para crear un dominio de mantenimiento:

  1. En el modo de configuración, cree un dominio de mantenimiento especificando el nombre y el formato de nombre en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management ].
    Nota:

    Si configura la longitud del nombre de dominio de mantenimiento mayor que 45 octetos, se mostrará el siguiente mensaje de error: error: configuration check-out failed.

  2. Especifique el nivel de dominio de mantenimiento especificando el valor en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management ].

Configuración de puntos intermedios de mantenimiento (MIC)

Los enrutadores serie MX admiten puntos intermedios de mantenimiento (MIP) para el protocolo CFM Ethernet OAM 802.1ag a nivel de dominio de puente. Esto le permite definir un dominio de mantenimiento para cada nivel predeterminado. Los nombres de los MIC se crean como default-level-number en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain] nivel de jerarquía. Utilice las bridge-domainopciones , instance, virtual-switchy mip-half-function MIP para especificar la configuración de MIP.

Utilice el show oam ethernet connectivity-fault-management mip (bridge-domain | instance-name | interface-name) comando para mostrar las configuraciones de MIP.

Para configurar el punto intermedio de mantenimiento (MIP):

  1. Configure un dominio de puente en un conmutador virtual definido por el usuario especificando la virtual-switch instrucción y el nombre del conmutador virtual definido por el usuario, en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name default-x] nivel de jerarquía.
    Nota:

    Un dominio de puente solo se debe especificar por nombre si está configurado mediante la inclusión de la vlan-id instrucción en la virtual-switch instrucción. Si un dominio de puente está configurado con un intervalo de ID de VLAN, los ID de VLAN se deben enumerar explícitamente después del nombre de dominio del puente.

    Nota:

    También puede configurar el dominio de puente para el conmutador virtual predeterminado incluyendo la bridge-domain instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] nivel de jerarquía.

  2. Configure la instancia de enrutamiento VPLS para el dominio de mantenimiento predeterminado.
  3. Configure la mitad de la función de punto intermedio de mantenimiento (MIP) para dividir la fuctionalidad del MIP en dos segmentos unidireccionales para mejorar la cobertura de la red mediante el aumento de la cantidad de MIC que se monitorean. La función de medio MIP también responde a los mensajes de circuito cerrado y de seguimiento de vínculos para identificar errores.
    Nota:

    Siempre que se configura un MIP y se asigna un dominio de puente a varios dominios de mantenimiento o asociaciones de mantenimiento, es esencial que el mip-half-function valor de todos los dominios de mantenimiento y asociaciones de mantenimiento sea el mismo.

Configuración de puntos intermedios de asociación de mantenimiento en la serie ACX

El punto intermedio de mantenimiento (MIP) ofrece capacidad de monitoreo de puntos intermedios para servicios como puente de capa 2, circuito de capa 2 y VPN de capa 2. Los enrutadores ACX5048 y ACX5096 admiten MIC para el protocolo CFM Ethernet OAM 802.1ag. Utilice las opciones de MIP de dominio de puente, interfaz y mip-half-function para especificar la configuración de MIP.

Nota:

Los enrutadores ACX5048 y ACX5096 no admiten la configuración MIP en los servicios VPLS.

Nota:

El enrutador ACX5448 no es compatible con MIP.

Nota:

Siempre que se configura un MIP y se asigna un dominio de puente a varios dominios de mantenimiento o asociaciones de mantenimiento, es esencial que el mip-half-function valor de todos los dominios de mantenimiento y asociaciones de mantenimiento sea el mismo.

Para mostrar configuraciones MIP, utilice el show oam ethernet connectivity-fault-management mip (bridge-domain | instance-name | interface-name) comando.

Las siguientes configuraciones MIP se admiten en enrutadores ACX5048 y ACX5096:

  • MIP con dominio de puente

  • MIP con conexión cruzada de circuito (CCC)

  • MIP con dominio de puente cuando se configura el punto final de la asociación de mantenimiento

  • MIP con CCC cuando se configura el punto final de la asociación de mantenimiento

En las siguientes secciones se describe la configuración de MIP:

Configurar el dominio de puente de dominio de mantenimiento

Para configurar el dominio de puente, incluya la vlans instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name] nivel de jerarquía.

Nota:

Las configuraciones de CLI de capa 2 y los comandos show para enrutadores ACX5048 y ACX5096 varían en comparación con otros enrutadores serie ACX. Para obtener más información, consulte Modo de última generación de capa 2 para la serie ACX.

Configuración de la función de mitad de MIP de dominio de mantenimiento

La función media de MIP (MHF) divide la funcionalidad del MIP en dos segmentos unidireccionales, mejora la visibilidad con una configuración mínima y mejora la cobertura de la red mediante el aumento de la cantidad de puntos que se pueden monitorear. MHF extiende la capacidad de monitoreo respondiendo a mensajes de circuito cerrado y seguimiento de vínculos para ayudar a aislar fallas.

Siempre que se configura un MIP y se asigna un dominio de puente a varios dominios de mantenimiento o asociaciones de mantenimiento, es esencial que el valor de la mitad de la función MIP para todos los dominios de mantenimiento y asociaciones de mantenimiento sea el mismo. Para configurar la función de medio MIP, incluya la mip-half-function instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name] nivel de jerarquía.

Configuración de los puntos intermedios de asociación de mantenimiento con dominio de puente

En los enrutadores ACX5048 y ACX5096, puede configurar el MIP con un dominio de puente. A continuación, se muestra un ejemplo para configurar el MIP con un dominio de puente:

Configuración de los puntos intermedios de asociación de mantenimiento con conexión cruzada de circuito

En los enrutadores ACX5048 y ACX5096, puede configurar el MIP con conexión cruzada de circuito (CCC). A continuación, se muestra un ejemplo para configurar el MIP con CCC:

Configuración de los puntos intermedios de asociación de mantenimiento con dominio de puente cuando se configura el punto final de la asociación de mantenimiento

En los enrutadores ACX5048 y ACX5096, puede configurar el MIP con un dominio de puente cuando se configura un punto final de asociación de mantenimiento (MEP). A continuación, se muestra un ejemplo para configurar el MIP con un dominio de puente cuando se configura MEP:

Configuración de los puntos intermedios de mantenimiento con conexión cruzada de circuito cuando se configura el punto final de la asociación de mantenimiento

En los enrutadores ACX5048 y ACX5096, puede configurar el MIP con conexión cruzada de circuito (CCC) cuando se configura un punto final de asociación de mantenimiento (MEP). A continuación, se muestra un ejemplo para configurar el MIP con CCC cuando se configura MEP:

Creación de una asociación de mantenimiento

Para crear una asociación de mantenimiento, incluya la maintenance-association ma-name instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] nivel de jerarquía.

Los nombres de asociación de mantenimiento pueden estar en uno de los siguientes formatos:

  • Como una cadena de caracteres ASCII sin formato

  • Como identificador vlan de la VLAN que asocia principalmente con la asociación de mantenimiento

  • Como identificador de dos octetos en el intervalo de 0 a 65 535

  • Como un nombre en el formato especificado por RFC 2685

El formato de nombre corto predeterminado es una cadena de caracteres ASCII.

Para configurar el formato de nombre corto de la asociación de mantenimiento, incluya la short-name-format (character-string | vlan | 2octet | rfc-2685-vpn-id) instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name] nivel de jerarquía.

Descripción general de los parámetros del protocolo de comprobación de continuidad

El protocolo de comprobación de continuidad se utiliza para la detección de fallas por puntos de final de mantenimiento (MEP) dentro de una asociación de mantenimiento. El MEP envía periódicamente mensajes de multidifusión de comprobación de continuidad. Los paquetes de protocolo de comprobación de continuidad utilizan el valor ethertype 0x8902 y la dirección MAC de destino de multidifusión 01:80:c2:00:00:32.

En la siguiente lista se describen los parámetros del protocolo de comprobación de continuidad que puede configurar:

  • interval— Frecuencia de los mensajes de verificación de continuidad (MCP), es decir, tiempo entre la transmisión de los mensajes del MCP. Puede especificar 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milisegundos (100ms) o 10 milisegundos (10ms). El valor predeterminado es 1 minuto. Por ejemplo, si especifica el intervalo como 1 minuto, el MEP envía los mensajes de comprobación de continuidad cada minuto al MEP receptor.

    Nota:

    Para que el intervalo de mensajes de comprobación de continuidad se configure durante 10 milisegundos, la administración periódica de paquetes (PPM) se ejecuta en el motor de enrutamiento y en el motor de reenvío de paquetes de forma predeterminada. Solo puede deshabilitar PPM en el motor de reenvío de paquetes. Para deshabilitar PPM en el motor de reenvío de paquetes, utilice la no-delegate-processing instrucción en el [edit routing-options ppm] nivel de jerarquía.

    No se admite un intervalo de comprobación de continuidad de 10 milisegundos para sesiones CFM a través de una interfaz conmutada por etiquetas (LSI).

  • hold-interval— Frecuencia en la que se puede vaciar la base de datos MEP, si no se producen actualizaciones. Los diputados receptores utilizan los mensajes de verificación de continuidad para crear una base de datos de MEP de todos los diputados de la asociación de mantenimiento. La frecuencia es el número de minutos que debe esperar antes de vaciar la base de datos del MEP si no se producen actualizaciones. El valor predeterminado es de 10 minutos.

    Nota:

    El vaciado basado en temporizador de retención solo se aplica a los diputados remotos descubiertos automáticamente y no a los diputados remotos configurados estáticamente.

    La lógica de intervalo de retención ejecuta un temporizador de sondeo por nivel de sesión CFM (no por nivel MEP remoto) donde la duración del temporizador de sondeo es igual al tiempo de espera configurado. Cuando caduca el temporizador de sondeo, elimina todas las entradas MEP remotas descubiertas automáticamente que han estado en estado de error durante un período de tiempo igual o mayor que el tiempo de espera configurado. Si el MEP remoto completa la duración del tiempo de espera en el estado de error, el vaciado no se producirá hasta que expire el próximo temporizador de sondeo. Por lo tanto, es posible que el vaciado del MEP remoto no ocurra exactamente en el tiempo de espera configurado.

  • loss-threshold— Número de mensajes de comprobación de continuidad que se pueden perder antes de que el enrutador marque el MEP como caído. El valor puede ser de 3 a 256 unidades de datos de protocolo (PDU). El valor predeterminado es 3 PDU.

Configuración de parámetros de protocolo de comprobación de continuidad para la detección de fallas

El protocolo de comprobación de continuidad se utiliza para la detección de fallas por un punto final de asociación de mantenimiento (MEP) dentro de una asociación de mantenimiento. Un MEP genera y responde periódicamente a los mensajes de multidifusión de comprobación de continuidad. Los paquetes de protocolo de comprobación de continuidad utilizan el valor ethertype 0x8902 y la dirección MAC de destino de multidifusión 01:80:c2:00:00:32. Los diputados receptores utilizan los mensajes de verificación de continuidad (MCC) para crear una base de datos de MEP de todos los diputados de la asociación de mantenimiento.

Para configurar parámetros de protocolo de comprobación de continuidad:

  1. Especifique el tiempo de espera en minutos antes de vaciar la base de datos del MEP, si no se producen actualizaciones, con un valor de 1 minuto a 30 240 minutos. El valor predeterminado es de 10 minutos.
    Nota:

    El vaciado basado en el temporizador de retención solo se aplica a los diputados remotos descubiertos automáticamente y no a los diputados remotos configurados estáticamente.

  2. Especifique el tiempo de espera (duración) entre las transmisiones de MCC. La duración puede ser uno de los siguientes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milisegundos (100 m) o 10 milisegundos (10 m). El valor predeterminado es 1 minuto.
  3. Especifique el número de mensajes de comprobación de continuidad que se pueden perder antes de que el enrutador marque el MEP como caído. El valor puede ser de 3 a 256 unidades de datos de protocolo (PDU). El valor predeterminado es 3 PDU.

Configuración de un MEP para generar y responder a mensajes de protocolo CFM

Un punto final de asociación de mantenimiento (MEP) hace referencia al límite de un dominio. Un MEP genera y responde a los mensajes de protocolo de administración de fallas de conectividad (CFM). Puede configurar varios MEP para una sola combinación de ID de asociación de mantenimiento e ID de dominio de mantenimiento para interfaces que pertenecen a un servicio VPLS determinado o a un dominio de puente. Puede configurar varios MEP descendentes para una sola instancia de identificador de dominio de mantenimiento y nombre de asociación de mantenimiento para supervisar los servicios proporcionados por el servicio de LAN privada virtual (VPLS), el dominio de puente, la conexión cruzada de circuitos (CCC) o los dominios IPv4.

Para instancias de enrutamiento VPN de capa 2 (conmutación local) e instancias de enrutamiento EVPN, también puede configurar varios MEP para una sola combinación de ID de asociación de mantenimiento e ID de dominio de mantenimiento en interfaces lógicas. La interfaz lógica se puede configurar en distintos dispositivos o en el mismo dispositivo. Para admitir varios MEP en dos IFLs, se deben configurar servicios de red IP mejorados para el chasis.

Puede habilitar la detección automática de un MEP. Con el descubrimiento automático, un MEP está habilitado para aceptar mensajes de verificación de continuidad (MCC) de todos los diputados remotos de la misma asociación de mantenimiento. Si no está habilitada la detección automática, se deben configurar los MEP remotos. Si el MEP remoto no está configurado, los MCC del MEP remoto se tratan como errores.

La medición de continuidad se proporciona mediante un protocolo de verificación de continuidad existente. La continuidad de cada MEP remoto se mide como el porcentaje de tiempo que el MEP remoto estuvo operativo sobre el tiempo total habilitado administrativamente. Aquí, el tiempo de actividad operativo es el tiempo total durante el cual la adyacencia del MCP está activa para un MEP remoto en particular y el tiempo de habilitación administrativa es el tiempo total durante el cual el MEP local está activo. También puede reiniciar la medición de continuidad borrando el tiempo de actividad operativo medido actualmente y el tiempo de actividad administrativo habilitado.

Configuración de un punto final de asociación de mantenimiento (MEP)

Para configurar un punto final de asociación de mantenimiento:

  1. Especifique un ID para el MEP en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. Puede especificar cualquier valor del 1 al 8191.
  2. Habilite la detección automática del punto final de mantenimiento para que el MEP pueda aceptar mensajes de comprobación de continuidad (MCC) de todos los diputados remotos de la misma asociación de mantenimiento.
  3. Especifique la dirección en la que se transmiten los paquetes de MCP para el MEP. Puede especificar arriba o abajo. Si especifica la dirección como ascendente, las CCM se transmiten desde todas las interfaces lógicas que forman parte de la misma instancia de puente o VPLS, excepto para la interfaz configurada en el MEP. Si especifica la dirección como hacia abajo, las CCM se transmiten solo fuera de la interfaz configurada en el MEP.
    Nota:

    Los puertos del estado de bloqueo del protocolo de árbol de expansión (STP) no bloquean los paquetes CFM destinados a un MEP caído. Los puertos en un estado de bloqueo STP sin el protocolo de comprobación de continuidad configurado bloquean paquetes CFM.

    Nota:

    A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM. Para todas las demás interfaces en enrutadores de la serie MX y en todos los demás enrutadores y conmutadores, debe seguir configurando la no-control-word instrucción en el [edit routing-instances routing-instance-name protocols l2vpn] nivel de jerarquía o [edit protocols l2circuit neighbor neighbor-id interface interface-name] cuando configure los MEP de CFM. De lo contrario, los paquetes CFM no se transmiten y el show oam ethernet connectivity-fault-management mep-database comando no muestra ningún MEP remoto.

  4. Especifique la interfaz a la que está asociado el MEP. Puede ser una interfaz física, lógica o troncal. En los enrutadores serie MX, el MEP se puede conectar a una VLAN específica de una interfaz troncal.
  5. Especifique los bits de prioridad IEEE 802.1 que utilizan los mensajes de seguimiento de seguimiento y comprobación de continuidad. Puede especificar un valor del 7 al 7 como prioridad.
  6. Especifique el defecto de prioridad más baja que genera una alarma de falla siempre que CFM detecte un defecto. Los valores posibles incluyen: todos los defectos, err-xcon, mac-rem-err-xcon, sin defectos, rem-err-xcon y xcon.
  7. Especifique el ID del MEP remoto en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id]. Puede especificar cualquier valor del 1 al 8191.

Configuración de un punto final de asociación de mantenimiento remoto (MEP)

Para configurar un punto final de asociación de mantenimiento remoto:

  1. Configure el MEP remoto especificando el ID de MEP en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id]. Puede especificar cualquier valor del 1 al 8191.
  2. Especifique el nombre del perfil de acción que se va a utilizar para el MEP remoto incluyendo la action-profile profile-name instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id remote-mep remote-mep-id]. El perfil debe definirse en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management].
  3. Configure el MEP remoto para detectar la pérdida inicial de conectividad. De forma predeterminada, el MEP no genera mensajes de defecto de pérdida de continuidad (LOC). Cuando configure la detect-loc instrucción, se detecta un defecto de pérdida de continuidad (LOC) si no se recibe ningún mensaje de comprobación de continuidad del MEP remoto en un período igual a 3,5 veces el intervalo de comprobación de continuidad configurado para la asociación de mantenimiento. Si se detecta un defecto de LOC, se genera un mensaje de error syslog.
    Nota:

    Cuando configure la administración de errores de conectividad (CFM) junto con detect-loc, cualquier action-profile configurado para derribar la interfaz se ejecuta si no se recibe el mensaje de comprobación de continuidad. Sin embargo, el action-profile no se ejecuta si no está configurado detect-loc y no se recibe el mensaje de comprobación de continuidad.

Configuración de interfaces MEP para admitir medidas de retraso de trama Ethernet

La medición de retraso de trama Ethernet es una herramienta útil para proporcionar estadísticas de rendimiento o apoyar o desafiar acuerdos de nivel de servicio (SLA). De forma predeterminada, la medición de retraso de trama Ethernet utiliza software para cálculos de marca de hora y retraso. Opcionalmente, puede usar el tiempo de hardware para ayudar en este proceso y aumentar la precisión de los resultados de la medición de retraso. Esta asistencia está disponible en la ruta de recepción.

Antes de poder realizar mediciones de retraso de trama Ethernet en enrutadores serie MX, debe haber hecho lo siguiente:

  • OAM y CFM Ethernet configurados correctamente

  • Preparó la medición entre dos enrutadores de la serie MX configurados de forma compatible

  • Habilitado el demonio de administración periódica distribuida de paquetes (ppmd)

  • Evitamos intentar realizar la medición de retraso de trama Ethernet en interfaces Ethernet o pseudowire agregadas, que no son compatibles

  • Asegúrese de que se admite la marca de hora asistida por hardware si esa función está configurada

Al final de esta configuración, creará dos enrutadores serie MX que pueden realizar y mostrar medidas de retraso de trama Ethernet en interfaces Ethernet mediante la marca de hora de hardware opcional. De forma predeterminada, la medición de retraso de trama Ethernet utiliza software para cálculos de marca de hora y retraso. Opcionalmente, puede usar el tiempo de hardware para ayudar en este proceso y aumentar la precisión de los resultados de la medición de retraso. Esta asistencia está disponible en la ruta de recepción.

Para configurar la marca de hora asistida por hardware:

  1. Para habilitar la asistencia de hardware de medición de retraso de trama Ethernet en la ruta de recepción, incluya la hardware-assisted-timestamping instrucción en el [edit protocols oam ethernet connectivity-fault-management performance-monitoring] nivel jerárquico:
  2. La medición de retraso de trama Ethernet requiere que el PPMD distribuido esté habilitado. Antes de poder recopilar estadísticas para la medición de retraso de trama Ethernet, debe asegurarse de que ELAPPD esté configurado correctamente. Sin LAMPD distribuida, los resultados de la medición de retrasos no son válidos.

    Para realizar la medición de retraso de trama Ethernet, asegúrese de que la siguiente instrucción de configuración NO está presente:

Configuración de la protección de servicio para VPWS a través de MPLS mediante la interfaz MEP

Puede habilitar la protección de servicio para un servicio de cable privado virtual (VPWS) a través de MPLS especificando una ruta de trabajo o protegiendo la ruta en el MEP. La protección del servicio proporciona protección de conexión de extremo a extremo de la ruta de trabajo en caso de falla.

Para configurar la protección del servicio, debe crear dos rutas de transporte independientes: una ruta de trabajo y una ruta de protección. Puede especificar la ruta de trabajo y proteger la ruta mediante la creación de dos asociaciones de mantenimiento. Para asociar la asociación de mantenimiento con una ruta, debe configurar la interface instrucción para el MEP dentro de la asociación de mantenimiento y especificar la ruta como trabajo o protección.

Nota:

Si no se especifica la ruta, la sesión monitorea la ruta activa.

Tabla 1 describe las opciones de protección de servicio disponibles.

Tabla 1: Opciones de protección de servicio

Opción

Descripción

working

Especifica la ruta de trabajo.

protect

Especifica la ruta de protección.

En esta configuración, habilitamos la protección del servicio para el servicio VPWS. La sesión de MCP está configurada para la ruta de trabajo y hace referencia a la sesión de MCP configurada para la ruta de protección mediante la protect-maintenance-association instrucción. El nombre de la ruta de transporte de protección para la asociación de mantenimiento se configura y se asocia con la asociación de mantenimiento para la ruta de trabajo.

Para configurar la protección del servicio para VPWS a través de MPLS:

  1. En el modo de configuración, cree un dominio de mantenimiento especificando el nombre y el formato de nombre en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management ].
    Nota:

    Si configura la longitud del nombre de dominio de mantenimiento mayor que 45 octetos, se mostrará el siguiente mensaje de error: error: configuration check-out failed.

  2. Especifique el nivel de dominio de mantenimiento especificando el valor en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management ].
  3. Cree una asociación de mantenimiento para la ruta de trabajo especificando el nombre y el formato de nombre corto en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name].
  4. Especifique el nombre de asociación de mantenimiento utilizado para la protección de conexión y el nombre del perfil de conmutación de protección automática (perfil de aps) en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name].
  5. Especifique el tiempo de espera entre las transmisiones de mensajes de comprobación de continuidad en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check ]. La duración puede ser uno de los siguientes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milisegundos (100 m) o 10 milisegundos (10 ms). El valor predeterminado es 1 minuto.
  6. Especifique un ID para el MEP en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. Puede especificar cualquier valor del 1 al 8191.
  7. Habilite la detección automática del punto final de mantenimiento para que el MEP pueda aceptar mensajes de comprobación de continuidad (MCC) de todos los diputados remotos de la misma asociación de mantenimiento.
  8. Especifique la dirección en la que se transmiten los paquetes de MCP para el MEP. Puede especificar arriba o abajo. Si especifica la dirección como ascendente, las CCM se transmiten desde todas las interfaces lógicas que forman parte de la misma instancia de puente o VPLS, excepto para la interfaz configurada en el MEP. Si especifica la dirección como hacia abajo, las CCM se transmiten solo fuera de la interfaz configurada en el MEP.
    Nota:

    Los puertos del estado de bloqueo del protocolo de árbol de expansión (STP) no bloquean los paquetes CFM destinados a un MEP caído. Los puertos en un estado de bloqueo STP sin el protocolo de comprobación de continuidad configurado bloquean paquetes CFM.

    Nota:

    A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM. Para todas las demás interfaces en enrutadores de la serie MX y en todos los demás enrutadores y conmutadores, debe seguir configurando la no-control-word instrucción en el [edit routing-instances routing-instance-name protocols l2vpn] nivel de jerarquía o [edit protocols l2circuit neighbor neighbor-id interface interface-name] cuando configure los MEP de CFM. De lo contrario, los paquetes CFM no se transmiten y el show oam ethernet connectivity-fault-management mep-database comando no muestra ningún MEP remoto.

  9. Especifique la interfaz a la que está asociado el MEP. Puede ser una interfaz física, lógica o troncal. En los enrutadores serie MX, el MEP se puede conectar a una VLAN específica de una interfaz troncal. Además, especifique la ruta de transporte como funcionando.
  10. Cree una asociación de mantenimiento para la ruta de protección especificando el nombre y el formato de nombre corto en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name].
  11. Especifique el tiempo de espera entre las transmisiones de mensajes de comprobación de continuidad en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check ]. La duración puede ser uno de los siguientes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milisegundos (100 m) o 10 milisegundos (10 ms). El valor predeterminado es 1 minuto.
  12. Especifique un ID para el MEP en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name]. Puede especificar cualquier valor del 1 al 8191.
  13. Habilite la detección automática del punto final de mantenimiento para que el MEP pueda aceptar mensajes de comprobación de continuidad (MCC) de todos los diputados remotos de la misma asociación de mantenimiento.
  14. Especifique la dirección en la que se transmiten los paquetes de MCP para el MEP. Puede especificar arriba o abajo. Si especifica la dirección como ascendente, las CCM se transmiten desde todas las interfaces lógicas que forman parte de la misma instancia de puente o VPLS, excepto para la interfaz configurada en el MEP. Si especifica la dirección como hacia abajo, las CCM se transmiten solo fuera de la interfaz configurada en el MEP.
    Nota:

    Los puertos del estado de bloqueo del protocolo de árbol de expansión (STP) no bloquean los paquetes CFM destinados a un MEP caído. Los puertos en un estado de bloqueo STP sin el protocolo de comprobación de continuidad configurado bloquean paquetes CFM.

    Nota:

    A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM. Para todas las demás interfaces en enrutadores de la serie MX y en todos los demás enrutadores y conmutadores, debe seguir configurando la no-control-word instrucción en el [edit routing-instances routing-instance-name protocols l2vpn] nivel de jerarquía o [edit protocols l2circuit neighbor neighbor-id interface interface-name] cuando configure los MEP de CFM. De lo contrario, los paquetes CFM no se transmiten y el show oam ethernet connectivity-fault-management mep-database comando no muestra ningún MEP remoto.

  15. Especifique la interfaz a la que está asociado el MEP. Puede ser una interfaz física, lógica o troncal. En los enrutadores serie MX, el MEP se puede conectar a una VLAN específica de una interfaz troncal. Además, especifique la ruta de transporte como funcionando.

Configuración del protocolo Linktrace en CFM

El protocolo linktrace se utiliza para la detección de rutas entre un par de puntos de mantenimiento. Un administrador activa los mensajes de enlace mediante el traceroute comando para comprobar la ruta entre un par de diputados bajo la misma asociación de mantenimiento. Los mensajes de linktrace también se pueden usar para comprobar la ruta entre un MEP y un MIP en el mismo dominio de mantenimiento. El protocolo linktrace le permite configurar el tiempo para esperar una respuesta. Si no se recibe ninguna respuesta para un mensaje de solicitud linktrace, las entradas de solicitud y respuesta se eliminarán después de que expire el intervalo. También puede configurar el número de entradas de respuesta de linktrace que se almacenarán para la solicitud correspondiente de linktrace.

La operación de los mensajes de solicitud y respuesta de enlace del IEEE 802.1ag es similar a la operación de los comandos de capa 3 traceroute . Para obtener más información acerca del traceroute comando, consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento.

Para configurar el protocolo linktrace:

  1. Configure el tiempo para esperar una respuesta de linktrace en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management]. Puede especificar el valor en minutos o segundos. El valor predeterminado es de 10 minutos.
  2. Configure el número de entradas de respuesta de linktrace que se almacenarán por solicitud de enlace. Puede especificar un valor del 1 al 500. El valor predeterminado es 100.

Configuración de la limitación de velocidad de los mensajes de OAM Ethernet

El M320 con los enrutadores enhanced III FPC, M120, M7i, M10 con CFEB y serie MX admite la limitación de velocidad de los mensajes de OAM Ethernet. Dependiendo de la configuración de administración de fallas de conectividad (CFM), los paquetes CFM se descartan, se envían a la CPU para su procesamiento o se inundan a otras interfaces de puente. Esta función permite al enrutador interceptar paquetes CFM entrantes para prevenir ataques DoS.

Puede aplicar la limitación de velocidad de los mensajes de OAM Ethernet en cualquiera de los dos niveles de control CFM, como se indica a continuación:

  • La policía CFM a nivel global: utiliza un agente de policía a nivel global para vigilar el tráfico de CFM que pertenece a todas las sesiones.

  • Control de CFM a nivel de sesión: utiliza un agente de policía creado para proteger el tráfico de CFM que pertenece a una sesión.

Para configurar la gestión de políticas CFM a nivel global, incluya la policer instrucción y sus opciones en el [edit protocols oam ethernet connectivity-fault-management] nivel jerárquico.

Para configurar el control de CFM a nivel de sesión, incluya la policer instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name level number maintenance-association ma-name] nivel jerárquico.

En el ejemplo siguiente se muestra un aplicador de policía CFM utilizado para CFM de limitación de velocidad:

Caso 1: Control de CFM a nivel global

En este ejemplo, se muestra un agente de policía de nivel global, a nivel de CFM, para CFM de limitación de velocidad. La continuity-check cfm-policer instrucción en el nivel de jerarquía global [edit protocols oam ethernet connectivity-fault-management policer] especifica el agente de policía que se debe usar para controlar todos los paquetes de comprobación de continuidad del tráfico CFM que pertenecen a todas las sesiones. La other cfm-policer1 instrucción en el [edit protocols oam ethernet connectivity-fault-management policer] nivel de jerarquía especifica el policía que se debe usar para controlar todos los paquetes de comprobación de no continuidad del tráfico CFM que pertenecen a todas las sesiones. La all cfm-policer2 instrucción especifica que se police todos los paquetes CFM con el policer especificado cfm-policer2. Si se utiliza la all policer-name opción, el usuario no puede especificar las opciones anteriores continuity-check ni other las anteriores.

Caso 2: Control de CFM a nivel de sesión

En este ejemplo, se muestra un policer CFM de nivel de sesión utilizado para CFM de limitación de velocidad. La policer instrucción en el nivel de jerarquía de sesión [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] especifica el aplicador de policía que se debe usar para controlar solo los paquetes de comprobación de continuidad del tráfico CFM que pertenece a la sesión especificada. La other cfm-policer1 instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] nivel de jerarquía especifica el agente de policía que se debe usar para controlar todos los paquetes de comprobación de no continuidad del tráfico CFM que pertenecen solo a esta sesión. La all cfm-policer2 instrucción especifica que se police todos los paquetes CFM con el policer especificado cfm-policer2. Si se utiliza la all policer-name opción, el usuario no puede especificar las opciones anteriores continuity-check ni other las anteriores.

En el caso de la vigilancia global de CFM, el mismo agente de policía se comparte en varias sesiones de CFM. En el control de CFM por sesión, se debe crear un agente de policía independiente para limitar la velocidad de los paquetes específicos de esa sesión.

Nota:

La configuración del agente de policía de nivel de servicio para dos sesiones de CFM en la misma interfaz a diferentes niveles debe satisfacer las siguientes restricciones si la dirección de las sesiones es la misma:

  • Si una sesión está configurada con policer all, la otra sesión no puede tener una policer all o policer other configuración.

  • Si una sesión está configurada con policer other, la otra sesión no puede tener una policer all o policer other configuración.

Si se confirma dicha configuración, se producirá un error de confirmación.

Nota:

No se admiten agentes de policía con PBB y MIC.

Configuración de la interfaz de administración local Ethernet

Descripción general de la interfaz de administración local ethernet

Las interfaces de Gigabit Ethernet (ge), 10 Gigabit Ethernet (xe) y Ethernet agregada (ae) admiten la interfaz de administración local de Ethernet (E-LMI).

Nota:

En los enrutadores de la serie MX, E-LMI se admite en interfaces de Gigabit Ethernet (ge), 10 Gigabit Ethernet (xe) y Ethernet agregada (ae) configuradas en enrutadores de la serie MX solo con DPC.

La especificación E-LMI está disponible en el Metro Ethernet Forum. Los procedimientos y protocolos E-LMI se utilizan para habilitar la configuración automática del borde del cliente (CE) para admitir servicios Metro Ethernet. El protocolo E-LMI también proporciona información de estado de interfaz de usuario a red (UNI) y conexión virtual Ethernet (EVC) al CE. La información de UNI y EVC permite la configuración automática de la operación CE según la configuración de Metro Ethernet.

El protocolo E-LMI funciona entre el dispositivo CE y el dispositivo de borde del proveedor (PE). Solo se ejecuta en el vínculo PE-CE y notifica al CE el estado de conectividad y los parámetros de configuración de los servicios Ethernet disponibles en el puerto CE. El alcance del protocolo E-LMI se muestra en Figura 1.

Figura 1: Alcance del protocolo E-LMIAlcance del protocolo E-LMI

La implementación de E-LMI en enrutadores serie ACX y MX incluye solo el lado pe del protocolo E-LMI.

E-LMI interopera con un protocolo OAM, como Connectivity Fault Management (CFM), que se ejecuta en la red del proveedor para recopilar el estado de OAM. El CFM se ejecuta en el nivel de mantenimiento del proveedor (UNI-N a UNI-N con eurodiputados en la UNI). E-LMI se basa en el CFM para el estado de extremo a extremo de las EVC en dominios CFM (dominio SVLAN o VPLS).

El protocolo E-LMI transmite la siguiente información:

  • Notificación al CE de la adición/eliminación de un EVC (activo, no activo o parcialmente activo)

  • Notificación al CE del estado de disponibilidad de un EVC configurado

  • Comunicación de atributos uni y EVC al CE:

    • Atributos uni:

      • Identificador UNI (un nombre configurado por el usuario para UNI)

      • ID/tipo de mapa EVC de CE-VLAN (agrupación todo a uno, multiplexación de servicio con agrupación o sin agrupación)

      • No se admite el perfil de ancho de banda (incluidas las siguientes funciones):

        • CM (modo de acoplamiento)

        • CF (indicador de color)

        • CIR (tasa de información confirmada)

        • CBR (tamaño de ráfaga confirmado)

        • EIR (tasa de exceso de información)

        • EBS (tamaño de ráfaga excesiva)

    • Atributos EVC:

      • ID de referencia de EVC

      • Tipo de estado EVC (activo, no activo o parcialmente activo)

      • Tipo EVC (punto a punto o multipunto a multipunto)

      • ID de EVC (un nombre configurado por el usuario para EVC)

      • Perfil de ancho de banda (no compatible)

    • MAPA DE ID/EVC de CE-VLAN

E-LMI en enrutadores serie MX admite los siguientes tipos de EVC:

  • SVLAN Q-in-Q (punto a punto o multipunto a multipunto): requiere una sesión CFM de extremo a extremo entre UNI-Ns para supervisar el estado del EVS.

  • VPLS (BGP o LDP) (punto a punto o multipunto a multipunto): se puede utilizar el estado de pseudowire VPLS o las sesiones CFM de extremo a extremo entre UNI-Ns para supervisar el estado de EVC.

  • Circuito/L2VPN L2 (punto a punto): el estado de pseudocables VPLS o las sesiones CFM de extremo a extremo entre UNI-Ns se pueden utilizar para monitorear el estado de EVC.

    Nota:

    l2-circuit y l2vpn no son compatibles.

El protocolo E-LMI en enrutadores serie ACX admite los tipos de EVC de VPN de capa 2 y circuito de capa 2, y habilita el reenvío de pérdida de vínculos para los servicios de pseudowire (circuito de capa 2 y VPN de capa 2) de la siguiente manera:

  • Intertrabajo entre el protocolo de administración de fallas de conectividad (CFM) y el protocolo E-LMI para circuitos de capa 2 y VPN de capa 2.

    • Sesión de CFM de extremo a extremo entre las UNIs para supervisar el estado de EVC.

    • En el caso de redundancia de pseudocables, CFM se puede utilizar para monitorear sesiones activas y de respaldo de pseudocables. El estado de EVC se declara como hacia abajo a los dispositivos CE solo cuando las sesiones de pseudocables activas y de respaldo se van abajo.

  • Intertrabajo entre la indicación de defectos remotos (RDI) y E-LMI para circuitos de capa 2 y VPN de capa 2.

    • Si un punto final de asociación de mantenimiento (MEP) recibe un bit RDI establecido en una trama de mensaje de comprobación de continuidad (MCP), y si la detección de fallas de RDI está habilitada en la configuración EVC en [edit protocols oam ethernet evcs evc-id evc-protocol cfm management-domain name management-association name faults rdi], entonces el pseudowire se declara como hacia abajo a enrutadores CE a través de E-LMI.

  • Si una sesión CFM de extremo a extremo no existe entre las UNIs, el pseudowire (circuito de capa 2 o VPN de capa 2) activa un mensaje de cambio de estado EVC asíncrono a enrutadores CE mediante E-LMI.

Nota:

Los enrutadores serie ACX no son compatibles con E-LMI para servicios de capa 2 (puente).

Configuración de la interfaz de administración local Ethernet

Para configurar E-LMI, realice los siguientes pasos:

Configuración de un protocolo OAM (CFM)

Para obtener información sobre cómo configurar el protocolo OAM (CFM), consulte Descripción general de la administración de fallas de conectividad IEEE 802.1ag OAM.

Asignación del protocolo OAM a un EVC

Para configurar una EVC, debe especificar un nombre para la EVC mediante la evcsevc-id instrucción en el [edit protocols oam ethernet] nivel de jerarquía. Puede establecer el protocolo EVC para supervisar las estadísticas de EVC en cfm o mediante la evc-protocol instrucción y sus opciones en el [edit protocols oam ethernet evcs]vpls nivel de jerarquía.

Puede establecer el número de UNIs remotas en la EVC mediante la remote-uni-count number instrucción en el [edit protocols oam ethernet evcs evcs-protocol] nivel de jerarquía. El remote-uni-count valor predeterminado es 1. Configurar un valor mayor que 1 hace que el EVC multipunto a multipunto. Si introduce un valor mayor que el número real de puntos de conexión, el estado de EVC se mostrará como parcialmente activo, incluso si todos los puntos de conexión están activados. Si introduce un remote-uni-count número menor que el número real de puntos de conexión, el estado se mostrará como activo, incluso si todos los puntos de conexión no están activados.

Puede configurar una EVC incluyendo la evcs instrucción en el [edit protocols oam ethernet] nivel de jerarquía:

Habilitación de E-LMI en una interfaz y asignación de ID de VLAN CE a una EVC

Para configurar E-LMI, incluya la lmi instrucción en el [edit protocols oam ethernet] nivel de jerarquía:

Puede establecer el contador de estado para contar errores consecutivos mediante la status-counter count instrucción en el [edit protocols oam ethernet lmi] nivel de jerarquía. El contador de estado se utiliza para determinar si E-LMI es operativo o no. El valor predeterminado es 4.

Puede establecer la polling-verification-timer value instrucción en el [edit protocols oam ethernet lmi] nivel de jerarquía. El valor predeterminado es de 15 segundos.

Puede habilitar una interfaz y establecer sus opciones para su uso con E-LMI mediante la interface name instrucción en el [edit protocols oam ethernet lmi] nivel de jerarquía. Solo gese admiten , xey ae las interfaces. Puede utilizar la opción de interfaz uni-id para especificar un nombre para la UNI. Si uni-id no está configurado, se establece de forma predeterminada la variable de nombre de interface name.

Puede especificar el tipo de mapa ID/EVC de CE-VLAN mediante la opción de evc-map-type type interfaz. Las opciones son all-to-one-bundling, bundlingo service-multiplexing. La multiplexación de servicio no tiene agrupación. El tipo predeterminado es all-to-one-bundling.

Para especificar la EVC que utiliza una interfaz, use la evc evc-id instrucción en el [edit protocols oam ethernet lmi interface name] nivel de jerarquía. Puede especificar una interfaz como la interfaz EVC predeterminada mediante la default-evc instrucción en el [edit protocols oam ethernet lmi interface name evc evc-id] nivel de jerarquía. Todos los VID que no están asignados a ninguna otra EVC se asignan a esta EVC. Solo se puede configurar un EVC como predeterminado.

Puede asignar una lista de VLAN a una EVC mediante la vlan-list vlan-id-list instrucción en el [edit protocols oam ethernet lmi interface name evc evc-id] nivel de jerarquía.

Configuración de E-LMI de ejemplo

Topología de ejemplo

Figura 2 muestra la configuración de E-LMI para una EVC punto a punto (SVLAN) supervisada por CFM. En este ejemplo, las VLAN del 1 al 2048 se asignan a evc1 (SVLAN 100) y del 2049 al 4096 se asignan a evc2 (SVLAN 200). Se crean dos sesiones CFM para supervisar estas EVC.

Figura 2: Configuración E-LMI para un EVC punto a punto (SVLAN) monitoreado por CFMConfiguración E-LMI para un EVC punto a punto (SVLAN) monitoreado por CFM

Configuración de PE1

Configuración de PE2

Configuración de dos UNIs que comparten el mismo EVC

Configuración de un perfil de acción de CFM para especificar acciones de CFM para eventos CFM

Puede crear un perfil de acción de administración de errores de conectividad (CFM) para definir los indicadores de eventos y los umbrales que se van a supervisar. También puede especificar la acción que se debe realizar cuando se produce cualquiera de los eventos configurados. Cuando se producen los eventos CFM, el enrutador realiza la acción correspondiente según su especificación. Puede configurar uno o más eventos en el perfil de acción. Como alternativa, puede configurar un perfil de acción y especificar acciones predeterminadas cuando se produce un error en la conectividad con un punto de conexión de asociación de mantenimiento remoto (MEP).

Nota:

No puede configurar varias acciones en este momento. Solo se puede configurar una acción. Esta limitación afecta tanto a las instrucciones como a actionclear-action las.

Para configurar el perfil de acción de CFM:

  1. En el modo de configuración, en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management], especifique el nombre del perfil de acción y los eventos CFM. Puede configurar más de un evento en el perfil de acción. Los posibles eventos incluyen: interfaz-estado-tlv, puerto-estado-tlv, adyacencia-pérdida, RDI.
  2. Especifique la acción que debe realizar el enrutador cuando se produzca el evento. La acción se activa cuando se produce el evento. Si ha configurado más de un evento en el perfil de acción, no es necesario que se produzcan todos los eventos para activar la acción.
  3. Especifique la acción predeterminada que debe realizar el enrutador cuando se produce un error en la conectividad con un MEP remoto. Si no se configura ninguna acción, no se realiza ninguna acción.
    Nota:

    Asociar un perfil de acción con la interface-down acción en una sesión CFM de MEP que se ejecuta sobre una interfaz de conexión cruzada de circuito (CCC) (l2circuit/l2vpn) no es recomendable y puede dar lugar a una situación de interbloqueo.

Perfil de acción de CFM para derribar un grupo de interfaces lógicas descripción general

Con las redes en crecimiento, es necesario monitorear una gran cantidad de servicios mediante CFM. Para supervisar cada servicio, se requiere una sesión por interfaz lógica de servicio. Si los servicios son grandes en número, este método no escala ya que el número de sesiones es limitado. En lugar de una sesión de CFM por servicio, una sola sesión de CFM puede supervisar varios servicios.

Además, hay escenarios en los que el dispositivo de la interfaz de usuario a red (UNI) debe ser derribado según las sesiones en la interfaz lógica de la interfaz de red a red (NNI). Aquí, la interfaz lógica NNI se refiere a la interfaz principal y la interfaz física de UNI se refiere a la interfaz de acceso que aloja varias interfaces lógicas de servicio. Según la supervisión de interfaz principal, puede reducir las interfaces lógicas de servicio asociadas con la interfaz de acceso.

Figura 3 muestra una topología en la que varios servicios destinados a enrutadores de borde del cliente (CE) comparten un solo puerto en un enrutador de borde de proveedor (PE). Cada servicio utiliza una interfaz lógica. Un conjunto de servicios o interfaces lógicas (de color amarillo) están destinados a un enrutador CE y un conjunto de servicios o interfaces lógicas de color rojo están destinados a otro enrutador CE. Para supervisar cada servicio, necesita sesiones dedicadas al punto final de la asociación de mantenimiento (MEP) para cada servicio. Puede reducir el servicio mediante la desinteción de la interfaz lógica del servicio cada vez que se cae la sesión. Sin embargo, este enfoque no es escalable si tenemos un gran número de servicios. La supervisión de la sesión de CFM en la interfaz física tampoco es posible porque varios enrutadores CE podrían estar conectados y los servicios a otro enrutador CE podrían interrumpirse. Para abordar este problema de supervisar varios servicios con una sola sesión, puede crear un perfil de acción de MCP para derribar un grupo de interfaces lógicas mediante una sesión de CFM configurada en una sola interfaz lógica.

Figura 3: Topología de varios servicios de VLAN que comparten un solo puerto en un enrutador de PE destinado a varios enrutadores CE Topología de varios servicios de VLAN que comparten un solo puerto en un enrutador de PE destinado a varios enrutadores CE

Puede configurar perfiles de acción de MCP para los siguientes escenarios:

  • Para derribar un grupo de interfaces lógicas que tengan el mismo puerto principal cuando la sesión de supervisión de MCP se ejecuta en una de las interfaces lógicas, pero en un puerto principal diferente.

  • Para derribar un grupo de interfaces lógicas cuando la sesión de supervisión de MCP se ejecuta en una de las interfaces lógicas, todas ellas pertenecientes al mismo puerto principal.

  • Para derribar el puerto, cuando la sesión de monitoreo de MCP se ejecuta en una de las interfaces lógicas de un puerto principal diferente.

Ventajas de crear un perfil de acción de CFM para reducir un grupo de interfaces lógicas

  • Reduce los requisitos de recursos en redes escalables en las que se deben supervisar varios servicios.

  • Evita la necesidad de crear sesiones de MEP individuales para cada servicio en una topología que incluye varios servicios que se deben supervisar, lo que mejora el rendimiento y la escalabilidad de la red.

Configuración de un perfil de acción CFM para reducir un grupo de interfaces lógicas

Para supervisar varios servicios o IFLs mediante sesión CFM configurada en una sola interfaz lógica, puede crear un perfil de acción de MCP para derribar un grupo de interfaces lógicas. Debe definir una acción para derribar el grupo de interfaces en el perfil de acción. A continuación, definirá el nombre del dispositivo de interfaz y el número de interfaces lógicas que se deben reducir. Una interfaz lógica se representa mediante una combinación de los comandos interface-device-name y unit-list. En los pasos siguientes se explica el procedimiento para derribar un grupo de interfaces lógicas cuando se especifican las interface-device-name o unit-list .

  1. En el modo de configuración, en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management], especifique el nombre del perfil de acción y los eventos CFM. Puede configurar más de un evento en el perfil de acción.

    Por ejemplo,

    Nota:

    La acción interface-group-down no se admitirá con eventos que no sean pérdida de adyacencia y RDI. Cualquier otro evento configurado da como resultado un error de confirmación.

  2. En el modo de configuración, en el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management action-profile profile-name ], defina la acción para derribar el grupo de interfaces.
    Nota:

    La acción interface-group-down no se admitirá con otras acciones relacionadas con la interfaz. Cualquier otra acción configurada da como resultado un error de confirmación.

  3. En el nivel de jerarquía [edit protocols oam ethernet connectivity-fault-management], defina el dominio de mantenimiento. Especifique los parámetros de asociación de mantenimiento.

    Por ejemplo,

  4. En el edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name, defina el punto de conexión de la asociación de mantenimiento y los parámetros asociados.

    Por ejemplo,

  5. Si el perfil de acción tiene interface-group-down la acción configurada, es obligatorio configurarla interface-group en el nivel RMEP. En el modo de configuración de la [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name instrucción include para interface-group derribar el grupo de interfaces marcado con el perfil de acción como interface-group-down.

    Por ejemplo,

    Nota:

    Si la interface-group configuración no se incluye en la configuración de RMEP. La configuración da como resultado un error de confirmación.

  6. Una interfaz lógica se representa mediante una combinación de los comandos interface-device-name y unit-list. Configure el nombre de interfaz del dispositivo y el número de interfaces lógicas en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name interface-group.

    Por ejemplo,

    En este ejemplo de configuración, se derriba la interfaz ge-0/0/0.0.

    Nota:
    • Al menos uno de los interface-group parámetros o interface-device-nameunit-list debe configurarse. Si el nombre del dispositivo de interfaz no está configurado, la interfaz MEP se considera como el nombre del dispositivo y la interfaz lógica en ese dispositivo se derriba.

    • Si el unit-list parámetro supera el límite recomendado, se produce un error de confirmación.

    • Si el nombre-dispositivo de interfaz no se especifica en el interface-group, se desconecten los números de interfaz lógica mencionados para unit-list la interfaz física.

    • Si la lista de unidades no se especifica en el interface-group, las IFLs se bajan para la interfaz configurada.

  7. Verifique la configuración mediante show protocols oam el comando.

Habilitación del modo de administración de fallas de conectividad mejorada

Puede habilitar el modo de administración de fallas de conectividad mejorada (CFM) para habilitar un despliegue eficaz de OAM Ethernet en el escalado de redes. Al habilitar el modo CFM mejorado, Junos OS admite 32 000 puntos de conexión de asociación de mantenimiento (MEP) y puntos intermedios de mantenimiento (MIP) cada uno por chasis para dominios de puente, VPLS, L2VPN y CCC. En versiones anteriores, Junos OS admite 8 000 MEP y 8000 MIPS por chasis. Si no habilita CFM mejorado, Junos OS sigue siendo compatible con la cantidad existente de MIC y MEP por chasis.

Nota:

Para admitir el modo CFM mejorado, configure el modo de servicios de red en el enrutador como enhanced-ip. Si el modo de servicios de red no enhanced-ipes y ha habilitado CFM mejorado, se mostrará el siguiente mensaje de advertencia:[edit protocols oam ethernet] 'connectivity-fault-management' enhanced ip is not effective please configure enhanced ip and give router reboot

Para habilitar el modo CFM mejorado, realice los siguientes pasos:

  1. En el modo de configuración, vaya al nivel de [edit protocols oam ethernet connectivity-fault-management] jerarquía.
  2. Habilite una implementación efectiva de OAM Ethernet mediante la habilitación del modo CFM mejorado.
  3. Confirme el cambio de modo. Se muestra un mensaje de advertencia en el que se le pide que reinicie CFM. Si no reinicia CFM, Junos OS reinicia automáticamente CFM.
  4. Para comprobar si se configuró el modo CFM mejorado, utilice el show oam ethernet connectivity-fault-management state comando.

Configuración de enrutadores serie M120 y MX para paquetes encapsulados CCC

Compatibilidad con OAM CFM IEEE 802.1ag para descripción general de paquetes encapsulados CCC

La red privada virtual de capa 2 (L2VPN) es un tipo de servicio de red privada virtual que se utiliza para transportar el tráfico privado de capa 2 del cliente (por ejemplo, Ethernet, ATM o Frame Relay) a través de la infraestructura IP/MPLS compartida del proveedor de servicios. El enrutador de borde del proveedor de servicios (PE) debe tener una interfaz con encapsulación de conexión cruzada de circuito (CCC) para cambiar el tráfico del borde del cliente (CE) a la red pública.

El IEEE 802.1ag Ethernet Connectivity Fault Management (CFM) es un estándar OAM que se utiliza para realizar la detección, el aislamiento y la verificación de fallas en LASN de puente virtual. Los enrutadores serie M120 y MX admiten CFM para interfaces bridge/VPLS/enrutadas y admiten OAM Ethernet 802.1ag para paquetes encapsulados CCC.

Características de CFM compatibles con circuitos VPN de capa 2

Las funciones de CFM compatibles con circuitos L2VPN son las siguientes:

  • Creación de MEP ascendentes o descendentes en cualquier nivel en las interfaces lógicas orientadas a CE.

  • Creación de MIC en cualquier nivel en las interfaces lógicas orientadas a CE.

  • Soporte para comprobación de continuidad, circuito cerrado y protocolo linkrace.

  • Soporte para el protocolo de medición de retraso Ethernet Y1731.

  • Compatibilidad con perfiles de acción para reducir las interfaces lógicas orientadas a CE cuando se detecta una pérdida de conectividad.

Figura 4: Topología VPN de capa 2Topología VPN de capa 2

Para supervisar el circuito L2VPN, se puede configurar un MEP cfm up (nivel 6 en Figura 4) en las interfaces lógicas orientadas a CE de los enrutadores de borde de proveedor PE1 y PE2. Para supervisar el circuito de conexión CE-PE, se puede configurar un MEP cfm abajo en las interfaces lógicas del cliente de CE1-PE1 y CE2-PE2 (nivel 0 en Figura 4).

Configuración de CFM para paquetes encapsulados CCC

El único cambio de la configuración de CLI existente es la introducción de un nuevo comando para crear un MIP en la interfaz orientada a CE del enrutador de PE.

Configuración de la administración de errores de conectividad para la interoperabilidad durante actualizaciones unificadas de software en servicio

A partir de la versión 17.1, la administración de errores de conectividad (CFM) de Junos OS, durante una actualización unificada de software en servicio (ISSU), funciona cuando el dispositivo par no es un enrutador de Juniper Networks. Al interoperar con el enrutador de otro proveedor, el enrutador de Juniper Networks conserva la información de la sesión y sigue transmitiendo PDU de mensaje de comprobación de continuidad (MCP) durante la ISSU unificada. La administración de fallas de conectividad sigue funcionando.

Esta función requiere que se cumplan las siguientes condiciones:

  • Los keepalives del motor de reenvío de paquetes deben estar habilitados para proporcionar la transmisión en línea de los MCC. La función no funciona cuando la CPU de una tarjeta de línea transmite los MCC, que es el método de transmisión predeterminado.

  • El intervalo entre MCC debe ser de 1 segundo.

La interoperabilidad de CFM durante una ISSU unificada se admite en los siguientes MPC: MPC1, MPC2, MPC2-NG, MPC3-NG, MPC5 y MPC6.

Para habilitar la interoperabilidad de CFM con dispositivos de terceros en una ISSU unificada:

  1. Habilite los keepalives en línea.
  2. Establezca el intervalo de MCP en 1 segundo.

Configuración de ISSU unificada para 802.1ag CFM

Una actualización unificada de software en servicio (ISSU) le permite actualizar entre dos versiones diferentes de Junos OS sin interrupciones en el plano de control y con una interrupción mínima del tráfico. El ISSU unificado se habilita automáticamente para los protocolos de administración de fallas de conectividad (CFM) e interopera entre puntos de conexión de mantenimiento local y remoto (MEP).

Junos OS ofrece soporte para ISSU unificada mediante el valor de longitud de tipo de umbral de pérdida (TLV), que se habilita automáticamente para CFM. Los TVS se describen en el estándar IEEE 802.1ag para CFM como un método de codificación de longitud variable e información opcional en una unidad de datos de protocolo (PDU). El umbral de pérdida TLV indica el valor de umbral de pérdida de un MEP remoto. El umbral de pérdida TLV se transmite como parte de los mensajes de comprobación de continuidad de CFM.

Nota:

A partir de Junos OS versión 15.1, la configuración de ISSU con CFM (802.1ag) solo se admite en enrutadores MX y PTX compatibles con TLV. No se admite la interoperación con otros proveedores.

Durante un ISSU unificado, el plano de control puede bajar durante varios segundos y hacer que los paquetes de comprobación de continuidad del CFM se caigan. Esto puede hacer que el MEP remoto detecte una pérdida de conectividad y marque al MEP como caído. Para mantener el MEP activo durante una ISSU unificada, el umbral de pérdida TLV comunica el valor de umbral mínimo que el MEP receptor requiere para mantener el MEP activo. El MEP receptor analiza la TLV y actualiza el valor del umbral de pérdida, pero solo si el nuevo valor de umbral es mayor que el valor de umbral configurado localmente.

Se describe una descripción general de CFM a partir de IEEE 802.1ag OAM Connectivity Fault Management Overview( Descripción general de la administración de fallas de conectividad de IEEE 802.1ag), y debe seguir observando los requisitos adicionales descritos en este tema.

Tabla 2 muestra el formato TLV del umbral de pérdida.

Tabla 2: Formato TLV de umbral de pérdida

Parámetro

Octeto (secuencia)

Descripción

Type=31

1

Obligatorio. Obligatorio. Si 0, no siguen los campos Longitud ni Valor. Si no es 0, al menos el campo Longitud sigue el campo Tipo.

Length=12

2

Obligatorio si el campo Tipo no es 0. No está presente si el campo Tipo es 0. Los 16 bits del campo Longitud indican el tamaño, en octetos, del campo Valor. 0 en el campo Longitud indica que no hay ningún campo Valor.

OUI

3

Opcional. Identificador único de la organización (OUI), que está controlado por el IEEE y suele ser los primeros tres bytes de una dirección MAC (Juniper OUI 0x009069).

Subtipo

1

Opcional. Subtipo definido por la organización.

valor

4

Opcional. Valor de umbral de pérdida.

Bandera

4

Opcional. Bit0 (identifica un ISSU en curso)

Bit1-31 (reservado)

Junos OS ofrece compatibilidad de configuración para la convey-loss-threshold instrucción, lo que le permite controlar la transmisión del umbral de pérdida TLV en los mensajes de comprobación de continuidad PDU. La convey-loss-threshold instrucción especifica que el umbral de pérdida TLV debe transmitirse como parte de los mensajes de comprobación de continuidad. Si no se especifica la convey-loss-threshold instrucción, los mensajes de comprobación de continuidad transmiten esta TLV solo cuando un ISSU unificado está en curso. Junos OS proporciona esta configuración en el nivel de comprobación de continuidad. De forma predeterminada, los mensajes de comprobación de continuidad no incluyen el umbral de pérdida TLV.

Para configurar el umbral de pérdida de transporte, use la convey-loss-threshold instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] nivel de jerarquía.

Para el MEP remoto, el umbral de pérdida TLV se transmite solo durante el ISSU unificado si la convey-loss-threshold instrucción no está configurada. El MEP remoto vuelve al umbral de pérdida predeterminado si no se recibe ningún umbral de pérdida TLV o la TLV tiene un valor de umbral predeterminado de 3.

A continuación, se muestra un ejemplo de las instrucciones de configuración issu:

Junos OS guarda el último umbral de pérdida recibido TLV del MEP remoto. Puede mostrar el último umbral de pérdida guardado TLV que recibe el MEP remoto mediante el show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier comando, como en el ejemplo siguiente:

Junos OS guarda el último umbral de pérdida transmitido TLV de un MEP local. Puede mostrar el último umbral de pérdida transmitida TLV y el umbral de pérdida (operativo) efectivo para el MEP remoto mediante el show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier comando, como en el ejemplo siguiente:

Soporte de Junos OS para monitoreo de rendimiento conforme con la especificación técnica MEF 36

Junos OS versión 16.1R1 y posteriores admite monitoreo de rendimiento que cumple con la especificación técnica MEF 36. La especificación técnica MEF 36 especifica el MIB de monitoreo de rendimiento. El MIB de monitoreo de rendimiento es necesario para administrar las implementaciones de operaciones de servicio, administración y mantenimiento (OAM) que satisfacen los requisitos y el marco de trabajo de OAM de servicio especificados en MEF 17 y MEF 35, los objetos de administración especificados en MEF 7.1 y las funciones de monitoreo de rendimiento definidas en ITU-T Y.1731 e IEEE 802.1ag.

Puede habilitar la supervisión de rendimiento compatible con MEF-36 mediante la configuración de la measurement-interval instrucción en el [edit protocols oam ethernet cfm performance-monitoring] nivel de jerarquía.

Cuando se habilita la supervisión del rendimiento compatible con MEF-36:

  • Es posible que una snmp obtenga la próxima solicitud de una variable que no obtenga el valor actual, a menos que se realice una caminata SNMP antes de realizar la siguiente solicitud get. Esta limitación solo se aplica a las estadísticas actuales para la medición del retraso, la medición de pérdidas y la medición de pérdidas sintéticas.

  • El resultado del campo Current delay measurement statistics puede mostrar un intervalo de medición de 0 (cero) y una marca de hora incorrecta hasta que haya expirado el primer ciclo.

  • El tamaño de TLV de datos compatibles para unidades de datos de protocolo de monitoreo de rendimiento (PDU) es de 1386 bytes cuando está habilitada la supervisión de rendimiento compatible con MEF-36. El tamaño de TLV es de 1400 bytes en modo heredado.

  • El valor máximo configurable para la bandeja de umbral inferior es 4.294.967.294.

  • La relación de pérdida de trama (FLR) se excluye en las mediciones de pérdidas durante el período de no disponibilidad solo para la medición de pérdida sintética. En caso de medición de pérdida, FLR se incluye incluso durante el período de indisponibilidad.

  • Durante un período de pérdida de continuidad (adyacencia hacia abajo), aunque no se envían PDU SOAM, no se detienen los cálculos de FLR y disponibilidad. Estos cálculos se realizan con la suposición de una pérdida del 100 %.

  • La cantidad de PDU SOAM que se envían durante el primer intervalo de medición puede ser menor de lo esperado. Esto se debe a un retraso en la detección del estado de adyacencia en el nivel de sesión de monitoreo de rendimiento.

  • Es posible que el número de PDU SOAM transmitidas durante un intervalo de medición para un tiempo de ciclo de 100 ms no sea preciso. Por ejemplo, en un intervalo de medición de dos minutos con un tiempo de ciclo de 100 ms, las PDU SOAM transmitidas podrían estar en el rango de 1198-2000.

Amortiguación de las trampas y notificaciones de monitoreo del rendimiento de CFM para evitar la congestión del NMS

Puede atenuar las trampas y notificaciones de paso de umbral de monitoreo de rendimiento que se generan cada vez que se produce un evento de cruce de umbral para evitar la congestión del sistema de administración de red (NMS).

La amortiguación limita la cantidad de trampas de jnxSoamPmThresholdCrossingAlarm enviadas al NMS mediante el resumen de las ocurrencias de la solapa durante un período de tiempo, conocido como el temporizador de trampa de solapa, y envía una única notificación jnxSoamPmThresholdFlapAlarm al NMS. Puede configurar la duración del temporizador de trampilla a cualquier valor de 1 a 360 segundos.

La notificación jnxSoamPmThresholdFlapAlarm se genera y se envía cuando se cumplen las siguientes condiciones:

  • Al menos una solapa se ha producido cuando el temporizador de la solapa ha expirado.

  • Cambió el valor del temporizador de trampilla, lo que hizo que el temporizador se detuviera.

Puede habilitar la amortiguación a nivel global para el iterador o puede habilitar la amortiguación en el tipo de umbral individual del iterador. Por ejemplo, para habilitar la amortiguación a nivel global, para el iterador, use el siguiente comando: set protocols oam ethernet cfm performance-monitoring sla-iterator-profiles profile-name flap-trap-monitor. Para habilitar la amortiguación en un tipo de umbral específico, para el avg-fd-twoway-thresholdcomando , utilice el siguiente comando: set protocols oam ethernet cfm performance-monitoring sla-iterator-profiles profile-name avg-fdv-twoway-threshold flap-trap-monitor.

También puede deshabilitar la amortiguación.

Ejemplo: Configuración de CFM Ethernet en interfaces físicas

En este ejemplo, se muestra la configuración de la administración de fallas de conectividad Ethernet (CFM) en interfaces físicas.

Requisitos

En este ejemplo, se utilizan los siguientes componentes de hardware y software:

  • Junos OS versión 9.3 o posterior.

Descripción general

CfM se puede utilizar para supervisar el vínculo físico entre dos enrutadores. Esta funcionalidad es similar a la que admite el protocolo LFM IEEE 802.3ah.

En junos OS versión 9.3 y posteriores, CFM también admite interfaces Ethernet agregadas. En las interfaces configuradas en concentradores de puerto modular (MPC) y tarjetas de interfaz modular (MIC) en enrutadores serie MX, CFM no se admite en vínculos de miembro Ethernet agregados sin etiquetar. Las MPC y MIC admiten CFM en interfaces lógicas de Ethernet agregadas sin etiquetar y etiquetadas.

Nota:

Las configuraciones de este ejemplo son solo ejemplos parciales de configuraciones de enrutador completas y funcionales. No copie estas configuraciones y úselas directamente en un sistema real.

Configuración

En el siguiente ejemplo, dos enrutadores (enrutador 1 y 2) se conectan mediante un vínculo Gigabit Ethernet punto a punto. El vínculo entre estos dos enrutadores se monitorea mediante CFM. Esto se muestra en Figura 5. El límite único es un "mep descendente" en la terminología CFM.

Figura 5: CFM Ethernet en interfaces físicasCFM Ethernet en interfaces físicas

Para configurar ethernet CFM en interfaces físicas, realice estas tareas:

Configuración rápida de CLI

Enrutador 1

Configure la interfaz y CFM:

La configuración del enrutador 2 refleja eso en el enrutador 1, con la excepción del mep-id.

Enrutador 2

Configure la interfaz y CFM:

Para comprobar que la interfaz física está configurada correctamente para CFM, utilice el show interface comando. Para comprobar la configuración de CFM, utilice uno o varios de los show oam ethernet connectivity-fault-management comandos enumerados en el Explorador de CLI.

Ejemplo: Configuración de CFM Ethernet en conexiones de puente

En este ejemplo, tanto el cliente como el proveedor de servicios ejecutan CFM Ethernet a través de una red de puente simple. La red se muestra en Figura 6. El cliente ha configurado ethernet CFM en enrutadores serie MX L2-CE1 y L2-CE2. El proveedor de servicios ha configurado ethernet CFM en los enrutadores serie MX PE1 y PE2.

Nota:

Las configuraciones de este ejemplo son solo ejemplos parciales de configuraciones de enrutador completas y funcionales. No copie estas configuraciones y úselas directamente en un sistema real.

El proveedor de servicios está utilizando CFM de nivel 3 para el vínculo entre PE1 y PE2 y el nivel 5 de un puerto ce orientado al otro. El cliente utiliza CFM de nivel 7. Los límites se marcan con la terminología CFM "up mep" y "down mep" en la figura.

Figura 6: CFM Ethernet a través de una red de puenteCFM Ethernet a través de una red de puente

Estas son las configuraciones de CFM en los enrutadores del cliente.

CFM en L2-CE1

CFM en L2-CE2

Estas son las configuraciones de CFM en los enrutadores del proveedor.

CFM en PE1

CFM en PE2

Ejemplo: Configuración de CFM Ethernet a través de VPLS

En este ejemplo, tanto el cliente como el proveedor de servicios ejecutan CFM Ethernet a través de una VPLS y una red de conmutación de etiquetas multiprotocolo (MPLS). La red se muestra en Figura 7. El cliente ha configurado ethernet CFM en enrutadores serie MX L2-CE1 y L2-CE2. El proveedor de servicios ha configurado CFM Ethernet en los enrutadores serie MX PE1, P y PE2.

Nota:

Las configuraciones de este ejemplo son solo ejemplos parciales de configuraciones de enrutador completas y funcionales. No copie estas configuraciones y úselas directamente en un sistema real.

El proveedor de servicios utiliza CFM de nivel 5 y el cliente usa CFM de nivel 7. Los límites se marcan con la terminología CFM "up mep" y "down mep" en la figura.

Figura 7: OAM Ethernet con VPLSOAM Ethernet con VPLS
Nota:

Las interfaces lógicas de una instancia de enrutamiento VPLS pueden tener las mismas configuraciones de VLAN o diferentes. La normalización de VLAN es necesaria para conmutar los paquetes correctamente entre estas interfaces. La normalización admite la asignación automática de VLAN y realiza operaciones en etiquetas VLAN para lograr la traducción deseada. Consulte Configurar una VLAN normalizada para traducción o etiquetado.

Nota:

Deben observarse las siguientes consideraciones de ruta de reenvío:

  • Ruta de recepción de paquetes:

    • Esta es la ruta de reenvío de los paquetes recibidos en las interfaces.

    • 802.1ag Ethernet OAM para VPLS utiliza filtros de interfaz implícitos y filtros de tabla de reenvío para inundar, aceptar y soltar los paquetes CFM.

  • Ruta de transmisión de paquetes:

    • Junos OS utiliza el reenvío basado en hardware del enrutador para paquetes generados por CPU.

    • Para los MEP caídos, los paquetes se transmiten en la interfaz en la que se configura el MEP.

    • En los enrutadores de la serie MX, para los MEP ascendentes, los paquetes se deben inundar a otras interfaces en la instancia de enrutamiento VPLS. El enrutador crea una ruta de inundación vinculada a un salto siguiente de inundación (con todas las interfaces para inundar) y, luego, origina los paquetes que se reenviarán con esta ruta de inundación.

A continuación, se muestran las configuraciones de VPLS y CFM en los enrutadores del proveedor de servicios.

Configuración de PE1

Configuración de PE2

Configuración del enrutador P

Solo MPLS, no se necesita CFM:

CFM en L2-CE1

Aquí está la configuración de CFM en L2-E1:

CFM en L2-CE2

Aquí está la configuración de CFM L2-CE2:

Notificación asíncrona del perfil de acción de CFM

SUMMARY 

La notificación asíncrona impulsada por CFM permite la sincronización del estado del vínculo entre dos dispositivos CE

conectados entre sí a través de un pseudo cable que se origina en sus respectivos dispositivos de PE. Emula

como si dos dispositivos CE estuvieran conectados directamente. CFM proporciona señalización de extremo a extremo, incluso si PE1

y el PE2 no se conectan a través de una sola red, sino de un conjunto de redes.

Conectividad de capa 2 entre PE1 y PE2

La Figura 1 es un ejemplo de escenario de despliegue en el que se puede utilizar 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 el

configuración de notificación asíncrona.

  • Cuando el vínculo entre PE2 a CE2 va abajo entonces el vínculo entre PE1 a CE1 también se realizó abajo.

    Cuando se restaura el vínculo, también debe restaurar el estado del vínculo PE1 a CE1. El estado del vínculo cambia entre

    PE1 a CE1 debe funcionar de la misma manera.

    • Cuando hay un problema de conectividad entre PE1 y PE2, su activa un vínculo hacia abajo entre PE1 y CE1

      y PE2 a CE2. Si se restaura el estado de conexión, debe restaurar el estado del vínculo en ambos extremos

Tabla de historial de versiones
Liberación
Descripción
17.1
A partir de la versión 17.1, la administración de errores de conectividad (CFM) de Junos OS, durante una actualización unificada de software en servicio (ISSU), funciona cuando el dispositivo par no es un enrutador de Juniper Networks.
15.1
A partir de Junos OS versión 15.1, la configuración de ISSU con CFM (802.1ag) solo se admite en enrutadores MX y PTX compatibles con TLV.
12.3
A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM.
12.3
A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM.
12.3
A partir de Junos OS versión 12.3, para todas las interfaces configuradas en concentradores de puerto modular (MPC) en plataformas de enrutamiento universal 5G serie MX, ya no es necesario configurar la no-control-word instrucción para todas las VPN de capa 2 y los circuitos de capa 2 en los que se ejecutan los MEP de CFM.