EN ESTA PÁGINA
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
Consulte también
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.
See Also
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-tlvinstrucción en el[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checknivel 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-rdiinstrucción en el[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checknivel de jerarquía. Esta opción es necesaria si el dispositivo de borde del cliente no admite el estado de la interfaz TLV.
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
- Caso de uso de multiconexión activa/activa con bit 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.
Consulte también
Configuración del estado de TLV del puerto y el estado de la interfaz TLV
- Descripción general de los TLV
- Varios TTV para PDU CFM
- Soporte para TAV opcionales adicionales
- Defectos del estado de MAC
- Configuración del soporte del perfil de acción de MEP remoto
- Monitoreo de un perfil de acción de MEP remoto
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.
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.
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.
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.
Parámetro |
Octeto (secuencia) |
|---|---|
Tipo = 2 |
1 |
Longitud |
2–3 |
Valor (Consulte Tabla 4) |
4 |
Mnemónica |
Datos ordinarios que pasan libremente por el puerto |
valor |
|---|---|---|
psBloqueado |
No: |
1 |
psUp |
Sí: |
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
- Mostrar el estado del puerto recibido TLV
- Mostrar el estado del puerto transmitido TLV
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.
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:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number,
loss-threshold number;
hold-interval number;
port-status-tlv; # Sets Port Status TLV
}
}
}
}
}
}
}
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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none # RX PORT STATUS
Interface status TLV: none
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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up # TX PORT STATUS
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
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.
Parámetro |
Octeto (secuencia) |
|---|---|
Tipo = 4 |
1 |
Longitud |
2–3 |
Valor (Consulte Tabla 6) |
4 |
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 |
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
- Mostrar el estado de la interfaz recibida TLV
- Mostrar el estado de la interfaz transmitida TLV
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.
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:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number;
loss-threshold number;
hold-interval number;
interface-status-tlv; # Sets the interface status TLV
}
}
}
}
}
}
}
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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none # displays the Interface Status TLV state
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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6 maintenance-association ma6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1658
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Utilice el interfaces comando para mostrar defectos de estado de MAC:
user@host> show oam ethernet connectivity-fault-management interfaces detail
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
Interface status TLV: up, Port status TLV: up
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
MEP status: running
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1328
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
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:
[edit protocols oam ethernet connectivity-fault-management]
action-profile tlv-action {
event {
# If interface status tlv with value specified in the config is received
interface-status-tlv down|lower-layer-down;
# If port status tlv with value specified in the config is received
port-status-tlv blocked;
# If connectivity is lost to the peer */
adjacency-loss;
}
action {
# Bring the interface down */
interface-down;
}
default-actions interface-down;
}
# domains
maintenance-domain identifier {
# maintenance domain level (0-7)
level number;
# association
maintenance-association identifier {
mep identifier {
interface ge-x/y/z.w;
remote-mep identifier {
# Apply the action-profile for the remote MEP
action-profile tlv-action;
}
}
}
}
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)
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 remote-mep 200
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 100, Direction: down, MAC address: 00:05:85:73:e8:ad
Auto-discovery: enabled, Priority: 0
Interface status TLV: none, Port status TLV: none # last status TLVs transmitted by the router
Interface name: ge-1/0/8.0, Interface status: Active, Link status: Up
Remote MEP identifier: 200, State: ok # displays the remote MEP name and state
MAC address: 00:05:85:73:96:1f, Type: Configured
Interface: ge-1/0/8.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: lower-layer-down
Action profile: juniper # displays remote MEP’s action profile identifier
Last event: Interface-status-tlv lower-layer-down # last remote MEP event
# to trigger action
Action: Interface-down, Time: 2009-03-27 14:25:10 PDT (00:00:02 ago)
# action occurrence time
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.
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.
Consulte también
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 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 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:
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
# If a connection protection TLV with a “Protection-in-use” value of SET is received */
connection-protection-tlv <using-protection-path>;
# If a connection protection TLV with a “Protection-in-use” value of RESET is received */
connection-protection-tlv <using-working-path>;
}
action {
# Bring the interface down */
interface-down;
}
}
Consulte también
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
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:
Configurar un perfil de acción
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event {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
connection-protection-tlv <using-protection-path>;
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
connection-protection-tlv <using-working-path>; }
Configure el perfil de acción para desactivar la interfaz
action { /* Bring the interface down */ interface-down; } }
Resultados
Comprobar los resultados de la configuración
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
connection-protection-tlv <using-protection-path>;
connection-protection-tlv <using-working-path>;
}
action {
interface-down;
}
}