Configuración de sondas de RPM en enrutadores de la serie MX y conmutadores de la serie EX

El propietario de la sonda y el nombre de prueba de una sonda RPM juntos representan una única instancia de configuración RPM. Cuando especifique el nombre de la prueba, también puede configurar los parámetros de prueba.

Para configurar el propietario de la sonda, el nombre de la prueba y los parámetros de prueba, incluya la probe instrucción en el nivel de [edit services rpm] jerarquía:

Tenga en cuenta los siguientes puntos al configurar clientes RPM y servidores RPM:

• RPM no es compatible con sistemas lógicos.

• La RPM basada en PIC y en el motor de enrutamiento se admite para túneles IPsec y túneles GRE si usa MS-MPC o MS-MIC. La RPM basada en el motor de reenvío de paquetes no se admite para túneles IPsec. La compatibilidad con RPM en túneles IPSec permite la supervisión del acuerdo de nivel de servicio (SLA) para el tráfico transportado en túneles IPSec.

• Puede configurar la generación de sondas IPv4 icmp-ping y icmp-ping-timestamp RPM en una MS-MPC o MS-MIC, lo que aumenta la cantidad de sondas generadas hasta 1 millón por segundo en cada NPU de servicio en comparación con la cantidad de sondeos que se generan en el motor de reenvío de paquetes. Puede configurar la generación de sondeos de icmp6-ping RPM en una MS-MPC o MS-MIC. Para configurar la generación de sondas RPM en una MS-MPC o MS-MIC:

  • Incluya la destination-interface interface-name.logical-unit-number instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía e incluya la delegate-probes instrucción en el [edit services rpm probe owner] nivel de jerarquía. Especifica interface-name.logical-unit-number una interfaz lógica en una ranura MS-MPC o MS-MIC, PIC y puerto que tiene una dirección IP válida definida (por ejemplo, ms-1/2/1.1). La interfaz no puede ser una interfaz de multiservicios agregada (ams-).

  • Incluya las rpm client-delegate-probes instrucciones y en el family (inet | inet6) address address [edit interfaces interface-name unit logical-unit-number] nivel jerárquico. El interface-name y el logical-unit-number debe coincidir con el interface-name.logical-unit-number que usó para el destination-interface.

  Para los sondeos RPM configurados en una MS-MPC o MS-MIC, no se puede configurar la routing-instance instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía y no se pueden configurar los sondeos IPv4 e IPv6 dentro de la misma prueba.

  Puede usar filtros adicionales para limitar la salida de los comandos show services rpm probe-results y show services rpm history-results para las sondas RPM generadas en una MS-MPC o MS-MIC.

• Puede optimizar la configuración de la CLI para las pruebas de RPM para IPv4. A partir de Junos OS versión 18.2R1, también puede optimizar la configuración de la CLI para las pruebas de RPM para IPv6. Esta optimización permite el uso de instrucciones de configuración de RPM mínimas para generar múltiples pruebas (hasta 100K pruebas) con nombres de prueba de RPM reservados y predefinidos. Esta optimización se puede configurar para pruebas con sondeos generados por el motor de reenvío de paquetes o por una MS-MPC o MS-MIC. Las pruebas se generan para varias combinaciones de direcciones de origen y destino, que se incrementan en función de su configuración.

  El número máximo de sondas de RPM simultáneas admitidas para varias versiones de Junos es el siguiente:

  • Sin configurar la delegate-probes instrucción: 2000 para los tipos de sonda ICMP y de marca de tiempo ICMP. Para sondas de otros tipos (UDP y TCP), el límite es de 500.

  • Con la configuración de la instrucción delegate-probes ): 1 millón por servicio-NPU.

    Nota:

    Una MS-MIC contiene una NPU de servicio y una MS-MPC contiene cuatro NPU de servicio.

    Con la configuración de la instrucción delegate-probes , las sondas RPM cumplen con RFC792 y RFC4443. Por lo tanto, se pueden usar para monitorear cualquier dispositivo IP que cumpla con RFC y pueden responder a paquetes icmp-timestamp y/o icmp6-ping.

  Primero se generan pruebas para todas las direcciones de origen con la dirección de destino inicial, luego se generan pruebas para todas las direcciones de origen con la siguiente dirección de destino disponible, y así sucesivamente. También puede configurar un grupo que contenga valores globales para un propietario de sonda determinado y aplicar el grupo al propietario de la sonda.

  Para generar varias pruebas de RPM, configure lo siguiente:

  Las opciones son:

  ipv4-address-base	La dirección de origen o destino IPv4 que se incrementa para generar las direcciones utilizadas en las pruebas RPM.
  ipv6-address-base	La dirección de origen o destino IPv6 que se incrementa para generar las direcciones utilizadas en las pruebas RPM.
  ipv4-step	La cantidad para incrementar la dirección de origen o destino IPv4 para cada prueba de RPM generada.
  ipv6-step	La cantidad para incrementar la dirección de origen o destino IPv6 para cada prueba de RPM generada.
  ipv4-count	El número máximo de direcciones de origen o destino IPv4 que se utilizarán para las pruebas de RPM generadas.
  ipv6-count	El número máximo de direcciones de origen o destino IPv6 que se utilizarán para las pruebas de RPM generadas.
  interface-name.logical-unit-number	La interfaz de servicios que genera sondeos de RPM y el número de unidad lógica que se usa para la primera prueba que se genera.
  subunit-cnt	Número máximo de unidades lógicas utilizadas por la interfaz de servicios en las pruebas generadas. La primera prueba generada utiliza la unidad lógica especificada en la interface-name.logical-unit-number opción y cada prueba sucesiva incrementa el número de unidad lógica en uno. Una vez que se ha utilizado el número máximo de unidades lógicas, la siguiente prueba generada vuelve a la unidad lógica que se utilizó en la primera prueba.
  tests-count	El número máximo de pruebas RPM que se van a generar. Este número debe ser menor o igual que el número de direcciones de origen generadas multiplicado por el número de direcciones de destino generadas.

  Para configurar un grupo con valores globales para un propietario de sondeo determinado:

• Para especificar un propietario de sondeo, incluya la probe instrucción en el nivel de [edit services rpm] jerarquía. El identificador del propietario de la sonda puede tener una longitud de hasta 32 caracteres.

• Para especificar un nombre de prueba, incluya la test instrucción en el nivel de [edit services rpm probe owner] jerarquía. El identificador de nombre de prueba puede tener una longitud de hasta 32 caracteres. Una prueba representa el rango de sondas sobre las cuales se calculan la desviación estándar, el promedio y la fluctuación.

• Para especificar el contenido de la parte de datos de los sondeos del Protocolo de mensajes de control de Internet (ICMP), incluya la data-fill instrucción en el [edit services rpm probe owner] nivel de jerarquía. El valor puede ser un valor hexadecimal. La data-fill instrucción no es válida con los tipos de http-get sondeo o http-metadata-get .

• Para especificar el tamaño de la parte de datos de los sondeos ICMP, incluya la data-size instrucción en el [edit services rpm probe owner] nivel de jerarquía. El tamaño puede ser de a través 65400 y 0 el tamaño predeterminado es 0. La data-size instrucción no es válida con los tipos de http-get sondeo ohttp-metadata-get.

  Nota:

  Si configura la función de marca de tiempo del hardware (consulte Configurar la marca de tiempo de RPM en enrutadores MX, M, T y serie PTX y Conmutadores serie EX):

  • El data-size valor predeterminado es 32 bytes y 32 es el valor mínimo para la configuración explícita. El tipo de sondeo de marca de tiempo UDP es una excepción; Requiere un tamaño de datos mínimo de 44 bytes.

  • El valor configurado en la data-size instrucción debe ser al menos 100 bytes menor que la UMT predeterminada de la interfaz de la interfaz de cliente RPM.

• En enrutadores de la serie MX, configure la instrucción para habilitar la destination-interface marca de tiempo de hardware de los paquetes de sondeo RPM. Especifique una interfaz sp- para que el AS o la PIC de multiservicios agreguen las marcas de hora del hardware; Para obtener más información, consulte Configurar marcas de tiempo de RPM en enrutadores MX, M, T y serie PTX y Conmutadores serie EX. También puede incluir la one-way-hardware-timestamp instrucción para habilitar mediciones unidireccionales de retraso y fluctuación.

• Para especificar el puerto del protocolo de datagramas de usuario (UDP) o el puerto del protocolo de control de transmisión (TCP) al que se envía el sondeo, incluya la destination-port instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. La destination-port instrucción solo se utiliza para los tipos de sondeo UDP y TCP. El valor puede ser 7 o desde a través 65535de 49160 .

  Cuando configure o probe-type udp-ping probe-type udp-ping-timestamp junto con la marca de tiempo del hardware, el valor de la destination-port puede ser solo 7. En este caso, una comprobación de restricciones le impide configurar cualquier otro valor para el puerto de destino. Esta restricción no se aplica cuando se utiliza una marca de tiempo de hardware unidireccional.

• Para especificar el valor del campo Servicios diferenciados (DiffServ) dentro del encabezado IP, incluya la dscp-code-point instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. El valor de bits del punto de código DiffServ (DSCP) se puede establecer en un patrón válido de 6 bits; Por ejemplo, 001111. También se puede establecer mediante un alias configurado en el nivel de [edit class-of-service code-point-aliases dscp] jerarquía. El valor predeterminado es 000000.

• Para especificar el número de entradas de historial almacenadas, incluya la history-size instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía. Especifique un valor de 0 a . 512 El valor predeterminado es 50.

• Para especificar una serie de muestras para realizar cálculos estadísticos, incluya la moving-average-size instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía. Especifique un valor desde 0 hasta .255

• Para especificar el número de sondeos dentro de una prueba, incluya la probe-count instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía. Especifique un valor desde 1 hasta .15

• Para especificar el tiempo de espera entre el envío de paquetes, incluya la probe-interval instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. Especifique un valor de a través 255 de 1 segundos.

• Para especificar el contenido de paquete y protocolo del sondeo, incluya la probe-type instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. Se admiten los siguientes tipos de sondeo:

  • http-get: envía una solicitud get del Protocolo de transferencia de hipertexto (HTTP) a una URL de destino.

  • http-metadata-get: envía una solicitud HTTP get de metadatos a una URL de destino.

  • icmp-ping: envía solicitudes de eco ICMP a una dirección de destino.

  • icmp-ping-timestamp: envía solicitudes de marca de tiempo ICMP a una dirección de destino.

  • tcp-ping: envía paquetes TCP a un destino.

  • udp-ping: envía paquetes UDP a un destino.

  • udp-ping-timestamp: envía solicitudes de marca de tiempo UDP a una dirección de destino.

  Los siguientes tipos de sondeo admiten marcas de tiempo de hardware de paquetes de sondeo: icmp-ping, icmp-ping-timestamp, , udp-pingudp-ping-timestamp, . Los sondeos delegados se distribuyen uniformemente en el intervalo de 3 segundos para evitar las ráfagas de paquetes en la red debido al monitoreo de rendimiento en tiempo real (RPM). Los syslogs de RPM se procesan con el aumento del tiempo de aceleración de las pruebas de delegados de RPM a 60 segundos. Con los syslogs RPM procesados, las posibilidades de que varias pruebas comiencen y terminen al mismo tiempo son menores, por lo tanto, una restricción potencial en event-processing.

  Nota:

  Algunos tipos de sonda requieren la configuración de parámetros adicionales. Por ejemplo, cuando especifique la tcp-ping opción o udp-ping , debe configurar el puerto de destino mediante la destination-port instrucción. La udp-ping-timestamp opción requiere un tamaño de datos mínimo de 12; cualquier tamaño de datos menor da como resultado un error de confirmación. El tamaño mínimo de datos para los paquetes de sonda TCP es 1.

  Cuando configure cualquiera probe-type udp-ping o probe-type udp-ping-timestamp junto con el one-way-hardware-timestamp comando, el valor de la destination-port puede ser solo 7. En este caso, una comprobación de restricciones le impide configurar cualquier otro valor para el puerto de destino.

• Para especificar la instancia de enrutamiento utilizada por los sondeos ICMP, incluya la routing-instance instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. La instancia de enrutamiento predeterminada es la tabla de enrutamiento de inet.0Internet.

• Para especificar la dirección IP de origen utilizada para los sondeos ICMP, incluya la source-address instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. Si la dirección IP de origen no es una de las direcciones asignadas por el enrutador, el paquete utiliza la dirección de la interfaz de salida como origen.

• Para especificar la dirección IPv6 de origen que se utilizará para los sondeos RPM que se envían desde el cliente RPM (el dispositivo que origina los paquetes RPM) al servidor RPM (el dispositivo que recibe los sondeos RPM), incluya inet6-options source-address ipv6-address statement el en el [edit services rpm probe owner test test-name] nivel de jerarquía. Si la dirección IPv6 de origen no es una de las direcciones asignadas del enrutador o conmutador, el paquete utilizará la dirección de la interfaz de salida como origen.

• Para especificar la dirección de destino utilizada para los sondeos, incluya la target instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía.

  • En Tipos de sondeo HTTP, especifique una dirección URL completamente formada que incluya http:// la dirección URL.

  • Para todos los demás tipos de sondeo, especifique una dirección IP versión 4 (IPv4) o IP versión 6 (IPv6) para el host de destino.

• Para especificar el tiempo de espera entre pruebas, incluya la test-interval instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía. Especifique un valor de a través 86400 de 0 segundos. Un valor de 0 segundos hace que la prueba de RPM se detenga después de una iteración. El valor predeterminado es 1.

• Para especificar los umbrales utilizados para los sondeos, incluya la thresholds instrucción en el [edit services rpm probe owner test test-name] nivel de jerarquía. Se genera un mensaje de registro del sistema cuando se supera el umbral configurado. Del mismo modo, se genera una captura SNMP (si está configurada) cuando se supera un umbral. Se admiten las siguientes opciones:

  • egress-time: mide el tiempo máximo de origen a destino por sonda.

  • ingress-time: mide el tiempo máximo de destino a origen por sonda.

  • jitter-egress: mide las fluctuaciones máximas de la fuente al destino por prueba.

  • jitter-ingress: mide la fluctuación máxima del destino a la fuente por prueba.

  • jitter-rtt: mide la fluctuación máxima por prueba, de 0 a 60000000 microsegundos.

  • rtt—Mide el tiempo máximo de ida y vuelta por sonda, en microsegundos.

  • std-dev-egress—Mide la desviación estándar máxima de la fuente al destino por prueba.

  • std-dev-ingress—Mide la desviación estándar máxima del destino a la fuente por prueba.

  • std-dev-rtt—Mide la desviación estándar máxima por prueba, en microsegundos.

  • successive-loss: mide el recuento de pérdidas de sonda sucesivas, lo que indica una falla de sonda.

  • total-loss: mide el recuento total de pérdidas de la sonda que indica una falla de prueba, de 0 a 15. El valor predeterminado para este umbral es 1.

• Las capturas se envían si se alcanza o supera el umbral configurado. Para establecer el bit de captura para generar trampas, incluya la traps instrucción en el nivel de [edit services rpm probe owner test test-name] jerarquía. Se admiten las siguientes opciones:

  • egress-jitter-exceeded: genera capturas cuando se alcanza o supera la fluctuación del umbral de tiempo de salida.

  • egress-std-dev-exceeded: genera trampas cuando se alcanza o supera el umbral de desviación estándar del tiempo de salida.

  • egress-time-exceeded: genera trampas cuando se alcanza o supera el umbral de tiempo máximo de salida.

  • ingress-jitter-exceeded: genera capturas cuando se alcanza o supera la fluctuación en el umbral de tiempo de entrada.

  • ingress-std-dev-exceeded: genera capturas cuando se alcanza o se supera el umbral de desviación estándar del tiempo de entrada.

  • ingress-time-exceeded: genera capturas cuando se alcanza o supera el umbral de tiempo de entrada máximo.

  • jitter-exceeded: genera trampas cuando se alcanza o supera la fluctuación en el umbral de tiempo de ida y vuelta.

  • probe-failure: genera trampas para umbrales de pérdida de sonda sucesivos cruzados.

  • rtt-exceeded: genera trampas cuando se alcanza o supera el umbral máximo de tiempo de ida y vuelta.

  • std-dev-exceeded: genera trampas cuando se alcanza o supera el umbral de desviación estándar del tiempo de ida y vuelta.

  • test-completion: genera trampas cuando se completa una prueba.

  • test-failure: genera trampas cuando se alcanza o supera el umbral total de pérdida de la sonda.