Configuração de sondas RPM em roteadores M, MX e Série T e switches da Série EX

O proprietário da sonda e o nome de teste de uma sonda RPM juntos representam uma única instância de configuração de RPM. Quando você especifica o nome do teste, você também pode configurar os parâmetros de teste.

Para configurar o proprietário da sonda, o nome do teste e os parâmetros de teste, inclua a probe declaração no nível de [edit services rpm] hierarquia:

Tenha em mente os seguintes pontos quando configurar clientes RPM e servidores RPM:

• O RPM não é suportado em sistemas lógicos.

• Você não pode configurar um cliente RPM baseado em PIC e um servidor RPM baseado no mecanismo de encaminhamento de pacotes ou no mecanismo de roteamento para receber as sondas RPM.

• Você não pode configurar um cliente RPM baseado em mecanismos de encaminhamento de pacotes e um servidor RPM que recebe as sondas RPM para estar no PIC ou mecanismo de roteamento.

• O cliente RPM e o servidor RPM devem estar localizados no mesmo tipo de módulo. Por exemplo, se o cliente RPM for baseado em PIC, o servidor RPM também deve ser baseado em PIC e, se o servidor RPM for baseado no mecanismo de encaminhamento de pacotes, o cliente RPM também deve ser baseado no mecanismo de encaminhamento de pacotes.

• A partir do Junos OS Release 17.3R1, o RPM baseado em mecanismos baseado em PIC e roteamento é suportado para túneis IPsec e túneis GRE se você estiver usando MS-MPCs ou MS-MICs. O RPM baseado em mecanismos de encaminhamento de pacotes não é suportado para túneis IPsec. O suporte de RPM em túneis IPSec permite o monitoramento do contrato de nível de serviço (SLA) para o tráfego transportado em túneis IPSec.

• A partir do Junos OS Release 17.3R1, você pode configurar a geração de sondas IPv4 icmp-ping e icmp-ping-timestamp RPM em um MS-MPC ou MS-MIC, o que aumenta o número de sondas geradas em até 1 milhão por segundo em cada NPU de serviço em comparação com o número de sondas geradas no Mecanismo de Encaminhamento de Pacotes. A partir do Junos OS Release 18.1R1, você pode configurar a geração de icmp6-ping sondas RPM em um MS-MPC ou MS-MIC. Para configurar a geração de sondas RPM em um MS-MPC ou MS-MIC:

  • Inclua o destination-interface interface-name.logical-unit-number nível de [edit services rpm probe owner test test-name] hierarquia e inclua a delegate-probes declaração no nível de [edit services rpm probe owner] hierarquia. A interface-name.logical-unit-number especifica uma interface lógica em um slot MS-MPC ou MS-MIC, PIC e porta que tenha um endereço IP válido definido nele (por exemplo, ms-1/2/1.1). A interface não pode ser uma interface multisserviço agregada (ams-).

  • Inclua o rpm client-delegate-probes e as family (inet | inet6) address address declarações no nível de [edit interfaces interface-name unit logical-unit-number] hierarquia. O interface-name e o logical-unit-number deve combinar com o interface-name.logical-unit-number que você usou para o destination-interface.

  Para sondas RPM configuradas em um MS-MPC ou MS-MIC, você não pode configurar a routing-instance declaração no nível de [edit services rpm probe owner test test-name] hierarquia e não pode configurar sondas IPv4 e IPv6 no mesmo teste.

  A partir do Junos OS Release 18.1R1, você pode usar filtros adicionais para limitar a saída dos resultados de sondagem rpm dos serviços de show e mostrar os comandos de resultados históricos de rpm dos serviços para sondas RPM geradas em um MS-MPC ou MS-MIC.

• A partir do Junos OS Release 17.4R1, você pode otimizar a configuração de CLI para testes de RPM para IPv4. A partir do Junos OS Release 18.2R1, você também pode otimizar a configuração CLI para testes de RPM para IPv6. Essa otimização permite o uso de declarações mínimas de configuração de RPM para gerar vários testes (até 100K) com nomes de teste de RPM pré-definidos e reservados. Essa otimização pode ser configurada para testes com sondas que são geradas pelo Mecanismo de Encaminhamento de Pacotes ou por um MS-MPC ou MS-MIC. Os testes são gerados para várias combinações de endereços de origem e alvo, que são incrementados com base em sua configuração.

  O número máximo de sondas RPM simultâricas suportadas para várias versões junos são as seguintes:

  • Junos OS versão com mais de 17.3R1 — 500

  • O Junos OS versão 17.3R1 e posterior — 2000 para tipos de sonda ICMP e ICMP-Timestamp. Para sondagens de outros tipos (UDP e TCP), o limite é de 500.

  • Junos OS Release 17.3R1 e posterior (com a implementação de delegações-sondas)— 1 milhão por Service-NPU.

    Nota:

    Um MS-MIC contém um serviço-NPU e um MS-MPC contém quatro NPUs de serviço.

    Com a implementação de sondas de delegado, as sondas RPM estão em conformidade com RFC792 e RFC4443. Assim, eles podem ser usados para monitorar qualquer dispositivo IP em conformidade com o RFC e podem responder a pacotes de icmp-timestamp e/ou icmp6-ping.

  Os testes são gerados primeiro para todos os endereços de origem com o endereço alvo inicial, depois são gerados testes para todos os endereços de origem com o próximo endereço alvo disponível e assim por diante. Você também pode configurar um grupo que contém valores globais para um determinado proprietário da sonda e aplicar o grupo ao proprietário da sonda.

  Para gerar vários testes de RPM, configure o seguinte:

  As opções são:

  ipv4-address-base	O endereço de origem ou alvo IPv4 que é incrementado para gerar os endereços usados nos testes de RPM.
  ipv6-address-base	O endereço de origem ou alvo IPv6 que é incrementado para gerar os endereços usados nos testes de RPM.
  ipv4-step	A quantidade para incrementar o endereço de origem ou alvo IPv4 para cada teste de RPM gerado.
  ipv6-step	A quantidade para incrementar o endereço de origem ou alvo IPv6 para cada teste de RPM gerado.
  ipv4-count	O número máximo de endereços de origem ou alvo IPv4 a ser usado para os testes de RPM gerados.
  ipv6-count	O número máximo de endereços de origem ou alvo IPv6 a ser usado para os testes de RPM gerados.
  interface-name.logical-unit-number	A interface de serviços que está gerando sondas RPM e o número de unidade lógica que é usado para o primeiro teste gerado.
  subunit-cnt	O número máximo de unidades lógicas usadas pela interface de serviços nos testes gerados. O primeiro teste gerado usa a unidade lógica especificada na opção interface-name.logical-unit-number , e cada teste sucessivo aumenta o número da unidade lógica por um. Uma vez usado o número máximo de unidades lógicas, o próximo ciclo de teste gerado volta para a unidade lógica que foi usada no primeiro teste.
  tests-count	O número máximo de testes de RPM a gerar. Esse número deve ser menor ou igual ao número de endereços de origem gerados multiplicados pelo número de endereços-alvo gerados.

  Configurar um grupo com valores globais para um determinado proprietário da sonda:

• Para especificar um proprietário da sonda, inclua a probe declaração no nível de [edit services rpm] hierarquia. O identificador do proprietário da sonda pode ter até 32 caracteres de comprimento.

• Para especificar um nome de teste, inclua a test declaração no nível de [edit services rpm probe owner] hierarquia. O identificador de nome de teste pode ter até 32 caracteres de comprimento. Um teste representa a variedade de sondas sobre as quais o desvio padrão, a média e o jitter são calculados.

• Para especificar o conteúdo da parte de dados das sondas do Protocolo de Mensagens de Controle de Internet (ICMP), inclua a data-fill declaração no nível de [edit services rpm probe owner] hierarquia. O valor pode ser um valor hexadecimal. A data-fill declaração não é válida com os http-get tipos ou http-metadata-get tipos de sonda.

• Para especificar o tamanho da porção de dados das sondas ICMP, inclua a data-size declaração no nível de [edit services rpm probe owner] hierarquia. O tamanho pode ser de 0 até 65400 o tamanho 0padrão. A data-size declaração não é válida com os http-get tipos ou http-metadata-get tipos de sonda.

  Nota:

  Se você configurar o recurso de tempo de tempo de hardware (consulte Configuração de tempos de RPM em roteadores MX, M, T e série PTX e switches da Série EX):

  • Este é um valor padrão de elemento data-size predeprecado é de 32 bytes e este é um elemento predefinido 32 é o valor mínimo para configuração explícita. O tipo de sonda de tempotamp UDP é uma exceção; exige um tamanho mínimo de dados de 44 bytes.

  • O data-size deve ser pelo menos 100 bytes menor do que o MTU padrão da interface da interface do cliente RPM.

• Nos roteadores série M e T, você configura a declaração para permitir o destination-interface tempo de tempo de hardware dos pacotes de sonda RPM. Você especifica uma interface sp para que o PIC de AS ou multisserviços adicione os tempos de hardware; para obter mais informações, consulte Configuração de tempos de RPM em roteadores MX, M, T e série PTX e switches da Série EX. Você também pode incluir a one-way-hardware-timestamp declaração para permitir medições de atraso e jitter unidirecionais.

• Para especificar a porta do protocolo de datagram do usuário (UDP) ou a porta de controle de transmissão (TCP) para a qual a sonda é enviada, inclua a destination-port declaração no nível de [edit services rpm probe owner test test-name] hierarquia. A destination-port declaração é usada apenas para os tipos de sonda UDP e TCP. O valor pode ser 7 ou de 49160 até 65535.

  Quando você configura ou probe-type udp-ping probe-type udp-ping-timestamp juntamente com o tempo de tempo de hardware, o valor para o destination-port pode ser apenas 7. Uma verificação de restrição impede que você configure qualquer outro valor para a porta de destino neste caso. Essa restrição não se aplica quando você está usando o tempo de tempo de hardware unidirecionário.

• Para especificar o valor do campo de Serviços Diferenciados (DiffServ) dentro do cabeçalho IP, inclua a dscp-code-point declaração no nível de [edit services rpm probe owner test test-name] hierarquia. O valor dos bits de ponto de código DiffServ (DSCP) pode ser definido em um padrão válido de 6 bits; por exemplo, 001111. Ele também pode ser definido usando um pseudônimo configurado no nível de [edit class-of-service code-point-aliases dscp] hierarquia. O padrão é 000000.

• Para especificar o número de entradas de histórico armazenadas, inclua a history-size declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 0 até 512. O padrão é 50.

• Para especificar várias amostras para fazer cálculos estatísticos, inclua a moving-average-size declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 0 até 255.

• Para especificar o número de sondas em um teste, inclua a probe-count declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 1 até 15.

• Para especificar o tempo de espera entre o envio de pacotes, inclua a probe-interval declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 1 até 255 segundos.

• Para especificar o conteúdo do pacote e do protocolo da sonda, inclua a probe-type declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Os seguintes tipos de sonda são suportados:

  • http-get— Envia um protocolo de transferência de hipertexto (HTTP) para obter solicitação para um URL alvo.

  • http-metadata-get— Envia uma solicitação de metadados para um URL alvo.

  • icmp-ping— Envia solicitações de eco do ICMP para um endereço alvo.

  • icmp-ping-timestamp— Envia solicitações de tempotamp de ICMP para um endereço alvo.

  • tcp-ping— Envia pacotes TCP para um alvo.

  • udp-ping— Envia pacotes UDP para um alvo.

  • udp-ping-timestamp— Envia solicitações de data center UDP para um endereço alvo.

  Os tipos de sonda a seguir oferecem suporte ao tempo de tempo de hardware de pacotes de sonda: icmp-ping, , icmp-ping-timestamp, udp-pingudp-ping-timestamp. A partir do Junos OS Release 17.3R3, as sondas de delegados são distribuídas uniformemente por todo o intervalo de 3 segundos para evitar explosões de pacotes na rede devido ao monitoramento de desempenho (RPM) em tempo real. Os syslogs de RPM são processados com o aumento do tempo de rampa dos testes de delegados de RPM para 60 segundos. Com os syslogs de RPM processados, as chances de vários testes começarem e terminarem ao mesmo tempo são menores, portanto, uma restrição potencial em event-processing.

  Nota:

  Alguns tipos de sonda exigem configuração de parâmetros adicionais. Por exemplo, quando você especifica a opção ou udp-ping a opçãotcp-ping, você deve configurar a porta de destino usando a destination-port declaração. A opção udp-ping-timestamp requer um tamanho mínimo de dados de 12; qualquer tamanho de dados menor resulta em um erro de comprometimento. O tamanho mínimo de dados para pacotes de sonda TCP é 1.

  Quando você configura ou probe-type udp-ping probe-type udp-ping-timestamp juntamente com o one-way-hardware-timestamp comando, o valor para o destination-port pode ser apenas 7. Uma verificação de restrição impede que você configure qualquer outro valor para a porta de destino neste caso.

• Para especificar a instância de roteamento usada pelas sondas ICMP, inclua a routing-instance declaração no nível de [edit services rpm probe owner test test-name] hierarquia. A instância de roteamento padrão é a tabela inet.0de roteamento da Internet.

• Para especificar o endereço IP de origem usado para sondas ICMP, inclua a source-address declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Se o endereço IP de origem não for um dos endereços atribuídos pelo roteador, o pacote usará o endereço da interface de saída como sua fonte.

• A partir do Junos OS Release 16.1R1, para especificar o endereço IPv6 de origem a ser usado para sondas RPM que são enviadas do cliente RPM (o dispositivo que origina os pacotes RPM) para o servidor RPM (o dispositivo que recebe as sondas RPM), inclua o inet6-options source-address ipv6-address statement [edit services rpm probe owner test test-name] nível de hierarquia. Se o endereço IPv6 de origem não for um dos endereços atribuídos pelo roteador ou switch, o pacote usará o endereço da interface de saída como fonte.

• Para especificar o endereço de destino usado para as sondas, inclua a target declaração no nível de [edit services rpm probe owner test test-name] hierarquia.

  • Para tipos de sonda HTTP, especifique uma URL totalmente formada que inclua http:// no endereço URL.

  • Para todos os outros tipos de sonda, especifique um endereço IP versão 4 (IPv4) ou IP versão 6 (IPv6) (IPv6 começa no endereço Junos OS versão 16.1R1) para o host alvo.

• Para especificar o tempo de espera entre os testes, inclua a test-interval declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 0 até 86400 segundos. Um valor de 0 segundos faz com que o teste de RPM pare após uma iteração. O valor padrão é 1.

• Para especificar os limites usados para as sondas, inclua a thresholds declaração no nível de [edit services rpm probe owner test test-name] hierarquia. Uma mensagem de log do sistema é gerada quando o limite configurado é excedido. Da mesma forma, uma armadilha SNMP (se configurada) é gerada quando um limite é excedido. As opções a seguir são suportadas:

  • egress-time— Mede o tempo máximo de origem ao destino por sonda.

  • ingress-time— Mede o tempo máximo de destino para fonte por sonda.

  • jitter-egress— Mede o jitter máximo de origem ao destino por teste.

  • jitter-ingress— Mede o jitter máximo de destino para fonte por teste.

  • jitter-rtt— Mede o jitter máximo por teste, de 0 a 6000000 microssegundos.

  • rtt— Mede o tempo máximo de ida e volta por sonda, em microssegundos.

  • std-dev-egress— Mede o desvio padrão máximo de origem ao destino por teste.

  • std-dev-ingress— Mede o desvio padrão máximo de destino para origem por teste.

  • std-dev-rtt— Mede o desvio padrão máximo por teste, em microssegundos.

  • successive-loss— Mede a contagem sucessiva de perdas de sondas, indicando falha na sonda.

  • total-loss— Mede a contagem total de perdas de sondas que indica falha no teste, de 0 a 15.

• As armadilhas são enviadas se o limiar configurado for atendido ou excedido. Para configurar o bit de armadilha para gerar armadilhas, inclua a traps declaração no nível de [edit services rpm probe owner test test-name] hierarquia. As opções a seguir são suportadas:

  • egress-jitter-exceeded— Gera armadilhas quando o jitter no limite de tempo de saída é atendido ou excedido.

  • egress-std-dev-exceeded— Gera armadilhas quando o limite de desvio padrão de tempo de saída é atendido ou excedido.

  • egress-time-exceeded— Gera armadilhas quando o limite máximo de tempo de saída é cumprido ou excedido.

  • ingress-jitter-exceeded— Gera armadilhas quando o limite de tempo de entrada é atendido ou excedido.

  • ingress-std-dev-exceeded— Gera armadilhas quando o limite de desvio padrão de tempo de entrada é atendido ou excedido.

  • ingress-time-exceeded— Gera armadilhas quando o limite máximo de tempo de entrada é atendido ou excedido.

  • jitter-exceeded— Gera armadilhas quando o jitter no limite de tempo de viagem de ida e volta é atendido ou excedido.

  • probe-failure— Gera armadilhas para sucessivos limites de perda de sondas cruzados.

  • rtt-exceeded— Gera armadilhas quando o limite máximo de tempo de viagem de ida e volta é cumprido ou excedido.

  • std-dev-exceeded— Gera armadilhas quando o limite de desvio padrão de ida e volta é cumprido ou excedido.

  • test-completion— Gera armadilhas quando um teste é concluído.

  • test-failure— Gera armadilhas quando o limite total de perda de sonda é atendido ou excedido.