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:

Lembre-se dos seguintes pontos ao configurar clientes RPM e servidores RPM:

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

• A partir do Junos OS Release 17.3R1, o RPM baseado em mecanismos baseado em PIC é suportado para túneis IPsec e túneis GRE se você estiver usando MS-MPCs ou MS-MICs. O RPM baseado em mecanismo de encaminhamento de pacotes não é compatível com túneis IPsec. O suporte de RPM em túneis IPSec permite o monitoramento de contrato de nível de serviço (SLA) para 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 sondagens geradas até 1 milhão por segundo em cada NPU de serviço em comparação com o número de sondagens 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 hierárquica [edit services rpm probe owner] . A interface-name.logical-unit-number especificação de 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 agregada de multisserviços (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 que deve combinar com o interface-name.logical-unit-number que você usou para.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 serviços de exibição resultados de sondagem rpm e mostrar serviços rpm comandos de resultados históricos 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 da CLI para testes de RPM para IPv4. A partir do Junos OS Release 18.2R1, você também pode otimizar a configuração da 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 sondagens 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:

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

  • O Junos OS lança 17.3R1 e posterior — 2000 para tipos de sondagem 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-sonda) — 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 delegados, as sondas RPM estão em conformidade com o RFC792 e RFC4443. Assim, eles podem ser usados para monitorar qualquer dispositivo IP compatível com RFC e podem responder a pacotes de temporizador de icmp e/ou icmp6-ping.

  Os testes são gerados primeiro para todos os endereços de origem com o endereço-alvo inicial e, em seguida, 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 de 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-alvo ou fonte 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	O valor incrementa a origem ou o endereço-alvo IPv4 para cada teste de RPM gerado.
  ipv6-step	O valor incrementa a origem ou o endereço-alvo IPv6 para cada teste de RPM gerado.
  ipv4-count	O número máximo de endereços de origem ou alvo IPv4 a serem usados para os testes de RPM gerados.
  ipv6-count	O número máximo de endereços de origem ou alvo IPv6 a serem usados 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 que é 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 em um. Assim que o número máximo de unidades lógicas tiver sido usado, o próximo 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 de sonda:

• Para especificar o proprietário de uma 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 gama 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 Mensagem 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 hexadácimal. A data-fill declaração não é válida com os http-get tipos de sondagem.http-metadata-get

• 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 onde o tamanho padrão é0. A data-size declaração não é válida com os http-get tipos de sondagem.http-metadata-get

  Nota:

  Se você configurar o recurso de data e hora do hardware (veja Configuração do tempo 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 data e hora do UDP é uma exceção; exige um tamanho mínimo de dados de 44 bytes.

  • Deve data-size ser pelo menos 100 bytes menores 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 de pacotes de sondagem RPM. Você especifica uma interface de sp para que o PIC de AS ou multisserviços adicione os tempos de hardware; para obter mais informações, veja Configuração do tempo de tempo de RPM em roteadores da Série MX, M, T e 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 de ida.

• Para especificar a porta do protocolo de datagrama do usuário (UDP) ou a porta de controle de transmissão (TCP) à 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 sondagem 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 do hardware, o valor para ele 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 de ida.

• Para especificar o valor do campo de Serviços diferenciados (DiffServ) dentro do cabeçalho de IP, inclua a dscp-code-point declaração no [edit services rpm probe owner test test-name] nível de 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 uma série de 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 segundos a 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 sondagem são suportados:

  • http-get— Envia um protocolo de transferência de hipertexto (HTTP) para receber uma URL-alvo.

  • http-metadata-get— Envia um pedido de metadados de HTTP para uma URL-alvo.

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

  • icmp-ping-timestamp— Envia solicitações de data e hora do ICMP para um endereço-alvo.

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

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

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

  Os tipos de sondagem a seguir suportam o tempo de tempo de hardware de pacotes de sonda: icmp-ping, , icmp-ping-timestamp, udp-ping. udp-ping-timestamp A partir do Junos OS Release 17.3R3, as sondas de delegado são distribuídas uniformemente por todo o intervalo de 3 segundos para evitar as explosões de pacotes na rede devido ao monitoramento de desempenho em tempo real (RPM). Os syslogs de RPM são processados com o aumento do tempo de ramp-up 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 sondagem 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 confirmação. 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 usa 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), incluem 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 de URL.

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

• Para especificar o tempo de espera entre 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 segundos a 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-fonte por sonda.

  • jitter-egress— Mede o jitter máximo de fonte a destino por teste.

  • jitter-ingress— Mede o jitter máximo de destino a 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 fonte a destino por teste.

  • std-dev-ingress— Mede o desvio padrão máximo de destino a fonte 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 sonda, indicando falha na sonda.

  • total-loss— Mede a contagem total de perdas de sonda que indica falha no teste, de 0 a 15. O padrão para este limite é de 1.

• As armadilhas são enviadas se o limiar configurado for cumprido ou excedido. Para definir 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 limite de tempo de saída é cumprido ou excedido.

  • egress-std-dev-exceeded— Gera armadilhas quando o limite de desvio padrão de tempo de saída é cumprido 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 é cumprido ou excedido.

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

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

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

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

  • rtt-exceeded— Gera armadilhas quando o limite máximo de tempo 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 é cumprido ou excedido.