EN ESTA PÁGINA
Descripción general de la medición de pérdida y retraso de paquetes bajo demanda para LSP UHP
Ejemplo: Configuración de la medición de pérdida y retardo bajo demanda
Ejemplo: Configuración de mediciones proactivas de pérdida y retardo para LSP MPLS bidireccionales
Configuración de la medición de pérdida y retardo bajo demanda
Configuración de mediciones proactivas de pérdidas y retardos
Recopilar estadísticas sobre las sesiones de MPLS
Configuración de MPLS para recopilar estadísticas
Puede configurar MPLS para que recopile periódicamente estadísticas de tráfico sobre todas las sesiones de MPLS, incluidas las sesiones de tránsito, mediante la configuración de la instrucción.statistics Debe configurar la instrucción si desea recopilar estadísticas de tráfico de MPLS mediante el sondeo SNMP de las bases de información de administración (MIB) de MPLS.statistics
Para habilitar o deshabilitar la recopilación de estadísticas MPLS, incluya la instrucción:statistics
statistics { auto-bandwidth (MPLS Statistics); file filename <files number> <size size> <world-readable | no-world-readable>; interval seconds; no-transit-statistics; transit-statistics-polling; }
Puede configurar estas instrucciones en los siguientes niveles jerárquicos:
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
El intervalo predeterminado es de 300 segundos.
Si configura la opción, las estadísticas se colocan en un archivo, con una entrada por LSP.file Durante el intervalo especificado, se registra la siguiente información en este archivo:
El número de paquetes, el número de bytes, los paquetes por segundo y los bytes por segundo transmitidos por cada LSP. La paridad de características para la visualización de estadísticas de paquetes y bytes para sub-LSP de un LSP de punto a multipunto en el chipset Junos Trio se admite en las versiones 11.1R2, 11.2R2 y 11.4 de Junos OS.
Porcentaje de ancho de banda transmitido a través de un LSP determinado en relación con el porcentaje de ancho de banda configurado para ese LSP. Si no se configura ningún ancho de banda para un LSP, se registra el 0 por ciento en la columna de porcentaje.
Al final de cada informe periódico, un resumen muestra la hora actual, el número total de sesiones, el número de sesiones leídas, el número de sesiones ignoradas y los errores de lectura, si los hubiere. Las sesiones ignoradas suelen ser aquellas que no están en el estado activo o aquellas con una etiqueta entrante reservada (de 0 a 15) (normalmente el punto de salida de un LSP). El motivo de un error de lectura aparece en la misma línea que la entrada del LSP en la que se produjo el error. La recopilación de estadísticas es un proceso poco fiable; Los errores de lectura ocasionales pueden afectar su precisión. A continuación se muestra el resultado de ejemplo:
lsp6 0 pkt 0 Byte 0 pps 0 Bps 0 lsp5 0 pkt 0 Byte 0 pps 0 Bps 0 lsp6.1 34845 pkt 2926980 Byte 1049 pps 88179 Bps 132 lsp5.1 0 pkt 0 Byte 0 pps 0 Bps 0 lsp4 0 pkt 0 Byte 0 pps 0 Bps 0 Dec 7 17:28:38 Total 6 sessions: 5 success, 0 fail, 1 ignored
Descripción general de la medición de pérdida y retraso de paquetes bajo demanda para LSP UHP
En este tema se describen métodos para medir la pérdida de paquetes, el retraso y el rendimiento de rutas de conmutación de etiquetas (LSP) punto a punto en redes MPLS para permitir la supervisión del rendimiento de la red.
- Importancia de medir la pérdida y el retraso de paquetes
- Definición de pérdida, retraso y rendimiento de paquetes
- Mecanismos de medición de pérdida y retraso de paquetes
- Métricas de pérdida y retraso de paquetes
- Conceptos de medición de pérdida y retraso de paquetes
- Funcionalidad de medición de pérdida y retraso de paquetes
- Características de pérdida y retraso de paquetes
Importancia de medir la pérdida y el retraso de paquetes
El aumento de las aplicaciones que consumen ancho de banda, como la IPTV y el vídeo móvil, junto con la presión para minimizar el costo por bit y maximizar el valor por bit, está obligando a los operadores a hacer la transición de sus redes de transporte de tecnologías basadas en circuitos a tecnologías basadas en paquetes. MPLS es una tecnología de transporte de paquetes ampliamente exitosa y orientada a la conexión que es ideal para redes de transporte basadas en paquetes.
Con la aparición de nuevas aplicaciones en las redes de datos, cada vez es más importante que los proveedores de servicios predigan con precisión el impacto de los lanzamientos de nuevas aplicaciones. Comprender y modelar el rendimiento de la red en la red es especialmente relevante para el despliegue de aplicaciones del nuevo mundo para garantizar implementaciones exitosas. En las redes de paquetes, la pérdida y el retraso de paquetes son dos de las medidas más fundamentales del rendimiento. Su papel es aún más central cuando se trata de mediciones de extremo a extremo.
El tráfico que pertenece a la mayoría de las aplicaciones de usuario de extremo a extremo es sensible a las pérdidas (transferencia de archivos), sensible al retraso (aplicaciones de voz o video) o ambas (aplicaciones informáticas interactivas). Los acuerdos de nivel de servicio (SLA) de los proveedores de servicios dependen de la capacidad de medir y monitorear estas métricas de rendimiento de red, ya que los SLA dependen directa o indirectamente de la pérdida y el retraso que experimenta el tráfico del cliente en la red del proveedor de servicios.
Para garantizar el cumplimiento del SLA, los proveedores de servicios necesitan herramientas para medir y monitorear las métricas de rendimiento de pérdida de paquetes, retraso unidireccional y bidireccional, y métricas relacionadas, como la variación del retraso y el rendimiento del canal. Esta capacidad de medición proporciona a los proveedores de servicios una mayor visibilidad de las características de rendimiento de sus redes, facilitando así la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Definición de pérdida, retraso y rendimiento de paquetes
En las redes de paquetes, la pérdida y el retraso de paquetes son dos de las medidas más fundamentales del rendimiento.
Loss—La pérdida de paquetes es el fallo de uno o más paquetes transmitidos para llegar a su destino. La pérdida de paquetes se refiere a los paquetes de datos que la red deja caer para administrar la congestión.
Las aplicaciones de datos son muy tolerantes a la pérdida de paquetes, ya que generalmente no son sensibles al tiempo y pueden retransmitir los paquetes que se cayeron. Sin embargo, en entornos de videoconferencia y comunicaciones de audio puro, como VoIP, la pérdida de paquetes puede crear fluctuación.
Delay—El retraso de paquetes (también llamado latencia) es la cantidad de tiempo que tarda un paquete de datos en llegar de un punto designado a otro, dependiendo de la velocidad del medio de transmisión, como cable de cobre, fibra óptica u ondas de radio, y los retrasos en la transmisión por dispositivos a lo largo del camino, como enrutadores y módems.
Una latencia baja indica una alta eficiencia de red.
Throughput—El retraso de paquetes mide la cantidad de tiempo entre el inicio de una acción y su finalización, mientras que el rendimiento es el número total de acciones de este tipo que se producen en un período de tiempo determinado.
Mecanismos de medición de pérdida y retraso de paquetes
El retraso y la pérdida de paquetes son dos medidas fundamentales del rendimiento de la red. Junos OS proporciona un mecanismo a pedido para medir la pérdida y el retraso de paquetes en las rutas de conmutación de etiquetas (LSP) de MPLS ultimate hop popping (UHP) bidireccionales asociadas.
El mecanismo de medición de demora y pérdida de paquetes bajo demanda se inicia mediante los siguientes comandos de CLI:
monitor mpls loss rsvp—Realiza una medición de pérdidas bajo demanda para los LSP UHP bidireccionales asociados.monitor mpls delay rsvp—Realiza una medición de retardo bajo demanda para los LSP UHP bidireccionales asociados.monitor mpls loss-delay rsvp—Realiza una medición combinada de pérdidas y retardos bajo demanda para los LSP UHP bidireccionales asociados.
Para iniciar el mecanismo de medición de retraso y pérdida de paquetes, es necesario introducir los parámetros deseados para la medición, como el tipo de medición y el nombre del LSP. Al recibir los parámetros, se muestra un resumen de los datos de supervisión del rendimiento y se finaliza el mecanismo.
Métricas de pérdida y retraso de paquetes
Las siguientes métricas de rendimiento se miden mediante los mecanismos de pérdida y retraso de paquetes bajo demanda:
Medición de pérdidas (paquete y octeto)
Medición de transferencia de datos (paquete y octeto)
Retardo de canal bidireccional
Retraso de ida y vuelta
Variación de retardo entre paquetes (IPDV)
El comando realiza la medición de pérdida y rendimiento, y el comando realiza las mediciones de retardo de canal bidireccional, retardo de ida y vuelta e IPDV.monitor mpls loss rsvpmonitor mpls delay rsvp El comando realiza una medición combinada de pérdida y retraso y mide todas las métricas de rendimiento mencionadas anteriormente simultáneamente.monitor mpls loss-delay rsvp
Conceptos de medición de pérdida y retraso de paquetes
Los siguientes conceptos ayudan a comprender mejor la funcionalidad de la pérdida y el retraso de paquetes:
Querier: una consulta es el enrutador perimetral del proveedor de entrada (PE), que origina el mensaje de consulta para la medición de pérdida o retraso.
Responder: un respondedor es el enrutador de PE de salida, que recibe y responde a los mensajes de consulta de una consulta.
Associated bidirectional LSP—Un LSP bidireccional asociado consta de dos LSP unidireccionales que están unidos (o asociados entre sí) a través de la configuración en ambos puntos finales del LSP.
La medición de pérdidas y retardos bajo demanda solo se puede llevar a cabo en los LSP UHP bidireccionales asociados.
Generic associated channel (G-Ach): los mensajes de supervisión del rendimiento para el flujo de medición de pérdida y retardo bajo demanda a través del G-Ach de MPLS. Este tipo de canal solo admite respuestas dentro de banda y no proporciona compatibilidad con los modos fuera de banda o sin respuesta.
Measurement point (MP)—MP es el lugar en el que se describe una condición para la medición.
El MP para la pérdida de paquetes en el lado de transmisión se encuentra entre la estructura de conmutación y la interfaz de transmisión. El valor del contador se marca en el mensaje de medición de pérdidas del hardware antes de que se ponga en cola para la transmisión.
El Panel de administración para la pérdida de paquetes en el lado de recepción se encuentra entre la interfaz de recepción y la estructura de conmutación. El Panel de administración se distribuye en el lado de recepción. Además, cuando la interfaz de transmisión es una interfaz agregada, el Panel de administración también se distribuye.
Query rate: la tasa de consultas es el intervalo entre dos consultas enviadas para la medición de pérdidas y retrasos.
Dado que los mensajes de medición de pérdida y retraso se originan en el motor de enrutamiento, una alta tasa de consultas para varios canales supone una pesada carga para el motor de enrutamiento. El intervalo mínimo de consulta admitido es de 1 segundo.
La velocidad de consulta debe ser alta para los contadores de 32 bits, ya que los contadores pueden ajustarse rápidamente cuando la tasa de tráfico de datos es muy alta. La tasa de consultas puede ser baja cuando se utilizan contadores de 64 bits en las cuatro ubicaciones de puntos de medición involucradas en la medición de pérdidas. Junos OS solo admite contadores de 64 bits.
Traffic class—De forma predeterminada, la medición de pérdidas se admite para todo el canal. Junos OS también admite la medición de pérdida de paquetes con ámbito de clase de tráfico, donde se deben crear contadores que mantengan estadísticas de tráfico de datos por clase de tráfico.
Los contadores por clase de tráfico no se crean de forma predeterminada. Para configurar la medición de pérdidas por ámbito de clase de tráfico, incluya la instrucción en el nivel de jerarquía.
traffic-class-statistics[edit protocols mpls statistics]Cuando está configurado, los paquetes de control que fluyen a través del G-Ach no se cuentan en los contadores de transmisión y recepción.
traffic-class-statisticsNota:La habilitación y deshabilitación de las estadísticas de clase de tráfico da como resultado el restablecimiento de todos los contadores (contadores agregados y por clase) para los LSP.
Loss measurement mode: Junos OS admite el modo directo de medición de pérdidas bajo demanda y no proporciona soporte para el modo inferido.
La medición de pérdidas directas requiere que se mantengan estadísticas de tráfico de datos en la entrada y salida de dos LSP unidireccionales del LSP bidireccional asociado. Cuando un enrutador de la serie MX utiliza solo MPC y MIC, los contadores para mantener las estadísticas de tráfico de datos se crean de forma predeterminada en la entrada de todos los tipos de LSP y en la salida de LSP UHP.
Sin embargo, el modo directo de medición de pérdidas no es completamente preciso debido a las siguientes razones:
Naturaleza de reenvío paralelo del hardware.
Presencia de múltiples rutas de igual costo (ECMP) en la red, como interfaces Ethernet agregadas, lo que puede dar lugar a un reordenamiento de los paquetes de datos en relación con los mensajes de medición de pérdidas.
Los paquetes de control que no fluyen a través de G-Ach no se cuentan en la entrada de LSP, pero se cuentan en la salida de LSP.
Reordenación del tráfico de datos en relación con el mensaje de medición de pérdida cuando se implementa un Diffserv en la red MPLS y el alcance de medición de pérdidas es el canal completo y no el ámbito de la clase de tráfico.
Para superar esta limitación, realice una medición de pérdidas por ámbito de clase de tráfico cuando se implemente un Diffserv.
Nota:La medición de pérdida en modo directo es vulnerable a interrupciones cuando cambia la interfaz de entrada o salida asociada con el LSP.
Loss measurement synchronization—Las condiciones de sincronización especificadas en la sección 2.9.8 de RFC 6374 no son válidas en sentido absoluto. Sin embargo, como los contadores de medición de pérdidas están estampados en el hardware, los errores introducidos debido a que no satisfacen las condiciones de sincronización son relativamente pequeños. Estos errores deben cuantificarse.
Cuando la interfaz de transmisión o recepción del LSP es una interfaz agregada, se introducen más errores en comparación con cuando las interfaces son interfaces no agregadas. En cualquier caso, los contadores de medición de pérdidas están estampados en el hardware y el error debe cuantificarse.
Delay measurement accuracy—Cuando las interfaces de transmisión y recepción residen en motores de reenvío de paquetes diferentes, el reloj debe estar sincronizado en estos motores de reenvío de paquetes para mediciones de retardo bidireccional. Esta condición es válida para la plataforma en la que se implementa la función de medición de retardo bajo demanda.
Cuando hay interfaces agregadas o ECMP, el retraso se mide solo para una de las rutas potenciales.
Cuando se utiliza un mensaje combinado de pérdida y retraso para el cálculo del retraso, la precisión del retraso es menor en comparación con cuando se utiliza el mensaje de medición de retraso en algunos casos, como cuando la interfaz de transmisión o recepción es una interfaz agregada.
La medición del retardo siempre se realiza por clase de tráfico, y la precisión de la medición debe cuantificarse después de la prueba.
Timestamp format—Junos OS solo admite el formato IEEE 1588 Precision Time Protocol (PTP) [IEEE1588] para grabar mensajes de medición de retardo. No se admite el formato de hora de red (NTP).
: para indicar que todos los mensajes OAM para los LSP MPLS fluyen por el G-Ach de MPLS y para permitir que los mensajes de supervisión del rendimiento de MPLS se transfieran a través del G-Ach de MPLS, la instrucción debe incluirse en el nivel de jerarquía.Operations, administration, and maintenance (OAM)
oam mpls-tp-mode[edit protocols mpls label-switched-path lsp-name]
Funcionalidad de medición de pérdida y retraso de paquetes
Figura 1 Ilustra los métodos básicos utilizados para la medición bidireccional de la pérdida y el retraso de paquetes. Existe un canal bidireccional entre los dos enrutadores, el enrutador A y el enrutador B. Los puntos de referencia temporales (T1, T2, T3 y T4) están asociados a una operación de medición que tiene lugar en el enrutador A. La operación consiste en que el enrutador A envía un mensaje de consulta al enrutador B y el enrutador B devuelve una respuesta. Cada punto de referencia indica el momento en el que la consulta o el mensaje de respuesta se transmite o recibe a través del canal.
En , el enrutador A puede hacer arreglos para medir la pérdida de paquetes a través del canal en las direcciones directa e inversa enviando mensajes de consulta de medición de pérdida al enrutador B. Cada uno de los mensajes de reenvío e inversión contiene el recuento de paquetes transmitidos antes del tiempo T1 a través del canal al enrutador B (A_TxP).Figura 1
Cuando el mensaje llega al enrutador B, se anexan dos valores al mensaje y el mensaje se refleja de nuevo en el enrutador A. Los dos valores son el recuento de paquetes recibidos antes de la hora T2 a través del canal desde el enrutador A (B_RxP) y el recuento de paquetes transmitidos antes del tiempo T3 a través del canal al enrutador A (B_TxP).
Cuando la respuesta llega al enrutador A, se anexa un cuarto valor al mensaje: el recuento de paquetes recibidos antes del tiempo T4 a través del canal desde el enrutador B (A_RxP).
Estos cuatro valores de contador ((A_TxP), (B_RxP), (B_TxP) y (A_RxP) permiten al enrutador A calcular las estadísticas de pérdida deseadas. Dado que es posible que el recuento de transmisiones en el enrutador A y el recuento de recepción en el enrutador B (y viceversa) no se sincronicen en el momento del primer mensaje, y para limitar los efectos del ajuste de contador, la pérdida se calcula en forma de delta entre los mensajes.
El enrutador A calcula la pérdida de transmisión (A_TxLoss[n-1,n]) y la pérdida de recepción (A_RxLoss[n-1,n]) dentro del intervalo de medición marcado por los mensajes LM[n-1] y LM[n] de la siguiente manera:
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
La aritmética es módulo del tamaño del contador.
Para medir en el enrutador A el retraso a través del canal al enrutador B, se envía un mensaje de consulta de medición de retraso desde el enrutador A al enrutador B que contiene una marca de tiempo que registra el instante en que se transmite. En , la marca de tiempo se registra en T1.Figura 1
Cuando el mensaje llega al enrutador B, se agrega una marca de tiempo, registrando el instante en que se recibe (T2). El mensaje ahora se puede reflejar del enrutador B al enrutador A, con el enrutador B agregando su marca de tiempo de transmisión (T3) y el enrutador A agregando su marca de tiempo de recepción (T4).
Estas cuatro marcas de tiempo (T1, T2, T3 y T4) permiten al enrutador A calcular el retraso unidireccional en cada dirección, así como el retardo bidireccional para el canal. Los cálculos de retraso unidireccional requieren que los relojes de los enrutadores A y B estén sincronizados.
En este punto, el enrutador A puede calcular el retraso de canal bidireccional y el retraso de ida y vuelta asociados con el canal de la siguiente manera:
Retardo de canal bidireccional = (T4 - T1) - (T3 - T2)
Retraso de ida y vuelta = T4 - T1
Características de pérdida y retraso de paquetes
Supported Features of Packet Loss and Delay
Junos OS admite las siguientes funciones con la medición de pérdidas y retrasos bajo demanda:
Supervisión del rendimiento solo para los LSP UHP punto a punto MPLS bidireccionales asociados
Medición de pérdidas
Medición del rendimiento
Medición de retardo bidireccional (retardo de canal y retardo de ida y vuelta)
Variación de retardo entre paquetes (IPDV)
Medición de pérdidas en modo directo
Ethernet agregada e interfaces SONET agregadas
Compatibilidad con múltiples chasis
Compatible con 64 bits
Unsupported Features of Packet Loss and Delay
Junos OS no admite la siguiente funcionalidad de medición de pérdida y retraso bajo demanda:
Medición de pérdidas y retardos para pseudohilos (sección 2.9.1 de RFC 6374)
Medición unidireccional (sección 2.6 de RFC 6374)
Medición diádica (sección 2.7 de RFC 6374)
Medición de pérdidas y retardos en modo de circuito cerrado (sección 2.8 de RFC 6374)
Medición de pérdidas y retrasos en un nodo intermedio desde un punto final de LSP (sección 2.9.5 de RFC 6374)
Postprocesamiento externo (sección 2.9.7 de RFC 6374)
Medición de pérdidas en modo inferido (sección 2.9.8 de RFC 6374)
Modo proactivo
Sistemas lógicos
SNMP
Ejemplo: Configuración de la medición de pérdida y retardo bajo demanda
En este ejemplo se muestra cómo habilitar la medición de pérdida y retraso bajo demanda para rutas de conmutación de etiquetas (LSP) punto a punto de estallido final (UHP) en redes MPLS para supervisar el rendimiento de la red.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Dos plataformas de enrutamiento universal 5G serie MX que contienen solo MPC/MIC
-
Junos OS versión 14.2 o posterior ejecutándose en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
-
Configure los protocolos siguientes:
-
Confirmación de asistencia (RSVP)
-
MPLS
-
OSPF
-
Descripción general
A partir de Junos OS versión 14.2, se introduce una herramienta bajo demanda para supervisar y medir la pérdida de paquetes, el retraso de paquetes o ambos para las rutas de conmutación de etiquetas (LSP) punto a punto (MPLS ultimate hop popping) bidireccionales asociadas. La herramienta se puede habilitar mediante los siguientes comandos de CLI: , , y .monitor mpls loss rsvpmonitor mpls delay rsvpmonitor mpls loss-delay rsvp
Estos comandos proporcionan un resumen a pedido de las métricas de rendimiento para la pérdida de paquetes en modo directo, el retraso bidireccional de paquetes y métricas relacionadas, como la variación del retraso entre paquetes y la medición del rendimiento de canal.
Esta funcionalidad proporciona visibilidad en tiempo real del rendimiento de la red, lo que facilita la planificación, resolución de problemas y evaluación del rendimiento de la red.
Topología
Figura 2 Ilustra la medición de pérdida y retardo bajo demanda mediante una topología simple de dos enrutadores.
En este ejemplo, se configura un LSP bidireccional asociado entre los enrutadores R1 y R2, para el cual se miden las métricas de rendimiento.
Configuración
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
R1
set chassis fpc 0 pic 3 tunnel-services bandwidth 1g set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.10.0.1/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.10.0.1 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set protocols mpls statistics traffic-class-statistics set protocols mpls label-switched-path R1-R2 to 10.20.0.1 set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode set protocols mpls label-switched-path R1-R2 ultimate-hop-popping set protocols mpls label-switched-path R1-R2 associate-lsp R2-R1 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable
R2
set chassis fpc 0 pic 3 tunnel-services bandwidth 1g set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.20.0.1/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.20.0.1 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set protocols mpls statistics traffic-class-statistics set protocols mpls label-switched-path R2-R1 to 10.10.0.1 set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode set protocols mpls label-switched-path R2-R1 ultimate-hop-popping set protocols mpls label-switched-path R2-R1 associate-lsp R1-R2 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0.interface fxp0.0 disable
Procedimiento
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar el enrutador R1:
-
Habilite el chasis con servicios de túnel y configuración mejorada de servicios de red IP.
[edit chassis] user@R1# set fpc 0 pic 3 tunnel-services bandwidth 1g user@R1# set network-services enhanced-ip
-
Configure las interfaces para el enrutador R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.1.1.1/30 user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.10.0.1/32 user@R1# set lo0 unit 0 family mpls
-
Configure el ID de enrutador para el enrutador R1.
[edit routing-options] user@R1# set router-id 10.10.0.1
-
Active RSVP en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set rsvp interface ge-0/0/0.0 user@R1# set rsvp interface lo0.0 user@R1# set rsvp interface fxp0.0 disable
-
Habilite MPLS en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set mpls interface ge-0/0/0.0 user@R1# set mpls interface lo0.0 user@R1# set mpls interface fxp0.0 disable
-
Configure un LSP bidireccional asociado al enrutador R2.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 to 10.20.0.1 user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping user@R1# set mpls label-switched-path R1-R2 associate-lsp R2-R1
-
Cree clases de tráfico para mantener estadísticas de tráfico de datos por clase de tráfico.
Esto permite la medición de pérdidas con ámbito de clase de tráfico.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configure OSPF con capacidades de ingeniería de tráfico y habilite OSPF en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf interface fxp0.0 disable
Resultados
Desde el modo de configuración, ingrese los comandos show chassis, show interfaces, show routing-options y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R1# show chassis
fpc 0 {
pic 3 {
tunnel-services {
bandwidth 1g;
}
}
}
network-services enhanced-ip;
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 1o.1.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.10.0.1/32;
}
family mpls;
}
}
user@R1# show routing-options router-id 10.10.0.1;
user@R1# show protocols
rsvp {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
mpls {
statistics {
traffic-class-statistics;
}
label-switched-path R1-R2 {
to 10.20.0.1;
oam mpls-tp-mode;
ultimate-hop-popping;
associate-lsp R2-R1;
}
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
}
Verificación
Confirme que la configuración funcione correctamente.
- Comprobación del estado del LSP
- Verificación de la medición de pérdida de paquetes
- Verificación de la medición del retraso de paquetes
- Verificación de la medición de pérdida y retardo de paquetes
Comprobación del estado del LSP
Propósito
Verifique que el LSP bidireccional asociado entre los enrutadores R1 y R2 esté activo.
Acción
Desde el modo operativo, ejecute el comando.show mpls lsp
user@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.20.0.1 10.10.0.1 Up 0 * R1-R2 Assoc-Bidir Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.10.0.1 10.20.0.1 Up 0 1 FF 299776 - R2-R1 Assoc-Bidir Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Significado
El LSP bidireccional asociado R1-R2 está activo y activo.
Verificación de la medición de pérdida de paquetes
Propósito
Verifique el resultado de la medición de pérdidas bajo demanda.
Acción
Desde el modo operativo, ejecute el comando.monitor mpls loss rsvp R1-R2 count 2 detail
user@R1> monitor mpls loss rsvp R1-R2 count 2 detail (0) Response code : Success Origin timestamp : 1404129082 secs, 905571890 nsecs Forward transmit count : 83040 Forward receive count : 83040 Reverse transmit count : 83100 Reverse receive count : 83100 (1) Response code : Success Origin timestamp : 1404129083 secs, 905048410 nsecs Forward transmit count : 83841 Forward receive count : 83841 Reverse transmit count : 83904 Reverse receive count : 83904 Current forward transmit count : 801 Current forward receive count : 801 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.801 kpps Current reverse transmit count : 804 Current reverse receive count : 804 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.804 kpps (2) Response code : Success Origin timestamp : 1404129084 secs, 904828715 nsecs Forward transmit count : 84423 Forward receive count : 84423 Reverse transmit count : 84487 Reverse receive count : 84487 Current forward transmit count : 582 Current forward receive count : 582 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.582 kpps Current reverse transmit count : 583 Current reverse receive count : 583 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.583 kpps Cumulative forward transmit count : 1383 Cumulative forward loss : 0 packets Average forward loss ratio : 0.000000 Average forward throughput : 0.692 kpps Cumulative reverse transmit count : 1387 Cumulative reverse loss : 0 packets Average reverse loss ratio : 0.000000 Average reverse throughput : 0.694 kpps LM queries sent : 3 LM responses received : 3 LM queries timedout : 0 LM responses dropped due to errors : 0
Significado
Se muestra la medición de pérdida de paquetes para dos recuentos.
Verificación de la medición del retraso de paquetes
Propósito
Verifique el resultado de la medición del retraso bajo demanda.
Acción
Desde el modo operativo, ejecute el comando.monitor mpls delay rsvp R1-R2 count 2 detail
user@R1> monitor mpls delay rsvp R1-R2 count 2 detail (1) Response code : Success Querier transmit timestamp : 1404129122 secs, 479955401 nsecs Responder receive timestamp : 1404129122 secs, 468519022 nsecs Responder transmit timestamp : 1404129122 secs, 470255123 nsecs Querier receive timestamp : 1404129122 secs, 481736403 nsecs Current two-way channel delay : 44 usecs Current round-trip-time : 1781 usecs (2) Response code : Success Querier transmit timestamp : 1404129123 secs, 480926210 nsecs Responder receive timestamp : 1404129123 secs, 469488696 nsecs Responder transmit timestamp : 1404129123 secs, 471130706 nsecs Querier receive timestamp : 1404129123 secs, 482613911 nsecs Current two-way channel delay : 45 usecs Current round-trip-time : 1687 usecs Best two-way channel delay : 44 usecs Worst two-way channel delay : 45 usecs Average two-way channel delay : 45 usecs Best round-trip-time : 1687 usecs Worst round-trip-time : 1781 usecs Average round-trip-time : 1734 usecs Average forward delay variation : 1 usecs Average reverse delay variation : 1 usecs DM queries sent : 2 DM responses received : 2 DM queries timedout : 0 DM responses dropped due to errors : 0
Significado
Se muestra la medición del retraso de paquetes para dos recuentos.
Verificación de la medición de pérdida y retardo de paquetes
Propósito
Verifique el resultado de la medición de pérdida y retraso bajo demanda.
Acción
Desde el modo operativo, ejecute el comando.monitor mpls loss-delay rsvp R1-R2 count 2 detail
user@R1> monitor mpls loss-delay rsvp R1-R2 count 2 detail (0) Response code : Success Forward transmit count : 142049 Forward receive count : 142049 Reverse transmit count : 142167 Reverse receive count : 142167 Querier transmit timestamp : 1404129161 secs, 554422723 nsecs Responder receive timestamp : 1404129161 secs, 542877570 nsecs Responder transmit timestamp : 1404129161 secs, 546004545 nsecs Querier receive timestamp : 1404129161 secs, 557599327 nsecs (1) Response code : Success Forward transmit count : 143049 Forward receive count : 143049 Reverse transmit count : 143168 Reverse receive count : 143168 Current forward transmit count : 1000 Current forward receive count : 1000 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 1.000 kpps Current reverse transmit count : 1001 Current reverse receive count : 1001 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 1.001 kpps Querier transmit timestamp : 1404129162 secs, 554465742 nsecs Responder receive timestamp : 1404129162 secs, 542919166 nsecs Responder transmit timestamp : 1404129162 secs, 545812736 nsecs Querier receive timestamp : 1404129162 secs, 557409175 nsecs Current two-way channel delay : 49 usecs Current round-trip-time : 2943 usecs (2) Response code : Success Forward transmit count : 143677 Forward receive count : 143677 Reverse transmit count : 143799 Reverse receive count : 143799 Current forward transmit count : 628 Current forward receive count : 628 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.627 kpps Current reverse transmit count : 631 Current reverse receive count : 631 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.630 kpps Querier transmit timestamp : 1404129163 secs, 556698575 nsecs Responder receive timestamp : 1404129163 secs, 545150128 nsecs Responder transmit timestamp : 1404129163 secs, 546918408 nsecs Querier receive timestamp : 1404129163 secs, 558515047 nsecs Current two-way channel delay : 48 usecs Current round-trip-time : 1816 usecs Cumulative forward transmit count : 1628 Cumulative forward loss : 0 packets Average forward loss ratio : 0.000000 Average forward throughput : 0.813 kpps Cumulative reverse transmit count : 1632 Cumulative reverse loss : 0 packets Average reverse loss ratio : 0.000000 Average reverse throughput : 0.815 kpps Best two-way channel delay : 48 usecs Worst two-way channel delay : 49 usecs Average two-way channel delay : 49 usecs Best round-trip-time : 1816 usecs Worst round-trip-time : 3176 usecs Average round-trip-time : 2645 usecs Average forward delay variation : 1 usecs Average reverse delay variation : 0 usecs LDM queries sent : 3 LDM responses received : 3 LDM queries timedout : 0 LDM responses dropped due to errors : 0
Significado
Se muestra la medición de pérdida y retraso de paquetes para dos recuentos.
Ejemplo: Configuración de mediciones proactivas de pérdida y retardo para LSP MPLS bidireccionales
En este ejemplo se muestra cómo configurar mediciones proactivas de pérdida y retardo para rutas de conmutación de etiquetas (LSP) de salto máximo punto a punto en redes MPLS para supervisar el rendimiento de la red.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Dos plataformas de enrutamiento universal 5G serie MX que contienen solo MPC/MIC
-
Junos OS versión 15.1 o posterior ejecutándose en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
-
Configure los protocolos siguientes:
-
MPLS
-
OSPF
-
Confirmación de asistencia (RSVP)
-
Descripción general
A partir de Junos OS versión 15.1, se introduce una herramienta proactiva para supervisar y medir la pérdida de paquetes, el retraso de paquetes o ambas para las rutas de conmutación de etiquetas punto a punto (LSP) de MPLS bidireccional de salto final asociadas.
Esta característica proporciona las siguientes métricas de rendimiento:
-
Variación de retardo entre paquetes (IPDV)
-
Medición de pérdidas
-
Retraso de ida y vuelta (RTT)
-
Medición del rendimiento
-
Retardo de canal bidireccional
Esta funcionalidad proporciona visibilidad en tiempo real del rendimiento de la red, lo que facilita la planificación, resolución de problemas y evaluación del rendimiento de la red.
Topología
Figura 3 Ilustra las mediciones proactivas de pérdida y retardo mediante una topología simple de dos enrutadores.
En este ejemplo, se configura un LSP bidireccional asociado entre los enrutadores R1 y R2, para el cual se miden las métricas de rendimiento.
Configuración
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía [edit] y, luego, ingrese commit desde el modo de configuración.
R1
set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.10.0.1/32 set interfaces lo0 unit 0 family mpls set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols mpls label-switched-path R1-R2 associate-lsp R2-R1 set protocols mpls label-switched-path R1-R2 install 10.20.0.0/24 active set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class none query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder delay min-query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder loss min-query-interval 1000 set protocols mpls label-switched-path R1-R2 to 10.20.0.1 set protocols mpls label-switched-path R1-R2 ultimate-hop-popping set protocols mpls statistics traffic-class-statistics set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set routing-options router-id 10.10.0.1
R2
set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.20.0.1/32 set interfaces lo0 unit 0 family mpls set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols mpls label-switched-path R2-R1 associate-lsp R1-R2 set protocols mpls label-switched-path R2-R1 install 10.10.0.0/24 active set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder delay min-query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder loss min-query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss traffic-class none query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R2-R1 to 10.10.0.1 set protocols mpls label-switched-path R2-R1 ultimate-hop-popping set protocols mpls statistics traffic-class-statistics set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set routing-options router-id 10.20.0.1
Procedimiento
Procedimiento paso a paso
El ejemplo siguiente requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI.Usar el editor de CLI en el modo de configuraciónhttps://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html
Para configurar el enrutador R1:
-
Habilite la configuración mejorada de los servicios de red IP.
[edit chassis] user@R1# set network-services enhanced-ip
-
Configure las interfaces para el enrutador R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.1.1.1/30 user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.10.0.1/32 user@R1# set lo0 unit 0 family mpls
-
Configure el ID de enrutador para el enrutador R1.
[edit routing-options] user@R1# set router-id 10.10.0.1
-
Active RSVP en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set rsvp interface ge-0/0/0.0 user@R1# set rsvp interface lo0.0 user@R1# set rsvp interface fxp0.0 disable
-
Habilite MPLS en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set mpls interface ge-0/0/0.0 user@R1# set mpls interface lo0.0 user@R1# set mpls interface fxp0.0 disable
-
Configure un LSP bidireccional asociado al enrutador R2.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 to 10.20.0.1 user@R1# set mpls label-switched-path R1-R2 install 10.20.0.0/24 active user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping user@R1# set mpls label-switched-path R1-R2 associate-lsp R2-R1
-
Cree clases de tráfico para mantener estadísticas de tráfico de datos por clase de tráfico.
Esto permite medir la pérdida y el retraso con ámbito de clase de tráfico.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configure la supervisión del rendimiento en el lado de la consulta.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class none query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000
-
Configure la supervisión del rendimiento en el lado del respondedor.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder delay min-query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder loss min-query-interval 1000
-
Configure OSPF con capacidades de ingeniería de tráfico y habilite OSPF en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.
[edit protocols] user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf interface fxp0.0 disable
Resultados
Desde el modo de configuración, ingrese los comandos show chassis, show interfaces, show routing-options y show protocols para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
user@R1# show chassis network-services enhanced-ip;
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.10.0.1/32;
}
family mpls;
}
}
user@R1# show routing-options router-id 10.10.0.1;
user@R1# show protocols
rsvp {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R1-R2 {
to 10.20.0.1;
install 10.20.0.0/24 active;
oam {
mpls-tp-mode;
performance-monitoring {
querier {
loss {
traffic-class none {
query-interval 1000;
}
}
delay {
traffic-class tc-0 {
query-interval 1000;
}
}
loss-delay {
traffic-class none {
query-interval 1000;
}
}
}
responder {
loss {
min-query-interval 1000;
}
delay {
min-query-interval 1000;
}
}
}
}
ultimate-hop-popping;
associate-lsp R2-R1;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
}
Verificación
Verificación de la medición de pérdidas y retrasos
Propósito
Verifique la medición de pérdidas y retrasos.
Acción
Desde el modo operativo, ejecute el comando.show performance-monitoring mpls lsp
user@R1> show performance-monitoring mpls lsp
Session Total: 3 Up: 3 Down: 0
LSP name:R1-R2, PM State:Up
Loss measurement Data:
Duration: 00:04:43
Traffic-class: None
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Forward loss measurement:
Average packet loss: 0
Average packet throughput: 554338
Reverse loss measurement:
Average packet loss: 0
Average packet throughput: 1352077
LSP name:R1-R2, PM State:Up
Delay measurement Data:
Duration: 00:04:43
Traffic-class: 0
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Best 2-way channel delay: 72 usecs
Worst 2-way channel delay: 365 usecs
Best round trip time: 843 usecs
Worst round trip time: 105523 usecs
Avg absolute fw delay variation: 1619 usecs
Avg absolute rv delay variation: 1619 usecs
LSP name:R1-R2, PM State:Up
Loss measurement Data:
Duration: 00:04:43
Traffic-class: None
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Forward loss measurement:
Average packet loss: 0
Average packet throughput: 553927
Reverse loss measurement:
Average packet loss: 0
Average packet throughput: 1351531
Delay measurement Data:
Best 2-way channel delay: 76 usecs
Worst 2-way channel delay: 368 usecs
Best round trip time: 1082 usecs
Worst round trip time: 126146 usecs
Avg absolute fw delay variation: 1618 usecs
Avg absolute rv delay variation: 1619 usecs
Significado
Se muestran las métricas de medición de pérdida y retraso de paquetes para LSP.
Configuración de la medición de pérdida y retardo bajo demanda
Puede configurar una medición de pérdida y retardo bajo demanda para rutas de conmutación de etiquetas (LSP) punto a punto en redes MPLS para supervisar el rendimiento de la red. Los comandos , , y CLI proporcionan un resumen a pedido de las métricas de rendimiento para la pérdida de paquetes en modo directo, el retraso bidireccional de paquetes y métricas relacionadas, como la variación del retraso entre paquetes y la medición del rendimiento de canal.monitor mpls loss rsvpmonitor mpls delay rsvpmonitor mpls loss-delay rsvp
Esta funcionalidad proporciona visibilidad en tiempo real del rendimiento de la red, lo que facilita la planificación, resolución de problemas y evaluación del rendimiento de la red.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure el ID del enrutador del dispositivo.
Configure los protocolos siguientes:
Confirmación de asistencia (RSVP)
OSPF
Habilite las capacidades de ingeniería de tráfico.
MPLS
Para configurar el dispositivo PE:
Configuración de mediciones proactivas de pérdidas y retardos
Puede configurar mediciones proactivas de pérdida y retardo para rutas de conmutación de etiquetas (LSP) de salto máximo punto a punto en redes MPLS para supervisar el rendimiento de la red. El comando CLI proporciona un resumen de las métricas de rendimiento para la pérdida de paquetes en modo directo, el retraso bidireccional de paquetes y métricas relacionadas, como la variación del retraso entre paquetes y la medición del rendimiento de canal.show performance-monitoring mpls lsp
Esta funcionalidad proporciona visibilidad en tiempo real del rendimiento de la red, lo que facilita la planificación, resolución de problemas y evaluación del rendimiento de la red.
Esta característica proporciona las siguientes métricas de rendimiento:
Variación de retardo entre paquetes (IPDV)
Medición de pérdidas
Retraso de ida y vuelta (RTT)
Medición del rendimiento
Retardo de canal bidireccional
Antes de empezar:
Configure las interfaces del dispositivo.
Configure los números de sistema autónomo y los ID de enrutador para los dispositivos.
Configure los protocolos siguientes:
MPLS
OSPF
Confirmación de asistencia (RSVP)
Para configurar mediciones proactivas de pérdidas y retardos en el dispositivo de PE: