3. En Configuración de reenvío de capturas, proporcione el nombre de host o la dirección IP de destino y proporcione
información de comunidad. Para enviar una captura de prueba a la estación de administración de destino, haga
clic en Probar acción. Para reenviar la captura en el mismo formato al destino configurado, haga clic en la casilla
Reenviar captura en formato original y luego haga clic en Siguiente.
4. En Asociación de gravedad, asigne la gravedad de alerta a la que desea asociar esta alerta de reenvío de capturas
y, a continuación, haga clic en Siguiente.
5. En Asociación de categorías y orígenes, asigne el origen de categorías de alertas al que desea asociar esta alerta
de reenvío de capturas) y, a continuación, haga clic en
Siguiente.
6. En Asociación de dispositivo, asigne el dispositivo o grupo de dispositivos a los que desea asociar esta alerta de
reenvío de capturas y, a continuación, haga clic en Siguiente.
7. De forma predeterminada, la opción Acción de reenvío de captura está siempre activa. Para limitar la actividad, en
Asociación de fechas y horas, introduzca un rango de fechas, horas o días y haga clic en Siguiente.
8. En Resumen, revise las entradas y haga clic en Terminar.
El estado de gravedad para cualquier captura se ha establecido en normal y para una acción de alerta
satisfactoria, la combinación de gravedad, categoría y dispositivo debe estar de acuerdo con las selecciones de
los pasos anteriores.
Escenarios de casos de uso de reenvío de alertas
Esta sección describe escenarios referidos al reenvío de alertas con los protocolos SNMP v1 y SNMP v2. Los
escenarios consisten de los siguientes componentes:
• Nodo administrado con un agente SNMP v1, denominado MN1
• Nodo administrado con un agente SNMP v2/v2c, denominado MN2
• Managed station 1 con OpenManage Essentials, denominada MS1
• Managed station 2 con OpenManage Essentials, denominada MS2
• Managed station 3 con un software de terceros, denominada MS3
Escenario 1: reenvío de alertas en formato original con el protocolo de SNMP v1
En este escenario, se envían las alertas de SNMP v1 de MN1 a MS1 y luego se reenvían de MS1 a MS2. Si intenta
recuperar el host remoto de la alerta reenviada, aparecerá el nombre de MN1, ya que la alerta se origina desde MN1.
MN1 aparece porque los estándares de las alertas SNMP v1 le permiten configurar el nombre del agente en la alerta
SNMP v1.
Escenario 2: reenvío de alertas en formato original con el protocolo de SNMP v2/v2c
En este escenario, se envían las alertas SNMP v2 de MNv2 a MS1 y luego se reenvían de MS1 a MS3. Si intenta
recuperar el host remoto de la alerta reenviada desde MS3, aparecerá como MS1.
Debido a que en una alerta SNMP v2 no existen campos para especificar el nombre del agente, se asume que el agente
es el host que envía la alerta. Cuando se reenvía una alerta SNMP v2 de MS1 a MS3, MS1 se considera como el origen
del problema. Para resolver esta situación, al reenviar alertas SNMP v2 o v2c, se agrega un varbind con OID como .
1.3.6.1.6.3.18.1.3.0, con el valor de la variable como Dirección del agente. Esto se ha establecido de acuerdo con el OID
estándar especificado en RFC2576-MIB. Cuando intenta recuperar la Dirección del agente de MS3, aparece como
MNv2.
NOTA: Si la alerta de SNMP v2 se reenvía desde MS1 a MS2, el host remoto aparece como MNv2 porque MS1
analiza el OID adicional junto con la captura reenviada.
Escenario 3: reenvío de alertas en formato de OMEssentials con cualquier protocolo de SNMP v1/v2
En este escenario, las alertas de SNMP v1 se envián desde MNv1 a MS1 y luego se reenvían a MS2. Si intenta
recuperar el host remoto de la alerta reenviada, aparece como MS1. MS1 también define la gravedad y el mensaje de la
alerta y no muestra la gravedad y el mensaje original definido por MNv1.
127