Configurar operaciones remotas SNMP

Antes de iniciar una prueba de ping, configure una vista Ping MIB. Esto permite solicitudes SNMP Set en pingMIB. Para obtener más información, consulte Configurar vistas MIB.

A partir de Junos OS versión 17.2X75-D100, debe configurar RPM antes de iniciar un ping ICMP. Configure RPM mediante el edit services rpm comando.

Para iniciar una prueba de ping, cree una fila en y establezca pingCtlAdminStatus en pingCtlTableenabled. La información mínima que debe especificarse antes de establecer pingCtlAdminStatus en enabled es:

• pingCtlOwnerIndexSnmpAdminString

• pingCtlTestNameSnmpAdminString

• pingCtlTargetAddressInetAddress

• pingCtlTargetAddressTypeInetAddressType

• pingCtlRowStatusRowStatus

Para todos los demás valores, se eligen valores predeterminados a menos que se especifique lo contrario. pingCtlOwnerIndex y pingCtlTestName se utilizan como índice, por lo que sus valores se especifican como parte del identificador de objeto (OID). Para crear una fila, establezca pingCtlRowStatus en createAndWait o createAndGo sobre una fila que aún no existe. Un valor de active para pingCtlRowStatus indica que se ha proporcionado toda la información necesaria y que la prueba puede comenzar; pingCtlAdminStatus se puede establecer en enabled. Una solicitud SNMP Set que se establece pingCtlRowStatus en active fallará si la información necesaria en la fila no se especifica o es incoherente.

Para obtener información acerca de cómo configurar una vista, consulte Configuración de vistas SNMP.

Lea las siguientes secciones para saber cómo ordenar las variables.

Puede utilizar PDU de varias Set solicitudes (varias PDU, con uno o más varbinds cada una) y establecer las siguientes variables en este orden para iniciar la prueba:

• pingCtlRowStatus Para createAndWait

• Todas las variables de prueba apropiadas

• pingCtlRowStatus Para active

  Junos OS ahora verifica que se haya especificado toda la información necesaria para ejecutar una prueba.

• pingCtlAdminStatus Para enabled

Puede usar una sola Set PDU de solicitud (una PDU, con varios varbinds) para establecer las siguientes variables para iniciar la prueba:

• pingCtlRowStatus Para createAndGo

• Todas las variables de prueba apropiadas

• pingCtlAdminStatus Para enabled

Mientras se ejecuta la prueba, pingResultsEntry realiza un seguimiento del estado de la prueba. El valor de pingResultsOperStatus es enabled mientras se ejecuta la prueba y disabled cuando se ha detenido.

El valor de pingCtlAdminStatus permanece enabled hasta que lo establezca en disabled. Por lo tanto, para obtener el estado de la prueba, debe examinar pingResultsOperStatus.

La pingCtlFrequency variable se puede utilizar para programar muchas pruebas para uno pingCtlEntry. Después de que una prueba finaliza normalmente (no la detuvo) y ha transcurrido el pingCtlFrequency número de segundos, la prueba se inicia de nuevo, como si hubiera establecido pingCtlAdminStatus en enabled. Si interviene en cualquier momento entre pruebas repetidas (configurado pingCtlAdminStatus en disabled o pingCtlRowStatus en notInService), la función de repetición se desactiva hasta que se inicie otra prueba y finalice normalmente. Un valor de 0 para pingCtlFrequency indica que esta característica de repetición no está activa.

pingResultsIpTgtAddr y pingResultsIpTgtAddrType se establecen en el valor de la dirección de destino resuelta cuando el valor de pingCtlTargetAddressType es dns. Cuando una prueba se inicia correctamente y pingResultsOperStatus pasa a enabled:

• pingResultsIpTgtAddr se establece en null-string.

• pingResultsIpTgtAddrType se establece en unknown.

pingResultsIpTgtAddr y pingResultsIpTgtAddrType no se establecen hasta pingCtlTargetAddress que se puedan resolver en una dirección numérica. Para recuperar estos valores, busque pingResultsIpTgtAddrType cualquier valor que no sea después de unknown establecer pingCtlAdminStatus correctamente en enabled.

Al inicio de una prueba, pingResultsSentProbes se inicializa en 1 y se envía la primera sonda. pingResultsSentProbes aumenta en 1 cada vez que se envía una sonda.

A medida que se ejecuta la prueba, cada segundo, ocurre lo pingCtlTimeOut siguiente:

• pingProbeHistoryStatuspara el correspondiente pingProbeHistoryEntry en se establece en requestTimedOutpingProbeHistoryTable .

• Se genera una pingProbeFailed trampa, si es necesario.

• Se intenta enviar la siguiente sonda.

  Nota:

  No existe más de una sonda pendiente para cada prueba.

Para cada sonda, puede recibir uno de los siguientes resultados:

• El host de destino reconoce la sonda con una respuesta.

• Se agota el tiempo de espera de la sonda; No hay respuesta del host de destino reconociendo la sonda.

• No se pudo enviar la sonda.

Cada resultado de la sonda se registra en pingProbeHistoryTable. Para obtener más información acerca de pingProbeHistoryTable, consulte pingProbeHistoryTable.

Cuando se recibe una respuesta del host de destino reconociendo la sonda actual:

• pingResultsProbeResponses aumenta en 1.

• Se actualizan las siguientes variables:

  • pingResultsMinRtt—Tiempo mínimo de ida y vuelta

  • pingResultsMaxRtt—Tiempo máximo de ida y vuelta

  • pingResultsAverageRtt—Tiempo promedio de ida y vuelta

  • pingResultsRttSumOfSquares—Suma de cuadrados de tiempos de ida y vuelta

  • pingResultsLastGoodProbe: marca de tiempo de la última respuesta

    Nota:

    Solo los sondeos que dan como resultado una respuesta del host de destino contribuyen al cálculo de las variables de tiempo de ida y vuelta (RTT).

Cuando se recibe una respuesta a la última sonda o se agota el tiempo de espera de la última sonda, la prueba se completa.

Una entrada en pingProbeHistoryTable (pingProbeHistoryEntry) representa el resultado de una sonda y está indexada por tres variables:

• Las dos primeras variables, pingCtlOwnerIndex y pingCtlTestName, son las mismas que se utilizan para pingCtlTable, que identifica la prueba.

• La tercera variable, pingProbeHistoryIndex, es un contador para identificar de forma exclusiva cada resultado de la sonda.

El número máximo de pingProbeHistoryTable entradas creadas para una prueba determinada está limitado por pingCtlMaxRows. Si pingCtlMaxRows se establece en 0, no se crean entradas pingProbeHistoryTable para esa prueba.

Cada vez que se determina el resultado de un sondeo, se crea a y se agrega a pingProbeHistoryEntrypingProbeHistoryTable. pingProbeHistoryIndex de los nuevos pingProbeHistoryEntry es 1 mayor que el último pingProbeHistoryEntry agregado a pingProbeHistoryTable para esa prueba. pingProbeHistoryIndex se establece en 1 si esta es la primera entrada de la tabla. La misma prueba se puede ejecutar varias veces, por lo que este índice sigue creciendo.

Si pingProbeHistoryIndex del último pingProbeHistoryEntry agregado es 0xFFFFFFFF, el siguiente pingProbeHistoryEntry agregado se ha pingProbeHistoryIndex establecido en 1.

Se registra lo siguiente para el resultado de cada sonda:

• pingProbeHistoryResponse—Tiempo de vida (TTL)

• pingProbeHistoryStatus—Qué pasó y por qué

• pingProbeHistoryLastRC—Valor del código de retorno (RC) del paquete ICMP

• pingProbeHistoryTime—Marca de tiempo cuando se determinó el resultado de la sonda

Cuando no se puede enviar un sondeo, pingProbeHistoryResponse se establece en 0. Cuando se agota el tiempo de espera de una sonda, pingProbeHistoryResponse se establece en la diferencia entre el momento en que se descubrió que se agotó el tiempo de espera de la sonda y la hora en que se envió la sonda.

Para que se genere cualquier trampa, se debe establecer el bit apropiado de pingCtlTrapGeneration . También debe configurar un grupo de capturas para recibir operaciones remotas. Se genera una captura en las siguientes condiciones:

• Se genera una pingProbeFailed captura cada vez que pingCtlTrapProbeFailureFilter un número de sondas consecutivas fallan durante la prueba.

• Se genera una pingTestFailed interrupción cuando se completa la prueba y se produce un error en al menos pingCtlTrapTestFailureFilter un número de sondas.

• Se genera una pingTestCompleted captura cuando se completa la prueba y fallan menos de pingCtlTrapTestFailureFilter sondas.

  Nota:

  Una sonda se considera un fallo cuando pingProbeHistoryStatus el resultado de la sonda es algo más que responseReceived.

Para obtener información acerca de cómo configurar un grupo de capturas para recibir operaciones remotas, consulte Configuración de grupos de capturas SNMP y ejemplo: Configuración de la notificación de captura para operaciones remotas.

Puede utilizar PDU de varias Set solicitudes (varias PDU, con uno o más varbinds cada una) y establecer las siguientes variables en este orden para iniciar la prueba:

• traceRouteCtlRowStatus para crearAndWait

• Todas las variables de prueba apropiadas

• traceRouteCtlRowStatus Para active

  Junos OS ahora verifica que se haya especificado toda la información necesaria para ejecutar una prueba.

• traceRouteCtlAdminStatus Para enabled

Puede usar una sola Set PDU de solicitud (una PDU, con varios varbinds) para establecer las siguientes variables para iniciar la prueba:

• traceRouteCtlRowStatus Para createAndGo

• Todas las variables de prueba apropiadas

• traceRouteCtlAdminStatus a habilitado

Mientras se ejecuta la prueba, traceRouteResultsTable realiza un seguimiento del estado de la prueba. El valor de traceRouteResultsOperStatus se habilita mientras se ejecuta la prueba y se deshabilita cuando se ha detenido.

El valor de traceRouteCtlAdminStatus permanece habilitado hasta que lo establezca en deshabilitado. Por lo tanto, para obtener el estado de la prueba, debe examinar traceRouteResultsOperStatus.

La variable traceRouteCtlFrequency se puede utilizar para programar muchas pruebas para un traceRouteCtlEntry. Después de que una prueba finaliza normalmente (no la detuvo) y ha transcurrido el número de segundos de traceRouteCtlFrequency, la prueba se inicia de nuevo, como si hubiera establecido traceRouteCtlAdminStatus en habilitado. Si interviene en cualquier momento entre pruebas repetidas (establece traceRouteCtlAdminStatus en disabled o traceRouteCtlRowStatus en notInService), la función de repetición se deshabilita hasta que se inicie otra prueba y finalice normalmente. Un valor de 0 para traceRouteCtlFrequency indica que esta característica de repetición no está activa.

traceRouteResultsIpTgtAddr y traceRouteResultsIpTgtAddrType se establecen en el valor de la dirección de destino resuelta cuando el valor de traceRouteCtlTargetAddressType es dns. Cuando una prueba se inicia correctamente y traceRouteResultsOperStatus cambia a habilitado:

• traceRouteResultsIpTgtAddr se establece en null-string.

• traceRouteResultsIpTgtAddrType se establece en desconocido.

traceRouteResultsIpTgtAddr y traceRouteResultsIpTgtAddrType no se establecen hasta que traceRouteCtlTargetAddress se pueda resolver en una dirección numérica. Para recuperar estos valores, sondee traceRouteResultsIpTgtAddrType para cualquier valor que no sea desconocido después de establecer correctamente traceRouteCtlAdminStatus en habilitado.

Al inicio de una prueba, traceRouteResultsCurHopCount se inicializa en traceRouteCtlInitialTtl, y traceRouteResultsCurProbeCount se inicializa en 1. Cada vez que se determina el resultado de un sondeo, traceRouteResultsCurProbeCount aumenta en 1. Mientras se ejecuta la prueba, el valor de traceRouteResultsCurProbeCount refleja el sondeo pendiente actual para el que aún no se han determinado los resultados.

El número de sondeos traceRouteCtlProbesPerHop se envía para cada valor de tiempo de vida (TTL). Cuando se determina el resultado del último sondeo para el salto actual, siempre que el salto actual no sea el salto de destino, traceRouteResultsCurHopCount aumenta en 1 y traceRouteResultsCurProbeCount se restablece en 1.

Al inicio de una prueba, si es la primera vez que se ejecuta esta prueba para este traceRouteCtlEntry, traceRouteResultsTestAttempts y traceRouteResultsTestSuccesses se inicializan en 0.

Al final de cada ejecución de prueba, traceRouteResultsOperStatus pasa a deshabilitado y traceRouteResultsTestAttempts aumenta en 1. Si la prueba logró determinar correctamente la ruta completa al destino, traceRouteResultsTestSuccesses aumenta en 1 y traceRouteResultsLastGoodPath se establece en la hora actual.

Cada entrada de traceRouteProbeHistoryTable está indexada por cinco variables:

• Las dos primeras variables, traceRouteCtlOwnerIndex y traceRouteCtlTestName, son las mismas que se utilizan para traceRouteCtlTable y para identificar la prueba.

• La tercera variable, traceRouteProbeHistoryIndex, es un contador que comienza desde 1 y se ajusta en FFFFFFFF. El número máximo de entradas está limitado por traceRouteCtlMaxRows.

• La cuarta variable, traceRouteProbeHistoryHopIndex, indica para qué salto es este sondeo (el valor de tiempo de vida real o TTL). Por lo tanto, el primer número traceRouteCtlProbesPerHop de entradas creadas cuando se inicia una prueba tiene el valor traceRouteCtlInitialTtl para traceRouteProbeHistoryHopIndex.

• La quinta variable, traceRouteProbeHistoryProbeIndex, es la sonda para el salto actual. Va desde 1 hasta traceRouteCtlProbesPerHop.

Mientras se ejecuta una prueba, tan pronto como se determina el resultado de una sonda, se envía la siguiente sonda. Transcurre un máximo de segundos traceRouteCtlTimeOut antes de que un sondeo se marque con status requestTimedOut y se envíe el siguiente sondeo. Nunca hay más de una sonda pendiente por prueba de traceroute. Cualquier resultado de la sonda que regrese después de que se agote el tiempo de espera de una sonda se ignora.

Cada sonda puede:

• Resultado en una respuesta de un host que reconoce la sonda

• Tiempo de espera sin respuesta de un host que reconozca la sonda

• Error al ser enviado

Cada estado de sonda se registra en traceRouteProbeHistoryTable con traceRouteProbeHistoryStatus establecido en consecuencia.

Los sondeos que dan como resultado una respuesta de un host registran los siguientes datos:

• traceRouteProbeHistoryResponse: tiempo de ida y vuelta (RTT)

• traceRouteProbeHistoryHAddrType: el tipo de HAddr (siguiente argumento)

• traceRouteProbeHistoryHAddr: la dirección del salto

Todas las sondas, independientemente de si se recibe una respuesta para la sonda, tienen registrado lo siguiente:

• traceRouteProbeHistoryStatus: qué ha ocurrido y por qué

• traceRouteProbeHistoryLastRC: valor de código de retorno (RC) del paquete ICMP

• traceRouteProbeHistoryTime: marca de tiempo cuando se determinó el resultado del sondeo

Cuando no se puede enviar una sonda, traceRouteProbeHistoryResponse se establece en 0. Cuando se agota el tiempo de espera de una sonda, traceRouteProbeHistoryResponse se establece en la diferencia entre la hora en que se descubrió que se agotó el tiempo de espera de la sonda y la hora en que se envió la sonda.

Las entradas de traceRouteHopsTable están indexadas por tres variables:

• Los dos primeros, traceRouteCtlOwnerIndex y traceRouteCtlTestName, son los mismos que se usan para traceRouteCtlTable e identifican la prueba.

• La tercera variable, traceRouteHopsHopIndex, indica el salto actual, que comienza en 1 (no traceRouteCtlInitialTtl).

Cuando se inicia una prueba, se eliminan todas las entradas de traceRouteHopsTable con traceRouteCtlOwnerIndex y traceRouteCtlTestName dados. Las entradas de esta tabla sólo se crean si traceRouteCtlCreateHopsEntries se establece en true.

Se crea un nuevo traceRouteHopsEntry cada vez que se determina el primer resultado del sondeo para un TTL determinado. La nueva entrada se crea independientemente de que la primera sonda llegue o no a un host. El valor de traceRouteHopsHopIndex se incrementa en 1 para esta nueva entrada.

Cada vez que un sondeo llega a un host, la dirección IP de ese host está disponible en el resultado del sondeo. Si no se establece el valor de traceRouteHopsIpTgtAddress de la traceRouteHopsEntry actual, el valor de traceRouteHopsIpTgtAddress se establece en esta dirección IP. Si el valor de traceRouteHopsIpTgtAddress de la traceRouteHopsEntry actual es el mismo que la dirección IP, el valor no cambia. Si el valor de traceRouteHopsIpTgtAddress de la traceRouteHopsEntry actual es diferente de esta dirección IP, lo que indica un cambio de ruta, se crea una nueva traceRouteHopsEntry con:

• Variable traceRouteHopsHopHopIndex aumentada en 1

• traceRouteHopsIpTgtAddress establecido en la dirección IP

  Nota:

  Se agrega una nueva entrada para una prueba a traceRouteHopsTable cada vez que se usa un nuevo valor TTL o cambia la ruta. Por lo tanto, el número de entradas para una prueba puede exceder el número de valores TTL diferentes utilizados.

Cuando se determina el resultado de un sondeo, el valor traceRouteHopsSentProbes del traceRouteHopsEntry actual aumenta en 1. Cuando se determina el resultado de un sondeo y el sondeo llega a un host:

• El valor traceRouteHopsProbeResponses del traceRouteHopsEntry actual se incrementa en 1.

• Se actualizan las siguientes variables:

  • traceRouteResultsMinRtt: tiempo mínimo de ida y vuelta

  • traceRouteResultsMaxRtt: tiempo máximo de ida y vuelta

  • traceRouteResultsAverageRtt: tiempo promedio de ida y vuelta

  • traceRouteResultsRttSumOfSquares: suma de cuadrados de tiempos de ida y vuelta

  • traceRouteResultsLastGoodProbe: marca de tiempo de la última respuesta

    Nota:

    Sólo los sondeos que llegan a un host afectan a los valores de tiempo de ida y vuelta.

Para generar cualquier captura, se debe establecer un bit apropiado de traceRouteCtlTrapGeneration. También debe configurar un grupo de capturas para recibir operaciones remotas. Las capturas se generan en las siguientes condiciones:

• traceRouteHopsIpTgtLa dirección de la sonda actual es diferente de la última sonda con el mismo valor TTL (traceRoutePathChange).

• No se pudo determinar una ruta de acceso al destino (traceRouteTestFailed).

Se determinó una ruta de acceso al destino (traceRouteTestCompleted).

Para obtener información acerca de cómo configurar un grupo de capturas para recibir operaciones remotas, consulte Configuración de grupos de capturas SNMP y Descripción general de las operaciones remotas SNMP.