Users Guide

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.
NOTA: El mismo comportamiento se aplica a las capturas de SNMPv2.
306