Descripción general de la OAM del servicio Ethernet ITU-T Y.1731
SUMMARY En esta sección se describe la OAM del servicio (ITU-TY.1731) y sus dos componentes principales: gestión de errores (monitoreo, detección y aislamiento) y monitoreo del rendimiento (medición de pérdida de trama, medición de pérdida de trama sintética y medición de retraso de trama).
Descripción general de las mediciones de retraso de trama Ethernet
- Función de medición de retraso de fotogramas ITU-T Y.1731
- Medición de retraso de marco Ethernet un solo sentido
- Medición de retraso de trama Ethernet bidireccional
- Elegir entre ETH-DM de una y dos vías
- Restricciones para la medición de retraso de trama Ethernet
Función de medición de retraso de fotogramas ITU-T Y.1731
El estándar IEEE 802.3-2005 para operaciones, administración y mantenimiento (OAM) de Ethernet define un conjunto de mecanismos de administración de fallas de vínculo para detectar e informar errores de vínculo en una SOLA LAN punto a punto de Ethernet.
Junos OS admite estándares clave de OAM que proporcionan administración y monitoreo automatizados de extremo a extremo del servicio ethernet por parte de los proveedores de servicios:
Estándar IEEE 802.1ag, también conocido como "Administración de errores de conectividad (CFM)".
Recomendación UIT-T Y.1731, que utiliza una terminología diferente a ieee 802.1ag y define las funciones de OAM del servicio Ethernet para la supervisión, el diagnóstico y la supervisión del rendimiento de los fallos.
Estas capacidades permiten a los operadores ofrecer acuerdos de nivel de servicio (SLA) vinculantes y generar nuevos ingresos a partir de paquetes de servicios con velocidad y rendimiento garantizados que se adaptan a las necesidades específicas de sus clientes.
Los enrutadores de la serie ACX admiten modos proactivos y a pedido.
Puede configurar las capacidades de medición de pérdidas de Ethernet (ETH-LM) que cumple con el estándar ITU-T Y.1731, medición de pérdida sintética de Ethernet (ETH-SLM) y medición de retraso de Ethernet (ETH-DM) en tarjetas de línea MPC10 y MPC11 solo en 20.2R2-S3 y 20.4R1 en adelante.
Los enrutadores ACX5048 y ACX5096 solo admiten el sello de tiempo basado en software para la medición de retrasos.
Ethernet CFM
El estándar IEEE 802.1ag para la administración de errores de conectividad (CFM) define mecanismos para proporcionar una garantía de servicio Ethernet de extremo a extremo en cualquier ruta, ya sea un solo vínculo o varios vínculos que abarcan redes compuestas por varias LAN.
Para interfaces Ethernet en enrutadores serie M320, MX y T, Junos OS admite los siguientes elementos clave del estándar CFM de Ethernet:
Monitoreo de errores mediante el protocolo de comprobación de continuidad de la OAM Ethernet 802.1ag
Descubrimiento de ruta y verificación de fallas mediante el protocolo IEEE 802.1ag Ethernet OAM Linktrace
Aislamiento de errores mediante el protocolo de circuito cerrado de OAM Ethernet 802.1ag
En un entorno de CFM, las entidades de red, como operadores de red, proveedores de servicios y clientes, pueden formar parte de diferentes dominios administrativos. Cada dominio administrativo se asigna en un dominio de mantenimiento. Los dominios de mantenimiento se configuran con diferentes valores de nivel para mantenerlos separados. Cada dominio proporciona suficiente información para que las entidades realicen su propia administración y supervisión de extremo a extremo, y aún así evitar vulneraciones de seguridad.
Figura 1 muestra las relaciones entre los clientes, proveedores y operadores de puentes Ethernet, dominios de mantenimiento, puntos finales de asociación de mantenimiento (MEP) y puntos intermedios de mantenimiento (MIC).

En los enrutadores serie ACX, los puntos intermedios de mantenimiento (MIP) solo se admiten en los enrutadores ACX5048 y ACX5096.
Medición de retraso de trama Ethernet
Dos objetivos clave de la funcionalidad de OAM son medir los atributos de calidad del servicio, como el retraso de trama y la variación de retraso de trama (también conocido como " fluctuación de tramas"). Estas mediciones pueden permitirle identificar problemas de red antes de que los clientes se vean afectados por defectos de red.
Junos OS admite la medición de retraso de trama Ethernet entre MEP configurados en interfaces físicas o lógicas de Ethernet en enrutadores serie MX. La medición de retraso de trama Ethernet proporciona un control fino a los operadores para activar la medición de retraso en un servicio determinado y se puede utilizar para monitorear los SLA. La medición de retraso de trama de Ethernet también recopila otra información útil, como retrasos en el peor y el mejor caso, retraso promedio y variación del retraso promedio. La implementación de Junos OS de la medición de retraso de trama de Ethernet (ETH-DM) cumple plenamente con la Recomendación ITU-T Y.1731, funciones y mecanismos de OAM para redes basadas en Ethernet. En la recomendación se definen los mecanismos de OAM para operar y mantener la red en la capa de servicio Ethernet, que en la terminología del ITU-T se denomina "capa ETH".
Los enrutadores serie MX con concentradores de puerto modular (MPC) y MPC de 10 Gigabit Ethernet con SFP+ admiten la funcionalidad ITU-T Y.1731 en VPLS para retardo de trama y variación.
El chasis virtual de la serie MX no admite la medición de retraso de trama (DM) de Ethernet.
Medición de retraso de marco Ethernet un solo sentido
En el modo ETH-DM un way, se calculan una serie de valores de variación de retraso de trama y de retraso de trama según el tiempo transcurrido entre el tiempo que se envía una trama de medición desde el MEP iniciador en un enrutador y el momento en que se recibe la trama en el MEP receptor en el otro enrutador.
Los enrutadores de la serie ACX no admiten la medición de retraso de tramas ethernet un solo sentido.
- Transmisión 1DM
- Recepción de 1DM
- Estadísticas de ETH-DM un solo sentido
- Recuentos de tramas UN WAY ETH-DM
- Sincronización de relojes del sistema
Transmisión 1DM
Cuando inicia una medición de retraso de fotogramas un solo sentido, el enrutador envía tramas 1DM (tramas que llevan la unidad de datos de protocolo (PDU) para una medición de retraso un solo sentido, desde el MEP iniciador hasta el MEP receptor a la velocidad y para el número de tramas que especifique. El enrutador marca cada trama de 1 MD como inelegible de caída e inserta una marca de hora del tiempo de transmisión en el marco.
Recepción de 1DM
Cuando un MEP recibe una trama de 1DM, el enrutador que contiene el MEP receptor mide el retraso un way para esa trama (la diferencia entre el tiempo en que se recibió la trama y la marca de hora contenida en la propia trama) y la variación de retraso (la diferencia entre los valores de retraso actual y anterior).
Estadísticas de ETH-DM un solo sentido
El enrutador que contiene el MEP receptor almacena cada conjunto de estadísticas de retraso un solo sentido en la base de datos ETH-DM. La base de datos ETH-DM recopila hasta 100 conjuntos de estadísticas para cualquier sesión de CFM dada (par de eurodiputados). Puede acceder a estas estadísticas en cualquier momento mostrando el contenido de la base de datos ETH-DM.
Recuentos de tramas UN WAY ETH-DM
Cada enrutador cuenta la cantidad de tramas ETH-DM un way enviadas y recibidas:
Para un MEP iniciador, el enrutador cuenta la cantidad de tramas 1DM enviadas.
Para un MEP receptor, el enrutador cuenta la cantidad de tramas 1DM válidas recibidas y la cantidad de tramas 1DM no válidas recibidas.
Cada enrutador almacena los recuentos de tramas DE ETH-DM en la base de datos de CFM. La base de datos de CFM almacena estadísticas de sesión de CFM y, para las interfaces que admiten ETH-DM, cualquier trama eth-DM cuenta. Puede acceder a los recuentos de tramas en cualquier momento mostrando información de la base de datos de CFM para las interfaces Ethernet asignadas a los eurodiputados o para los eurodiputados en las sesiones de CFM.
Sincronización de relojes del sistema
La precisión de los cálculos de retraso en un sentido depende de la sincronización de cierre de los relojes del sistema en el MEP iniciador y el MEP receptor.
La precisión de la variación de retraso un solo sentido no depende de la sincronización del reloj del sistema. Dado que la variación de retraso es simplemente la diferencia entre los valores de retraso un solo sentido consecutivos, el período fuera de fase se elimina de los valores de fluctuación de trama.
Para una medida dada de retraso de trama Ethernet un way, los valores de variación de frame delay y frame delay solo están disponibles en el enrutador que contiene el MEP receptor.
Medición de retraso de trama Ethernet bidireccional
En el modo ETH-DM bidireccional, los valores de variación de retraso de trama y retraso de trama se basan en la diferencia de tiempo entre cuando el MEP iniciador transmite una trama de solicitud y recibe una trama de respuesta del MEP de respuesta, restando el tiempo transcurrido en el MEP de respuesta.
- Transmisión DMM
- Transmisión DMR
- Recepción de DMR
- Estadísticas ETH-DM bidireccionales
- Recuentos de tramas ETH-DM bidireccionales
Transmisión DMM
Cuando inicia una medición de retraso de trama bidireccional, el enrutador envía tramas de mensaje de medición de retraso (DMM) (tramas que llevan la PDU para una solicitud ETH-DM bidireccional) desde el MEP iniciador hasta el MEP de respuesta a la velocidad y para el número de tramas que especifique. El enrutador marca cada trama DMM como elegible de caída e inserta una marca de hora del tiempo de transmisión en la trama.
Transmisión DMR
Cuando un MEP recibe una trama DMM, el MEP que responde responde con una trama de respuesta de medición de retraso (DMR), la cual lleva la información de respuesta ETH-DM y una copia de la marca de hora contenida en el marco DMM.
Recepción de DMR
Cuando un MEP recibe un DMR válido, el enrutador que contiene el MEP mide el retraso bidireccional para esa trama en función de la siguiente secuencia de marcas de hora:
TI TxDMM
TR RxDMM
Tr TxDMR
RxDMR de TI
Un retraso de trama bidireccional se calcula de la siguiente manera:
[TIRxDMR – TITxDMM] – [TRTxDMR – TRRxDMM]
El cálculo muestra que el retraso de trama es la diferencia entre el tiempo en el que el MEP iniciador envía un marco DMM y el tiempo en el que el MEP iniciador recibe el marco DMR asociado del MEP de respuesta, menos el tiempo transcurrido en el MEP de respuesta.
La variación de retraso es la diferencia entre los valores de retraso actuales y anteriores.
Estadísticas ETH-DM bidireccionales
El enrutador que contiene el MEP iniciador almacena cada conjunto de estadísticas de retraso bidireccional en la base de datos ETH-DM. La base de datos ETH-DM recopila hasta 100 conjuntos de estadísticas para cualquier sesión de CFM dada (par de eurodiputados). Puede acceder a estas estadísticas en cualquier momento mostrando el contenido de la base de datos ETH-DM.
Recuentos de tramas ETH-DM bidireccionales
Cada enrutador cuenta la cantidad de tramas ETH-DM bidireccional enviadas y recibidas:
Para un MEP iniciador, el enrutador cuenta el número de tramas DMM transmitidas, la cantidad de tramas DMR válidas recibidas y la cantidad de tramas DMR no válidas recibidas.
Para un MEP de respuesta, el enrutador cuenta la cantidad de tramas DMR enviadas.
Cada enrutador almacena los recuentos de tramas DE ETH-DM en la base de datos de CFM. La base de datos de CFM almacena estadísticas de sesión de CFM y, para las interfaces que admiten ETH-DM, cualquier trama eth-DM cuenta. Puede acceder a los recuentos de tramas en cualquier momento mostrando información de la base de datos de CFM para las interfaces Ethernet asignadas a los eurodiputados o para los eurodiputados en las sesiones de CFM.
Para una medición dada de retraso de trama Ethernet bidireccional, los valores de variación de retraso de trama y de retraso de trama solo están disponibles en el enrutador que contiene el MEP iniciador.
Elegir entre ETH-DM de una y dos vías
La medición de retraso de fotogramas un solo sentido requiere que los relojes del sistema en el MEP iniciador y el MEP receptor estén estrechamente sincronizados. La medición del retraso de fotogramas bidireccional no requiere sincronización de los dos sistemas. Si no es práctico para la sincronización de los relojes, las mediciones de retraso de fotogramas bidireccionales son más precisas.
Cuando dos sistemas están físicamente cerca entre sí, sus valores de retraso un solo sentido son muy altos en comparación con sus valores de retraso bidireccional. La medición de retrasos un solo sentido requiere que el tiempo de los dos sistemas se sincronice a un nivel muy granular, y los enrutadores serie MX actualmente no admiten esta sincronización granular.
Restricciones para la medición de retraso de trama Ethernet
Se aplican las siguientes restricciones a la función de medición de retraso de trama de Ethernet:
La función ETH-DM no se admite en pseudocables de interfaz conmutada por etiquetas (LSI).
La función ETH-DM se admite en interfaces Ethernet agregadas.
La marca de hora asistida por hardware para tramas ETH-DM en la ruta de recepción solo se admite para interfaces MEP en DPC mejorados y DPC de cola mejoradas en enrutadores serie MX. Para obtener más información acerca de la marca de hora asistida por hardware, consulte Directrices para configurar enrutadores para admitir una sesión ETH-DM y Habilitar la opción marca de hora asistida por hardware.
Las mediciones de retraso de trama Ethernet solo se pueden activar cuando el demonio de administración de paquetes periódicos distribuido (
ppm
) está habilitado. Para obtener más información acerca de esta limitación, consulte Directrices para configurar enrutadores para que admitan una sesión ETH-DM y garantizar que las ppm distribuidas no estén deshabilitadas.Solo puede supervisar una sesión a la vez con la misma dirección MEP o MAC remota. Para obtener más información acerca de cómo iniciar una sesión ETH-DM, consulte Inicio de una sesión ETH-DM.
Las estadísticas de ETH-DM se recopilan en solo uno de los dos enrutadores pares en la sesión ETH-DM. Para una sesión ETH-DM un solo sentido, puede mostrar estadísticas de ETH-DM de marco solo en el MEP receptor, usando comandos específicos
show
de ETH-DM. Para una sesión ETH-DM bidireccional, puede mostrar estadísticas de retraso de trama solo en el MEP iniciador, usando los mismos comandos específicosshow
de ETH-DM. Para obtener más información, consulte Administración de estadísticas ETH-DM y recuentos de tramas ETH-DM.Los recuentos de tramas DE ETH-DM se recopilan en ambos parlamentos y se almacenan en las respectivas bases de datos de CFM.
Si se produce un cambio agraciado del motor de enrutamiento (GRES), se pierden las estadísticas ETH-DM recopiladas y los recuentos de tramas ETH-DM se restablecen a ceros. Por lo tanto, la recopilación de estadísticas ETH-DM y contadores de tramas ETH-DM debe reiniciarse después de que se complete la conmutación. GRES permite que un enrutador con motores de enrutamiento dual cambie de un motor de enrutamiento principal a un motor de enrutamiento de respaldo sin interrupción para el reenvío de paquetes. Para obtener más información, consulte la Guía del usuario de alta disponibilidad de Junos OS.
La precisión de las estadísticas de retraso de fotogramas se ve comprometida cuando el sistema está cambiando (por ejemplo, a partir de la reconfiguración). Recomendamos realizar mediciones de retraso de trama Ethernet en un sistema estable.
Descripción general de la medición de pérdida de trama Ethernet
Los objetivos clave de la funcionalidad de OAM son medir los atributos de calidad del servicio, como el retraso de trama, la variación del retraso de trama (también conocido como " fluctuación de tramas") y la pérdida de tramas. Estas mediciones le permiten identificar problemas de red antes de que los clientes se vean afectados por defectos de red.
Junos OS admite la medición de pérdida de trama ethernet (ETH-LM) entre los puntos finales de asociación de mantenimiento (MEP) configurados en interfaces físicas o lógicas de Ethernet en enrutadores de la serie MX, y actualmente solo se admite para el servicio VPWS . Los operadores utilizan ETH-LM para recopilar valores de contador aplicables para tramas de servicio de entrada y salida. Estos contadores mantienen un recuento de tramas de datos transmitidas y recibidas entre un par de eurodiputados. La medición de la pérdida de tramas de Ethernet se realiza mediante el envío de tramas con información de ETH-LM a un MEP par y de manera similar recibiendo tramas con información de ETH-LM del par MEP. Este tipo de medición de pérdida de trama también se conoce como medición de pérdida de Ethernet de un solo extremo.
El chasis virtual serie MX no admite la medición de pérdida de trama ethernet (ETH-LM).
ETH-LM admite las siguientes mediciones de pérdida de trama:
Medición de pérdida de trama del extremo cercano: medición de la pérdida de trama asociada con tramas de datos de entrada.
Medición de pérdida de trama del extremo final: medición de la pérdida de trama asociada con las tramas de datos de salida.
La funcionalidad de medición de pérdidas proactiva y de doble extremo del ITU-T Y1731 no se admite en los enrutadores de la serie ACX.
La función ETH-LM se admite en interfaces Ethernet agregadas.
A partir de la versión 16.1 de Junos OS, los resultados de la medición de pérdida de Ethernet (ETH-LM) son incorrectos cuando la administración de fallas de conectividad (CFM) y las PDU de supervisión del rendimiento (PM) se reciben localmente en un punto de conexión de mantenimiento (MEP) clasificado como perteneciente a la clase amarilla o una prioridad de pérdida de paquete (PLP) de medio-alto. Este problema de resultados incorrectos es específico de la medición de pérdidas de Ethernet para las sesiones de CFM de los eurodiputados caídos. Las estadísticas de medición de pérdidas de Ethernet son inexactas en los siguientes casos:
La medición de pérdida de Ethernet está trabajando en una sesión de CFM para un MEP en estado inactivo
Las PDU de CFM recibidas en la interfaz lógica del MEP descendente se clasifican por el clasificador como PLP amarillo o PLP medio-alto
Un paquete se identifica como amarillo cuando el clasificador de entrada marca el PLP como medio-alto.
El problema de las discrepancias con los resultados de la medición de pérdida de Ethernet no se observa cuando configura la medición de pérdida de Ethernet en modo sin color. Para evitar este problema de resultados incorrectos de la medición de pérdidas, aprovisione todas las PDU de CFM locales en verde o con el PLP como alto.
A partir de Junos OS versión 16.1, no se admite la supervisión del rendimiento para la administración de errores de conectividad (al incluir la performance-monitoring
instrucción y sus subestados en el [edit protocols oam ethernet connectivity-fault-management]
nivel jerárquico) cuando la interfaz de red a red (NNI) o de salida es una interfaz Ethernet agregada con vínculos de miembro en DPC.
Medición del acuerdo de nivel de servicio
La medición del acuerdo de nivel de servicio (SLA) es el proceso de monitoreo del ancho de banda, el retraso, la variación de retraso (fluctuación), la continuidad y la disponibilidad de un servicio (E-Line o E-LAN). Le permite identificar problemas de red antes de que los clientes se vean afectados por defectos de red.
Los servicios VPN Ethernet se pueden clasificar en:
Servicios par a par (servicios E-Line): los servicios de E-Line se ofrecen mediante el servicio de cable privado virtual (VPWS) de VPN de capa 2 basado en MPLS.
Servicios de multipunto a multipunto (servicios E-LAN): los servicios de E-LAN se ofrecen mediante el servicio de LAN privada virtual (VPLS) basado en MPLS.
Para obtener más información, consulte la Guía de configuración de VPN de Junos.
En Junos OS, las mediciones de SLA se clasifican en:
Modo a pedido: en el modo a pedido, las mediciones se activan a través de la CLI.
Modo proactivo: en el modo proactivo, las mediciones se activan mediante una aplicación iteradora.
Tenga en cuenta que la medición de retraso de trama de Ethernet y la medición de pérdida de trama de Ethernet no se admiten en la ae
interfaz.
Modo a pedido para la medición de SLA
En el modo bajo demanda, el usuario activa las mediciones a través de la CLI.
Cuando el usuario activa la medición de retraso a través de la CLI, la solicitud de medición de retraso que se genera es según los formatos de trama especificados por el estándar ITU-T Y.1731. Para la medición de retraso bidireccional, el procesamiento del lado del servidor se puede delegar en el motor de reenvío de paquetes para evitar la sobrecarga en el motor de enrutamiento. Para obtener más información, consulte Configuración de enrutadores para admitir una sesión ETH-DM. Cuando se delega el procesamiento del lado del servidor al motor de reenvío de paquetes, el comando no muestra los contadores de tramas receive
de mensaje de medición de retraso (DMM) y los contadores de tramas transmit
de respuesta de medición de show
retraso (DMR).
Cuando el usuario activa la medición de pérdidas a través de la CLI, el enrutador envía los paquetes en formato estándar junto con el TLV de medición de pérdidas. De forma predeterminada, el session-id-tlv
argumento se incluye en el paquete para permitir sesiones simultáneas de medición de pérdidas desde el mismo MEP local. También puede deshabilitar el ID de sesión TLV mediante el no-session-id-tlv
argumento.
ETH-LM de un solo extremo se utiliza para fines de operación, administración y mantenimiento a pedido. Un MEP envía tramas con información de solicitud DE ETH-LM a su par MEP y recibe tramas con información de respuesta de ETH-LM de su par MEP para llevar a cabo mediciones de pérdidas. La unidad de datos de protocolo (PDU) utilizada para una solicitud de ETH-LM de un solo extremo se conoce como un mensaje de medición de pérdida (LMM) y la PDU utilizada para una respuesta de ETH-LM de un solo extremo se denomina respuesta de medición de pérdidas (LMR).
Modo proactivo para la medición de SLA
En modo proactivo, las mediciones de SLA se activan mediante una aplicación iteradora. Un iterador está diseñado para transmitir periódicamente paquetes de medición de SLA en forma de tramas compatibles con ITU-Y.1731 para la medición de retraso bidireccional o la medición de pérdidas en enrutadores de la serie MX. Este modo difiere de la medición de SLA a pedido, que se inicia el usuario. El iterador envía paquetes de solicitud de medición de pérdida o retraso periódicos para cada una de las conexiones registradas en él. Los iteradores se aseguran de que los ciclos de medición no se produzcan al mismo tiempo para la misma conexión, a fin de evitar la sobrecarga de la CPU. Junos OS admite el modo proactivo para VPWS. Para que un iterador forme una adyacencia remota y se vuelva funcionalmente operativo, el mensaje de comprobación de continuidad (CCM) debe estar activo entre las configuraciones de MEP local y remota de la administración de errores de conectividad (CFM). Cualquier cambio en los parámetros de adyacencia del iterador restablece las estadísticas del iterador existentes y reinicia el iterador. En este caso, el término adyacencia se refiere a un emparejamiento de dos puntos de conexión (conectados directa o virtualmente) con información relevante para el entendimiento mutuo, que se utiliza para su posterior procesamiento. Por ejemplo, la adyacencia iteradora se refiere a la asociación iteradora entre los dos puntos de conexión de los diputados al Parlamento Europeo.
Por cada DPC o MPC, solo se admiten 30 instancias iteradoras para un valor de tiempo de ciclo de 10 milisegundos (ms). En Junos OS, se admiten 255 configuraciones de perfil de iterador y 2000 asociaciones mep remotas.
Los iteradores con un valor de tiempo de ciclo menor que 100 ms se admiten solo para iteradores infinitos, mientras que los iteradores con un valor de tiempo de ciclo mayor que 100 ms se admiten tanto para iteradores finitos como infinitos. Los iteradores infinitos son iteradores que se ejecutan infinitamente hasta que el iterador está deshabilitado o desactivado manualmente.
Los enrutadores ACX5048 y ACX5096 admiten tiempo de ciclo del iterador de solo 1 segundo o más.
Un servicio VPWS configurado en un enrutador se monitorea para las mediciones de SLA mediante el registro de la conexión (aquí, la conexión es un par de MEP remotos y locales) en un iterador y, luego, iniciando una transmisión periódica de trama de medición de SLA en esas conexiones. El servicio de extremo a extremo se identifica a través de un punto de final de asociación de mantenimiento (MEP) configurado en ambos extremos.
Para la medición de retraso bidireccional y la medición de pérdidas, un iterador envía un mensaje de solicitud para la conexión en la lista (si la hubiera) y, luego, envía un mensaje de solicitud para la conexión que se sondizó en el ciclo de iteración anterior. Los mensajes de solicitud de respaldo para las tramas de medición del SLA y sus respuestas ayudan a calcular la variación de retrasos y la medición de pérdidas.
La transmisión de tramas Y.1731 para un servicio conectado a un iterador continúa sin límites, a menos que un operador la intervenga y detenga, o hasta que se cumpla la condición de recuento de iteración. Para evitar que el iterador envíe marcos de medición de SLA más proactivos, el operador debe realizar una de las siguientes tareas:
Habilite la
deactivate sla-iterator-profile
instrucción en el[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance association ma-name mep mep-id remote-mep mep-id]
nivel de jerarquía.Aprovisione una
disable
instrucción en el perfil del iterador correspondiente en el[edit protocols oam ethernet connectivity-fault-management performance-monitoring sla-iterator-profiles profile-name]
nivel jerárquico.
Mediciones de retraso de Ethernet y medición de pérdidas por modo proactivo
En la medición de retraso bidireccional, la trama del mensaje de medición de retraso (DMM) se activa a través de una aplicación iteradora. La trama DMM lleva un tipo, longitud y valor (TLV) iterador además de los campos descritos en formato de trama estándar, y el servidor copia el TLV iterador del marco DMM al marco de respuesta de medición de retraso (DMR).
En el cálculo de la variación de retraso un solo sentido mediante el método de medición de retraso bidireccional, el cálculo de la variación de retraso se basa en las marcas de hora que están presentes en la trama DMR (y no en la trama 1DM). Por lo tanto, no es necesario que los relojes del lado del cliente y del servidor estén sincronizados. Suponiendo que la diferencia en sus relojes sigue siendo constante, se espera que los resultados de variación de retraso un solo sentido sean bastante precisos. Este método también elimina la necesidad de enviar tramas 1DM separadas solo para el propósito de medir la variación de retraso un solo sentido.
En modo proactivo para la medición de pérdidas, el enrutador envía paquetes en formato estándar junto con TLV de medición de pérdidas y TLV de iterador.
Descripción general del protocolo de notificación de fallas de Ethernet
El protocolo de notificación de fallas (FNP) es un mecanismo de notificación de fallas que detecta fallas en redes de transporte Ethernet punto a punto en enrutadores serie MX. Si se produce un error en un vínculo de nodo, la FNP la detecta y envía mensajes FNP a los nodos adyacentes en que un circuito está inactivo. Al recibir el mensaje FNP, los nodos pueden redirigir el tráfico al circuito de protección.
El FNP solo se admite en los servicios de E-Line.
Un servicio de E-Line proporciona una conectividad Ethernet de punto a punto segura entre dos interfaces de red de usuario (UNIs). Los servicios de E-Line son un servicio protegido y cada servicio tiene un circuito operativo y un circuito de protección. La CFM se utiliza para supervisar el funcionamiento y proteger rutas. Los intervalos de CCM dan como resultado un tiempo de conmutación por error en cientos de milisegundos o unos pocos segundos. FNP ofrece detección y propagación de fallas en el circuito de servicio en menos de 50 ms y proporciona una conmutación por error de 50ms para los servicios de E-Line.
El enrutador MX actúa como un nodo de PE y controla los mensajes FNP recibidos en la VLAN de administración y los mensajes FNP recibidos en las interfaces ethernet y los PW creados para el VPLS de administración. Los enrutadores serie MX no inician mensajes FNP y solo responden a los mensajes FNP generados por los dispositivos en la red Ethernet Access. FNP solo se puede habilitar en interfaces lógicas que formen parte de una instancia de enrutamiento VPLS, y ninguna interfaz física en esa instancia de enrutamiento VPLS debe tener CCM configurado. FNP solo se puede habilitar en una interfaz lógica por interfaz física.
Todos los servicios de E-Line están configurados como circuitos de capa 2 con protección de borde. Una VLAN asociada con el circuito de trabajo o circuito de protección debe asignarse a una interfaz lógica. No se admite ningún puerto de troncalización ni de acceso en el vínculo de anillo para las VLAN utilizadas por los servicios E-LINE. FNP no controla la interfaz lógica asociada con el circuito de protección. Solo el servicio de E-Line cuyo punto de terminación no está en un nodo MX está controlado por FNP.
FNP admite el reinicio agraciado y las funciones de conmutación del motor de enrutamiento (GRES) graceful.
Consulte también
Descripción general de la medición de pérdidas sintéticas de Ethernet
La medición de pérdidas sintéticas de Ethernet (ETH-SLM) es una aplicación que permite calcular la pérdida de tramas mediante el uso de tramas sintéticas en lugar de tráfico de datos. Este mecanismo puede considerarse como una muestra estadística para aproximar el ratio de pérdida de tramas del tráfico de datos. Cada punto de final de asociación de mantenimiento (MEP) realiza mediciones de pérdida de trama, lo que contribuye al tiempo no disponible.
Una pérdida de trama del extremo cercano especifica la pérdida de trama asociada con tramas de datos de entrada, y una pérdida de trama del extremo final especifica la pérdida de trama asociada con tramas de datos de salida. Las mediciones de pérdida de fotogramas tanto del extremo cercano como del extremo final final contribuyen a segundos con errores graves y a segundos con errores graves del extremo final que se utilizan en combinación para determinar el tiempo no disponible. ETH-SLM se realiza mediante tramas de mensaje de pérdida sintética (SLM) y respuesta de pérdida sintética (SLR). ETH-SLM facilita que cada MEP realice mediciones de pérdida de trama sintéticas del extremo cercano y del extremo final mediante el uso de tramas sintéticas, ya que un servicio bidireccional se define como no disponible si se determina que cualquiera de las dos direcciones no está disponible.
Existen dos tipos de medición de pérdida de trama, definidos por las normas ITU-T Y.1731, ETH-LM y ETH-SLM. Junos OS solo admite ETH-SLM de un extremo. En el ETH-SLM de un solo extremo, cada MEP envía tramas con la información de solicitud de ETH-SLM a su par MEP y recibe tramas con la información de respuesta de ETH-SLM de su par MEP para realizar mediciones sintéticas de pérdida. Eth-SLM de un solo extremo se utiliza para una OAM proactiva o a pedido para realizar mediciones de pérdida sintéticas aplicables a la conexión Ethernet de punto a punto. Este método permite que un eurodiputado inicie y reporte mediciones de pérdida del extremo final y del extremo cercano asociadas con un par de eurodiputados que forman parte del mismo grupo de entidades de mantenimiento (MEG).
El chasis virtual de la serie MX no admite la medición de pérdidas sintéticas de Ethernet (ETH-SLM).
ETH-SLM de un solo extremo se utiliza para realizar pruebas a pedido o proactivas mediante la iniciación de una cantidad finita de tramas ETH-SLM a uno o varios pares MEP y recibir la respuesta de ETH-SLM de los pares. Las tramas ETH-SLM contienen la información ETH-SLM que se utiliza para medir e informar mediciones de pérdida sintética tanto del extremo cercano como del extremo final. La medición del acuerdo de nivel de servicio (SLA) es el proceso de monitoreo del ancho de banda, el retraso, la variación de retraso (fluctuación), la continuidad y la disponibilidad de un servicio. Le permite identificar problemas de red antes de que los clientes se vean afectados por defectos de red. En modo proactivo, las mediciones de SLA se activan mediante una aplicación iteradora. Un iterador está diseñado para transmitir periódicamente paquetes de medición de SLA en forma de tramas que cumplen con itu-Y.1731 para medir la pérdida de tramas sintéticas. Este modo difiere de la medición de SLA a pedido, que se inicia el usuario. En el modo bajo demanda, el usuario activa las mediciones a través de la CLI. Cuando el usuario activa el ETH-SLM a través de la CLI, la solicitud de SLM que se genera es según los formatos de trama especificados por el estándar ITU-T Y.1731.
Los enrutadores ACX5048 y ACX5096 admiten ETH-SLM para servicios de capa 2.
Escenarios para la configuración de ETH-SLM
ETH-SLM mide la pérdida de fotogramas del extremo cercano y del extremo final entre dos eurodiputados que forman parte del mismo nivel de MEG. Puede configurar ETH-SLM para medir la pérdida sintética tanto para MEP ascendente o ascendente como para MEP descendente o descendente. En esta sección se describen los siguientes escenarios para la operación de ETH-SLM:
MEP ascendente en túneles MPLS
Considere una situación en la que un MEP está configurado entre las interfaces de red de usuario (UNIs) de dos enrutadores serie MX, MX1 y MX2, en la dirección ascendente. MX1 y MX2 están conectados a través de una red central MPLS. Las mediciones de ETH-SLM se realizan entre el MEP ascendente en la ruta que une los dos enrutadores. Tanto MX1 como MX2 pueden iniciar ETH-SLM a pedido o proactivo, que puede medir las pérdidas tanto del extremo como del extremo cercano en MX1 y MX2, respectivamente. Las dos UNIs se conectan mediante el servicio de cable privado virtual (VPWS) de VPN de capa 2 basado en MPLS.
MEP descendente en redes Ethernet
Considere una situación en la que un MEP está configurado entre dos enrutadores de la serie MX, MX1 y MX2, en las interfaces Ethernet en la dirección descendente. MX1 y MX2 se conectan en una topología Ethernet y meP descendente se configura hacia la red Ethernet. Las mediciones de ETH-SLM se realizan entre el MEP descendente en la ruta que une a los dos enrutadores. ETH-SLM se puede medir en la ruta entre estos dos enrutadores.
Considere otro escenario en el que un MEP está configurado en la dirección descendente y la protección de servicio para un VPWS a través de MPLS se habilita especificando una ruta de trabajo o una ruta de protección en el MEP. La protección del servicio proporciona protección de conexión de extremo a extremo de la ruta de trabajo en caso de que se produzca un error. Para configurar la protección de servicio, debe crear dos rutas de transporte independientes: una ruta de trabajo y una ruta de protección. Puede especificar la ruta de trabajo y protegerla mediante la creación de dos asociaciones de mantenimiento. Para asociar la asociación de mantenimiento con una ruta, debe configurar la interfaz MEP en la asociación de mantenimiento y especificar la ruta como funciona o protege.
En una topología de ejemplo, un enrutador de la serie MX, MX1, se conecta a otros dos enrutadores serie MX, MX2 y MX3, mediante un núcleo MPLS. La sesión de administración de errores de conectividad (CFM) entre MX1 y MX2 es la ruta de trabajo en el MEP y la sesión de CFM entre MX1 y MX3 es la ruta de protección en el MEP. Mx2 y MX3 están, a su vez, conectados en interfaces Ethernet a MX4 en la red de acceso. MeP descendente está configurado entre MX1 y MX4 que pasa por MX2 (sesión CFM en funcionamiento) y también entre MX1 y MX4 que pasa por MX3 (sesión cfm protegida). ETH-SLM se realiza entre estos meP descendentes. En ambos MEP descendentes, la configuración se realiza en UNIs MX1 y MX4, similar a la MEP ascendente.
Formato de los mensajes ETH-SLM
Los mensajes de pérdida sintética (SLA) admiten solicitudes de medición de pérdidas sintéticas (ETH-SLM) de Ethernet de un extremo único. Este tema contiene las siguientes secciones en las que se describen los formatos de las unidades de datos de protocolo (PDU) de SLM, las PDU de la SLM y el valor de longitud (TLV) del iterador de datos.
Formato SLM PDU
El formato PDU de SLM es utilizado por un MEP para transmitir información de SLM. Los siguientes componentes están contenidos en las PDU de SLM:
ID MEP fuente: el ID mep de origen es un campo de 2 octetos en el que se utilizan los últimos 13 bits menos significativos para identificar al MEP que transmite la trama SLM. El ID de MEP es único dentro del MEG.
ID de prueba: el ID de prueba es un campo de 4 octetos establecido por el MEP transmisor y se utiliza para identificar una prueba cuando se ejecutan varias pruebas simultáneamente entre los eurodiputados (incluidas las pruebas simultáneas a pedido y proactivas).
TxFCf— TxFCf es un campo de 4 octetos que transporta la cantidad de tramas SLM transmitidas por el MEP hacia su par MEP.
Los siguientes son los campos en una PDU de SLM:
Nivel MEG: nivel de dominio de mantenimiento configurado en el intervalo 0-7.
Versión— 0.
OpCode (OpCode): permite identificar un tipo de PDU de OAM. Para SLM, es 55.
Indicadores (Flags): se establece en todos los ceros.
TLV offset: 16.
ID mep de origen: campo de 2 octetos que se utiliza para identificar al MEP que transmite la trama SLM. En este campo de 2 octetos, se utilizan los últimos 13 bits menos significativos para identificar al MEP que transmite la trama SLM. El ID de MEP es único dentro del MEG.
RESV: los campos reservados se establecen en todos los ceros.
ID de prueba: campo de 4 octetos establecido por el mep que transmite y que se utiliza para identificar una prueba cuando se ejecutan varias pruebas simultáneamente entre los eurodiputados (incluidas las pruebas simultáneas a pedido y proactivas).
TxFCf: un campo de 4 octetos que transporta el número de tramas SLM transmitidas por el MEP hacia su par MEP.
TLV opcional: se puede incluir una TLV de datos en cualquier SLM transmitida. Para el propósito de ETH-SLM, la parte de valor de los datos TLV no está especificada.
TLV final: valor de octeto de ceros todos.
Formato SLR PDU
El formato PDU de respuesta de pérdida sintética (SLR) es utilizado por un MEP para transmitir información DE SLR. Los siguientes son los campos de una PDU SLR:
Nivel MEG: campo de 3 bits cuyo valor se copia desde la última PDU de SLM recibida.
Versión: un campo de 5 bits cuyo valor se copia desde la última PDU de SLM recibida.
OpCode (OpCode): permite identificar un tipo de PDU de OAM. Para SLR, se establece como 54.
Indicadores: un campo de 1 octeto copiado de la PDU de SLM.
TLV offset: campo de 1 octeto copiado desde la PDU de SLM.
ID MEP fuente: un campo de 2 octetos copiado de la PDU de SLM.
ID de MEP de respuesta: campo de 2 octetos que se utiliza para identificar al MEP que transmite la trama SLR.
ID de prueba: un campo de 4 octetos copiado de la PDU de SLM.
TxFCf: un campo de 4 octetos copiado de la PDU de SLM.
TxFCb: un campo de 4 octetos. Este valor representa el número de tramas SLR transmitidas para este ID de prueba.
TLV opcional: el valor se copia desde la PDU de SLM, si está presente.
TLV final: un campo de 1 octeto copiado de la PDU de SLM.
Formato de TLV iterador de datos
El iterador de datos TLV especifica la parte TLV datos del marco de datos Y.1731. El MEP usa un TLV de datos cuando el MEP está configurado para medir el retraso y la variación de retraso para diferentes tamaños de trama. Los siguientes son los campos de una TLV de datos:
Tipo (Type): permite identificar el tipo de TLV; valor para este tipo de TLV es Datos (3).
Longitud (Length): permite identificar el tamaño, en octetos, del campo Valor que contiene el patrón de datos. El valor máximo del campo Longitud es 1440.
Patrón de datos: patrón nde bits arbitrario -octeto (n que indica longitud). El receptor lo ignora.
Transmisión de mensajes ETH-SLM
La funcionalidad ETH-SLM puede procesar varias solicitudes de mensajes de pérdida sintéticos (SLM) simultáneamente entre un par de eurodiputados. La sesión puede ser proactiva o a pedido de SLM. Cada solicitud de SLM se identifica de manera única mediante un ID de prueba.
Un MEP puede enviar solicitudes de SLM o responder a solicitudes de SLM. Una respuesta a una solicitud de SLM se denomina respuesta de pérdida sintética (SLR). Después de que un MEP determina una solicitud de SLM mediante el ID de prueba, el MEP calcula la pérdida de trama del extremo y del extremo cercano sobre la base de la información del mensaje de SLM o la unidad de datos de protocolo (PDU) de SLM.
Un MEP mantiene los siguientes contadores locales para cada ID de prueba y para cada MEP par que se está monitoreando en una entidad de mantenimiento para la cual se deben realizar mediciones de pérdidas:
TxFCl: número de tramas sintéticas transmitidas al par MEP para un ID de prueba. Un MEP de origen incrementa este número para la transmisión sucesiva de tramas sintéticas con información de solicitud ETH-SLM, mientras que un MEP de destino o receptora incrementa este valor para la transmisión sucesiva de tramas sintéticas con la información de SLR.
RxFCl: número de tramas sintéticas recibidas del par MEP para un ID de prueba. Un MEP fuente incrementa este número para la recepción sucesiva de tramas sintéticas con información RÉL, mientras que un MEP de destino o receptor lo incrementa para la recepción sucesiva de tramas sintéticas con información de solicitud ETH-SLM.
En las siguientes secciones se describen las fases de procesamiento de las PDU de SLM para determinar la pérdida sintética de tramas:
- Iniciación y transmisión de solicitudes de SLM
- Recepción de SLA y transmisión de SLAR
- Recepción de SLE
- Cálculo de la pérdida de tramas
Iniciación y transmisión de solicitudes de SLM
Un MEP transmite periódicamente una solicitud de SLM con el campo OpCode establecido como 55. El MEP genera un ID de prueba único para la sesión, agrega el ID mep de origen e inicializa los contadores locales para la sesión antes de iniciar la SLM. Para cada PDU SLM transmitido para la sesión (ID de prueba), el txFCl del contador local se envía en el paquete.
No se requiere sincronización del valor del ID de prueba entre los MEP iniciados y los que responden, ya que el ID de prueba está configurado en el MEP iniciador y el MEP que responde usa el ID de prueba que recibe del MEP iniciador. Dado que ETH-SLM es una técnica de toma de muestras, es menos precisa que contar las tramas de servicio. Además, la precisión de la medición depende del número de tramas de SLM utilizadas o del período para transmitir tramas de SLM.
Recepción de SLA y transmisión de SLAR
Después de que el MEP de destino recibe una trama SLM válida del MEP de origen, se genera una trama SLR y se transmite al MEP solicitante o de origen. La trama SLR es válida si el nivel MEG y la dirección MAC de destino coinciden con la dirección MAC del MEP receptor. Todos los campos de las PDU de SLM se copian de la solicitud de SLM, excepto para los siguientes campos:
La dirección MAC de origen se copia en la dirección MAC de destino y la dirección de origen contiene la dirección MAC del MEP.
El valor del campo OpCode se cambia de SLM a SLR (54).
El ID mep de respuesta se rellena con el ID mep del mep.
TxFCb se guarda con el valor del contador local RxFCl en el momento de la transmisión de trama SLR.
Se genera una trama SLR cada vez que se recibe una trama SLM; por lo tanto, RxFCl en el respondedor es igual al número de tramas SLM recibidas y también es igual al número de tramas SLR enviadas. En el mep que responde o recibe, RxFCl es igual a TxFCl.
Recepción de SLE
Después de transmitir una trama SLM (con un valor TxFCf dado), un MEP espera recibir una trama SLR correspondiente (que lleve el mismo valor TxTCf) dentro del valor de tiempo de espera de su par MEP. Las tramas SLR que se reciben después de descartar el valor de tiempo de espera (5 segundos). Con la información contenida en tramas SLR, un MEP determina la pérdida de trama para el período de medición especificado. El período de medición es un intervalo de tiempo durante el cual el número de tramas SLM transmitidas es estadísticamente adecuado para realizar una medición con una precisión dada. Un MEP usa los siguientes valores para determinar la pérdida de tramas del extremo cercano y del extremo final durante el período de medición:
Última vez recibidos los valores TxFCf y TxFCb de la trama SLR y el valor rxFCl del contador local al final del período de medición. Estos valores se representan como TxFCf[tc], TxFCb[tc], y RxFCl[tc], donde tc es el tiempo final del período de medición.
Los valores TxFCf y TxFCb de la primera trama SLR recibida después de que se inicia la prueba y el contador local RxFCl al principio del período de medición. Estos valores se representan como TxFCf[tp], TxFCb[tp], y RxFCl[tp], donde tp es la hora de inicio del período de medición.
Para cada paquete SLR que se recibe, el contador RxFCl local se incrementa en el MEP de envío o de origen.
Cálculo de la pérdida de tramas
La pérdida de trama sintética se calcula al final del período de medición sobre la base del valor de los contadores locales y la información de la última trama recibida. Las últimas tramas recibidas contienen los valores TxFCf y TxFCb. El contador local contiene el valor RxFCl. Con estos valores, la pérdida de trama se determina mediante la siguiente fórmula:
Pérdida de tramas (extremo final) = TxFCf – TxFCb
Pérdida de trama (extremo cercano) = TxFCb – RxFCl
performance-monitoring
instrucción y sus subestados en el [edit protocols oam ethernet connectivity-fault-management]
nivel jerárquico) cuando la interfaz de red a red (NNI) o de salida es una interfaz Ethernet agregada con vínculos de miembro en DPC.