Sophos Switch SNMP-Monitoring sicher einrichten

Die SNMP-Seite in Sophos Fusion steuert zwei getrennte Datenwege: Ein SNMP-Manager fragt Werte vom Switch ab, und der Switch kann bei Ereignissen Benachrichtigungen an einen Empfänger senden. Für neue Integrationen ist SNMPv3 mit Privilege, SHA und AES_CFB128 die sichere Wahl. Eine eng begrenzte Read view reicht für reines Monitoring; Schreibrechte werden dann nicht erteilt.

Kurzablauf:

1. Erreichbarkeit, Lizenz, Änderungsumfang und benötigte OIDs klären.
2. Unter Switches > [Switch, Stack oder Site] > SNMP > Global settings SNMP einschalten und die Engine ID unverändert lassen.
3. Unter Users & Communities einen SNMPv3-Benutzer mit Privilege erstellen.
4. Unter Groups, Views und Access lists nur die benötigten Leserechte zuweisen.
5. Die Modell-MIBs in den SNMP-Manager importieren und Polling positiv sowie negativ testen.
6. Nur wenn Benachrichtigungen benötigt werden, Target parameters, Notifications und Target address konfigurieren.
7. Polling und Benachrichtigungsempfang im Monitoring-System getrennt abnehmen.

SNMPv1 und SNMPv2c verwenden einen Community String als Kennwort und übertragen diese Information im Klartext. Enable SNMP v1/v2c for this user bleibt deshalb deaktiviert, sofern kein begründetes Altsystem ohne SNMPv3-Unterstützung existiert.

Voraussetzungen, Rollen und Erreichbarkeit

Für Änderungen über Sophos Fusion benötigt jeder zentral verwaltete Switch eine gültige Sophos Switch Support and Services Subscription. Ohne gültige Subscription funktioniert der Switch lokal weiter, Änderungen über Sophos Fusion sind jedoch nicht möglich. Die Lizenzgrenze ist unter Sophos Fusion Lizenzierung eingeordnet.

Die Konfiguration führt ein Sophos-Fusion-Administrator aus, dessen Berechtigung Änderungen am ausgewählten Switch, Stack oder Standort erlaubt. Die offizielle SNMP-Maske nennt keine eigene SNMP-spezifische Administratorrolle. Der Monitoring-Verantwortliche stellt die Managerdaten bereit, importiert die MIBs und prüft Polling sowie Benachrichtigungen. Zugangsdaten werden über einen freigegebenen Geheimniskanal ausgetauscht, nicht in Tickets oder Screenshots.

Vor dem ersten Speichern müssen folgende Angaben feststehen:

• der richtige Switch, Stack oder Standort und damit der tatsächliche Wirkungsbereich;
• Management-IP des Switches und IP-Adresse des SNMP-Managers;
• Routing und Netzfilter für Polling vom Manager zum Switch sowie für Benachrichtigungen vom Switch zum Empfänger;
• der am Empfänger konfigurierte UDP-Port für Benachrichtigungen;
• die vom Monitoring wirklich benötigten MIB-Zweige und OIDs;
• ein eindeutiger Benutzername sowie je ein starkes Geheimnis für Authentifizierung und Verschlüsselung;
• die Entscheidung, ob nur Polling oder zusätzlich Traps beziehungsweise Informs benötigt werden.

Die SNMP-Access lists in dieser Oberfläche begrenzen OID-Rechte einer Gruppe. Sie ersetzen keine Netzwerk-ACL und erlauben keine Quell-IP-Liste für Manager. Die Erreichbarkeit wird deshalb im Managementnetz auf die vorgesehenen Monitoring-Systeme begrenzt. Den verwendeten Polling-Port nicht aus einem vermeintlichen Produktstandard ableiten, sondern mit der tatsächlichen Manager- und Netzkonfiguration abgleichen.

Bei einer Site oder einem Stack kann eine Änderung mehrere Geräte betreffen. Zuerst einen Pilot-Switch und danach den vorgesehenen Geltungsbereich prüfen. Configuration source zeigt in den Listen, woher eine Einstellung stammt. Not set bedeutet, dass die lokale Switch-Konfiguration verwendet wird; es bedeutet nicht automatisch Off.

SNMPv3-Sicherheitsmodell festlegen

Die Oberfläche bietet drei Privilege mode-Stufen:

Für produktives Monitoring wird Privilege verwendet. Als Authentication protocol stehen MD5 mit HMAC-MD5 und SHA mit HMAC-SHA-96 zur Verfügung. Bei Encryption protocol kann zwischen DES_CBC mit 64-Bit-DES-CBC und AES_CFB128 mit 128-Bit-AES-CFB gewählt werden. Die stärkere in der Oberfläche verfügbare Kombination ist SHA mit AES_CFB128.

Ein sicherer, anpassbarer Namensplan kann beispielsweise so aussehen:

Die Namen sind Beispiele und werden an den eigenen Namensstandard angepasst. Für Passwörter gibt es bewusst keinen kopierbaren Beispielwert: Beide Geheimnisse werden zufällig erzeugt, getrennt gespeichert und müssen die unten genannten Zeichenregeln erfüllen. Eine universelle Sophos-OID gibt es für diesen Zweck nicht; die benötigten OIDs werden aus den MIB-Dateien des eingesetzten Switch-Modells und dem tatsächlichen Monitoringbedarf gewählt.

1. Globale SNMP-Einstellungen setzen

1. Switches öffnen, den Switch, Stack oder Standort auswählen und SNMP wählen.
2. Unter Global settings bei SNMP status den Wert On auswählen.
3. Für Engine ID die empfohlene Option Default beibehalten.
4. Mit Update speichern.
5. Configuration source und den wirksamen SNMP status kontrollieren.

Eine manuelle Engine ID muss hexadezimal sein und 10 bis 64 Zeichen enthalten. Sie identifiziert den Switch eindeutig und schützt gegen Replay-, Verzögerungs- und Umleitungsprobleme.

Clear setzt die in der Ansicht eingetragenen Werte zurück. Es stellt nicht automatisch einen zuvor dokumentierten Produktionszustand wieder her.

2. SNMPv3-Benutzer erstellen

Unter Users & Communities zeigt die Liste Name, Protocols, Authentication und Configuration source.

1. Unter Users & Communities auf Add klicken.
2. Unter Name einen Namen mit 4 bis 20 Zeichen eingeben, beispielsweise swmon_v3.
3. Bei Privilege mode den Wert Privilege auswählen.
4. Authentication protocol auf SHA setzen.
5. Unter Authentication password ein neues Geheimnis mit 8 bis 32 Zeichen eintragen.
6. Encryption protocol auf AES_CFB128 setzen.
7. Unter Encryption password ein neues Geheimnis mit 8 bis 40 Zeichen eintragen.
8. Enable SNMP v1/v2c for this user deaktiviert lassen.
9. Mit Add anlegen und danach den Listeneintrag kontrollieren.

Benutzername und beide Passwörter dürfen keine Leerzeichen und keines dieser Zeichen enthalten: ", \, %, &, ?, ', !, ;, |, +.

Wird SNMPv1/v2c ausnahmsweise aktiviert, erzeugt Sophos Fusion aus Name eine Community und ordnet sie dem Benutzer zu. Ein Transport tag kann die Community bestimmten Geräten zuordnen. Derselbe Wert muss als Tag identifier unter Notifications > Target address definiert sein; fehlt er in der Community-Zuordnung, kann der Switch die betreffenden Anfragen nicht beantworten. Da die Community im Klartext übertragen wird, gehört diese Ausnahme in einen befristeten Ablöseplan.

3. Gruppe, View und Access List nach Least Privilege aufbauen

Eine Access list setzt mindestens eine Gruppe voraus. Die Objekte werden deshalb in dieser Reihenfolge angelegt.

Gruppe erstellen

1. Unter Groups auf Add klicken.
2. Einen Group name mit 1 bis 30 Zeichen eingeben, beispielsweise monitor_ro.
3. In der Spalte v3 nur den vorgesehenen Benutzer auswählen.
4. Mit Add speichern.
5. Den Gruppennamen öffnen und prüfen, ob der Benutzer tatsächlich enthalten ist.

Der Gruppenname unterliegt denselben ausgeschlossenen Zeichen wie der Benutzername. Wird ein Benutzer ohne das für den gewählten Security mode erforderliche Privileg ausgewählt oder ist er bereits in einer Gruppe mit denselben Einstellungen, zeigt Sophos Fusion einen Fehler. Die Gruppe wird trotzdem erstellt, jedoch ohne den betroffenen Benutzer. Ein vorhandener Gruppenname ist daher noch kein Erfolgsnachweis.

OID-View begrenzen

1. Unter Views auf Add klicken.
2. Einen View name mit 1 bis 20 Zeichen eingeben, beispielsweise monitoring.
3. Add new mapping auswählen.
4. Unter Subtree OID einen tatsächlich benötigten Zweig aus der importierten Modell-MIB eintragen.
5. Unter Subtree mask eine Ganzzahl von 1 bis 20 eintragen. Sie bezeichnet die Ebene im MIB-Baum, auf der die Maske angewendet wird.
6. Als View type je Zuordnung Included oder Excluded wählen.
7. Weitere Zuordnungen bei Bedarf über Add new mapping ergänzen.
8. Mit Save speichern und die angezeigten OID-Mappings kontrollieren.

Mit Included werden nur benötigte Zweige freigegeben. Bei einem Eintrag vom Typ Excluded empfiehlt Sophos einen zusätzlichen überlappenden Included-Eintrag. So ist ausdrücklich definiert, welcher Teil des OID-Baums erreichbar bleibt. Nicht vorsorglich den gesamten Baum freigeben, nur weil der Manager später weitere Sensoren entdecken könnte.

Access List zuweisen

1. Unter Access lists auf Add klicken.
2. Die zuvor erstellte Gruppe auswählen.
3. Den angezeigten Security mode kontrollieren und Privilege mode für v3 auf Privilege setzen.
4. Für v3 die angelegte View als Read view auswählen.
5. Für reines Monitoring keine schreibberechtigte Write view zuweisen.
6. Nur für geplante Benachrichtigungen die passende View als Notify view auswählen.
7. Mit Save speichern und die resultierende Zeile kontrollieren.

Read view, Write view und Notify view regeln getrennt, welche OIDs die Gruppe lesen, schreiben oder in vom Switch-Agent erzeugten Trap-Nachrichten verwenden darf. Die Sophos-Hilfe beschreibt die Auswahl einer Write view, dokumentiert aber nicht, dass reines Monitoring Schreibrechte benötigt. Deshalb keine View mit schreibbaren OIDs freigeben. Verlangt die konkrete Oberfläche zwingend eine Auswahl, nicht ersatzweise eine breite View wählen, sondern die firmwarespezifische Auswahlmöglichkeit zuerst auf einem Pilot-Switch klären.

4. Modell-MIBs importieren

Die Sophos-Switch-MIB-Dateien stehen in Sophos Fusion bereit:

1. My Environment > Installers öffnen.
2. Unter Switches auf Download SNMP MIB files klicken.
3. Das Archiv geschützt speichern und entpacken.
4. Die zum eingesetzten Switch-Modell gehörenden MIB-Dateien in den SNMP-Manager importieren.
5. Die für Sensoren und Benachrichtigungen ausgewählten OIDs gegen diese MIB-Version prüfen.

Das Archiv enthält MIB-Dateien für alle Sophos-Switch-Modelle. Eine MIB ist die Referenz für die strukturierten Geräteinformationen; jede OID bezeichnet eine Variable, die per SNMP gelesen oder gesetzt werden kann. Dass eine OID in einer MIB existiert, beweist noch nicht, dass sie in der eigenen Read view freigegeben oder auf jedem Modell sinnvoll befüllt ist.

5. Polling im Monitoring-System einrichten und prüfen

Ein Polling-Intervall wird nicht auf der SNMP-Seite festgelegt. Der SNMP-Manager plant seine Abfragen selbst. Dort werden Management-IP des richtigen Switches, SNMPv3, Benutzername, Privilege, SHA samt Authentication Password sowie AES_CFB128 samt Encryption Password hinterlegt.

Die Abnahme erfolgt von einem autorisierten Monitoring-System:

1. Zuerst eine OID aus der Read view abfragen und einen fachlich plausiblen Wert erhalten.
2. Switchname, Management-IP und Modell gegen das Inventar vergleichen, damit nicht versehentlich ein anderes Gerät überwacht wird.
3. Eine absichtlich nicht freigegebene OID abfragen. Sie darf keinen Wert liefern.
4. Mehrere Polling-Zyklen beobachten und Timeout, Paketverlust sowie Last im vorgesehenen Intervall prüfen.
5. Bestätigen, dass keine schreibberechtigte Write view zugewiesen ist. Dafür keine produktive OID testweise verändern; Berechtigung und Managerprofil prüfen und einen Schreibtest nur in einer freigegebenen Laborumgebung durchführen.
6. In Sophos Fusion SNMP status, Benutzer, Gruppenmitgliedschaft, Read view, nicht erteilte Schreibrechte und Configuration source nochmals gegen den Plan vergleichen.

Ein erfolgreicher einzelner Poll bestätigt die Zugangsdaten und eine OID, aber noch nicht alle Sensoren. Umgekehrt ist ein Timeout nicht automatisch ein Credential-Fehler: Routing, Netzfilter, Ziel-IP, verwendeter Port, SNMP-Version und Managerprofil werden zuerst getrennt geprüft.

6. Traps oder Informs nur bei Bedarf konfigurieren

Für den Versand sind drei Objekte nötig:

• Target parameters definieren SNMP-Version, Sicherheitskontext, Privileg und Benutzer.
• Notifications definieren Typ und Tag.
• Target address definiert Empfängeradresse, UDP-Port, Tag und Parametersatz.

Traps sind unidirektional; Empfang und Zustellung werden weder bestätigt noch garantiert. Informs fordern eine Empfangsbestätigung an und sind deshalb zuverlässiger, verbrauchen aber mehr System- und Netzwerkressourcen. Informs stehen nur mit SNMPv2c und SNMPv3 zur Verfügung. Die Bestätigung bietet jedoch weder Authentifizierung noch Verschlüsselung: Auch ein Inform über SNMPv2c bleibt durch den Community String lediglich schwach geschützt und wird im Klartext übertragen. Für einen neuen SNMPv3-Aufbau sind Informs sinnvoll, wenn der Empfänger sie unterstützt und die Bestätigung betrieblich benötigt wird. Andernfalls werden Traps bewusst als unbestätigter Kanal behandelt.

Target parameters

1. Unter Notifications > Target parameters auf Add klicken.
2. Einen Name mit 1 bis 30 Zeichen eingeben, beispielsweise notify_v3.
3. Message processing model auf v3 setzen.
4. Security mode auf v3 setzen.
5. Privilege mode auf Privilege setzen.
6. Den zuvor angelegten User auswählen.
7. Mit Save speichern.

Notification

1. Unter Notifications > Notifications auf Add klicken.
2. Unter Notify name einen Namen mit 1 bis 32 Zeichen eingeben, beispielsweise ops_inform.
3. Einen Tag identifier mit 1 bis 20 Zeichen festlegen, beispielsweise ops_nms.
4. Unter Notify type Traps oder Informs auswählen.
5. Mit Save speichern.

Target address

1. Unter Notifications > Target address auf Add klicken. Mindestens ein Target Parameter muss bereits vorhanden sein.
2. Einen Target address name mit 1 bis 32 Zeichen eingeben.
3. Unter IP address die IP-Adresse des SNMP-Empfängers eintragen, im Beispiel 192.0.2.60.
4. Unter UDP port exakt den am Empfänger konfigurierten Empfangsport eintragen. Keinen nicht geprüften Standardwert übernehmen.
5. Bei Informs Timeout und Retry festlegen.
6. Unter Tag identifier exakt denselben Tag wie in der Notification eintragen, im Beispiel ops_nms.
7. Unter Target parameter den zuvor erstellten Parametersatz auswählen.
8. Mit Save speichern.

Für Namen, Tag identifier und die weiteren Namensfelder gelten die jeweils genannten Längengrenzen sowie dieselben ausgeschlossenen Zeichen: ", \, %, &, ?, ', !, ;, |, + und Leerzeichen.

Die Sophos-Seite dokumentiert weder eine Ereignisauswahl noch einen Send test-Button oder einen vollständigen Ereigniskatalog. Deshalb wird im Wartungsfenster ein bereits fachlich bekanntes, gefahrlos auslösbares Ereignis verwendet und die tatsächlich empfangene Nachricht gegen die importierte MIB ausgewertet. Gibt es kein solches Ereignis, bleibt der Benachrichtigungsweg bis zum ersten realen Ereignis als noch nicht Ende-zu-Ende bestätigte Kontrolle dokumentiert.

End-to-End-Abnahme

Polling und Benachrichtigungen werden getrennt freigegeben:

1. Switch-Seite: Unter Global settings steht SNMP status auf On; Configuration source entspricht der vorgesehenen Konfigurationsebene, also Switch, Stack oder Site.
2. Berechtigung: Der neue Benutzer ist in der v3-Gruppe enthalten; Privilege, Read view, nicht erteilte Schreibrechte und gegebenenfalls Notify view stimmen.
3. Manager-Seite: Ein erlaubter OID-Wert wird wiederholt gelesen, eine nicht freigegebene OID nicht.
4. Netzpfad: Polling erreicht nur den vorgesehenen Switch; Benachrichtigungsverkehr erreicht nur die konfigurierte Empfänger-IP und den konfigurierten UDP-Port.
5. Empfänger: Eine Test- oder reale Benachrichtigung wird mit erwartetem Absender, SNMPv3-Sicherheitskontext, Zeitbezug und decodierten MIB-Feldern angezeigt.
6. Informs: Der Empfänger bestätigt den Eingang; es entstehen keine unerklärten Wiederholungen. Bei Traps wird ausdrücklich festgehalten, dass keine Zustellbestätigung existiert.
7. Betrieb: Zuständigkeit für Zugangsdaten, Rotationsdatum, OID-/Sensorliste, Empfänger und Rückweg sind dokumentiert, ohne Geheimnisse offenzulegen.

Wenn Sophos Fusion für das Objekt einen ausstehenden oder fehlgeschlagenen Auftrag zeigt, gilt die Konfiguration noch nicht als wirksam. Die Einordnung von Configuration source und Task queue beschreibt Sophos Switch Flotte, Sites und Stacks betreiben.

Fehler nach Symptom eingrenzen

Kein Polling möglich

1. SNMP status, Zielobjekt und Configuration source prüfen. Not set kann eine ungeeignete lokale Einstellung übernehmen.
2. Vom Monitoring-System Routing und Netzfilter bis zur Management-IP prüfen; keine Freigabe für beliebige Quellnetze als Abkürzung erstellen.
3. SNMP-Version, Benutzername, Privilege, Authentifizierungs- und Verschlüsselungsverfahren auf beiden Seiten vergleichen.
4. Geheimnisse kontrolliert neu aus dem Credential Store übernehmen, ohne sie in Logs oder Kommandozeilen offenzulegen.
5. Gruppenmitgliedschaft und Access List prüfen. Eine Gruppe kann trotz Fehlermeldung ohne den ausgewählten Benutzer erstellt worden sein.
6. Mit einer sicher erlaubten OID aus der importierten Modell-MIB erneut testen.

Erlaubte OIDs liefern keine Daten

Subtree OID, Subtree mask, Included/Excluded und die als Read view zugewiesene View gegen die MIB prüfen. Zusätzlich bestätigen, dass die OID zum tatsächlichen Switch-Modell gehört. Nicht als schnelle Lösung den gesamten OID-Baum freigeben.

SNMPv3 fällt nach einer Engine-ID-Änderung aus

Das Ändern oder Löschen der Engine ID entfernt lokale SNMP-Benutzer. Benutzer und alle abhängigen Zuordnungen anhand der gesicherten Konfiguration neu erstellen. Danach im SNMP-Manager den für das Gerät gespeicherten SNMPv3-Engine-ID- und USM-Zustand zurücksetzen und neu erkennen lassen. Bietet das eingesetzte Monitoring-Produkt dafür keine Aktualisierungsfunktion, den betroffenen Geräte- oder Sensor-Eintrag mit der aktuellen Engine ID und den neu erstellten Zugangsdaten neu anlegen. Die Engine ID nicht nochmals versuchsweise ändern.

Gruppe existiert, Benutzer fehlt

Der Benutzer besitzt nicht das für den Security mode erforderliche Privileg oder ist bereits in einer Gruppe mit denselben Einstellungen. Fehlermeldung lesen, Benutzer- und Gruppenwerte korrigieren und danach die tatsächliche Mitgliedschaft kontrollieren.

Access List lässt sich nicht erstellen

Zuerst mindestens einen Benutzer und eine Gruppe erstellen. Danach die Gruppe auswählen und die Views pro aktivierter SNMP-Version zuweisen.

Keine Benachrichtigung am Empfänger

1. Prüfen, ob Target parameters, Notifications und Target address vorhanden und über Benutzer, Parametersatz und identischen Tag identifier verbunden sind.
2. Empfänger-IP und den tatsächlich konfigurierten UDP port kontrollieren.
3. Den Rückweg vom Switch zum Empfänger sowie Netzfilter prüfen.
4. Bei v3 Privilege mode, Benutzer, SHA/AES-Einstellungen und Notify view vergleichen.
5. Bei Informs Empfangsbestätigung, Timeout und Retry in der realen Oberfläche beziehungsweise im Paketmitschnitt prüfen.
6. Bei Traps beachten, dass fehlende Bestätigung zum Verfahren gehört und kein Zustellnachweis existiert.
7. Sicherstellen, dass überhaupt ein dokumentiertes beziehungsweise im Betrieb bekanntes Ereignis aufgetreten ist; die SNMP-Seite bietet keine dokumentierte Ereignisauswahl oder Testtaste.

Informs ist nicht auswählbar

Informs werden nur mit SNMPv2c und SNMPv3 unterstützt. Für den sicheren Aufbau v3 in den Target Parameters verwenden und Versions- sowie Sicherheitsmodus konsistent halten.

Legacy-v1/v2c-Manager erhält keine Antwort

Community-Zuordnung und Transport tag prüfen. Der Wert muss zum Tag identifier unter Notifications > Target address passen. Weil die Community im Klartext übertragen wird, den Fehler nicht durch eine breitere dauerhafte v1/v2c-Freigabe umgehen.

Credentials ohne Unterbruch rotieren

Eine Rotation ändert die Engine ID nicht. Da die Benutzeransicht das Anlegen und Löschen dokumentiert, wird ein neuer Benutzer parallel aufgebaut, statt das einzige funktionierende Konto zuerst zu entfernen.

1. Unter Users & Communities einen neuen, eindeutig benannten SNMPv3-Benutzer mit Privilege, SHA, AES_CFB128 und neuen Geheimnissen anlegen.
2. Den bestehenden Gruppennamen öffnen, den neuen Benutzer für v3 ergänzen und die tatsächliche Mitgliedschaft prüfen.
3. Polling im Manager mit dem neuen Benutzer auf eine erlaubte und eine nicht erlaubte OID testen.
4. Werden Benachrichtigungen genutzt, den betreffenden Target parameter öffnen, auf den neuen User umstellen und den Empfang erneut prüfen.
5. Erst nach erfolgreicher Abnahme alle Managerjobs auf den neuen Benutzer umstellen.
6. Den alten Benutzer aus Gruppen entfernen und nicht mehr verwendete Target-Parameter-Zuordnungen kontrollieren.
7. Den alten Benutzer unter Users & Communities markieren und mit Delete entfernen.
8. Credential Store, Betriebsdokumentation und nächstes Rotationsdatum aktualisieren. Alte Geheimnisse nicht in der Change-Dokumentation behalten.

Solange der alte Benutzer noch existiert, besteht der Rückweg darin, Manager und Target Parameter wieder auf ihn zu stellen und die neue Zuordnung zu entfernen. Nach seiner Löschung ist dieser schnelle Rückweg nicht mehr verfügbar; deshalb die Löschung erst nach einem vereinbarten Beobachtungsfenster ausführen.

Rollback und laufender Betrieb

Vor jeder Änderung werden bestehende Werte, Configuration source, Objektzuordnungen und Managerprofil ohne Geheimnisse dokumentiert. Ein kontrollierter Rückbau erfolgt in umgekehrter Abhängigkeitsreihenfolge:

1. Neue Polling-Jobs und Benachrichtigungsannahme im Manager stoppen oder auf die vorherige Konfiguration zurückstellen.
2. Neu angelegte Target address-Einträge löschen.
3. Danach die zugehörigen Notifications und nicht mehr verwendeten Target parameters löschen.
4. Neue Access lists, Views, Groups und Users & Communities entfernen, sofern sie nicht von einer verbleibenden Integration verwendet werden.
5. Soll SNMP vollständig beendet werden, unter Global settings SNMP status: Off wählen und mit Update speichern.
6. Soll bewusst wieder die dokumentierte lokale Switch-Konfiguration gelten, Not set wählen und mit Update speichern.
7. Bestätigen, dass der entfernte Benutzer nicht mehr pollen kann und am entfernten Ziel keine neuen Benachrichtigungen eintreffen.

Die Engine ID bleibt beim Rollback unverändert. Ein Wechsel auf Not set ist nur dann ein Rückweg, wenn der zuvor wirksame lokale Zustand bekannt ist; andernfalls kann damit eine unbekannte lokale SNMP-Konfiguration aktiviert werden.

Zum laufenden Lebenszyklus gehören eine regelmässige Kontrolle von Subscription, Firmware, Configuration source, Benutzer- und Gruppenbestand, minimalen Views, Manager-IP, Empfängerport und MIB-Version. Nicht mehr benötigte Benutzer, v1/v2c-Ausnahmen, Write Views und Ziele werden nach Abhängigkeitsprüfung entfernt. Nach Managerwechsel, Credential-Rotation, Switch-Austausch, Firmwareänderung oder Anpassung der OID-Views werden Positivtest, Negativtest und – sofern eingesetzt – der Benachrichtigungsweg erneut abgenommen.