EN ESTA PÁGINA
Monitoreo CFM entre dispositivos CE y PE
Utilice este tema para obtener más información sobre la supervisión de CFM entre dispositivos perimetrales de proveedor y dispositivos perimetrales de cliente cuando el dispositivo perimetral de cliente no es un dispositivo de Juniper. Además, puede obtener más información sobre cómo los TLV de estado de interfaz, los TLV de estado de puerto, los TLV de ID de chasis y los TLV de protección de conexión ayudan a monitorear su red.
Notificación asincrónica del perfil de acción CFM
La notificación asíncrona basada en CFM permite la sincronización del estado del vínculo entre dos dispositivos CE conectados entre sí a través de un pseudocable que se origina en sus respectivos dispositivosPE. Emula el escenario como si dos dispositivos CE estuvieran conectados directamente. CFM proporciona señalización de extremo a extremo incluso si PE1 y PE2 no están conectados a través de una sola red, sino a través de un conjunto de redes.
Conectividad de capa 2 entre PE1 y PE2
La figura 1 es un ejemplo de escenario de despliegue en el que se puede usar la notificación asincrónica basada en CFM para sincronizar el estado del vínculo entre CE1 y CE2. Los siguientes dos requisitos se pueden cumplir con la configuración de notificación asíncrona.
-
Cuando el vínculo entre PE2 y CE2 se cae, el vínculo entre PE1 y CE1 también disminuye . Cuando se restaura el vínculo, se restaurael estado delvínculo entre PE1 y CE1. El cambio de estado del vínculo entre PE1 y CE1 debería funcionar de manerasimilar.
-
Cuando hay un problema de conectividad entre PE1 y PE2, se activa un vínculo entre PE1 y CE1 y PE2 y CE2. Si se restaura el estado de la conexión, debería restaurar el estado del vínculo en ambos extremos.
Consulte también
Configurar un perfil de acción CFM para la notificación asincrónica
CFM UP-MEP en PE1 y PE2, monitorea la conectividad entre PE1 y PE2. El interface-status-tlv en estos puntos finales UP-MEP transmite el estado del enlace entre PE1, CE1y PE2, así como entre PE2, CE2y PE1. Debe configurar el perfil de acción en PE1 a PE2 para dirigir notificaciones asíncronas hacia los respectivos dispositivos CE. El perfil de acción activa esas notificaciones cuando el sistema detecta pérdida de adyacencia o una condición de vínculo caído en el archivo . interface-status-tlv
Comprender 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 perimetrales del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo perimetral del cliente no es un dispositivo de Juniper. Cuando la interfaz deja de funcionar, CFM propaga el estado de la interfaz en los mensajes CC. El mensaje CC notifica al dispositivo perimetral 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 la interfaz (tipo, longitud y valor): puede habilitar la supervisión de la administración de errores de conectividad (CFM) entre los dispositivos perimetrales del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo perimetral del cliente no es un dispositivo Juniper mediante el TLV de estado de la interfaz. Cuando la interfaz deja de funcionar, CFM propaga el estado de la interfaz mediante el TLV de estado de la interfaz. La TLV de estado de interfaz indica el estado de la interfaz que aloja el MEP que transmite el MCP, o indica la siguiente interfaz inferior en el IETF RFC 2863 IF-MIB. Por lo tanto, el dispositivo perimetral del cliente se entera 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 nivel de[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkjerarquía. Esta configuración es la opción estándar.RDI (indicación remota de defectos): puede habilitar la supervisión de la administración de errores de conectividad (CFM) entre los dispositivos perimetrales del proveedor y los dispositivos perimetrales del cliente cuando el dispositivo perimetral del cliente no es un dispositivo Juniper mediante el bit RDI. Cuando se habilita la supervisión de CFM, CFM propaga el estado del dispositivo perimetral del proveedor a través del bit RDI en los mensajes CC, que informa al dispositivo perimetral del cliente de que el dispositivo perimetral del proveedor no funciona. El bit RDI se borra cuando se realiza una copia de seguridad del servicio. Para configurar la supervisión de CFM mediante el bit RDI, utilice la
interface-status-send-rdiinstrucción en el nivel de[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkjerarquía. Esta opción es necesaria si el dispositivo perimetral del cliente no admite el TLV de estado de interfaz.
Cuando establece la interfaz en CCC y configura RDI, el dispositivo envía el bit RDI. CFM no supervisa el estado de la interfaz.
Si desactiva CCC mientras la interfaz no está en modo de espera y configura RDI, el dispositivo incluye el bit RDI en los mensajes CC.
- Caso de uso de multi-homing activo único con bit RDI
- Caso de uso de multi-homing activo/activo usando el bit RDI
Caso de uso de multi-homing activo único con bit RDI
Considere la siguiente topología, que incluye dos dispositivos perimetrales de proveedor (PE1 y PE2) y dos dispositivos perimetrales de cliente (CE1 y CE2). PE1 funciona en el estado activo, mientras que PE2 permanece en el estado de espera. Cuando configura CFM MEP hacia abajo entre PE y CE, CFM detecta que el CCC está inactivo y el sistema incluye el bit RDI en los mensajes CC. Los mensajes CC de PE2 a CE2 tienen el bit RDI configurado para indicar el estado bloqueado. Cuando PE2 se activa, el sistema borra el estado de inactividad del MCC y elimina el bit RDI de los mensajes CC posteriores.
Caso de uso de multi-homing activo/activo usando el bit RDI
Considere la siguiente topología, que incluye dos dispositivos perimetrales de proveedor (PE1 y PE2) y dos dispositivos perimetrales de cliente (CE1 y CE2). PE1 funciona en el estado activo, mientras que PE2 permanece en el estado de espera. Cuando no se configura CFM abajo MEP entre PE y CE para supervisar la conectividad del vínculo, el sistema no incluye el bit RDI en los mensajes CC. Cuando configura CFM MEP hacia abajo entre PE y CE, CFM detecta que el CCC está inactivo y el sistema incluye el bit RDI en los mensajes CC. Los mensajes CC de PE2 a CE2 tienen el bit RDI configurado para indicar el estado bloqueado. Cuando PE2 se activa, el sistema borra el estado de inactividad del MCC y elimina el bit RDI de los mensajes CC posteriores.
Consulte también
ConfigurarTLV de estado de puerto electrónico y TLV de estado de interfaz
- Descripción general de los TLV
- Varios TLV para PDU CFM
- Compatibilidad con TLV opcionales adicionales
- Defectos de estado MAC
- Configurar la compatibilidad con perfiles de acción MEP remotos
- Supervisar un perfil de acción 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 variable y/o información opcional en una PDU. Los TLV no están alineados con ninguna palabra o límite de octeto en particular. Los TLV se suceden sin relleno entre ellos.
Tabla 1 muestra el formato TLV e indica si es obligatorio u opcional.
Parámetro |
Octeto (secuencia) |
Description |
|---|---|---|
Tipo |
1 |
Este campo es obligatorio. Si el valor es 0, no hay más campos (Longitud o Valor). Si el valor no es 0, debe seguir el campo Longitud. |
Largura |
2–3 |
Este campo sólo es 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. Un valor de campo Longitud de 0 significa que no hay ningún campo Valor. |
valor |
4 |
La longitud de este campo se especifica mediante el campo Longitud. Es opcional y no estará presente si el campo Tipo es 0 o si el campo Longitud es 0. |
Varios TLV para PDU CFM
Tabla 2 muestra un conjunto de TLV definidos por IEEE 802.1ag para varios tipos de PDU CFM. Cada TLV se puede identificar por el valor único asignado a su campo Tipo. Algunos valores de campo Tipo están reservados.
TLV u organización |
Tipo de campo |
|---|---|
Finalizar TLV |
0 |
ID de remitente TLV |
1 |
TLV de estado del puerto |
2 |
TLV de datos |
3 |
Estado de la interfaz TLV |
4 |
Respuesta TLV de entrada |
5 |
Respuesta salida TLV |
6 |
Identificador de salida LTM TLV |
7 |
Identificador de salida LTR TLV |
8 |
Reservado para IEEE 802.1 |
9 a 30 |
TLV específico de la organización |
31 |
Definido por el UIT-T Y.1731 |
32 a 63 |
Reservado para IEEE 802.1 |
64 a 255 |
No todos los TLV son aplicables a todos los tipos de PDU CFM.
TLV aplicables al mensaje de verificación de continuidad (CCM):
Finalizar TLV
ID de remitente TLV
TLV de estado del puerto
Estado de la interfaz TLV
TLV específico de la organización
TLV aplicables para mensajes de circuito cerrado (LBM):
Finalizar TLV
ID de remitente TLV
TLV de datos
TLV específico de la organización
TLV aplicables para la respuesta de circuito cerrado (LBR):
Finalizar TLV
ID de remitente TLV
TLV de datos
TLV específico de la organización
TLV aplicables para mensajes de rastreo de enlaces (LTM):
Finalizar TLV
Identificador de salida LTM TLV
ID de remitente TLV
TLV específico de la organización
TLV aplicables para la respuesta de rastreo de enlaces (LTR):
Finalizar TLV
Identificador de salida LTR TLV
Respuesta TLV de entrada
Respuesta salida TLV
ID de remitente TLV
TLV específico de la organización
Los siguientes TLV son actualmente compatibles con las PDU de CFM aplicables:
Finalizar TLV
Respuesta TLV de entrada
Respuesta salida TLV
Identificador de salida LTR TLV
Identificador de salida LTM TLV
TLV de datos
Compatibilidad con TLV opcionales adicionales
Se admiten los siguientes TLV opcionales adicionales:
TLV de estado del puerto
Estado de la interfaz TLV
Los enrutadores de la serie MX admiten la configuración de TLV de estado de puerto y TLV de estado de interfaz. La configuración de la TLV de estado de puerto permite al operador controlar la transmisión de la TLV de estado de puerto en PDU CFM.
Para obtener información de configuración, consulte las secciones siguientes:
TLV de estado del puerto
El TLV de estado del puerto indica la capacidad del puerto puente en el que reside el MEP transmisor para pasar datos ordinarios, independientemente del estado del MAC. El valor de este TLV está controlado por la variable enableRmepDefectMEP , como se muestra en Tabla 4. El formato de este TLV se muestra en Tabla 3.
Cualquier cambio en el valor de los TLV de estado del puerto desencadena una transmisión adicional de los MCPs MEP de los puertos de puente.
Parámetro |
Octeto (secuencia) |
|---|---|
Tipo = 2 |
1 |
Largura |
2–3 |
Valor (Ver Tabla 4) |
4 |
Mnemotécnico |
Datos ordinarios que pasan libremente por el puerto |
valor |
|---|---|---|
psBloqueado |
No: |
1 |
psUp |
Sí: |
2 |
La variable enableRmepDefect MEP es una variable booleana. Indica si las tramas de la instancia de servicio supervisada por las asociaciones de mantenimiento del MEP pueden pasar a través del 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 del 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 a un dominio puente.
- Configurar TLV de estado de puerto
- Mostrar el TLV de estado del puerto recibido
- Mostrar el TLV de estado del puerto transmitido
Configurar TLV de estado de puerto
Junos OS proporciona compatibilidad de configuración para el TLV de estado de puerto, lo que le permite controlar la transmisión del TLV en PDU CCM. Junos OS proporciona esta configuración en el nivel de comprobación de continuidad. De forma predeterminada, el MCP 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 nivel de [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] jerarquía.
IEEE 802.1ag no exige la configuración del TLV de estado del puerto. Junos OS proporciona esta configuración para dar más flexibilidad al operador; sin embargo, recibe y procesa MCPs con un TLV de estado de puerto, independientemente de la 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 la transmisión TLV de estado de puerto en los dos casos siguientes:
Si la interfaz MEP bajo la asociación de mantenimiento no es de tipo puente.
Si el MEP está configurado en una interfaz física.
Mostrar el TLV de estado del puerto recibido
Junos OS guarda el último TLV de estado de puerto recibido de un MEP remoto. Si el valor Estado de puerto recibido no corresponde a uno de los valores estándar enumerados en Tabla 4, show el comando lo muestra como "desconocido". Puede mostrar la última TLV de estado del puerto recibida guardada 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 siguiente ejemplo:
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 TLV de estado del puerto transmitido
Junos OS guarda el último TLV de estado de puerto transmitido de un MEP local. Si no se ha habilitado la transmisión de la TLV de estado del puerto, el show comando muestra "none". Puede mostrar el último TLV de estado del puerto transmitido guardado utilizando 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 siguiente ejemplo:
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
Estado de la interfaz TLV
El TLV Estado de la interfaz indica el estado de la interfaz en la que está configurado el MEP que transmite el MCP, o la interfaz siguiente inferior en el IETF RFC 2863 IF-MIB. El formato de este TLV se muestra en Tabla 5. Los valores enumerados se muestran en Tabla 6.
Parámetro |
Octeto (secuencia) |
|---|---|
Tipo = 4 |
1 |
Largura |
2–3 |
Valor (Ver Tabla 6) |
4 |
Mnemotécnico |
Estado de la interfaz |
valor |
|---|---|---|
Isup |
hacia arriba |
1 |
isDown |
abajo |
2 |
isTesting |
ensayo |
3 |
esDesconocido |
desconocido |
4 |
isDormant |
inactivo |
5 |
isNotPresent |
notPresent |
6 |
isLowerLayerDown |
lowerLayerDown |
7 |
Cuando el estado operativo de una interfaz lógica cambia del estado abajo (valor de estado de 2) al estado de capa inferior (valor de estado de 7) y viceversa, no se genera la captura SNMP de LinkDown. Por ejemplo, si configura un paquete de interfaz Ethernet agregado con una etiqueta VLAN y agrega al paquete una interfaz física que está en estado operativamente inactivo, el estado operativo del paquete de interfaz lógica Ethernet agregado en ese punto es capa inferior (7). Si desconecta el MIC asociado a la interfaz, la captura LinkDown no se genera cuando la interfaz lógica cambia del estado inferior de capa descendente al estado descendente.
Del mismo modo, considere otro escenario de ejemplo en el que se agrega una interfaz física a un paquete de Ethernet agregado que tiene etiquetado VLAN y la interfaz lógica 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 Ethernet agregado, el estado operativo de la interfaz lógica Ethernet agregada permanece inactivo. Si vuelve a habilitar la interfaz lógica Ethernet agregada, el estado operativo de la misma cambia de capa inferior a capa inferior. La captura SNMP de LinkDown no se genera en este momento.
- Configurar TLV de estado de interfaz
- Mostrar el TLV de estado de interfaz recibido
- Mostrar el TLV de estado de la interfaz transmitida
Configurar TLV de estado de interfaz
Junos OS proporciona soporte de configuración para el TLV de estado de interfaz, lo que permite a los operadores controlar la transmisión de este TLV en PDU CCM a través de la configuración a nivel de verificació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 MCPs con el TLV Estado de interfaz, independientemente de esta configuración.
La configuración del TLV de estado de la interfaz se muestra a continuació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;
interface-status-tlv; # Sets the interface status TLV
}
}
}
}
}
}
}
Junos OS admite la transmisión de solo tres de los siete valores posibles para el TLV de estado de la 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 la interfaz.
Mostrar el TLV de estado de interfaz recibido
Junos OS guarda el último TLV de estado de interfaz recibido del MEP remoto. Si el valor de Estado de interfaz recibido no corresponde a uno de los valores estándar enumerados en Tabla 5, el show comando muestra "desconocido".
Puede mostrar este último TLV de estado de interfaz guardado usando 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 siguiente ejemplo:
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 TLV de estado de la interfaz transmitida
Junos OS guarda el último TLV de estado de interfaz transmitido desde un MEP local. Si no se ha habilitado la transmisión del TLV de estado de la interfaz, el show comando muestra "none".
Puede mostrar el último TLV de estado de interfaz transmitido 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 de estado MAC
Junos OS proporciona información sobre defectos de estado MAC que indica cuándo los MEP remotos informan de errores en su TLV de estado de puerto o TLV de estado de interfaz. El sistema indica "sí" si uno o más eurodiputados remotos informan que su interfaz no está "activa" (por ejemplo, cuando la interfaz de un eurodiputado remoto no está disponible) o si, todos los eurodiputados remotos informan de un TLV de estado de puerto con algún valor distinto de "Arriba" (por ejemplo, cuando todos los puertos puente de los eurodiputados remotos no están reenviando datos). Puede ver la indicación de defectos de estado MAC mediante dos show comandos.
Utilice el comando para mostrar los defectos de mep-database 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 comando para mostrar los defectos de interfaces 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
Configurar la compatibilidad con perfiles de acción MEP remotos
Según los valores de y port-status-tlv en los paquetes CCM interface-status-tlv 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 uno o más eventos, y la acción se desencadena cuando se produce cualquiera de estos eventos. No es necesario que se activen actiontodos los eventos configurados .
Un perfil de acción solo se puede aplicar a nivel de MEP remoto.
En el ejemplo siguiente se muestra una configuración de 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;
}
}
}
}
Supervisar un perfil de acción MEP remoto
Puede utilizar 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:
mostrar conectividad Ethernet OAM gestión de fallos MEP-base de datos remote-mep (evento de 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
Configurar el ID de chasis TLV
Puede configurar Junos OS para enviar el TLV de ID de remitente junto con los paquetes. El TLV de ID de remitente es un TLV opcional que se envía en mensajes de comprobación de continuidad (CCM), mensajes de circuito cerrado y mensajes de seguimiento de vínculos (LTM), como se especifica en el estándar IEEE 802.1ag. El TLV de ID de remitente 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 length campo en el TLV indica si el TLV contiene o no la información del ID del chasis. Los valores posibles para el length campo son cero (0) o cualquier número válido, lo que indica la ausencia o presencia de información de ID de chasis en el TLV, respectivamente.
Puede habilitar Junos OS para que envíe el TLV del ID de remitente a nivel global mediante el set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv comando. Si el TLV ID de remitente está configurado en el nivel global, el dominio de mantenimiento predeterminado, la asociación de mantenimiento y la mitad de la función de punto intermedio de asociación de mantenimiento (MIP) heredan esta configuración.
También puede configurar el TLV de ID de remitente en los siguientes niveles jerárquicos:
[edit protocols oam ethernet connectivity-fault-management][edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check]
La configuración de TLV de ID de remitente en el maintenance-association nivel tiene prioridad sobre la configuración a nivel global.
La TLV de ID de remitente solo se admite para PDU 802.1ag y no para unidades de datos de protocolo de supervisión de rendimiento (PDU).
Consulte también
Configurar el procesamiento de mensajes de vaciado de MAC en modo CET
En el modo de transporte Ethernet de operadora (CET), los enrutadores de la serie MX se utilizan como enrutadores de borde de proveedor (PE) y, en el lado de acceso, se utilizan conmutadores Ethernet de operadora A2200 de Nokia Siemens Networks (denominados dispositivos de dominio electrónico) que ejecutan protocolos basados en estándares. En los enrutadores de la serie MX, los pseudocables VPLS se configuran dinámicamente mediante el protocolo de distribución de etiquetas (LDP). En los dispositivos de dominio electrónico, los cambios en la topología se detectan mediante sesiones de administración de errores de conectividad (CFM) que se ejecutan entre los dispositivos de dominio electrónico y los enrutadores PE de la serie MX. Los enrutadores PE de la serie MX pueden desactivar la interfaz Ethernet del operador si se produce una pérdida de conectividad CFM. Esto activa un vaciado de MAC local, así como una notificación de vaciado de MAC de protocolo de distribución de etiquetas dirigido (T-LDP) que se envía a los PE remotos de la serie MX para activar el vaciado de MAC en ellos.
En el modo interoperativo CET, los enrutadores de la serie MX deben interoperar con los dispositivos de acceso Ax100 Carrier Ethernet de Nokia Siemens Networks (denominados dispositivos de dominio A) que ejecutan protocolos heredados. Los dispositivos Nokia Siemens Networks A4100 y A8100 actúan como un intermediario entre los enrutadores PE de la 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 operaciones (OAM) se puedan ejecutar entre enrutadores de la serie MX y dispositivos de dominio A. No hay pseudocables VPLS entre los enrutadores PE de la serie MX y los dispositivos intermedios A4100 y A8100 de Nokia Siemens Networks, por lo que no hay ningún protocolo LDP ejecutándose entre los enrutadores PE para enviar notificaciones de cambio de topología. Para comunicar los cambios de topología, los enrutadores de la serie MX pueden activar un vaciado de MAC y propagarlo en el núcleo. Los enrutadores de la serie MX pueden usar perfiles de acción basados en el evento de valor de longitud de tipo de protección de conexión (TLV). El perfil de acción desactiva la interfaz lógica del borde de la operadora en los enrutadores PE de la serie MX, lo que activará un vaciado de MAC local y también propagará el cambio de topología al núcleo mediante la notificación LDP.
Para VPLS no hay conectividad de extremo a extremo monitoreada. Los anillos de acceso se supervisan de forma independiente mediante la ejecución de CFM en múltiples puntos finales (MEP) en las rutas de trabajo y protección para cada uno de los servicios entre los dispositivos de dominio electrónico y los enrutadores PE de la serie MX, y entre los dispositivos de dominio A y los enrutadores PE de la serie MX, el IWF alojado por los dispositivos A-4100 de Nokia Siemens Networks. Cuando hay un fallo de conectividad en la ruta de trabajo, los dispositivos Nokia Siemens Networks Ax200 realizan un cambio a la ruta de protección, activando una notificación de cambio de topología (en forma de TLV transportados en CCM) que se enviará en la ruta activa.
Figura 1 describe la topología de base dual en los enrutadores PE de la serie MX conectados al dominio A. Cuando un dispositivo de dominio A activa un cambio, comienza a cambiar el tráfico de servicio a la nueva ruta activa. Este cambio se comunica en las unidades de datos del protocolo HELLO (PDU) enviadas por ese dispositivo de dominio A en las rutas de trabajo y protección. Cuando el IWF en el A4100 recibe estas PDU HELLO, las convierte en mensajes CCM estándar y también inserta un TLV de protección de conexión. El campo "Protección en uso" de la TLV de protección de conexión está codificado con la ruta actualmente activa y se incluye en el mensaje del MCP. Los mensajes CCM son recibidos por los enrutadores PE de la serie MX a través del radio VLAN en A4100. En el escenario de base dual anterior, un enrutador de PE de la serie MX supervisa la ruta de trabajo y el otro enrutador de PE de la serie MX supervisa la ruta de protección.
Un vaciado de MAC se produce cuando la sesión de CFM que supervisa la ruta de trabajo detecta que el tráfico de servicio se ha movido a la ruta de protección o cuando la sesión de CFM que supervisa la ruta de protección detecta que el tráfico de servicio se ha movido a la ruta de trabajo.
Figura 2 describe la topología de conexión dual en los enrutadores PE de la serie MX conectados al dominio A. El mecanismo de vaciado de MAC utilizado en este caso también es el mismo que el utilizado para el dominio A en el escenario de base dual (Figura 1). Sin embargo, en este caso, ambas sesiones de CFM están alojadas por un solo enrutador PE de la serie MX. Cuando el Ax100 en el dominio A detecta cambios en la topología, el enrutador PE de la serie MX recibe el TLV de protección de conexión en el mensaje CCM para las rutas de trabajo y protección con el valor de "Protección en uso" que indica qué ruta es la activa. Según el evento que se genere para la sesión CFM, el enrutador PE de la serie MX desplegará la interfaz adecuada que activará un vaciado de MAC local.
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 en función de los valores de connection-protection-tlv los paquetes CCM recibidos.
En el ejemplo siguiente se muestra una configuración de 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 TLV de protección de conexión
En este ejemplo se muestra cómo configurar un perfil de acción basado en la TLV de protección de conexión con el fin de desencadenar vaciados de MAC basados en cambios de topología en una red CET.
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 mediante enrutadores PE de la 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 perimetral del proveedor (PE): dispositivo o conjunto de dispositivos, en el borde de la red del proveedor que presenta la vista del proveedor del sitio del cliente.
E-domain—Nokia Siemens Networks Carrier Ethernet Switches que ejecutan protocolos basados en estándares y se utilizan en el lado de acceso.
Dominio A: 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, realice estas tareas:
Configurar un perfil de acción
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event { } }Si el TLV de protección de conexión se recibe con un valor de "Protección en uso" de SET, entonces el TLV de protección de conexión debe usar la ruta de protección
connection-protection-tlv <using-protection-path>;
Si el TLV de protección de conexión se recibe con un valor de "Protección en uso" de RESET, entonces el 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;
}
}
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.