EN ESTA PÁGINA
Descripción general de la pérdida de paquetes y la medición de retraso a pedido para LSP de UHP
Ejemplo: Configuración de la medición de pérdidas y retrasos a pedido
Ejemplo: Configuración de mediciones de pérdida y retraso pro-activas para LSP MPLS bidireccional
Configuración de la medición de pérdidas y retrasos a pedido
Recopilar estadísticas sobre sesiones de MPLS
Configuración de MPLS para recopilar estadísticas
Puede configurar MPLS para que recopile periódicamente estadísticas de tráfico de todas las sesiones de MPLS, incluidas las sesiones de tránsito, mediante la configuración de la statistics instrucción. Debe configurar la statistics instrucción si desea recopilar estadísticas de tráfico de MPLS mediante sondeo SNMP de bases de información de administración (MIB) de MPLS.
Para habilitar o deshabilitar la recopilación de estadísticas MPLS, incluya la statistics instrucción:
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 file opción, las estadísticas se colocan en un archivo con una entrada por LSP. Durante el intervalo especificado, se registra la siguiente información en este archivo:
Número de paquetes, bytes, paquetes por segundo y bytes por segundo transmitidos por cada LSP. La paridad de funciones para la visualización de estadísticas de paquetes y bytes para sub LSP de un LSP punto a multipunto en el chipset Junos Trio se admite en las versiones 11.1R2, 11.2R2 y 11.4 de Junos OS.
El porcentaje de ancho de banda transmitido a través de un LSP dado 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 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 hubiera. Las sesiones ignoradas suelen ser aquellas que no están en estado ascendente o que tienen una etiqueta de entrada reservada (de 0 a 15) (por lo general, 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 el que se produjo el error. Recopilar estadísticas es un proceso poco confiable; los errores de lectura ocasionales pueden afectar su precisión. A continuación, se muestra el resultado:
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 pérdida de paquetes y la medición de retraso a pedido para LSP de UHP
En este tema, se describen los métodos para medir la pérdida, el retraso y la transferencia de datos de paquetes para las rutas conmutadas por etiquetas (LSP) de punto a punto en las 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 transferencia de datos de paquetes
- Mecanismos de medición de pérdida de paquetes y retraso
- 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 retrasos y pérdida 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 IPTV y video móvil, junto con la presión de minimizar el costo por bit y maximizar el valor por bit, está obligando a las operadoras a cambiar 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, es cada vez más importante para los proveedores de servicios predecir con precisión el impacto de las implementaciones de nuevas aplicaciones. La comprensión y el modelado del rendimiento de la red en la red son especialmente relevantes 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 de rendimiento más fundamentales. Su función 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 pérdidas (transferencia de archivos), sensible a retrasos (aplicaciones de voz o video), o ambos (aplicaciones de computación 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 de las experiencias de tráfico de los clientes en la red de proveedores de servicios.
Para garantizar el cumplimiento del SLA, los proveedores de servicios necesitan herramientas para medir y monitorear las métricas de rendimiento para la pérdida de paquetes, el retraso un solo sentido y el retraso bidireccional, y métricas relacionadas, como la variación de retraso y la transferencia de datos del canal. Esta capacidad de medición ofrece a los proveedores de servicios una mayor visibilidad de las características de rendimiento de sus redes, lo que facilita la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Definición de pérdida, retraso y transferencia de datos de paquetes
En las redes de paquetes, la pérdida y el retraso de paquetes son dos de las medidas de rendimiento más fundamentales.
Loss— La pérdida de paquetes es la falla de uno o más paquetes transmitidos que llegan 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 han caído. Sin embargo, en entornos de videoconferencia y comunicaciones de audio puras, como VoIP, la pérdida de paquetes puede crear fluctuación.
Delay— El retraso de paquete (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 el cable de cobre, la fibra óptica u ondas de radio, y los retrasos en la transmisión de 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 la transferencia de datos es el número total de estas acciones que se producen en un tiempo determinado.
Mecanismos de medición de pérdida de paquetes y retraso
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 sobre las rutas de conmutación de etiquetas (LSP) de MPLS bidireccionales asociadas al último salto de salto (UHP).
El mecanismo de medición del retraso a pedido y la pérdida de paquetes se inicia mediante los siguientes comandos de CLI:
monitor mpls loss rsvp— Realiza una medición de pérdidas a pedido para LSP UHP bidireccional asociados.monitor mpls delay rsvp: realiza una medición de retraso a pedido para los LSP de UHP bidireccional asociados.monitor mpls loss-delay rsvp: realiza una medición de pérdida y retraso combinados a pedido para los LSP de UHP bidireccional 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 medida y el nombre de 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 a pedido:
Medición de pérdidas (paquete y octeto)
Medición de la transferencia de datos (paquete y octeto)
Retraso de canal bidireccional
Retraso de ida y vuelta
Variación de retraso entre paquetes (IPDV)
El monitor mpls loss rsvp comando realiza la medición de pérdida y transferencia de datos, y el monitor mpls delay rsvp comando realiza el retraso del canal bidireccional, el retraso de ida y vuelta y las mediciones de IPDV. El monitor mpls loss-delay rsvp comando realiza una medición combinada de pérdida y retraso y mide todas las métricas de rendimiento mencionadas a la vez.
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— Un querier es el enrutador de borde (PE) del proveedor de entrada, 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 un querier.
Associated bidirectional LSP— Un LSP bidireccional asociado consta de dos LSP unidireccionales que se vinculan entre sí (o están asociados entre sí) mediante la configuración en ambos puntos de final del LSP.
La medición de pérdidas y retrasos a pedido solo se puede realizar en LSP de UHP bidireccional asociados.
Generic associated channel (G-Ach)— Los mensajes de monitoreo del rendimiento para el flujo de medición de pérdidas y retrasos a pedido en el G-Ach de MPLS. Este tipo de canal solo admite respuestas en banda y no admite los modos fuera de banda o sin respuesta.
Measurement point (MP)—MP es la ubicación en la 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 en el hardware antes de que se cola para la transmisión.
El MP 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 MP se distribuye en el lado de recepción. Además, cuando la interfaz de transmisión es una interfaz agregada, el MP también se distribuye.
Query rate— La velocidad de consulta es el intervalo entre dos consultas enviadas para la medición de pérdida y retraso.
Dado que los mensajes de medición de pérdida y retraso se originan en el motor de enrutamiento, una alta tasa de consulta para varios canales supone una gran 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 terminar rápidamente cuando la tasa de tráfico de datos es muy alta. La velocidad de consulta puede ser baja cuando se utilizan contadores de 64 bits en las cuatro ubicaciones de puntos de medición involucrados en la medición de pérdidas. Junos OS solo admite contadores de 64 bits.
Traffic class— De forma predeterminada, se admite la medición de pérdidas para todo el canal. Junos OS también admite la medición de pérdida de paquetes con alcance de clase de tráfico, en la que se deben crear contadores que mantengan estadísticas de tráfico de datos por clase de tráfico.
Los contadores de clases por tráfico no se crean de forma predeterminada. Para configurar la medición de pérdida de ámbito de clase de tráfico, incluya la
traffic-class-statisticsinstrucción en el[edit protocols mpls statistics]nivel jerárquico.Cuando
traffic-class-statisticsestá configurado, los paquetes de control que fluyen por la G-Ach no se cuentan en los contadores de transmisión y recepción.Nota:La habilitación y deshabilitación de 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 a pedido y no proporciona soporte para el modo inferido.
La medición directa de pérdidas requiere que las estadísticas de tráfico de datos se mantengan en la entrada y salida de dos LSP unidireccionales del LSP bidireccional asociado. Cuando un enrutador serie MX solo usa MPC y MIC, se crean contadores para mantener estadísticas de tráfico de datos de forma predeterminada en la entrada de todos los tipos de LSP y salida de LSP UHP.
Sin embargo, el modo directo de medición de pérdidas no es completamente exacto 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 reoordenación de los paquetes de datos en relación con los mensajes de medición de pérdida.
Los paquetes de control que no fluyen por G-Ach no se cuentan en la entrada de LSP, sino que se cuentan en la salida de LSP.
El reordenación del tráfico de datos en relación con el mensaje de medición de pérdidas cuando se implementa un Diffserv en la red MPLS y el alcance de la 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érdida de ámbito de clase de tráfico cuando se implementa un Diffserv.
Nota:La medición de pérdida en modo directo es vulnerable a la interrupción cuando la interfaz de entrada o salida asociada con el LSP cambia.
Loss measurement synchronization— Las condiciones de sincronización especificadas en la sección 2.9.8 del RFC 6374 no son verdaderas en sentido absoluto. Sin embargo, como los contadores de medición de pérdidas se estampan en el hardware, los errores introducidos debido a no satisfacer 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 no son interfaces agregadas. En cualquier caso, los contadores de medición de pérdidas se estampan 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 sincronizarse en estos motores de reenvío de paquetes para que se realicen mediciones de retraso bidireccional. Esta condición es válida para la plataforma en la que se implementa la función de medición de retraso a pedido.
Cuando hay interfaces agregadas o ECMP, el retraso se mide solo para una de las rutas potenciales.
Cuando se utiliza un mensaje de pérdida y retraso combinados para el cálculo de 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 retraso siempre se realiza por clase de tráfico, y la precisión de la medición debe cuantificarse después de las pruebas.
Timestamp format—Junos OS solo admite el formato ieee 1588 del protocolo de tiempo de precisión (PTP) [IEEE1588] para registrar mensajes de medición de retraso. No se admite el formato de tiempo de red (NTP).
Operations, administration, and maintenance (OAM)— para indicar que todos los mensajes de OAM de los LSP de MPLS fluyen a través del G-Ach de MPLS y para permitir que los mensajes de supervisión del rendimiento de MPLS se lleven a través del G-Ach de MPLS, la
oam mpls-tp-modeinstrucción debe incluirse en el[edit protocols mpls label-switched-path lsp-name]nivel jerárquico.
Funcionalidad de medición de retrasos y pérdida 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 B. Los puntos de referencia temporales (T1, T2, T3 y T4) se asocian a una operación de medición que se lleva a cabo en el enrutador A. La operación consiste en el enrutador A que envía un mensaje de consulta al enrutador B y el enrutador B envía una respuesta. Cada punto de referencia indica el momento en el que se transmite o recibe la consulta o el mensaje de respuesta a través del canal.
En Figura 1, el enrutador A puede organizar para medir la pérdida de paquetes sobre el canal en las direcciones hacia adelante y hacia atrás mediante el envío de mensajes de consulta de medición de pérdida al enrutador B. Cada uno de los mensajes de reenvío e inverso contiene la cantidad de paquetes transmitidos antes del tiempo T1 a través del canal al enrutador B (A_TxP).
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 del tiempo T2 a través del canal del 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: la cantidad de paquetes recibidos antes del tiempo T4 a través del canal del enrutador B (A_RxP).
Estos cuatro valores de contador (A_TxP), (B_RxP), (B_TxP) y (A_RxP) permiten que el enrutador A calcule las estadísticas de pérdida deseadas. Dado que es posible que el recuento de transmisión 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 del contador, la pérdida se calcula en forma de un delta entre los mensajes.
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] se computan mediante el enrutador A 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 el módulo del tamaño del contador.
Para medir en el enrutador A el retraso en el canal del 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 hora que registra el instante en el que se transmite. En Figura 1, la marca de hora se registra en T1.
Cuando el mensaje llega al enrutador B, se agrega una marca de hora, que registra el instante en el que se recibe (T2). El mensaje ahora se puede reflejar desde el enrutador B al enrutador A, con el enrutador B agregando su marca de hora de transmisión (T3) y el enrutador A agregando su marca de recepción (T4).
Estas cuatro marcas de tiempo (T1, T2, T3 y T4) permiten que el enrutador A calcule el retraso un way en cada dirección, así como el retraso bidireccional para el canal. Los cálculos de retraso un solo sentido requieren que se sincronicen los relojes de los enrutadores A y B.
En este punto, el enrutador A puede calcular el retraso del canal bidireccional y el retraso de ida y vuelta asociados con el canal de la siguiente manera:
Retraso del 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 medición de pérdidas y retrasos a pedido:
Monitoreo del rendimiento solo para LSP UHP punto a punto de MPLS bidireccional asociado
Medición de pérdidas
Medición de transferencia de datos
Medición de retraso bidireccional (retraso del canal y retraso de ida y vuelta)
Variación de retraso entre paquetes (IPDV)
Medición de pérdidas en modo directo
Interfaces Ethernet y SONET agregadas
Soporte multichasis
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 a pedido:
Medición de pérdida y retraso para pseudocables (sección 2.9.1 del RFC 6374)
Medición unidireccional (sección 2.6 del RFC 6374)
Medición diádica (sección 2.7 del RFC 6374)
Medición de pérdida y retraso en modo de circuito cerrado (sección 2.8 del RFC 6374)
Medición de pérdida y retraso en un nodo intermedio desde un punto de conexión LSP (sección 2.9.5 del RFC 6374)
Postprocesamiento externo (sección 2.9.7 del RFC 6374)
Medición de pérdida de modo inferido (sección 2.9.8 del RFC 6374)
Modo activo
Sistemas lógicos
SNMP
Ejemplo: Configuración de la medición de pérdidas y retrasos a pedido
En este ejemplo, se muestra cómo habilitar la medición de pérdida y retraso a pedido para las rutas conmutadas por etiquetas (LSP) de punto a punto en las 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 serie MX de 5G que contienen solo MPC/MIC
-
Junos OS versión 14.2 o posterior se ejecuta en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.
-
Configure los siguientes protocolos:
-
RSVP
-
MPLS
-
OSPF
-
Descripción general
A partir de junos OS versión 14.2, se presenta una herramienta a pedido para monitorear y medir la pérdida de paquetes, el retraso o ambos para las rutas de conmutación de etiquetas (LSP) de punto a punto de la MPLS bidireccional asociada. La herramienta se puede habilitar mediante los siguientes comandos de CLI: monitor mpls loss rsvp, monitor mpls delay rsvpy monitor 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 de paquete bidireccional y las métricas relacionadas, como la variación de retraso entre paquetes y la medición de la transferencia de datos del canal.
Esta funcionalidad ofrece visibilidad del rendimiento de la red en tiempo real, lo que facilita la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Topología
Figura 2 ilustra la medición de pérdida y retraso a pedido mediante una topología simple de dos enrutadores.
En este ejemplo, se configura un LSP bidireccional asociado entre los enrutadores R1 y R2, para los que 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 y, luego, ingrese commit desde el [edit] 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.
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
-
Habilite 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érdida de alcance de clase de tráfico.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configure el OSPF con capacidades de ingeniería de tráfico y habilite el 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 interfaces, show routing-optionsy show protocols para confirmar la show chassisconfiguració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 funciona correctamente.
- Verificar el estado de LSP
- Verificación de la medición de pérdida de paquetes
- Verificación de la medición de retraso de paquetes
- Verificación de la medición del retraso en la pérdida de paquetes
Verificar el estado de LSP
Propósito
Compruebe que el LSP bidireccional asociado entre los enrutadores R1 y R2 está activo.
Acción
Desde el modo operativo, ejecute el show mpls lsp comando.
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
La LSP bidireccional asociada R1-R2 está activa y activa.
Verificación de la medición de pérdida de paquetes
Propósito
Verifique el resultado de la medición de pérdidas a pedido.
Acción
Desde el modo operativo, ejecute el monitor mpls loss rsvp R1-R2 count 2 detail comando.
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 de retraso de paquetes
Propósito
Verifique el resultado de la medición de retraso a pedido.
Acción
Desde el modo operativo, ejecute el monitor mpls delay rsvp R1-R2 count 2 detail comando.
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 de retraso de paquetes para dos recuentos.
Verificación de la medición del retraso en la pérdida de paquetes
Propósito
Verifique el resultado de la medición de pérdidas y retrasos a pedido.
Acción
Desde el modo operativo, ejecute el monitor mpls loss-delay rsvp R1-R2 count 2 detail comando.
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 de paquetes y retraso para dos recuentos.
Ejemplo: Configuración de mediciones de pérdida y retraso pro-activas para LSP MPLS bidireccional
En este ejemplo, se muestra cómo configurar mediciones de pérdida y retraso proactivas para rutas conmutadas por etiquetas (LSP) de punto a punto en las 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 serie MX de 5G que contienen solo MPC/MIC
-
Junos OS versión 15.1 o posterior se ejecuta en todos los enrutadores
Antes de empezar:
-
Configure las interfaces del dispositivo.
-
Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.
-
Configure los siguientes protocolos:
-
MPLS
-
OSPF
-
RSVP
-
Descripción general
A partir de la versión 15.1 de Junos OS, se presenta una herramienta proactiva para supervisar y medir la pérdida de paquetes, el retraso de paquetes o ambos para las rutas de conmutación de etiquetas (LSP) de MPLS bidireccionales asociadas de último salto de punto a punto (LSP).
Esta función proporciona las siguientes métricas de rendimiento:
-
Variación de retraso entre paquetes (IPDV)
-
Medición de pérdidas
-
Retraso de ida y vuelta (RTT)
-
Medición de transferencia de datos
-
Retraso de canal bidireccional
Esta funcionalidad ofrece visibilidad del rendimiento de la red en tiempo real, lo que facilita la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Topología
Figura 3 muestra las mediciones proactivas de pérdida y retraso mediante una topología simple de dos enrutadores.
En este ejemplo, se configura un LSP bidireccional asociado entre los enrutadores R1 y R2, para los que 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 y, luego, ingrese commit desde el [edit] 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 siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de CLI.
Para configurar el enrutador R1:
-
Habilite la configuración de servicios de red IP mejorada.
[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
-
Habilite 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 la medición de pérdida y retraso en el ámbito de la clase de tráfico.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configure la supervisión del rendimiento en el lado más querier.
[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 respondedores.
[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 el OSPF con capacidades de ingeniería de tráfico y habilite el 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 interfaces, show routing-optionsy show protocols para confirmar la show chassisconfiguració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 show performance-monitoring mpls lsp comando.
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 de paquetes y retraso para LSP.
Configuración de la medición de pérdidas y retrasos a pedido
Puede configurar una medición de pérdida y retraso a pedido para rutas conmutadas por etiquetas (LSP) de punto a punto para supervisar el rendimiento de la red. Los monitor mpls loss rsvpcomandos , monitor mpls delay rsvpy monitor mpls loss-delay rsvp 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 las métricas relacionadas, como la variación de retraso entre paquetes y la medición de la transferencia de datos del canal.
Esta funcionalidad ofrece visibilidad del rendimiento de la red en tiempo real, lo que facilita la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Antes de empezar:
Configure las interfaces del dispositivo.
Configure el ID del enrutador del dispositivo.
Configure los siguientes protocolos:
RSVP
OSPF
Habilite capacidades de ingeniería de tráfico.
MPLS
Para configurar el dispositivo PE:
Configuración de mediciones de pérdida y retraso pro active
Puede configurar mediciones proactivas de pérdida y retraso para rutas conmutadas por etiquetas (LSP) en redes MPLS para supervisar el rendimiento de la red. El show performance-monitoring mpls lsp comando de CLI proporciona un resumen de las métricas de rendimiento para la pérdida de paquetes en modo directo, el retraso de paquete bidireccional y las métricas relacionadas, como la variación del retraso entre paquetes y la medición de la transferencia de datos del canal.
Esta funcionalidad ofrece visibilidad del rendimiento de la red en tiempo real, lo que facilita la planificación, la resolución de problemas y la evaluación del rendimiento de la red.
Esta función proporciona las siguientes métricas de rendimiento:
Variación de retraso entre paquetes (IPDV)
Medición de pérdidas
Retraso de ida y vuelta (RTT)
Medición de transferencia de datos
Retraso de canal bidireccional
Antes de empezar:
Configure las interfaces del dispositivo.
Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.
Configure los siguientes protocolos:
MPLS
OSPF
RSVP
Para configurar mediciones de pérdida y retraso proactivas en el dispositivo de PE: