Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoreo de CFM entre dispositivos CE y PE

Utilice este tema para comprender más acerca de la supervisión de CFM entre los dispositivos de borde del proveedor y los dispositivos de borde del cliente cuando el dispositivo de borde del cliente no es un dispositivo Juniper. Además, puede comprender más acerca de cómo los TRV del estado de la interfaz, los TRV del estado del puerto, la TLV de ID del chasis y la protección de la conexión TLV ayudan a monitorear su red.

Notificación asincrónica del perfil de acción de CFM

SUMMARY La notificación asincrónica 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 el escenario como si dos dispositivos CE estuvieran conectados directamente. CFM ofrece señalización de extremo a extremo incluso si PE1 y PE2 no están conectados 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. La configuración de notificaciones asincrónicas puede cumplir con dos requisitos.

  • Cuando el vínculo entre PE2 y CE2 se cae, entonces el vínculo entre PE1 y CE1 también se ha caído. Cuando se restaura el vínculo, también debe restaurar el estado del vínculo PE1 a CE1. El cambio de estado del vínculo entre PE1 y CE1 debería funcionar de manera similar.

  • Cuando hay un problema de conectividad entre PE1 y PE2, se activa un vínculo hacia abajo entre PE1 a 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

Configuring a CFM Action Profile to Asyncronus Notification

SUMMARY CFM UP-MEP on PE1 to PE2, monitors the connectivity between PE1 to PE2. Use of interface-status-tlv on these UP-MEP end points conveys the link status between PE1 to CE1 to PE2 and link-status between PE2 to CE2 to PE1. Action profile must be configured on PE1 to PE2 to drive asynchronous-notification towards respective CE devices . It is triggered when either adjacency-loss is detected or link-down is detected in the received interface-status-tlv.

  1. Enable asynchronous-notification at interface level

    For example

  2. Configure the action profile and the CFM event(s) to triggered this action profile at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can configure more than one event in the action profile

    For example

    The action asynchronous-notification is not supported with events other than interface-status-tlv down, interface-status-tlv lower-layer-down and adjacency-loss. Any other events configured results in a commit error

    .
  3. Define the action to asynchronous-notification at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name] hierarchy level.
  4. Define the maintenance domain at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level and specify the maintenance-association parameters

    For example

  5. Configure the generation of interface-status-tlv .it is required if asynchronous-notification configured based on interface-status-tlv.

    For example

  6. Define the maintenance association endpoint at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level and specify the associated parameters.

    For example

  7. Set asynchronous-notification action profile at the RMEP level.

    For example,

Descripción de la supervisión de CFM entre dispositivos CE y PE

Puede habilitar la supervisión de la administración de errores de conectividad (CFM) entre los dispositivos de borde del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo de borde del cliente no es un dispositivo Juniper. Cuando la interfaz está desactivada, CFM propaga el estado de la interfaz en los mensajes CC. El mensaje CC informa al dispositivo de borde del cliente que el dispositivo perimetral del proveedor está inactivo.

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

  • TLV de estado de 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 uso de la TLV de estado de la interfaz. Cuando la interfaz está desactivada, CFM propaga el estado de la interfaz mediante el estado de la interfaz TLV. El TLV estado de interfaz indica el estado de la interfaz en la que está configurado el MEP que transmite el CCM o la interfaz inferior siguiente en el IETF RFC 2863 IF-MIB. Por lo tanto, el dispositivo de borde 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 [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check nivel jerárquico. 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 de borde 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 de defecto remoto (RDI). Cuando habilita la supervisión de CFM, CFM propaga el estado del dispositivo de borde del proveedor a través del bit de indicación remota de defecto (RDI) en los mensajes CC. Por lo tanto, el dispositivo de borde del cliente es consciente de que el dispositivo perimetral del proveedor está inactivo. El bit de RDI se borra cuando se hace 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 [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check nivel de jerarquía. Esta opción es necesaria si el dispositivo de borde del cliente no admite el estado de la interfaz TLV.

Nota:

Cuando la interfaz se establece en CCC abajo y se ha configurado RDI, se envía el bit RDI. CFM no supervisa el estado de la interfaz. Si CCC abajo se establece cuando la interfaz no está en espera, el bit RDI se envía con los mensajes CC si ha configurado RDI.

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

Considere la siguiente topología en la que hay dos dispositivos de borde del proveedor (PE1 y PE2), así como dos dispositivos de borde del cliente (CE1 y CE2). PE1 está en estado activo, mientras que PE2 está en estado de espera. El MEP descendente de CFM se configura entre pe y CE. CFM detecta que el CCC está caído y, dado que CFM mep está configurado, los mensajes CC generados tienen el bit RDI. Los mensajes CC de PE2 a CE2 tienen el bit RDI establecido para indicar el estado bloqueado. Cuando PE2 se activa, CCM hacia abajo se borra y el bit RDI se borra de los mensajes CC subsiguientes.

Caso de uso de multiconexión activa/activa con bit RDI

Considere la topología en la que hay dos dispositivos de borde del proveedor (PE1 y PE2) y dos dispositivos perimetrales del cliente (CE1 y CE2). PE1 está en estado activo, mientras que PE2 está en estado de espera. Si CFM abajo MEP no está configurado entre pe y CE para supervisar la conectividad del vínculo, los mensajes CC generados no tienen el bit RDI. El MEP descendente de CFM se configura entre pe y CE. CFM detecta que el CCC está caído y, dado que CFM mep está configurado, los mensajes CC generados tienen el bit RDI. Los mensajes CC de PE2 a CE2 tienen el bit RDI establecido para indicar el estado bloqueado. Cuando PE2 se activa, CCM hacia abajo se borra y el bit RDI se borra de los mensajes CC subsiguientes.

Configuración del estado de TLV del puerto y el estado de la interfaz TLV

Descripción general de los TLV

El tipo, la longitud y el valor (TLV) se describen en el estándar IEEE 802.1ag para CFM como un método de codificación de longitud de variable o información opcional en una PDU. Los TLV no están alineados con ningún límite de palabra u octeto en particular. Los TLV se suceden entre sí sin acolchamiento entre ellos.

Tabla 1 muestra el TLV formato e indica si es obligatorio o opcional.

Tabla 1: Formato de los TLV

Parámetro

Octeto (secuencia)

Descripción

Tipo

1

Obligatorio. Si es 0, no hay campos longitud ni valor. Si no es 0, al menos el campo Longitud sigue el campo Tipo.

Longitud

2–3

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 Value. 0 en el campo Longitud indica que no hay ningún campo Valor.

valor

4

Longitud especificada por el campo Longitud. Opcional. No está presente si el campo Tipo es 0 o si el campo Longitud es 0.

Varios TTV para PDU CFM

Tabla 2 muestra un conjunto de TLV definidos por IEEE 802.1ag para varios tipos de PDU de CFM. Cada TLV se puede identificar por el valor único asignado a su campo tipo. Algunos valores de campo de tipo están reservados.

Tabla 2: Valores de campo de tipo para varios TTLV para PDU de CFM

TLV u organización

Campo de tipo

Fin de TLV

0

TLV de ID de remitente

1

TLV de estado del puerto

2

TLV de datos

3

TLV de estado de interfaz

4

TLV de entrada de respuesta

5

TLV de salida de respuesta

6

TLV de identificador de salida LTM

7

TLV de identificador de salida LTR

8

Reservado para IEEE 802.1

De 9 a 30

TLV específicos de la organización

31

Definido por ITU-T Y.1731

32 a 63

Reservado para IEEE 802.1

De 64 a 255

No todos los TLV se aplican a todos los tipos de PDU de CFM.

  • TLV aplicables para mensajes de verificación de continuidad (CCM):

    • Fin de TLV

    • TLV de ID de remitente

    • TLV de estado del puerto

    • TLV de estado de interfaz

    • TLV específicos de la organización

  • TLV aplicables para mensajes de circuito cerrado (LBM):

    • Fin de TLV

    • TLV de ID de remitente

    • TLV de datos

    • TLV específicos de la organización

  • TLV aplicables para respuesta de circuito cerrado (LBR):

    • Fin de TLV

    • TLV de ID de remitente

    • TLV de datos

    • TLV específicos de la organización

  • TLV aplicables para el mensaje de conexión (LTM):

    • Fin de TLV

    • TLV de identificador de salida LTM

    • TLV de ID de remitente

    • TLV específicos de la organización

  • TLV aplicables para respuesta de conexión (LTR):

    • Fin de TLV

    • TLV de identificador de salida LTR

    • TLV de entrada de respuesta

    • TLV de salida de respuesta

    • TLV de ID de remitente

    • TLV específicos de la organización

Actualmente, se admiten los siguientes TLV en las PDU de CFM aplicables:

  • Fin de TLV

  • TLV de entrada de respuesta

  • TLV de salida de respuesta

  • TLV de identificador de salida LTR

  • TLV de identificador de salida LTM

  • TLV de datos

Soporte para TAV opcionales adicionales

Se admiten los siguientes TLV opcionales adicionales:

  • TLV de estado del puerto

  • TLV de estado de interfaz

Los enrutadores serie MX admiten la configuración del estado TLV del puerto y el estado de la interfaz TLV. La configuración de la TLV de estado del puerto permite que el operador controle la transmisión del TLV de estado del puerto en las PDU de CFM.

Nota:

Aunque las instrucciones de configuración del estado del puerto TLV son visibles en la CLI en enrutadores M120 y M320, el estado del puerto TLV no se puede configurar en estos sistemas. El estado del puerto TLV solo se puede habilitar en una interfaz MEP si se trata de una interfaz lógica de puente, lo que no es posible en estos sistemas.

Para obtener información de configuración, consulte las siguientes secciones:

TLV de estado del puerto

El TLV estado del puerto indica la capacidad del puerto de puente en el que reside el MEP transmisor para pasar datos ordinarios, independientemente del estado de la MAC. El valor de esta TLV se basa en la variable enableRmepDefectMEP, como se muestra en Tabla 4. El formato de esta TLV se muestra en Tabla 3.

Cualquier cambio en el valor de LLV de estado de puerto activa una transmisión adicional de las MCC MEP de los puertos de puente.

Tabla 3: Formato de TLV de estado de puerto

Parámetro

Octeto (secuencia)

Tipo = 2

1

Longitud

2–3

Valor (Consulte Tabla 4)

4

Tabla 4: Valores de TLV de estado de puerto

Mnemónica

Datos ordinarios que pasan libremente por el puerto

valor

psBloqueado

No: enableRmepDefect = false

1

psUp

Sí: enableRmepDefect = verdadero

2

La variable enableRmepDefect MEP es una variable booleana que indica si las tramas de la instancia de servicio supervisadas por las asociaciones de mantenimiento, si este MEP está habilitado para pasar a través de este puerto de puente mediante el protocolo de árbol de expansión y la administración de topología de VLAN. Se establece en TRUE si:

  • El puerto de puente se establece en un estado en el que el tráfico puede pasar a través de él.

  • El puerto de puente ejecuta varias instancias del árbol de expansión.

  • La interfaz MEP no está asociada con un dominio de puente.

Configuración de TLV del estado del puerto

Junos OS ofrece compatibilidad de configuración para el TLV de estado del puerto, lo que le permite controlar la transmisión de esta TLV en PDU de CCM. Junos OS proporciona esta configuración en el nivel de comprobación de continuidad. De forma predeterminada, el CCM no incluye el TLV de estado del puerto. Para configurar la TLV de estado del puerto, utilice la port-status-tlv instrucción en el [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] nivel de jerarquía.

Nota:

El estado del puerto TLV configuración no es obligatorio por IEEE 802.1ag. Junos OS lo proporciona para darle más flexibilidad al operador; sin embargo, recibe y procesa MCC con un TLV de estado de puerto, independientemente de esta configuración.

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

No puede habilitar estado de puerto TLV transmisión en los dos casos siguientes:

  • Si la interfaz MEP bajo la asociación de mantenimiento no es de tipo bridge.

  • Si el MEP está configurado en una interfaz física.

Mostrar el estado del puerto recibido TLV

Junos OS guarda el último estado de puerto recibido TLV desde un MEP remoto. Si el valor de estado del puerto recibido no corresponde con uno de los valores estándar enumerados en Tabla 4, el show comando lo muestra como "desconocido". Puede mostrar el último estado del puerto guardado TLV con 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:

Mostrar el estado del puerto transmitido TLV

Junos OS guarda el último estado del puerto transmitido TLV de un MEP local. Si la transmisión del estado del puerto TLV no se ha habilitado, el show comando muestra "ninguno". Puede mostrar el último estado del puerto transmitido guardado TLV 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:

TLV de estado de interfaz

El TLV estado de interfaz indica el estado de la interfaz en la que está configurado el MEP que transmite el CCM o la interfaz inferior siguiente en el IETF RFC 2863 IF-MIB. El formato de esta TLV se muestra en Tabla 5. Los valores enumerados se muestran en Tabla 6.

Tabla 5: Formato TLV estado de interfaz

Parámetro

Octeto (secuencia)

Tipo = 4

1

Longitud

2–3

Valor (Consulte Tabla 6)

4

Tabla 6: Valores de TLV estado de interfaz

Mnemónica

Estado de interfaz

valor

Isup

hacia arriba

1

isDown

bajar

2

isTesting

Pruebas

3

esUnknown

Desconocido

4

esDormant

Inactivo

5

isNotPresent

notPresent

6

esLowerLayerDown

lowerLayerDown

7

Nota:

Cuando el estado operativo de una interfaz lógica cambia del estado descendente (valor de estado de 2) al estado descendente de la capa inferior (valor de estado de 7) y viceversa, no se genera la captura SNMP LinkDown. Por ejemplo, si configura un paquete de interfaz Ethernet agregado con una etiqueta VLAN y agrega una interfaz física que se encuentra en el estado operativo caído al paquete, el estado operativo del paquete de interfaz lógica de Ethernet agregado en ese punto está de capa inferior abajo (7). Si toma el MIC asociado con la interfaz sin conexión, la captura LinkDown no se genera cuando la interfaz lógica cambia del estado de la capa inferior hacia abajo al estado descendente.

De manera similar, considere otro caso de ejemplo en el que se agrega una interfaz física a un paquete de Ethernet agregado que tiene etiquetado de VLAN y la interfaz lógica de Ethernet agregada está deshabilitada. Cuando la interfaz lógica está deshabilitada, el estado operativo de la interfaz lógica cambia a inactivo. Si deshabilita la interfaz física que forma parte del paquete de Ethernet agregado, el estado operativo de la interfaz lógica de Ethernet agregada permanece inactivo. Si vuelve a activar la interfaz lógica de Ethernet agregada, el estado operativo de la capa baja a la inferior. La captura SNMP LinkDown no se genera en este punto.

Configuración de TLV del estado de la interfaz

Junos OS ofrece compatibilidad de configuración para el TLV de estado de la interfaz, lo que permite a los operadores controlar la transmisión de este TLV en las PDU de CCM mediante la configuración en el nivel de comprobación de continuidad.

Nota:

Ieee 802.1ag no exige esta configuración; más bien se proporciona para dar más flexibilidad al operador. Junos OS recibe y procesa las MCC con el TLV de estado de interfaz, independientemente de esta configuración.

A continuación, se muestra el estado TLV configuración de la interfaz:

Nota:

Junos OS solo admite la transmisión de tres de siete valores posibles para el TLV de estado de interfaz. Los valores admitidos son 1, 2 y 7. Sin embargo, Junos OS es capaz de recibir cualquier valor para el TLV de estado de interfaz.

Mostrar el estado de la interfaz recibida TLV

Junos OS guarda el último estado de interfaz recibido TLV del MEP remoto. Si el valor de estado de interfaz recibido no corresponde con uno de los valores estándar enumerados en Tabla 5, el show comando muestra "desconocido".

Puede mostrar este último estado de interfaz guardado TLV 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:

Mostrar el estado de la interfaz transmitida TLV

Junos OS guarda el último estado de interfaz transmitido TLV desde un MEP local. Si no se ha habilitado la transmisión del estado de la interfaz TLV, el show comando muestra "ninguno".

Puede mostrar el último estado de interfaz transmitido TLV 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:

Defectos del estado de MAC

Junos OS proporciona información de defectos del estado de MAC, lo que indica que uno o más de los MEP remotos están informando de un error en su TLV de estado de puerto o TLV de estado de interfaz. Indica "sí" si algún mep remoto informa que su interfaz no es isUp (por ejemplo, al menos una interfaz mep remota no está disponible) o si todos los MEP remotos informan de un TLV de estado de puerto que contiene algún valor distinto al psUp (por ejemplo, todos los puertos de puente MEP remotos no están reenviando datos). Hay dos show comandos que puede usar para ver la indicación de defectos de estado de MAC.

Utilice el mep-database comando para mostrar defectos de estado de MAC:

Utilice el interfaces comando para mostrar defectos de estado de MAC:

Configuración del soporte del perfil de acción de MEP remoto

Según los valores de interface-status-tlv y port-status-tlv en los paquetes CCM recibidos, se puede realizar una acción específica, como interface-down, mediante las action-profile opciones. Se pueden configurar varios perfiles de acción en el enrutador, pero solo se puede asignar un perfil de acción a un MEP remoto.

El perfil de acción se puede configurar con al menos un evento para activar la acción; pero la acción se activará si ocurre cualquiera de estos eventos. No es necesario que todos los eventos configurados se produzcan para activar action.

Un perfil de acción solo se puede aplicar a nivel mep remoto.

En el siguiente ejemplo, se muestra la configuración de un perfil de acción con comentarios explicativos agregados:

Monitoreo de un perfil de acción de MEP remoto

Puede usar el show oam ethernet connectivity-fault-management mep-database comando para ver el estado del perfil de acción de un MEP remoto, como en el ejemplo siguiente:

muestra oam Ethernet connectivity-fault-management remote-database remote-mep (evento del perfil de acción)

Configuración del ID de chasis TLV

En la versión 16.1R2 y posteriores, puede configurar Junos OS para enviar el ID de remitente TLV junto con los paquetes. La TLV de ID de remitente es una TLV opcional que se envía en mensajes de comprobación de continuidad (MCC), mensajes de circuito cerrado y mensajes de seguimiento de vínculos (LTM), como se especifica en el estándar IEEE 802.1ag. El ID de remitente TLV contiene el ID de 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 campo de la length TLV indica si el TLV contiene o no la información del ID de 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 del ID de chasis en el TLV, respectivamente.

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

También puede configurar el ID de remitente TLV 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].

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

Nota:

La TLV de ID de remitente solo se admite para las PDU 802.1ag y no para unidades de datos (PDU) de supervisión del rendimiento.

Configuración del procesamiento de mensajes de descarga MAC en modo CET

En el modo de transporte Ethernet de operadora (CET), los enrutadores serie MX se utilizan como enrutadores de borde de proveedor (PE), y los conmutadores Ethernet de operadora A2200 de Nokia Siemens Networks (denominados dispositivos de dominio E) que ejecutan protocolos estándar se utilizan en el lado de acceso. En los enrutadores serie MX, los pseudocables VPLS se configuran dinámicamente mediante el protocolo de distribución de etiquetas (LDP). En los dispositivos de dominio E, los cambios en la topología se detectan a través de sesiones de administración de errores de conectividad (CFM) que se ejecutan entre los dispositivos de dominio E y los enrutadores de la serie MX PE. Los enrutadores de PE serie MX pueden bajar la interfaz ethernet de operadora si hay pérdida de conectividad CFM. Esto activa una notificación mac de descarga local, así como una notificación de mac descarga del protocolo de distribución de etiquetas (T-LDP) de destino que se envía a los PEs de la serie MX remotos para activar el lavado de MAC en ellos.

En el modo operativo CET, los enrutadores de la serie MX deben interoperar con los dispositivos de acceso Ethernet de operadora Ax100 de Nokia Siemens Networks (conocidos como dispositivos de dominio A) que ejecutan protocolos heredados. Los dispositivos Nokia Siemens Networks A4100 y A8100 actúan como un intermediario entre los enrutadores de PE serie MX y los dispositivos de dominio A. Estos dispositivos intermedios realizan procedimientos de función de intertrabajo (IWF) para que las sesiones de administración de administración de operaciones (OAM) se puedan ejecutar entre enrutadores serie MX y dispositivos de dominio A. No hay pseudocables VPLS entre los enrutadores de PE serie MX y los dispositivos intermedios Nokia Siemens Networks A4100 y A8100, por lo que no hay ningún protocolo LDP que se ejecute entre los enrutadores de PE para enviar notificaciones de cambio de topología. Para comunicar los cambios de topología, los enrutadores de la serie MX pueden activar una MAC en descarga y propagarla en el núcleo. Los enrutadores de la serie MX pueden usar perfiles de acción basados en el evento valor de longitud del tipo de protección de conexión (TLV). El perfil de acción baja la interfaz lógica del borde de la operadora en los enrutadores de la serie MX PE, lo que activará un descarga de MAC local y también propagará el cambio de topología al núcleo mediante la notificación LDP.

Para VPLS no se supervisa ninguna conectividad de extremo a extremo. Los anillos de acceso se monitorean de forma independiente mediante la ejecución de CFM en varios puntos de extremo (MEP) en las rutas de trabajo y protección para cada uno de los servicios entre los dispositivos de dominio E y los enrutadores de PE serie MX, y entre los dispositivos de dominio A y los enrutadores de PE serie MX, la IWF alojada por los dispositivos A-4100 de Nokia Siemens Networks. Cuando hay un error 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 TTL transportados en CCM) que se enviará a la ruta activa.

Figura 1: Topología homed dual interoperacional CETTopología homed dual interoperacional CET

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

Se produce un lavado de MAC cuando la sesión de CFM que monitorea 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 monitorea la ruta de protección detecta que el tráfico de servicio se ha movido a la ruta de trabajo.

Figura 2: Topología adjunta dual interoperatoria CETTopología adjunta dual interoperatoria CET

Figura 2 describe la topología dual adjunta en enrutadores de la serie MX PE conectados al dominio A. El mecanismo de descarga mac utilizado en este caso también es el mismo que se utiliza para el dominio A en el escenario de doble hogar (Figura 1). Sin embargo, en este caso, ambas sesiones de CFM están alojadas por un solo enrutador de la serie MX PE. Cuando Ax100 en el dominio A detecta cambios en la topología, el enrutador de la serie MX PE recibe la protección de la conexión TLV 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 genera para la sesión de CFM, el enrutador de la serie MX PE desactivará la interfaz adecuada que activará un descarga de MAC local.

Configurar un perfil de acción TLV de protección de conexión

Se puede configurar un perfil de acción para realizar la interface-down acción según los valores de connection-protection-tlv los paquetes CCM recibidos.

En el siguiente ejemplo, se muestra la configuración de un perfil de acción con comentarios explicativos agregados:

Ejemplo: Configurar un perfil de acción basado en TTLV de protección de conexión

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

Requisitos

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

  • Junos OS versión 11.2 o posterior

  • Un enrutador PE serie MX

Descripción general y topología

La topología física de una red CET que usa enrutadores de pe serie MX se muestra en Figura 3

Topología

Figura 3: Topología de la red CETTopología de la red CET

Las siguientes definiciones describen el significado de la abreviatura del dispositivo y los términos utilizados en Figura 3.

  • Dispositivo de borde de proveedor (PE): un dispositivo o conjunto de dispositivos en el borde de la red del proveedor que presenta la vista del proveedor del sitio del cliente.

  • Dominio electrónico: conmutadores Ethernet de operadora de Nokia Siemens Networks que ejecutan protocolos estándar basados en protocolos y se utilizan en el lado de acceso.

  • A-domain: conmutadores Ethernet de operadora de Nokia Siemens Networks que ejecutan protocolos heredados.

Configuración

Procedimiento

Procedimiento paso a paso

Para configurar un perfil de acción basado en el TLV de protección de conexión, preforme estas tareas:

  1. Configurar un perfil de acción

  2. Si la TLV de protección de la conexión se recibe con un valor "Protección en uso" de SET, la TLV de protección de conexión debe usar la ruta de protección

  3. Si la TLV de protección de la conexión se recibe con un valor "Protección en uso" de RESET, la TLV de protección de conexión debe usar la ruta de trabajo

  4. Configure el perfil de acción para desactivar la interfaz

Resultados

Comprobar los resultados de la configuración

Tabla de historial de versiones
Liberación
Descripción
17.3R1
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 de borde del cliente no es un dispositivo Juniper mediante el bit de indicación de defecto remoto (RDI).
16.1
En la versión 16.1R2 y posteriores, puede configurar Junos OS para enviar el ID de remitente TLV junto con los paquetes.