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
- Definir visualizações de SNMP
- Definir notificação de armadilhas para operações remotas
- Use índices de cordas de comprimento variável
- Habilite o registro
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]
:
[edit snmp] community community-name { authorization authorization; view view-name; } view view-name { oid object-identifier (include | exclude); }
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:
snmp { view remote-view { oid 1.3.6.1.2.1.80 include; # pingMIB oid 1.3.6.1.4.1.2636.3.7 include; # jnxPingMIB oid 1.3.6.1.2.1.81 include; # traceRouteMIB oid 1.3.6.1.4.1.2636.3.8 include; # jnxTraceRouteMIB } community remote-community { view remote-view; authorization read-write; } }
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:
[edit snmp trap-group group-name] categories { category; } targets { address; } }
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:
snmp { trap-group remote-traps { categories remote-operations; targets { 172.17.12.213; } } }
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):
pingMIB.pingObjects.pingCtlTable.pingCtlEntry.pingCtlTargetAddress."bob"."test" 1.3.6.1.2.1.80.1.2.1.4.3.98.111.98.4.116.101.115.116
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:
[edit] snmp { traceoptions { flag general; } }
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 pingCtlAdminStatus
enabled
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 createAndWait
createAndGo
em uma linha que ainda não existe. Um valor para active
pingCtlRowStatus
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
ParacreateAndWait
Todas as variáveis de teste apropriadas
pingCtlRowStatus
Paraactive
O Junos OS verifica agora que todas as informações necessárias para realizar um teste foram especificadas.
pingCtlAdminStatus
Paraenabled
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
ParacreateAndGo
Todas as variáveis de teste apropriadas
pingCtlAdminStatus
Paraenabled
Monitore um teste de ping em execução
Quando pingCtlAdminStatus
for definido com enabled
sucesso, 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 paraenabled
.
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 é pingResultsOperStatus
enabled
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 pingCtlAdminStatus
disabled
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 paranull-string
.pingResultsIpTgtAddrType
está definido paraunknown
.
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 pingCtlAdminStatus
enabled
com 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 correspondentespingProbeHistoryEntry
estápingProbeHistoryTable
definido pararequestTimedOut
.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 voltapingResultsMaxRtt
— Tempo máximo de ida e voltapingResultsAverageRtt
— Tempo médio de ida e voltapingResultsRttSumOfSquares
— Soma de praças de tempos de ida e voltapingResultsLastGoodProbe
— Tempor da última respostaNota: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 (pingProbeHistoryTable
pingProbeHistoryEntry
) representa um resultado de sonda e é indexada por três variáveis:
As duas primeiras
pingCtlOwnerIndex
variáveis epingCtlTestName
, são as mesmas usadas,pingCtlTable
que identificam o teste.A terceira variável é
pingProbeHistoryIndex
um 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 quepingProbeHistoryLastRC
— Valor do código de devolução (RC) do pacote ICMPpingProbeHistoryTime
— 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 quepingCtlTrapProbeFailureFilter
o número de sondas consecutivas falha durante o teste.Uma
pingTestFailed
armadilha é gerada quando o teste é concluído e pelo menospingCtlTrapTestFailureFilter
o número de sondas falha.Uma
pingTestCompleted
armadilha é gerada quando o teste é concluído e menos do quepingCtlTrapTestFailureFilter
as sondas falham.Nota:Uma sonda é considerada uma falha quando
pingProbeHistoryStatus
o resultado da sonda é algo alémresponseReceived
.
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 voltapingResultsMaxRtt
— Tempo máximo de ida e voltapingResultsAverageRtt
— Tempo médio de ida e voltapingResultsProbeResponses
— Número de respostas recebidaspingResultsSentProbes
— Número de tentativas de enviar sondagenspingResultsRttSumOfSquares
— Soma de praças de tempos de ida e voltapingResultsLastGoodProbe
— 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.
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.
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.
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
paradestroy
.
Pare um teste de ping
Para interromper um teste ativo, definir pingCtlAdminStatus
para disabled
. Para interromper o teste e remover seu pingCtlEntry
, pingResultsEntry
e 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 depingCtlDataSize
(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, opingCtlDataFill
padrão é usado em repetição. O padrão padrão (quandopingCtlDataFill
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
epingCtlTrapTestFailureFilter
— Um valor de 0 parapingCtlTrapProbeFailureFilter
oupingCtlTrapTestFailureFilter
não é bem definido pelo Ping MIB. SepingCtlTrapProbeFailureFilter
for 0,pingProbeFailed
as armadilhas não serão geradas para o teste em nenhuma circunstância. SepingCtlTrapTestFailureFilter
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 createAndWait
createAndGo
em uma linha que ainda não existe. Um valor para active
traceRouteCtlRowStatus
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 oAndWaitTodas as variáveis de teste apropriadas
traceRouteCtlRowStatus
Paraactive
O Junos OS verifica agora que todas as informações necessárias para realizar um teste foram especificadas.
traceRouteCtlAdminStatus
Paraenabled
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
ParacreateAndGo
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.
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 enabled
disabled
. 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 atraceRouteCtlMaxttl
ter sido enviado.traceRouteCtlMaxFailures
limite é excedido. O número de sondagens consecutivas que terminam com o statusrequestTimedOut
excedetraceRouteCtlMaxFailures
.Você termina o teste. Você define
traceRouteCtlAdminStatus
disabled
ou exclui a linha configurandotraceRouteCtlRowStatus
paradestroy
.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é depoistraceRouteResultsOperStatus
da transição paraenabled
. Quando isso ocorre, uma entrada é adicionadatraceRouteProbeHistoryTable
comtraceRouteProbeHistoryStatus
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.
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
, traceRouteProbeHistoryEntry
e 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 é detraceRouteCtlMaxRows
2550. Isso representa o TTL máximo (255) multiplicado pelo máximo paratraceRouteCtlProbesPerHop
(10). Portanto, eletraceRouteProbeHistoryTable
acomoda um teste completo com os valores máximos de umtraceRouteCtlEntry
. Normalmente, os valores máximos não são usados e étraceRouteProbeHistoryTable
capaz de acomodar o histórico completo de muitos testes para o mesmotraceRouteCtlEntry
.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êmtraceRouteResultsOperStatus
um valor deenabled
. Qualquer tentativa de iniciar um teste comtraceRouteMaxConcurrentRequests
testes em execução resultará na criação de uma sonda comtraceRouteProbeHistoryStatus
configuração emaxConcurrentLimitReached
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 umaBAD_VALUE
mensagem para SNMPv1 e umaRESOURCE_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.