Users Guide

im selben Format an das konfigurierte Ziel weiterzuleiten, markieren Sie Trap im ursprünglichen Format weiterleiten
und klicken Sie auf Weiter.
4. Weisen Sie in Schweregradzuordnung den Warnungsschweregrad zu, dem Sie diese Trap-Weiterleitungswarnung
zuordnen möchten, und klicken Sie dann auf Weiter.
5. Weisen Sie in Kategorien- und Quellenzuordnung die Warnungskategoriequelle zu, der Sie diese Trap-
Weiterleitungswarnung zuordnen möchten, und klicken Sie dann auf Weiter.
6. Weisen Sie in Gerätezuordnung das Gerät oder die Gerätegruppen zu, denen Sie diese Trap-
Weiterleitungswarnung zuordnen möchten, und klicken Sie dann auf
Weiter.
7. Die Option „Trap-Weiterleitungsmaßnahme“ ist standardmäßig immer aktiv. Um die Aktivität einzuschränken,
geben Sie in Datum/Uhrzeitzuordnung, einen Datumsbereich, Uhrzeitbereich oder Tage ein und klicken dann auf
Weiter.
8. Überprüfen Sie in Zusammenfassung die Eingaben und klicken Sie auf Fertigstellen.
Der Schweregradstatus wird für alle Traps auf normal gesetzt und für eine erfolgreiche Warnungsmaßnahme muss
die Kombination aus Schweregrad, Kategorie und Gerät mit den Auswahlen der vorherigen Schritte abgestimmt
sein.
Weiterleiten von Warnungen mit Fallszenarien
Dieser Abschnitt beschreibt Szenarien über die Weiterleitung von Warnungen unter Verwendung der SNMP v1- und
SNMP v2-Protokolle. Die Szenarien enthalten die folgenden Komponenten:
• Verwalteter Knoten mit einem SNMP v1-Agenten, der als MNv1 bezeichnet wird
• Verwalteter Knoten mit einem SNMP v2/v2c-Agenten, der als MNv2 bezeichnet wird
• Verwaltete Station 1 mit OpenManage Essentials, die als MS1 bezeichnet wird
• Verwaltete Station 2 mit OpenManage Essentials, die als MS2 bezeichnet wird
• Verwaltete Station 3 mit einer Fremdsoftware, die als MS3 bezeichnet wird
Szenario 1 - Weiterleiten von Warnungen im Originalformat unter Verwendung des SNMP v1-Protokolls
In diesem Szenario werden SNMP v1-Warnungen von MNv1 an MS1 gesandt und dann von MS1 an MS2 weitergeleitet.
Falls Sie den Remote-Host der weitergeleiteten Warnung abrufen möchten, wird der Name von MNv1 angezeigt, da die
Warnung von MNv1 ausgeht. MNv1 wird angezeigt, weil die SNMP v1-Warnungsstandards Ihnen die Einstellung des
Agentennamens in der SNMP v1-Warnung gestatten.
Szenario 2 - Weiterleitung von Warnungen im Originalformat unter Verwendung des SNMP v2/v2c-
Protokolls
In diesem Szenario werden SNMP v2-Warnungen von MNv2 an MS1 gesandt und dann von MS1 an MS3 weitergeleitet.
Falls Sie den Remote-Host der weitergeleiteten Warnung von MS3 abrufen möchten, wird er als MS1 angezeigt
Da keines der Felder in einer SNMP v2-Warnung den Agentennamen angeben, wird der Host, der die Warnung
versendet, als Agent angesehen. Wenn eine SNMP v2-Warnung von MS1 an MS3 weitergeleitet wird, wird MS1 als
Quelle des Problems betrachtet. Um dieses Problem zu lösen, während SNMP v2- oder v2c-Warnungen weitergeleitet
werden, wird ein varbind mit OID als .1.3.6.1.6.3.18.1.3.0 mit dem variablen Wert als Agentenadresse hinzugefügt. Dies
wurde basierend auf dem in RFC2576-MIB angegebenen Standard-OID eingestellt. Wenn Sie versuchen, die
Agentenadresse von MS3 abzurufen, wird sie als MNv2 angezeigt
ANMERKUNG: Wenn die SNMP v2-Warnung von MS1 an MS2 weitergeleitet wird, wird der Remote-Host als MNv2
angezeigt, da MS1 die zusätzliche OID zusammen mit der weitergeletieten Trap analysiert.
Szenario 3 - Weiterleiten von Warnungen im OMEssentials-Format mittels entweder des SNMP v1-
Protokolls oder des SNMP v2-Protokolls
In diesem Szenario werden SNMP v1-Warnungen von MNv1 an MS1 gesendet und dann an MS2 weitergeleitet. Wenn
Sie versuchen, den Remote-Host der weitergeleiteten Warnung abzurufen, wird er als MS1 angezeigt. Der Schweregrad
131