Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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:

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:

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

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-statistics instrucción en el [edit protocols mpls statistics] nivel jerárquico.

    Cuando traffic-class-statistics está 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-mode instrucció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.

Figura 1: Medición bidireccional básicaMedición bidireccional básica

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:

  1. A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

  2. 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:

  1. Retraso del canal bidireccional = (T4 - T1) - (T3 - T2)

  2. 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:

  1. Configure las interfaces del dispositivo.

  2. Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.

  3. 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.

Figura 2: Configuración de la medición de pérdidas y retrasos a pedido Configuración de la medición de pérdidas y retrasos a pedido

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

R2

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:

  1. Habilite el chasis con servicios de túnel y configuración mejorada de servicios de red IP.

  2. Configure las interfaces para el enrutador R1.

  3. Configure el ID de enrutador para el enrutador R1.

  4. Habilite RSVP en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.

  5. Habilite MPLS en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.

  6. Configure un LSP bidireccional asociado al enrutador R2.

  7. 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.

  8. 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.

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.

Verificación

Confirme que la configuración funciona correctamente.

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.

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.

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.

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.

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:

  1. Configure las interfaces del dispositivo.

  2. Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.

  3. Configure los siguientes protocolos:

    1. MPLS

    2. OSPF

    3. 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.

Figura 3: Configuración de mediciones de pérdida y retraso pro active Configuración de mediciones de pérdida y retraso pro active

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

R2

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:

  1. Habilite la configuración de servicios de red IP mejorada.

  2. Configure las interfaces para el enrutador R1.

  3. Configure el ID de enrutador para el enrutador R1.

  4. Habilite RSVP en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.

  5. Habilite MPLS en todas las interfaces del enrutador R1, excluyendo la interfaz de administración.

  6. Configure un LSP bidireccional asociado al enrutador R2.

  7. 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.

  8. Configure la supervisión del rendimiento en el lado más querier.

  9. Configure la supervisión del rendimiento en el lado del respondedores.

  10. 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.

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.

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.

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:

  1. Configure las interfaces del dispositivo.

  2. Configure el ID del enrutador del dispositivo.

  3. Configure los siguientes protocolos:

    • RSVP

    • OSPF

      Habilite capacidades de ingeniería de tráfico.

    • MPLS

Para configurar el dispositivo PE:

  1. Habilite el chasis con servicios de túnel y configuración mejorada de servicios de red IP.
  2. Configure un LSP bidireccional asociado al enrutador remoto.
  3. 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.

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:

  1. Configure las interfaces del dispositivo.

  2. Configure los números de sistema autónomo y los identificaciones de enrutador para los dispositivos.

  3. Configure los siguientes protocolos:

    • MPLS

    • OSPF

    • RSVP

Para configurar mediciones de pérdida y retraso proactivas en el dispositivo de PE:

  1. Configure un LSP bidireccional asociado al enrutador R2.
  2. 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 de la clase de tráfico.

  3. Configure la supervisión del rendimiento en el lado más querier.
  4. Configure la supervisión del rendimiento en el lado del respondedores.