Configuração de sondas RPM em roteadores da Série MX 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. Ao especificar 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 da [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.

• O RPM baseado em PIC e baseado em Mecanismo de Roteamento é suportado para túneis IPsec e túneis GRE se você estiver usando MS-MPCs ou MS-MICs. Mecanismo de Encaminhamento de Pacotes O RPM baseado em Mecanismo de Encaminhamento de Pacotes não é suportado para túneis IPsec. O suporte ao RPM em túneis IPSec permite o monitoramento do SLA (contrato de nível de serviço) para o tráfego transportado em túneis IPSec.

• 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. 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 no nível da [edit services rpm probe owner test test-name] hierarquia e inclua a delegate-probes instrução no nível da [edit services rpm probe owner] hierarquia. O interface-name.logical-unit-number especifica uma interface lógica em um slot MS-MPC ou MS-MIC, PIC e porta que tem um endereço IP válido definido nela (por exemplo, ms-1/2/1.1). A interface não pode ser uma interface multisserviços agregada (ams-).

  • Inclua as rpm client-delegate-probes instruções e as family (inet | inet6) address address no nível de [edit interfaces interface-name unit logical-unit-number] hierarquia. O interface-name e o logical-unit-number deve corresponder ao 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.

  Você pode usar filtros adicionais para limitar a saída dos comandos show services rpm probe-results e show services rpm history-results para sondas RPM geradas em um MS-MPC ou MS-MIC.

• 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 instruções de configuração de RPM mínimas para gerar vários testes (até 100 mil testes) com nomes de teste de RPM reservados e predefinidos. Essa otimização pode ser configurada para testes com sondas 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 destino, que são incrementados com base na sua configuração.

  O número máximo de sondas RPM simultâneas suportadas para várias versões do Junos é o seguinte:

  • Sem configurar a delegate-probes declaração — 2000 para os tipos de sonda ICMP e ICMP-timestamp. Para sondas de outros tipos (UDP e TCP), o limite é 500.

  • Com a configuração da delegate-probes declaração)— 1 milhão por serviço-NPU.

    Observação:

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

    Com a configuração da delegate-probes declaração, as sondas RPM são compatíveis com RFC792 e RFC4443. Portanto, eles podem ser usados para monitorar qualquer dispositivo IP compatível com RFC e são capazes de responder a pacotes icmp-timestamp e/ou icmp6-ping.

  Os testes são gerados primeiro para todos os endereços de origem com o endereço de destino inicial e, em seguida, os testes são gerados para todos os endereços de origem com o próximo endereço de destino disponível e assim por diante. Você também pode configurar um grupo que contenha valores globais para um proprietário de sondagem específico e aplicar o grupo ao proprietário da sondagem.

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

  As opções são:

  ipv4-address-base	O endereço de origem ou destino IPv4 que é incrementado para gerar os endereços usados nos testes de RPM.
  ipv6-address-base	O endereço de origem ou destino IPv6 que é incrementado para gerar os endereços usados nos testes de RPM.
  ipv4-step	A quantidade a ser incrementada no endereço de origem ou destino IPv4 para cada teste de RPM gerado.
  ipv6-step	A quantidade a ser incrementada no endereço de origem ou destino IPv6 para cada teste de RPM gerado.
  ipv4-count	O número máximo de endereços de origem ou destino IPv4 a serem usados para os testes de RPM gerados.
  ipv6-count	O número máximo de endereços de origem ou destino 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 da 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 interface-name.logical-unit-number opção, e cada teste sucessivo incrementa o número da unidade lógica em um. Uma vez que o número máximo de unidades lógicas tenha 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 serem gerados. Esse número deve ser menor ou igual ao número de endereços de origem gerados multiplicado pelo número de endereços de destino gerados.

  Para configurar um grupo com valores globais para um proprietário de sondagem específico:

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

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

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

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

  Observação:

  Se você configurar o recurso de carimbo de data e hora de hardware (veja a configuração do carimbo de data/hora de RPM em roteadores da Série PTX, M, T e PTX e switches da Série EX):

  • O data-size valor padrão é 32 bytes e 32 é o valor mínimo para configuração explícita. O tipo de sondagem de carimbo de data/hora UDP é uma exceção; Requer um tamanho mínimo de dados de 44 bytes.

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

• Nos roteadores da Série MX, você configura a declaração para habilitar o carimbo destination-interface de data e hora de hardware de pacotes de sondagem RPM. Você especifica uma interface sp- para que o AS ou o PIC multisserviços adicionem os carimbos de data/hora do hardware; para obter mais informações, consulte a configuração do carimbo de data/hora RPM em roteadores da Série PTX, M, T e PTX e switches da Série EX. Você também pode incluir a one-way-hardware-timestamp instrução para habilitar medições unidirecionais de atraso e jitter.

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

  Quando você configura um ou probe-type udp-ping probe-type udp-ping-timestamp junto com o carimbo de data/hora do hardware, o valor do destination-port pode ser de 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 um carimbo de data/hora de hardware unidirecional.

• Para especificar o valor do campo Serviços Diferenciados (DiffServ) no cabeçalho IP, inclua a dscp-code-point instrução no nível da [edit services rpm probe owner test test-name] hierarquia. O valor de bits do ponto de código DiffServ (DSCP) pode ser definido como um padrão válido de 6 bits; Por exemplo, 001111. Ele também pode ser definido usando um alias configurado no nível da [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 instrução no nível da [edit services rpm probe owner test test-name] hierarquia. Especifique um valor de 0 para 512. O padrão é 50.

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

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

• Para especificar o tempo de espera entre o envio de pacotes, inclua a probe-interval instrução no nível da [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 da [edit services rpm probe owner test test-name] hierarquia. Os seguintes tipos de sondagem são suportados:

  • http-get— Envia uma solicitação get HTTP (Hypertext Transfer Protocol) para uma URL de destino.

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

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

  • icmp-ping-timestamp— Envia solicitações de carimbo de data/hora ICMP para um endereço de destino.

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

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

  • udp-ping-timestamp— Envia solicitações de carimbo de data/hora UDP para um endereço de destino.

  Os seguintes tipos de sondagem oferecem suporte ao carimbo de data/hora de hardware de pacotes de sondagem: icmp-ping, icmp-ping-timestamp, udp-ping, udp-ping-timestamp. As sondas delegadas são distribuídas uniformemente em um intervalo de 3 segundos para evitar 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 aceleração dos testes de delegados de RPM para 60 segundos. Com os syslogs RPM processados, as chances de vários testes começarem e terminarem ao mesmo tempo são menores, portanto, uma restrição potencial no event-processing.

  Observação:

  Alguns tipos de sondagem exigem parâmetros adicionais para serem configurados. Por exemplo, ao especificar a tcp-ping opção or udp-ping , você deve configurar a porta de destino usando a destination-port declaração. A udp-ping-timestamp opção 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 sondagem TCP é 1.

  Quando você configura um ou probe-type udp-ping probe-type udp-ping-timestamp junto com o one-way-hardware-timestamp comando, o valor do 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 por 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 de roteamento da inet.0Internet.

• Para especificar o endereço IP de origem usado para sondas ICMP, inclua a source-address declaração no nível da [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 ao roteador, o pacote usará o endereço da interface de saída como sua origem.

• Para especificar o endereço IPv6 de origem a ser usado para sondas RPM 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 no nível de [edit services rpm probe owner test test-name] hierarquia. Se o endereço IPv6 de origem não for um dos endereços atribuídos do roteador ou switch, o pacote usará o endereço da interface de saída como sua origem.

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

  • Para tipos de sondagem HTTP, especifique uma URL totalmente formada que inclua http:// o 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) para o host de destino.

• Para especificar o tempo de espera entre os testes, inclua a test-interval instrução no nível da [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 instrução no nível da [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 interceptação SNMP (se configurada) é gerada quando um limite é excedido. Há suporte para as seguintes opções:

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

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

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

  • jitter-ingress— Mede o jitter máximo de destino à origem por teste.

  • jitter-rtt— Mede o jitter máximo por teste, de 0 a 60000000 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 da 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 de perda de sonda sucessiva, indicando falha de sonda.

  • total-loss— Mede a contagem total de perda de sonda indicando falha no teste, de 0 a 15. O padrão para esse limite é 1.

• As armadilhas são enviadas se o limite configurado for atingido ou excedido. Para definir o bit de interceptação para gerar armadilhas, inclua a traps instrução no nível da [edit services rpm probe owner test test-name] hierarquia. Há suporte para as seguintes opções:

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

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

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

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

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

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

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

  • probe-failure— Gera armadilhas para limites sucessivos de perda de sonda ultrapassados.

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

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

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

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