Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configure operações remotas de SNMP

Visão geral das operações remotas do SNMP

Uma operação remota de SNMP é qualquer processo no roteador que pode ser controlado remotamente usando SNMP. Atualmente, o Junos OS oferece suporte para duas operações remotas de SNMP: O Ping MIB e o Traceroute MIB, definidos na RFC 2925. Usando esses MIBs, um cliente SNMP no sistema de gerenciamento de rede (NMS) pode:

  • Inicie uma série de operações em um roteador

  • Receba a notificação quando as operações estiverem concluídas

  • Reúna os resultados de cada operação

O Junos OS também oferece funcionalidade estendida a esses MIBs nas extensões específicas jnxPingMIB da Juniper Networks e jnxTraceRouteMIB. Para obter mais informações sobre jnxPingMIB e jnxTraceRouteMIB, veja PING MIB e Traceroute MIB.

Este tópico abrange as seguintes seções:

Requisitos de operação remota de SNMP

Para usar operações remotas de SNMP, você deve ter experiência com convenções de SNMP. Você também deve configurar o Junos OS para permitir o uso das MIBs de operação remota.

Antes de iniciar o Ping MIB, consulte Iniciar um teste de ping.

Antes de iniciar o Traceroute MIB, consulte Iniciar um teste de traceroute.

Definir visualizações de SNMP

Todos os MIBs de operação remota suportados pelo Junos OS exigem que os clientes SNMP tenham privilégios de leitura. A configuração SNMP padrão do Junos OS não oferece aos clientes uma cadeia de comunidade com esses privilégios.

Para definir privilégios de leitura para uma cadeia de comunidade SNMP, inclua as seguintes declarações no nível hierárquicos [edit snmp] :

Exemplo: Definir visualizações de SNMP

Para criar uma comunidade nomeada remote-community que concede aos clientes SNMP acesso a leitura de texto ao Ping MIB, jnxPing MIB, Traceroute MIB e jnxTraceRoute MIB, inclua as seguintes declarações no nível de [edit snmp] hierarquia:

Para obter mais informações sobre a community declaração, veja Configure comunidades SNMP e a comunidade (SNMP).

Para obter mais informações sobre a view declaração, consulte Configure visualizações do MIB, visualize (Comunidade SNMP) e visualize (Configurando uma visualização do MIB).

Definir notificação de armadilhas para operações remotas

Além de configurar o MIB de operações remotas para notificação de armadilhas, você também deve configurar o Junos OS. Você deve especificar um host alvo para armadilhas de operações remotas.

Para configurar a notificação de armadilhas para operações remotas SNMP, inclua o e targets as categories declarações no nível de [edit snmp trap-group group-name] hierarquia:

Exemplo: Definir notificação de armadilhas para operações remotas

Especifique 172.17.12.213 como um host-alvo para todas as armadilhas de operação remotas:

Para obter mais informações sobre grupos de armadilhas, veja Configure grupos de armadilhas SNMP.

Use índices de cordas de comprimento variável

Todos os objetos tabulares nas MIBs de operações remotas suportados pelo Junos OS são indexados por duas variáveis de tipo SnmpAdminString. Para obter mais informações sobre SnmpAdminString, veja RFC 2571.

O Junos OS não lida de SnmpAdminString maneira diferente do tipo variável de string de octet. No entanto, os índices são definidos como comprimento variável. Quando uma corda de comprimento variável é usada como um índice, o comprimento da corda deve ser incluído como parte do identificador de objetos (OID).

Exemplo: Definir índices de cordas de comprimento variável

Para fazer referência à pingCtlTargetAddress variável de uma linha em pingCtlTable onde pingCtlOwnerIndex está bob e pingCtlTestName está test, use o seguinte identificador de objetos (OID):

Para obter mais informações sobre a definição do Ping MIB, consulte RFC 2925.

Habilite o registro

O código de erro SNMP devolvido em resposta a solicitações de SNMP só pode fornecer uma descrição genérica do problema. As descrições de erro registradas pelo processo de operações remotas podem muitas vezes fornecer informações mais detalhadas sobre o problema e ajudá-lo a resolver o problema mais rapidamente. Esse registro não é habilitado por padrão. Para habilitar o registro, inclua a flag general declaração no nível de [edit snmp traceoptions] hierarquia:

Se o processo de operações remotas receber uma solicitação SNMP que não possa acomodar, o erro será registrado no /var/log/rmopd arquivo. Para monitorar este arquivo de log, emita o monitor start rmopd comando no modo operacional da interface de linha de comando (CLI).

Use o Ping MIB para dispositivos de monitoramento remoto que executam o Junos OS

Um teste de ping é usado para determinar se os pacotes enviados do host local chegam ao host designado e são devolvidos. Se o host designado puder ser alcançado, o teste de ping fornece o tempo aproximado de ida e volta para os pacotes. Os resultados dos testes de ping são armazenados pingResultsTable e pingProbeHistoryTable.

RFC 2925 é a descrição autoritária do Ping MIB em detalhes e fornece a definição ASN.1 MIB do Ping MIB.

Inicie um teste de ping

Use este tópico para lançar um teste de ping ICMP. Existem duas maneiras de iniciar um teste de ping: usando várias unidades de dados de protocolo definidas (PDUs) ou usando uma única PDU definida.

Antes de começar

Antes de iniciar um teste de ping, configure uma visualização de Ping MIB. Isso permite solicitações de SNMPSet.pingMIB Para obter mais informações, veja Configure visualizações do MIB.

A partir do Junos OS Release 17.2X75-D100, você deve configurar RPM antes de iniciar um ping de ICMP. Configure o RPM usando o edit services rpm comando.

Inicie um teste de ping

Para iniciar um teste de ping, crie uma linha pingCtlTable e configure pingCtlAdminStatus para enabled. As informações mínimas que devem ser especificadas antes da configuração pingCtlAdminStatusenabled são:

  • pingCtlOwnerIndexSnmpAdminString

  • pingCtlTestNameSnmpAdminString

  • pingCtlTargetAddressInetAddress

  • pingCtlTargetAddressTypeInetAddressType

  • pingCtlRowStatusRowStatus

Para todos os outros valores, os padrões são escolhidos a menos que especificado de outra forma. pingCtlOwnerIndex e pingCtlTestName são usados como índice, de modo que seus valores são especificados como parte do identificador de objetos (OID). Para criar uma linha, definir pingCtlRowStatus ou createAndWaitcreateAndGo em uma linha que ainda não existe. Um valor para activepingCtlRowStatus indica que todas as informações necessárias foram fornecidas e que o teste pode começar; pingCtlAdminStatus pode ser definido para enabled. Uma solicitação de SNMP Set que se define pingCtlRowStatus para active falhará se as informações necessárias na linha não forem especificadas ou forem inconsistentes.

Para obter informações sobre como configurar uma visualização, veja Configuração de visualizações de SNMP.

Leia as seções a seguir sobre como solicitar as variáveis.

Use várias PDUs definidas

Você pode usar várias Set PDUs de solicitação (várias PDUs, com uma ou mais varbindas cada) e definir as seguintes variáveis nesta ordem para iniciar o teste:

  • pingCtlRowStatus Para createAndWait

  • Todas as variáveis de teste apropriadas

  • pingCtlRowStatus Para active

    O Junos OS verifica agora que todas as informações necessárias para realizar um teste foram especificadas.

  • pingCtlAdminStatus Para enabled

Use uma PDU de conjunto único

Você pode usar uma única Set PDU de solicitação (uma PDU, com várias varbindas) para definir as seguintes variáveis para iniciar o teste:

  • pingCtlRowStatus Para createAndGo

  • Todas as variáveis de teste apropriadas

  • pingCtlAdminStatus Para enabled

Monitore um teste de ping em execução

Quando pingCtlAdminStatus for definido com enabledsucesso, o seguinte é feito antes que o reconhecimento da solicitação de SNMP Set seja enviado de volta ao cliente:

  • pingResultsEntry é criado se ainda não existir.

  • pingResultsOperStatus transições para enabled.

Para obter mais informações, veja as seguintes seções:

pingResultsTable

Enquanto o teste estiver sendo executado, pingResultsEntry mantenha o controle da situação do teste. O valor é pingResultsOperStatusenabled enquanto o teste está sendo executado e disabled quando ele parou.

O valor dos pingCtlAdminStatus restos mortais enabled até você configurá-lo.disabled Assim, para obter a situação do teste, você deve examinar pingResultsOperStatus.

A pingCtlFrequency variável pode ser usada para agendar muitos testes para um pingCtlEntry. Depois que um teste termina normalmente (você não interrompeu o teste) e o pingCtlFrequency número de segundos se passou, o teste é iniciado novamente como se você tivesse definido pingCtlAdminStatus para enabled. Se você intervir a qualquer momento entre testes repetidos (você definir pingCtlAdminStatusdisabled para ou pingCtlRowStatus para notInService), o recurso de repetição é desativado até que outro teste seja iniciado e termine normalmente. Um valor de 0 para pingCtlFrequency indica que esse recurso repetido não está ativo.

pingResultsIpTgtAddr e pingResultsIpTgtAddrType estão definidos para o valor do endereço de destino resolvido quando o valor pingCtlTargetAddressType é dns. Quando um teste começa com sucesso e pingResultsOperStatus faz a transição para enabled:

  • pingResultsIpTgtAddr está definido para null-string.

  • pingResultsIpTgtAddrType está definido para unknown.

pingResultsIpTgtAddr e pingResultsIpTgtAddrType não são definidos até pingCtlTargetAddress que possa ser resolvido em um endereço numérico. Para recuperar esses valores, pesquisar pingResultsIpTgtAddrType por qualquer valor que não seja depois de unknown definir pingCtlAdminStatusenabledcom sucesso.

No início de um teste, pingResultsSentProbes é inicializada para 1 e a primeira sonda é enviada. pingResultsSentProbes Aumenta em 1 cada vez que uma sonda é enviada.

Conforme o teste é executado, a cada pingCtlTimeOut segundo, ocorre o seguinte:

  • pingProbeHistoryStatus para os correspondentes pingProbeHistoryEntry está pingProbeHistoryTable definido para requestTimedOut.

  • Uma pingProbeFailed armadilha é gerada, se necessário.

  • Uma tentativa é enviar a próxima sonda.

    Nota:

    Não existe mais do que uma sonda excepcional para cada teste.

Para cada sondagem, você pode receber um dos seguintes resultados:

  • O host alvo reconhece a sonda com uma resposta.

  • Os tempos de sondagem foram esgotados; não há resposta do host alvo reconhecendo a sonda.

  • A sonda não pôde ser enviada.

Cada resultado da sonda é registrado em pingProbeHistoryTable. Para obter mais informações sobre pingProbeHistoryTable, veja pingProbeHistoryTable.

Quando uma resposta é recebida do host alvo, reconhecendo a sonda atual:

  • pingResultsProbeResponses aumenta em 1.

  • As variáveis a seguir são atualizadas:

    • pingResultsMinRtt— Tempo mínimo de ida e volta

    • pingResultsMaxRtt— Tempo máximo de ida e volta

    • pingResultsAverageRtt— Tempo médio de ida e volta

    • pingResultsRttSumOfSquares— Soma de praças de tempos de ida e volta

    • pingResultsLastGoodProbe— Tempor da última resposta

      Nota:

      Apenas sondagens que resultam em uma resposta do host alvo contribuem para o cálculo das variáveis de tempo de viagem de ida e volta (RTT).

Quando uma resposta à última sonda é recebida ou a última sonda é cronometrada, o teste é concluído.

pingProbeHistoryTable

Uma entrada (pingProbeHistoryTablepingProbeHistoryEntry) representa um resultado de sonda e é indexada por três variáveis:

  • As duas primeiras pingCtlOwnerIndex variáveis e pingCtlTestName, são as mesmas usadas, pingCtlTableque identificam o teste.

  • A terceira variável é pingProbeHistoryIndexum contador para identificar com exclusividade cada resultado da sonda.

O número máximo de pingProbeHistoryTable entradas criadas para um determinado teste é limitado por pingCtlMaxRows. Se pingCtlMaxRows for definido para 0, não pingProbeHistoryTable serão criadas entradas para esse teste.

Cada vez que um resultado da sonda é determinado, um pingProbeHistoryEntry é criado e adicionado a pingProbeHistoryTable. pingProbeHistoryIndex do novo pingProbeHistoryEntry é 1 maior do que o último pingProbeHistoryEntry adicionado para pingProbeHistoryTable esse teste é pingProbeHistoryIndex definido para 1 se esta for a primeira entrada na tabela. O mesmo teste pode ser executado várias vezes, de modo que esse índice continua crescendo.

Se pingProbeHistoryIndex o último pingProbeHistoryEntry adicionado for 0xFFFFFFFF, o próximo pingProbeHistoryEntry adicionado está pingProbeHistoryIndex definido para 1.

Os seguintes são registrados para cada resultado da sonda:

  • pingProbeHistoryResponse— Hora de viver (TTL)

  • pingProbeHistoryStatus— O que aconteceu e por que

  • pingProbeHistoryLastRC— Valor do código de devolução (RC) do pacote ICMP

  • pingProbeHistoryTime— Temporidade em que o resultado da sonda foi determinado

Quando uma sonda não pode ser enviada, pingProbeHistoryResponse está configurada para 0. Quando uma sonda é cronometrada, pingProbeHistoryResponse é definida para a diferença entre o tempo em que a sonda foi descoberta a ser cronometrada e o momento em que a sonda foi enviada.

Gerar armadilhas

Para que qualquer armadilha seja gerada, a parte pingCtlTrapGeneration apropriada deve ser definida. Você também deve configurar um grupo de armadilhas para receber operações remotas. Uma armadilha é gerada sob as seguintes condições:

  • Uma pingProbeFailed armadilha é gerada sempre que pingCtlTrapProbeFailureFilter o número de sondas consecutivas falha durante o teste.

  • Uma pingTestFailed armadilha é gerada quando o teste é concluído e pelo menos pingCtlTrapTestFailureFilter o número de sondas falha.

  • Uma pingTestCompleted armadilha é gerada quando o teste é concluído e menos do que pingCtlTrapTestFailureFilter as sondas falham.

    Nota:

    Uma sonda é considerada uma falha quando pingProbeHistoryStatus o resultado da sonda é algo além responseReceived.

Para obter informações sobre como configurar um grupo de armadilhas para receber operações remotas, veja Configuração de grupos de armadilhas SNMP e exemplo: Configurando a notificação de armadilhas para operações remotas.

Reúna os resultados dos testes de ping

Você pode fazer uma pesquisa pingResultsOperStatus para descobrir quando o teste está concluído ou solicitar que uma armadilha seja enviada quando o teste estiver concluído. Para obter mais informações sobre pingResultsOperStatus, consulte pingResultsTable. Para obter mais informações sobre as armadilhas ping MIB, veja Gerando armadilhas.

As estatísticas calculadas e armazenadas em pingResultsTable seguida incluem:

  • pingResultsMinRtt— Tempo mínimo de ida e volta

  • pingResultsMaxRtt— Tempo máximo de ida e volta

  • pingResultsAverageRtt— Tempo médio de ida e volta

  • pingResultsProbeResponses— Número de respostas recebidas

  • pingResultsSentProbes— Número de tentativas de enviar sondagens

  • pingResultsRttSumOfSquares— Soma de praças de tempos de ida e volta

  • pingResultsLastGoodProbe— Tempor da última resposta

Você também pode consultar pingProbeHistoryTable informações mais detalhadas sobre cada sonda. O índice usado para pingProbeHistoryTable começa em 1, vai para 0xFFFFFFFF e termina em 1 novamente.

Por exemplo, se pingCtlProbeCount tiver 15 anos e pingCtlMaxRows tiver 5, então após a conclusão da primeira execução deste teste, pingProbeHistoryTable contém sondagens como as de Tabela 1.

Tabela 1: Resultados em pingProbeHistoryTable: Após o primeiro teste de ping

pingProbeHistoryIndex

Resultado da sondagem

11

Resultado da 11ª sonda da corrida 1

12

Resultado da 12ª sonda da corrida 1

13

Resultado da 13ª sonda da corrida 1

14

Resultado da 14ª sonda da corrida 1

15

Resultado da 15ª sonda da corrida 1

Após a conclusão da primeira sonda da segunda corrida deste teste, pingProbeHistoryTable conterá sondas como as de Tabela 2.

Tabela 2: Resultados em pingProbeHistoryTable: Após a primeira sonda do segundo teste

pingProbeHistoryIndex

Resultado da sondagem

12

Resultado da 12ª sonda da corrida 1

13

Resultado da 13ª sonda da corrida 1

14

Resultado da 14ª sonda da corrida 1

15

Resultado da 15ª sonda da corrida 1

16

Resultado da 1ª sonda da corrida 2

Após a conclusão da segunda execução deste teste, pingProbeHistoryTable conterá sondagens como as de Tabela 3.

Tabela 3: Resultados em pingProbeHistoryTable: Após o segundo teste de ping

pingProbeHistoryIndex

Resultado da sondagem

26

Resultado da 11ª sonda da corrida 2

27

Resultado da 12ª sonda da corrida 2

28

Resultado da 13ª sonda da corrida 2

29

Resultado da 14ª sonda da corrida 2

30

Resultado da 15ª sonda da corrida 2

As entradas de histórico podem ser excluídas do MIB de duas maneiras:

  • Mais inscrições de histórico para um determinado teste são adicionadas e o número de inscrições de histórico excede pingCtlMaxRows. As entradas de histórico mais antigas são excluídas para abrir espaço para as novas.

  • Você exclui todo o teste configurando pingCtlRowStatus para destroy.

Pare um teste de ping

Para interromper um teste ativo, definir pingCtlAdminStatus para disabled. Para interromper o teste e remover seu pingCtlEntry, pingResultsEntrye quaisquer pingHistoryEntry objetos do MIB, definido pingCtlRowStatus para destroy.

Interpretar variáveis de ping

Esta seção esclarece as faixas para as seguintes variáveis que não estão explicitamente especificadas no Ping MIB:

  • pingCtlDataSize— O valor dessa variável representa o tamanho total da carga (em bytes) de um pacote de sondagem de saída. Essa carga inclui o data-tempo (8 bytes) usado para cronometrar a sonda. Isso é consistente com a definição de pingCtlDataSize (valor máximo de 65.507) e o aplicativo padrão de ping.

    Se o valor pingCtlDataSize estiver entre 0 e 8 inclusive, ele é ignorado e a carga útil é de 8 bytes (o temporizador). O Ping MIB pressupõe que todas as sondas sejam cronometradas, de modo que a carga deve sempre incluir o temporizantes.

    Por exemplo, se você deseja adicionar 4 bytes adicionais de carga ao pacote, você deve definir pingCtlDataSize para 12.

  • pingCtlDataFill— Os primeiros 8 bytes do segmento de dados do pacote são para o data-tempo. Depois disso, o pingCtlDataFill padrão é usado em repetição. O padrão padrão (quando pingCtlDataFill não é especificado) é (00, 01, 02, 03 ... FF, 00, 01, 02, 03 ... FF, ...).

  • pingCtlMaxRows— O valor máximo é de 255.

  • pingMaxConcurrentRequests— O valor máximo é de 500.

  • pingCtlTrapProbeFailureFilter e pingCtlTrapTestFailureFilter— Um valor de 0 para pingCtlTrapProbeFailureFilter ou pingCtlTrapTestFailureFilter não é bem definido pelo Ping MIB. Se pingCtlTrapProbeFailureFilter for 0, pingProbeFailed as armadilhas não serão geradas para o teste em nenhuma circunstância. Se pingCtlTrapTestFailureFilter for 0, pingTestFailed as armadilhas não serão geradas para o teste em nenhuma circunstância.

Use o Traceroute MIB para dispositivos de monitoramento remoto que executam o Junos OS

Um teste de traceroute aproxima o caminho que os pacotes fazem do host local até o host remoto.

RFC 2925 é a descrição autoritária do Traceroute MIB em detalhes e fornece a definição ASN.1 MIB do Traceroute MIB.

Inicie um teste de traceroute

Antes de iniciar um teste de traceroute, configure uma visão Traceroute MIB. Isso permite solicitações de SNMPSet.tracerouteMIB Para iniciar um teste, crie uma linha traceRouteCtlTable e configure traceRouteCtlAdminStatus para enabled. Você deve especificar pelo menos o seguinte antes de definirtraceRouteCtlAdminStatus:enabled

  • traceRouteCtlOwnerIndexSnmpAdminString

  • traceRouteCtlTestNameSnmpAdminString

  • traceRouteCtlTargetAddressInetAddress

  • traceRouteCtlRowStatusRowStatus

Para todos os outros valores, os padrões são escolhidos a menos que especificado de outra forma. traceRouteCtlOwnerIndex e traceRouteCtlTestName são usados como índice, de modo que seus valores são especificados como parte da OID. Para criar uma linha, definir traceRouteCtlRowStatus ou createAndWaitcreateAndGo em uma linha que ainda não existe. Um valor para activetraceRouteCtlRowStatus indica que todas as informações necessárias foram especificadas e que o teste pode começar; traceRouteCtlAdminStatus pode ser definido para enabled. Uma solicitação de SNMP Set que se define traceRouteCtlRowStatus para active falhará se as informações necessárias na linha não forem especificadas ou forem inconsistentes. Para obter informações sobre como configurar uma visualização, veja Configuração de visualizações de SNMP.

Existem duas maneiras de iniciar um teste de traceroute:

Use várias PDUs definidas

Você pode usar várias Set PDUs de solicitação (várias PDUs, com uma ou mais varbindas cada) e definir as seguintes variáveis nesta ordem para iniciar o teste:

  • traceRouteCtlRowStatus para criar oAndWait

  • Todas as variáveis de teste apropriadas

  • traceRouteCtlRowStatus Para active

    O Junos OS verifica agora que todas as informações necessárias para realizar um teste foram especificadas.

  • traceRouteCtlAdminStatus Para enabled

Use uma PDU de conjunto único

Você pode usar uma única Set PDU de solicitação (uma PDU, com várias varbindas) para definir as seguintes variáveis para iniciar o teste:

  • traceRouteCtlRowStatus Para createAndGo

  • Todas as variáveis de teste apropriadas

  • traceRouteCtlAdminStatus habilitado

Monitore um teste de traceroute em execução

Quando o traceRouteCtlAdminStatus é definido com sucesso para habilitação, o seguinte é feito antes que o reconhecimento da solicitação do SNMP Set seja enviado de volta ao cliente:

  • traceRouteResultsEntry é criado se ainda não existir.

  • traceRouteResultsOperStatus para habilitado.

Para obter mais informações, veja as seguintes seções:

traceRouteResultsTable

Enquanto o teste está sendo executado, este traceRouteResultsTable mantém o controle da situação do teste. O valor do traceRouteResultsOperStatus é habilitado enquanto o teste está sendo executado e desativado quando ele é interrompido.

O valor do traceRouteCtlAdminStatus permanece habilitado até que você o configure para desabilitado. Assim, para obter a situação do teste, você deve examinar traceRouteResultsOperStatus.

A variável traceRouteCtlFrequency pode ser usada para agendar muitos testes para um traceRouteCtlEntry. Depois que um teste termina normalmente (você não interrompeu o teste) e o número de segundos de traceRouteCtlFrequency se passou, o teste é iniciado novamente como se você tivesse definido traceRouteCtlAdminStatus para habilitado. Se você intervir a qualquer momento entre testes repetidos (você definir traceRouteCtlAdminStatus para desativado ou rastrearRouteCtlRowStatus para nãoInService), o recurso de repetição é desativado até que outro teste seja iniciado e termine normalmente. Um valor de 0 para traceRouteCtlFrequency indica que esse recurso de repetição não está ativo.

traceRouteResultsIpTgtAddr e traceRouteResultsIpTgtAddrGet são definidos para o valor do endereço de destino resolvido quando o valor do traceRouteCtlTargetAddressOtipado é dns. Quando um teste começa com sucesso e traceRouteResultsOperStatus faz a transição para habilitar:

  • traceRouteResultsIpTgtAddr está definido para anular as cordas.

  • traceRouteResultsIpTgtAddrÓtipo é definido como desconhecido.

traceRouteResultsIpTgtAddr e traceRouteResultsIpTgtAddrGet não são definidos até que o traceRouteCtlTargetAddress possa ser resolvido em um endereço numérico. Para recuperar esses valores, a pesquisa rastreie oRouteResultsIpTgtAddrType para qualquer valor que não seja desconhecido depois de definir com sucesso o traceRouteCtlAdminStatus para habilitado.

No início de um teste, traceRouteResultsCurHopCount é inicializado para rastrearRouteCtlInitialTtl, e traceRouteResultsCurProbeCount é inicializado para 1. Cada vez que um resultado da sonda é determinado, traceRouteResultsCurProbeCount aumenta em 1. Enquanto o teste está sendo executado, o valor do traceRouteResultsCurProbeCount reflete a sonda pendente atual para a qual os resultados ainda não foram determinados.

O número de sondas TraceRouteCtlProbesPerHop é enviado para cada valor de tempo de vida (TTL). Quando o resultado da última sonda para o salto atual é determinado, desde que o salto atual não seja o salto de destino, traceRouteResultsCurHopCount aumenta em 1 e traceRouteResultsCurProbeCount resets para 1.

No início de um teste, se esta é a primeira vez que este teste é executado para este traceRouteCtlEntry, traceRouteResultsTestAttempts e traceRouteResultsTestSuccesses são inicializados para 0.

Ao final de cada execução de teste, traceRouteResultsOperStatus faz a transição para desativado, e traceRouteResultsTestAttempts aumenta em 1. Se o teste tiver sido bem-sucedido na determinação de todo o caminho até o alvo, traceRouteResultsTestSuccesses aumenta em 1, e traceRouteResultsLastGoodPath está definido para o momento atual.

traceRouteProbeResultsTable

Cada entrada no traceRouteProbeHistoryTable é indexada por cinco variáveis:

  • As duas primeiras variáveis, traceRouteCtlOwnerIndex e traceRouteCtlTestName, são as mesmas usadas para traceRouteCtlTable e para identificar o teste.

  • A terceira variável, traceRouteProbeHistoryIndex, é um contador, a partir de 1 e embrulho no FFFFFF. O número máximo de entradas é limitado por traceRouteCtlMaxRows.

  • A quarta variável, traceRouteProbeHistoryHopIndex, indica para qual salto esta sonda é (o tempo real de vida ou valor TTL). Assim, o primeiro traceRouteCtlProbesPerHop número de entradas criadas quando um teste começa tem um valor de traceRouteCtlInitialTtl para traceRouteProbeHistoryHopIndex.

  • A quinta variável, traceRouteProbeHistoryProbeIndex, é a sonda para o salto atual. Ela varia de 1 a traceRouteCtlProbesPerHop.

Enquanto um teste é executado, assim que o resultado da sonda é determinado, a próxima sonda é enviada. Um máximo de traceRouteCtlTimeOut se passa antes que uma sonda seja marcada com solicitação de statusTimedOut e a próxima sonda é enviada. Nunca há mais de uma sonda excepcional por teste de traceroute. Qualquer resultado da sonda que volta após um tempo de sonda é ignorado.

Cada sonda pode:

  • Resulte em uma resposta de um host reconhecendo a sonda

  • Tempo fora sem resposta de um host reconhecendo a sonda

  • Não ser enviado

Cada status da sonda é registrado no traceRouteProbeHistoryTable com traceRouteProbeHistoryStatus definido de acordo.

Sondagens que resultam em uma resposta de um host registram os seguintes dados:

  • traceRouteProbeHistoryResponse — Tempo de ida e volta (RTT)

  • traceRouteProbeHistoryHAddrType — O tipo de HAddr (próximo argumento)

  • traceRouteProbeHistoryHAddr — O endereço do salto

Todas as sondas, independentemente de uma resposta para a sonda ser recebida, registraram o seguinte:

  • traceRouteProbeHistoryStatus — O que aconteceu e por que

  • traceRouteProbeHistoryLastRC — Valor do código de devolução (RC) do pacote ICMP

  • traceRouteProbeHistoryTime — Tempo em que o resultado da sonda foi determinado

Quando uma sonda não pode ser enviada, traceRouteProbeHistoryResponse é definido como 0. Quando uma sonda é enviada, traceRouteProbeHistoryResponse é definido para a diferença entre o tempo em que a sonda foi descoberta a ser cronometrada e o tempo em que a sonda foi enviada.

traceRouteHopsTable

As entradas no traceRouteHopsTable são indexadas por três variáveis:

  • Os dois primeiros, traceRouteCtlOwnerIndex e traceRouteCtlTestName, são os mesmos usados para traceRouteCtlTable e identificam o teste.

  • A terceira variável, traceRouteHopsHopIndex, indica o salto atual, que começa em 1 (não traceRouteCtlInitialTtl).

Quando um teste começa, todas as entradas no traceRouteHopsTable com o traceRouteCtlOwnerIndex e traceRouteCtlTestName são excluídas. As entradas nesta tabela só serão criadas se o traceRouteCtlCreateHopsEntries for definido como verdadeiro.

Um novo traceRouteHopsEntry é criado cada vez que o resultado da primeira sonda para um determinado TTL é determinado. A nova entrada é criada se a primeira sonda chega ou não a um host. O valor do traceRouteHopsHopIndex é aumentado em 1 para esta nova entrada.

Nota:

Qualquer traceRouteHopsEntry pode não ter valor para traceRouteHopsIpTgtAddress se não houver respostas às sondas com o TTL dado.

Cada vez que uma sonda chega a um host, o endereço IP desse host está disponível no resultado da sonda. Se o valor do traceRouteHopsIpTgtAddress do traceRouteHopsEntry atual não estiver definido, então o valor do traceRouteHopsIpTgtAddress está definido para este endereço IP. Se o valor do traceRouteHopsIpTgtAddress do traceRouteHopsEntry atual for o mesmo que o endereço IP, então o valor não mudará. Se o valor do traceRouteHopsIpTgtAddress do trace AtualRouteHopsEntry for diferente deste endereço IP, indicando uma mudança de caminho, um novo traceRouteHopsEntry é criado com:

  • traceRouteHopsHopIndex aumentou em 1

  • traceRouteHopsIpTgtAddress definido para o endereço IP

    Nota:

    Uma nova entrada para um teste é adicionada ao traceRouteHopsTable cada vez que um novo valor de TTL é usado ou o caminho muda. Assim, o número de entradas para um teste pode exceder o número de diferentes valores de TTL usados.

Quando um resultado da sonda é determinado, o rastreamento de valorRouteHopsSentProbes do tracerouteHopsEntry atual aumenta em 1. Quando um resultado da sonda é determinado, e a sonda chega a um host:

  • O trace de valorRouteHopsProbeResponses do trace atualRouteHopsEntry é aumentado em 1.

  • As variáveis a seguir são atualizadas:

    • traceRouteResultsMinRtt — Tempo mínimo de ida e volta

    • traceRouteResultsMaxRtt — Tempo máximo de ida e volta

    • traceRouteResultsAverageRtt — Tempo médio de ida e volta

    • traceRouteResultsRttSumOfSquares — Soma de quadrados de tempos de ida e volta

    • traceRouteResultsLastGoodProbe — data temporal da última resposta

      Nota:

      Apenas as sondagens que chegam a um host afetam os valores de tempo de viagem de ida e volta.

Gerar armadilhas

Para gerar qualquer armadilha, um pouco apropriado de traceRouteCtlTrapGeneration deve ser definido. Você também deve configurar um grupo de armadilhas para receber operações remotas. As armadilhas são geradas sob as seguintes condições:

  • traceRouteHopsIpTgtAddress da sonda atual é diferente da última sonda com o mesmo valor de TTL (traceRoutePathChange).

  • Um caminho para o alvo não pôde ser determinado (traceRouteTestFailed).

Um caminho para o alvo foi determinado (traceRouteTestCompleted).

Para obter informações sobre como configurar um grupo de armadilhas para receber operações remotas, veja a configuração de grupos de armadilhas SNMP e uma visão geral das operações remotas de SNMP.

Monitore a conclusão do teste de traceroute

Quando um teste é concluído, traceRouteResultsOperStatus faz a transição para enableddisabled. Essa transição ocorre nas seguintes situações:

  • O teste termina com sucesso. Um resultado da sonda indica que o destino foi alcançado. Neste caso, o salto atual é o último salto. As demais sondas para este salto são enviadas. Quando o último resultado da sonda para o salto atual é determinado, o teste termina.

  • traceRouteCtlMaxTtl limite é excedido. O destino nunca é alcançado. O teste termina após o número de sondas com valor TTL igual a traceRouteCtlMaxttl ter sido enviado.

  • traceRouteCtlMaxFailures limite é excedido. O número de sondagens consecutivas que terminam com o status requestTimedOut excede traceRouteCtlMaxFailures.

  • Você termina o teste. Você define traceRouteCtlAdminStatusdisabled ou exclui a linha configurando traceRouteCtlRowStatus para destroy.

  • Você confundiu mal o teste de traceroute. Um valor ou variável especificado traceRouteCtlTable por você é incorreto e não permitirá que uma única sonda seja enviada. Devido à natureza dos dados, esse erro não pôde ser determinado até o início do teste; ou seja, até depois traceRouteResultsOperStatus da transição para enabled. Quando isso ocorre, uma entrada é adicionada traceRouteProbeHistoryTable com traceRouteProbeHistoryStatus conjunto ao código de erro apropriado.

Se traceRouteCtlTrapGeneration estiver configurado corretamente, a armadilha ou traceRouteTestCompleted a traceRouteTestFailed armadilha são geradas.

Reúna os resultados dos testes de traceroute

Você pode pesquisar traceRouteResultsOperStatus para descobrir quando o teste está concluído ou solicitar que uma armadilha seja enviada quando o teste estiver concluído. Para obter mais informações sobre traceResultsOperStatus, consulte traceRouteResultsTable. Para obter mais informações sobre as armadilhas Traceroute MIB, veja a seção Gerando armadilhas no monitoramento de um teste de traceroute em execução.

As estatísticas são calculadas por salto e depois armazenadas no traceRouteHopsTable. Eles incluem o seguinte para cada salto:

  • traceRouteHopsIpTgtAddressOtipamento — Atenda o tipo de host neste salto

  • traceRouteHopsIpTgtAddress — Endereço do host neste salto

  • traceRouteHopsMinRtt — Tempo mínimo de ida e volta

  • traceRouteHopsMaxRtt — Tempo máximo de ida e volta

  • traceRouteHopsAverageRtt — Tempo médio de ida e volta

  • traceRouteHopsRttSumOfSquares — Soma de quadrados de tempos de ida e volta

  • traceRouteHopsSentProbes — Número de tentativas de enviar sondagens

  • traceRouteHopsProbeResponses — Número de respostas recebidas

  • traceRouteHopsLastGoodProbe — data temporal da última resposta

Você também pode consultar traceRouteProbeHistoryTable para obter informações mais detalhadas sobre cada sonda. O índice usado para traceRouteProbeHistoryTable começa em 1, vai para 0xFFFFFFFF e termina em 1 novamente.

Por exemplo, assuma o seguinte:

  • traceRouteCtlMaxRows é 10.

  • traceRouteCtlProbesPerHop é 5.

  • Há oito saltos para o alvo (o alvo é o número oito).

  • Cada sonda enviada resulta em uma resposta de um host (o número de sondas enviadas não é limitado por traceRouteCtlMaxFailures).

Neste teste, 40 sondas são enviadas. Ao final do teste, traceRouteProbeHistoryTable teria um histórico de sondagens como as de Tabela 4.

Tabela 4: traceRouteProbeHistoryTable

HistoryIndex

HistoryHopIndex

HistoryProbeIndex

31

7

1

32

7

2

33

7

3

34

7

4

35

7

5

36

8

1

37

8

2

38

8

3

39

8

4

40

8

5

Pare um teste de traceroute

Para interromper um teste ativo, definir traceRouteCtlAdminStatus para disabled. Para interromper um teste e remover seus traceRouteCtlEntry, traceRouteResultsEntry, traceRouteProbeHistoryEntrye traceRouteProbeHistoryEntry objetos do MIB, definido traceRouteCtlRowStatus para destroy.

Interprete variáveis de traceroute

Este tópico contém informações sobre as faixas para as seguintes variáveis que não estão explicitamente especificadas no Traceroute MIB:

  • traceRouteCtlMaxRows— O valor máximo é de traceRouteCtlMaxRows 2550. Isso representa o TTL máximo (255) multiplicado pelo máximo para traceRouteCtlProbesPerHop (10). Portanto, ele traceRouteProbeHistoryTable acomoda um teste completo com os valores máximos de um traceRouteCtlEntry. Normalmente, os valores máximos não são usados e é traceRouteProbeHistoryTable capaz de acomodar o histórico completo de muitos testes para o mesmo traceRouteCtlEntry.

  • traceRouteMaxConcurrentRequests— O valor máximo é de 50. Se um teste estiver sendo executado, ele tem uma sonda excepcional. traceRouteMaxConcurrentRequests representa o número máximo de testes de traceroute que têm traceRouteResultsOperStatus um valor de enabled. Qualquer tentativa de iniciar um teste com traceRouteMaxConcurrentRequests testes em execução resultará na criação de uma sonda com traceRouteProbeHistoryStatus configuração e maxConcurrentLimitReached esse teste terminará imediatamente.

  • traceRouteCtlTable— O número máximo de entradas permitidas nesta tabela é de 100. Qualquer tentativa de criar uma 101ª entrada resultará em uma BAD_VALUE mensagem para SNMPv1 e uma RESOURCE_UNAVAILABLE mensagem para SNMPv2.

Tabela de histórico de alterações

A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.

Versão
Descrição
17.2X75-D100
A partir do Junos OS Release 17.2X75-D100, você deve configurar RPM antes de iniciar um ping de ICMP.