Configuración de sondas RPM en enrutadores de las series M, MX y T, y conmutadores de las series EX

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

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

Tenga en cuenta los siguientes puntos cuando configure clientes RPM y servidores RPM:

• RPM no se admite en sistemas lógicos.

• No puede configurar un cliente RPM basado en PIC y un servidor RPM basado en el motor de reenvío de paquetes o en el motor de enrutamiento para recibir los sondeos RPM.

• No puede configurar un cliente RPM basado en motor de reenvío de paquetes y un servidor RPM que recibe los sondeos RPM para que estén en el PIC o motor de enrutamiento.

• El cliente RPM y el servidor RPM deben estar ubicados en el mismo tipo de módulo. Por ejemplo, si el cliente RPM está basado en PIC, el servidor RPM también debe estar basado en PIC y si el servidor RPM está basado en motor de reenvío de paquetes, el cliente RPM también debe estar basado en motor de reenvío de paquetes.

• A partir de Junos OS versión 17.3R1, se admiten RPM basados en PIC y en motor de enrutamiento para túneles IPsec y túneles GRE si utiliza MS-MPC o MS-MIC. RPM basado en 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.

• A partir de Junos OS versión 17.3R1, puede configurar la generación de sondas IPv4 icmp-ping y icmp-ping-timestamp RPM en un MS-MPC o MS-MIC, lo que aumenta el número de sondeos generados hasta 1 millón por segundo en cada NPU de servicio en comparación con el número de sondeos que se generan en el motor de reenvío de paquetes. A partir de Junos OS versión 18.1R1, puede configurar la generación de sondeos RPM icmp6-ping en un MS-MPC o MS-MIC. Para configurar la generación de sondeos RPM en un MS-MPC o MS-MIC:

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

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

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

  A partir de Junos OS versión 18.1R1, puede utilizar filtros adicionales para limitar la salida de los comandos show services rpm probe-results y show services rpm history-results para sondeos RPM generados en un MS-MPC o MS-MIC.

• A partir de Junos OS versión 17.4R1, puede optimizar la configuración de la CLI para pruebas RPM para IPv4. A partir de Junos OS versión 18.2R1, también puede optimizar la configuración de la CLI para pruebas RPM para IPv6. Esta optimización permite el uso de instrucciones de configuración RPM mínimas para generar múltiples pruebas (hasta 100K pruebas) con nombres de prueba RPM predefinidos y reservados. Esta optimización se puede configurar para pruebas con sondeos generados por el motor de reenvío de paquetes o por un MS-MPC o MS-MIC. Se generan pruebas 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 sondeos RPM simultáneos admitidos para varias versiones de Junos es el siguiente:

  • Versión de Junos OS anterior a 17.3R1—500

  • Junos OS versión 17.3R1 y posteriores: 2000 para los tipos de sonda ICMP e ICMP-Timestamp. Para sondas de otros tipos (UDP y TCP) el límite es 500.

  • Junos OS versión 17.3R1 y posteriores (con la implementación de sondeos delegados): 1 millón por NPU de servicio.

    Nota:

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

    Con la implementación de sondas delegadas, 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 la marca de tiempo icmp y / o paquetes icmp6-ping.

  Las pruebas se generan primero 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 sondeo determinado y aplicar el grupo al propietario del sondeo.

  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	Cantidad que se va a incrementar la dirección de origen o destino IPv4 para cada prueba de RPM generada.
  ipv6-step	Cantidad para incrementar la dirección de origen o destino IPv6 para cada prueba de RPM generada.
  ipv4-count	Número máximo de direcciones IPv4 de origen o destino que se van a usar para las pruebas de RPM generadas.
  ipv6-count	Número máximo de direcciones IPv6 de origen o destino que se van a utilizar para las pruebas de RPM generadas.
  interface-name.logical-unit-number	La interfaz de servicios que genera sondeos RPM y el número de unidad lógica que se utiliza 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, los siguientes ciclos de prueba generados vuelven a la unidad lógica que se utilizó en la primera prueba.
  tests-count	Número máximo de pruebas de 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 el propietario de un 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 máxima de 32 caracteres.

• Para especificar un nombre de prueba, incluya la instrucción en el nivel de test [edit services rpm probe owner] jerarquía. El identificador del nombre de la prueba puede tener una longitud máxima de 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 nivel de [edit services rpm probe owner] 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 nivel jerárquico [edit services rpm probe owner] . El tamaño puede ser de 0 a través 65400 y el tamaño predeterminado es 0. La data-size instrucción no es válida con los tipos de http-get sondeo o http-metadata-get .

  Nota:

  Si configura la función de marca de tiempo de hardware (consulte Configuración de marcas de tiempo RPM en enrutadores de las series MX, M, T y PTX, y conmutadores de las series EX):

  • Este es un elemento obsoleto El valor predeterminado es 32 bytes y este es un elemento data-size obsoleto 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.

  • Debe data-size ser al menos 100 bytes menor que la MTU predeterminada de la interfaz de la interfaz de cliente RPM.

• En los enrutadores serie M y T, 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 multiservicios agreguen las marcas de tiempo del hardware; para obtener más información, consulte Configuración de marcas de tiempo RPM en enrutadores serie MX, M, T y PTX, y conmutadores serie EX. También puede incluir la instrucción para habilitar las one-way-hardware-timestamp 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 sólo se utiliza para los tipos de sondeo UDP y TCP. El valor puede ser 7 o desde 49160 .65535

  Cuando se configura 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 sólo 7. En este caso, una comprobación de restricción le impide configurar cualquier otro valor para el puerto de destino. Esta restricción no se aplica cuando se utiliza la 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 de 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 del historial almacenadas, incluya la history-size instrucción en el nivel jerárquico [edit services rpm probe owner test test-name] . Especifique un valor de 0 a 512. El valor predeterminado es 50.

• Para especificar un número de ejemplos 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 de 0 a .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 jerárquico. Especifique un valor de 1 a .15

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

• Para especificar el contenido del paquete y del protocolo de la sonda, incluya la probe-type instrucción en el [edit services rpm probe owner test test-name] nivel de 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 la marca de tiempo de hardware de los paquetes de sondeo: icmp-ping, , udp-ping, icmp-ping-timestampudp-ping-timestamp. A partir de Junos OS versión 17.3R3, los sondeos delegados se distribuyen uniformemente en el intervalo de 3 segundos para evitar las ráfagas de paquetes en la red debido a la supervisión del rendimiento en tiempo real (RPM). Los syslogs de RPM se procesan con el aumento en el tiempo de aceleración de RPM delega las pruebas 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 posible restricción en event-processing.

  Nota:

  Algunos tipos de sonda requieren la configuración de parámetros adicionales. Por ejemplo, cuando especifique la opción oudp-ping, debe configurar el puerto de destino mediante la tcp-ping 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 más pequeño da como resultado un error de confirmación. El tamaño mínimo de datos para los paquetes de sondeo TCP es 1.

  Cuando se configura probe-type udp-ping el comando o probe-type udp-ping-timestamp junto con él, el one-way-hardware-timestamp valor de la destination-port puede ser sólo 7. En este caso, una comprobación de restricción 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 inet.0de enrutamiento de Internet.

• 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 del router, el paquete utiliza la dirección de la interfaz saliente como origen.

• A partir de Junos OS versión 16.1R1, 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 el en el inet6-options source-address ipv6-address statement nivel de [edit services rpm probe owner test test-name] 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 saliente 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.

  • Para los tipos de sondeo HTTP, especifique una dirección URL completamente formada que incluya http:// en 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) (la compatibilidad con IPv6 comienza en Junos OS versión 16.1R1) para el host de destino.

• Para especificar el tiempo de espera entre pruebas, incluya la test-interval instrucción en el nivel jerárquico [edit services rpm probe owner test test-name] . Especifique un valor de 0 segundos a extremos 86400. 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 nivel jerárquico [edit services rpm probe owner test test-name] . 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 la fluctuación máxima del origen al destino por prueba.

  • jitter-ingress: mide la fluctuación máxima del destino al origen 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 típica máxima del origen al destino por prueba.

  • std-dev-ingress—Mide la desviación típica máxima del destino al origen 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 sucesivas de la sonda, lo que indica el fallo de la sonda.

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

• Las interrupciones se envían si se alcanza o supera el umbral configurado. Para establecer el bit de interrupción para generar capturas, 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 interrupciones cuando se alcanza o supera la fluctuación en el umbral de tiempo de salida.

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

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

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

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

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

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

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

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

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

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

  • test-failure: genera interrupciones cuando se alcanza o supera el umbral de pérdida total del sondeo.