DHCP Relay und DHCP Snooping auf Sophos Switch konfigurieren

DHCP Relay und DHCP Snooping lösen zwei verschiedene Probleme. Ein Relay leitet DHCP-Pakete zwischen Clients und DHCP-Servern in unterschiedlichen Subnetzen weiter, entweder direkt zum DHCP-Server oder gemäss Design über ein weiteres Relay. DHCP Snooping ist dagegen eine Layer-2-Sicherheitsfunktion: Der Switch lässt Serverantworten nur über bewusst vertrauenswürdig konfigurierte Ports zu und kann DHCP-Pakete auf nicht vertrauenswürdigen Ports überprüfen.

⚠️ Wichtig: Falsch gesetzte Trust-Ports können die Adressvergabe eines ganzen VLANs unterbrechen. Zuerst den tatsächlichen DHCP-Pfad dokumentieren, dann Relay und Snooping einzeln aktivieren und jeweils mit einem Testclient prüfen. DHCP Snooping hat nichts mit IGMP- oder MLD-Snooping zu tun; Multicast-Snooping gehört nicht in diesen Ablauf.

Kurzablauf:

1. Entscheiden, ob DHCP Relay, DHCP Snooping oder beides benötigt wird.
2. VLANs, aktive Layer-3-VLAN-Interfaces, Gateway beziehungsweise Relay, DHCP-Server, Uplinks und lokale Überschreibungen erfassen.
3. Bei Bedarf unter L3 protocols > DHCP relay den Status und bis zu fünf Server IP addresses für DHCP-Server oder nachgelagerte Relay-Ziele gemäss Design setzen.
4. Unter L3 protocols > DHCP snooping zuerst die konkreten Eingänge legitimer Serverantworten als Trusted und Clientports als Untrusted planen.
5. Den Aktivierungsumfang für Snooping wählen: global oder für einzelne VLANs; MAC address verification zunächst kontrolliert testen.
6. Adressbezug, unerlaubte Serverantwort, Configuration source und Binding list validieren.
7. Bei Störungen gezielt die letzte Änderung zurücknehmen, statt wahllos Ports zu vertrauen.

Relay oder Snooping: die richtige Funktion wählen

Snooping ersetzt weder Routing noch einen DHCP-Server. Relay schützt seinerseits nicht vor einem Rogue-DHCP-Server am Accessport. Ein Eintrag in der Binding list ist ein Beobachtungsergebnis, keine Freigabe für einen Serverport.

Voraussetzungen und Änderungsplan

Vor der Konfiguration müssen folgende Angaben feststehen:

• der verwaltete Switch oder die Site in Sophos Fusion (ehemals Sophos Central) und ein funktionierender Managementzugang;
• alle Client-VLANs mit VLAN-ID, IP-Netz und vorgesehenem Gateway beziehungsweise Relay;
• für jedes per Relay zu bedienende Client-VLAN ein aktives, diesem VLAN korrekt zugeordnetes Layer-3-VLAN-Interface mit einer zum Clientnetz passenden IP-Adresse; über dieses Interface muss der Switch die Client-Broadcasts empfangen und dem richtigen Clientnetz zuordnen können;
• die IP-Adressen der vorgesehenen DHCP-Server oder nachgelagerten Relay-Ziele (nächster Relay-Hop) gemäss Design; für Relay sind höchstens fünf Server IP addresses möglich;
• der vollständige Layer-2-Pfad von jedem Client-VLAN zum autorisierten Server oder Relay, einschliesslich Uplinks, LAGs und Switch-zu-Switch-Verbindungen;
• ein Testport und ein Testclient pro betroffenem VLAN;
• ein Wartungsfenster sowie ein lokaler oder anderweitig unabhängiger Managementpfad, falls Administratorgeräte selbst DHCP verwenden;
• ein dokumentierter Ausgangszustand für Status, MAC address verification, VLAN-Status und Trust-Status aller betroffenen Ports.

Für Relay muss der Switch die betreffende Funktion im vorgesehenen Layer-3-Design übernehmen. Vor der Relay-Aktivierung für jedes Client-VLAN prüfen, dass das zugehörige Layer-3-VLAN-Interface aktiv, korrekt für das Clientnetz adressiert und tatsächlich dem betreffenden VLAN zugeordnet ist. Die Einrichtung dieses Interfaces und der VLAN-Zugehörigkeit erfolgt im separaten Layer-3-/VLAN-Ablauf und wird hier nicht ersetzt. Vom Layer-3-VLAN-Interface muss ein gerouteter Hinweg zum konfigurierten DHCP-Server oder nachgelagerten Relay-Ziel bestehen; ebenso muss der vollständige Rückweg bis in das Clientnetz vorhanden sein. Bei einem weiteren Relay umfasst die Prüfung auch dessen Weiterleitung zum eigentlichen DHCP-Server und den Rückweg über die gesamte Kette. Dazwischenliegende Regeln oder ACLs dürfen den DHCP-Verkehr nicht blockieren. Vorhandene Relays auf Firewall, Router oder anderem Switch erfassen: Pro Clientsegment soll der gewünschte Weiterleitungspfad eindeutig sein.

Kompaktes Topologiebeispiel

Ein Client-VLAN 20 verwendet das Dokumentationsnetz 192.0.2.0/24. Die Clientports 1 bis 20 eines Access-Switches sind Untrusted. Sein Port 24 führt zum Relay-Switch und ist auf diesem Access-Switch nur deshalb Trusted, weil legitime serverseitige DHCP-Nachrichten über genau diesen Uplink eintreffen. Der Relay-Switch besitzt für VLAN 20 das Layer-3-VLAN-Interface 192.0.2.1/24 und leitet DHCP an den Server 198.51.100.10 im gerouteten Dokumentationsnetz 198.51.100.0/24 weiter. Routing, Regeln und ACLs müssen den Hinweg zum Server und den Rückweg zum Clientnetz erlauben.

Die Trust-Zuweisung gilt nicht automatisch für gleich nummerierte Ports oder andere Switches: Auf jedem snoopenden Switch wird der tatsächliche Eingangsport legitimer Serverantworten Trusted gesetzt; clientseitige Ports bleiben Untrusted. Befinden sich Relay und Snooping auf demselben Switch, wird insbesondere kein Port allein wegen der Bezeichnung «Uplink» vertraut.

In Sophos Fusion My Products > Switches > Switches öffnen, den Switch oder die Site wählen und zu L3 protocols wechseln. Die Konfiguration auf Site-Ebene kann mehrere Switches betreffen. Deshalb vor Save kontrollieren, ob wirklich das richtige Objekt gewählt ist.

Not set richtig verstehen

Bei Relay, Snooping, VLANs, MAC-Prüfung und Trust-Ports bedeutet Not set nicht automatisch «aus». Der Switch verwendet dann den lokal konfigurierten Status. Die Spalte Configuration source zeigt bei den VLAN- und Trust-Port-Einstellungen, woher der wirksame Wert stammt. Wer einen definierten Central-Zustand benötigt, setzt ausdrücklich Enabled, Disabled, Trusted oder Untrusted und prüft anschliessend die Synchronisation.

DHCP Relay konfigurieren

Zu L3 protocols > DHCP relay wechseln.

Exakte Felder

• Status
  • Not set: lokal auf dem Switch konfigurierten Relay-Status verwenden.
  • Enabled: DHCP Relay einschalten.
  • Disabled: DHCP Relay ausschalten.
• Server IP addresses: Bis zu fünf IP-Adressen von DHCP-Servern oder nachgelagerten Relay-Zielen, an die der Switch DHCP-Pakete gemäss dem vorgesehenen Design weiterleitet.

Vorgehen

1. Unter Status zunächst Enabled wählen.
2. Die erste Zieladresse eines DHCP-Servers oder nachgelagerten Relays in Server IP addresses eingeben und Enter drücken. Erst dadurch wird die Adresse als Eintrag übernommen.
3. Weitere Zieladressen auf dieselbe Weise hinzufügen. Insgesamt sind maximal fünf möglich.
4. Entscheiden, ob die Einstellungen sofort mit den Switches synchronisiert werden sollen.
5. Save wählen.
6. Warten, bis die Konfiguration auf dem vorgesehenen Switch angekommen ist, und sofort einen kontrollierten DHCP-Neubezug im ersten Test-VLAN durchführen.
7. Weitere VLANs einzeln prüfen. Mehrere konfigurierte Zieladressen nur verwenden, wenn die betreffenden DHCP-Server oder Relay-Ziele für die jeweiligen Scopes und den vorgesehenen Weiterleitungspfad ausgelegt sind.

Eine Adresse wird entfernt, indem beim betreffenden Eintrag unter Server IP addresses das Löschsymbol gewählt, die sofortige Synchronisation passend gesetzt und mit Save bestätigt wird.

DHCP Snooping als Layer-2-Schutz planen

Die wichtigste Designentscheidung ist nicht der globale Schalter, sondern die Trust-Grenze:

• Trusted: Nur die konkrete Schnittstelle, über die legitime serverseitige DHCP-Nachrichten am snoopenden Switch eintreffen. Das kann ein direkt angeschlossener Serverport oder ein anhand der Topologie bestimmter Uplink beziehungsweise LAG sein.
• Untrusted: Normale Client- und sonstige Edge-Ports. Ein Endgerät an einem solchen Port darf nicht als DHCP-Server auftreten.

Nicht pauschal alle Uplinks oder Infrastrukturports vertrauen. Eine Schnittstelle wird nur dann Trusted, wenn legitime Offer- und ACK-Pakete über genau diese Schnittstelle in den snoopenden Switch gelangen. Die blosse Richtung zu einem Relay reicht als Begründung nicht: Arbeitet das Relay auf demselben Switch, gibt es dafür unter Umständen gar keinen physischen Eingangsport. Bei mehreren Switches ist die Eingangsrichtung auf jedem snoopenden Switch separat aus der tatsächlichen Topologie abzuleiten.

Sicherer Rollout: Trust-Ports zuerst korrekt festlegen und danach entweder global oder für einzelne VLANs aktivieren. Die Sophos-Dokumentation beschreibt diese Aktivierungsarten als Alternativen, aber keine Priorität für gleichzeitig gesetzte globale und VLAN-Werte. Deshalb beide Ebenen nicht ohne geräte- und firmwarespezifischen Funktionstest kombinieren. Für einen begrenzten Rollout zuerst ein einzelnes VLAN verwenden. Wenn DHCP Snooping ausgeschaltet ist, behandelt der Switch alle Ports als vertrauenswürdig; der Schutz ist dann nicht aktiv.

DHCP Snooping konfigurieren

Zu L3 protocols > DHCP snooping wechseln. Die Ansicht ist in Settings, VLAN settings, Trust port settings und Binding list gegliedert.

1. Globale Settings festlegen

Unter Settings stehen diese Felder zur Verfügung:

• Status
  • Not set: lokal konfigurierten DHCP-Snooping-Status verwenden.
  • Enabled: DHCP Snooping einschalten.
  • Disabled: DHCP Snooping ausschalten.
• MAC address verification
  • Not set: lokal konfigurierte MAC-Prüfung verwenden.
  • Enabled: Auf Untrusted Ports prüfen, ob die Source-MAC-Adresse des DHCP-Pakets mit der Hardwareadresse des Endpunkts übereinstimmt.
  • Disabled: MAC-Prüfung ausschalten.

Soll DHCP Snooping switchweit gelten, Status: Enabled setzen. Soll es nur für ausgewählte VLANs gelten, den globalen Status nicht zusätzlich aktivieren und mit Schritt 2 fortfahren. Vorher sicherstellen, dass über Not set kein lokal aktivierter globaler Status wirksam ist. Ist globales Snooping bereits aktiv, den Rollout nicht als VLAN-begrenzt behandeln; den Ausgangswert nur im Wartungsfenster ändern oder das Zusammenspiel auf dem konkreten Modell und Firmwarestand testen. Die gleichzeitige Konfiguration beider Aktivierungsebenen wird hier bewusst vermieden, weil die dokumentierte Oberfläche keine allgemeingültige Vorrangregel ausweist.

MAC address verification: Enabled nur dann im selben Schritt aktivieren, wenn der normale Clientpfad bereits bekannt und ein sofortiger Funktionstest möglich ist. Andernfalls zuerst Snooping mit MAC address verification: Disabled stabilisieren und die MAC-Prüfung in einem zweiten, klar abgegrenzten Schritt einschalten.

Nach jeder Auswahl festlegen, ob sofort zu den Switches synchronisiert wird, und Save wählen.

2. Alternativ: VLAN settings setzen

Für einen auf einzelne VLANs begrenzten Schutz in der Tabelle VLAN settings für jedes betroffene VLAN den Status wählen:

• Enabled: DHCP Snooping für dieses VLAN einschalten.
• Disabled: DHCP Snooping für dieses VLAN ausschalten.
• Not set: lokalen VLAN-Status des Switches verwenden.

Die Auswahl synchronisieren und mit Save bestätigen. Danach die angezeigte Configuration source kontrollieren. Nur VLANs aktivieren, deren serverseitiger Eingangsweg und Trust-Ports geprüft sind. Globalen und VLAN-spezifischen Status nicht als zwingende UND-Bedingung behandeln und aus gleichzeitig gesetzten Werten keine unbestätigte Vorrangregel ableiten. Entscheidend ist der anschliessende Positiv- und Negativtest im gewählten Geltungsbereich.

3. Trust port settings setzen

In Trust port settings jeden betroffenen Port bewusst klassifizieren:

• Trusted: Konkreter Eingangsport beziehungsweise konkretes LAG, über den oder das legitime serverseitige DHCP-Nachrichten diesen Switch erreichen dürfen.
• Untrusted: Client- oder anderer Edge-Port, auf dem keine DHCP-Serverantworten eintreffen dürfen.
• Not set: lokal konfigurierten Trust-Status verwenden.

Die Einstellungen synchronisieren und mit Save bestätigen. Für jeden kritischen Port anschliessend Configuration source prüfen. Portbezeichnung und Verkabelungsplan müssen übereinstimmen; nicht allein aus einer Beschreibung wie «Uplink» auf den physischen Pfad schliessen.

4. MAC address verification kontrolliert aktivieren

Nach erfolgreichem Basis-Test MAC address verification: Enabled setzen, synchronisieren und speichern. Dann mit einem normalen Client erneut Discover, Offer, Request und ACK beziehungsweise mindestens einen vollständigen Lease-Neubezug prüfen.

Wenn ein legitimer Client jetzt scheitert, nicht sofort weitere Ports auf Trusted setzen. Zuerst feststellen, ob die Source-MAC-Adresse des auf dem Untrusted Port eintreffenden DHCP-Pakets tatsächlich von der im Paket angegebenen Endpunkt-Hardwareadresse abweicht. Adapter, virtuelle Clients, DHCP-Proxy-Funktionen oder andere Zwischenkomponenten können den sichtbaren Paketaufbau beeinflussen. Nur nach diesem Nachweis MAC address verification gezielt auf Disabled zurücksetzen oder das Design der Zwischenkomponente korrigieren.

Binding list lesen und für die Prüfung nutzen

Die Binding list zeigt gelernte Zuordnungen mit folgenden Angaben:

• MAC-Adresse;
• IP-Adresse;
• VLAN;
• Port, an dem das Gerät verbunden ist.

Nach einem erfolgreichen Lease-Neubezug muss die Zuordnung zum erwarteten Client passen: richtige MAC-Adresse, vergebene IP aus dem richtigen Scope, richtige VLAN-ID und tatsächlicher Accessport. Bei einem Clientwechsel oder einer Lease-Erneuerung die Anzeige neu laden und nicht einen alten Eintrag als aktuellen Beweis interpretieren.

Die Liste ist besonders hilfreich, um diese Fehler zu unterscheiden:

• Kein Binding: Der DHCP-Austausch wurde nicht vollständig beobachtet oder erreicht den Switch nicht wie erwartet.
• Falsches VLAN: Portzuweisung oder Tagging-Pfad prüfen.
• Falscher Port: Patchung, Uplink-Topologie oder nachgelagerte Switches prüfen.
• Unerwartete IP-Adresse: DHCP-Scope und tatsächlich antwortenden Server untersuchen.

Die Binding list wird in dieser Oberfläche als Anzeige beschrieben. Es gibt hier keinen Schritt zum manuellen Erstellen eines statischen Bindings.

Validierung nach der Änderung

Die Freigabe erfolgt für jeden gewählten Geltungsbereich und nicht nur anhand eines grünen Switch-Status.

Positivtest mit autorisiertem DHCP-Server

1. Testclient am vorgesehenen Untrusted Accessport anschliessen.
2. Vorhandenen Lease kontrolliert erneuern oder den Client neu verbinden.
3. Prüfen, ob der Client eine Adresse aus dem erwarteten Scope, das richtige Gateway und die benötigten DHCP-Optionen erhält.
4. In Binding list MAC-Adresse, IP-Adresse, VLAN und Port abgleichen.
5. Bei Relay zusätzlich mit Protokollen oder einem Mitschnitt nachweisen, dass die Anfrage das konfigurierte Ziel erreicht. Bei einem nachgelagerten Relay den Eingang am eigentlichen DHCP-Server nachweisen. Der Test ist erst erfolgreich, wenn der Endclient den erwarteten Lease erhalten hat.
6. Den Test nach Aktivierung von MAC address verification wiederholen.

Negativtest gegen einen unerlaubten DHCP-Server

Nur in einer isolierten Testumgebung oder einem Wartungsfenster einen kontrollierten Testserver an einem Untrusted Port verwenden. Zuerst per Mitschnitt am Rogue-Port oder Serverprotokoll belegen, dass der Testserver ein Offer beziehungsweise ACK tatsächlich sendet. Gleichzeitig am Testclient oder dessen clientseitigem Switchport mitschneiden und nachweisen, dass genau diese Serverpakete dort nicht eintreffen. Alternativ oder ergänzend einen passenden Drop-Zähler beziehungsweise ein Snooping-Ereignis des Switches erfassen. Dass der Client lediglich ein anderes Angebot auswählt, genügt nicht als Blockierungsnachweis. Anschliessend einen vollständigen Lease über den autorisierten Server durchführen und damit belegen, dass dessen serverseitiger Eingangsweg weiterhin funktioniert. Keinen Rogue-DHCP-Test in einem produktiven VLAN starten, wenn dadurch andere Clients ein falsches Lease erhalten könnten.

Konfigurationskontrolle

• Relay Status und alle als DHCP-Server oder nachgelagerte Relay-Ziele vorgesehenen Server IP addresses stimmen mit dem Plan überein.
• Jede eingegebene Zieladresse wurde mit Enter übernommen.
• Der in der Vorbereitung dokumentierte Relay-Pfad ist nach der Änderung durch den serverseitigen Eingang der Anfrage und einen erfolgreichen Lease am Endclient validiert.
• Der gewählte globale oder VLAN-spezifische Snooping-Status sowie MAC address verification sind wirksam.
• Nur die konkreten Eingänge für legitime serverseitige DHCP-Nachrichten sind Trusted, Clientports Untrusted.
• Configuration source zeigt bei VLANs und Ports die erwartete zentrale oder lokale Herkunft.
• Die sofortige Synchronisation wurde verwendet oder die geplante spätere Synchronisation ist nachweislich abgeschlossen.
• Nach einem Neustart oder einer erneuten Synchronisation bleiben Adressvergabe, Schutzwirkung und Bindings plausibel.

Typische Fehlerbilder und Ursachen

Client erhält nach Aktivierung von Snooping keine Adresse

1. Prüfen, ob die konkrete Schnittstelle, auf der Offer und ACK vom legitimen Server in diesen Switch eintreffen, Trusted ist.
2. Bei mehreren Switches den gesamten Serverpfad kontrollieren, nicht nur den Client-Switch.
3. Den Status auf der gewählten globalen oder VLAN-spezifischen Aktivierungsebene prüfen; bei VLANs zusätzlich Configuration source kontrollieren. Not set kann einen unerwarteten lokalen Wert übernehmen.
4. MAC address verification testweise auf den dokumentierten vorherigen Wert zurücksetzen. Funktioniert DHCP danach, Paket-MAC und Endpunkt-Hardwareadresse untersuchen.
5. In der Binding list prüfen, ob überhaupt eine Zuordnung entsteht.

DHCP Relay liefert keinen Lease

• Status steht noch auf Not set oder Disabled, oder die Central-Änderung wurde nicht synchronisiert.
• Die Zieladresse wurde nur eingetippt, aber nicht mit Enter als Eintrag übernommen.
• Eine falsche Zieladresse ist hinterlegt oder die Grenze von fünf Server IP addresses wurde erreicht.
• Das Layer-3-VLAN-Interface des Client-VLANs ist inaktiv, falsch adressiert oder nicht dem richtigen VLAN zugeordnet.
• Der geroutete Hin- oder Rückweg zwischen dem Layer-3-VLAN-Interface und dem DHCP-Server beziehungsweise nachgelagerten Relay-Ziel fehlt, oder eine Regel beziehungsweise ACL blockiert den Pfad.
• Bei einem nachgelagerten Relay fehlt dessen Weiterleitung zum eigentlichen DHCP-Server oder ein Teil des vollständigen Rückwegs.
• Ein anderes Gerät relayed denselben Client-Broadcast ebenfalls und erzeugt einen unerwünschten zweiten Pfad.
• Snooping blockiert die zurückkommende Serverantwort, weil die konkrete Schnittstelle, über die sie in den snoopenden Switch eintritt, nicht Trusted ist. Nicht allein aufgrund der Bezeichnung «Relay» oder «Uplink» vertrauen.

Unerlaubter DHCP-Server funktioniert weiterhin

• DHCP Snooping ist auf der gewählten globalen oder VLAN-spezifischen Aktivierungsebene nicht wirksam Enabled.
• Not set übernimmt lokal einen deaktivierten Status.
• Der Rogue-Server hängt an einem fälschlich Trusted gesetzten Port.
• Der Test findet in einem anderen VLAN oder über einen anderen physischen Pfad statt.
• Snooping wurde ausgeschaltet; dann behandelt der Switch alle Ports als vertrauenswürdig.

Central zeigt den gewünschten Wert, der Switch verhält sich aber anders

Synchronisationsstatus und Zielobjekt prüfen. Danach Configuration source bei VLAN und Port lesen. Ein nicht sofort synchronisierter Wert, eine Site-Konfiguration am falschen Objekt oder ein lokaler Wert hinter Not set kann die Abweichung erklären. Nicht durch wiederholtes Speichern überdecken, sondern Central-Wert, lokalen Ursprung und wirksamen Zustand dokumentieren.

Binding fehlt oder zeigt unerwartete Werte

Den Client zu einem vollständigen Lease-Neubezug zwingen und danach neu laden. Bleibt der Eintrag aus, den DHCP-Pfad paketweise eingrenzen. Bei falschem VLAN oder Port zuerst Tagging und Verkabelung korrigieren; bei falscher IP den antwortenden DHCP-Server und dessen Scope identifizieren. Ein fehlendes Binding nicht durch manuelles Erfinden einer Zuordnung kompensieren.

Rollback

Der Rückbau richtet sich nach der Funktion, die den Fehler verursacht hat. Ausgangswerte und Configuration source müssen vorab dokumentiert sein.

MAC-Prüfung zurücknehmen

1. Unter DHCP snooping > Settings MAC address verification auf den vorherigen Wert setzen: meist Disabled oder, wenn die lokale Verwaltung bewusst erhalten bleiben soll, Not set.
2. Sofort synchronisieren und Save wählen.
3. Lease erneuern und prüfen, ob der legitime Client wieder funktioniert.

Snooping im gewählten Geltungsbereich zurücknehmen

1. Bei VLAN-spezifischer Aktivierung unter VLAN settings nur das betroffene VLAN auf seinen Ausgangswert Disabled oder Not set setzen. Bei globaler Aktivierung stattdessen den globalen Status auf seinen dokumentierten Ausgangswert zurücksetzen.
2. Synchronisieren, speichern und DHCP erneut testen.
3. Keine zweite Aktivierungsebene ändern, die für diesen Rollout nicht verwendet wurde.

Ein pauschales Umstellen aller Ports auf Trusted ist kein sauberer Rollback: Es beseitigt die Schutzgrenze und verdeckt den falsch geplanten Pfad. Wird DHCP Snooping vollständig ausgeschaltet, behandelt der Switch ohnehin alle Ports als vertrauenswürdig; dieser Zustand muss als temporärer Schutzverlust dokumentiert werden.

Trust-Port zurücksetzen

Den versehentlich geänderten Port unter Trust port settings auf den dokumentierten Ausgangswert Trusted, Untrusted oder Not set stellen, synchronisieren und speichern. Danach Configuration source und positiven Lease-Test prüfen. Beim kontrollierten Rogue-Server-Negativtest erneut per Mitschnitt, Drop-Zähler oder Snooping-Ereignis belegen, dass dessen Offer beziehungsweise ACK den Client nicht erreicht.

Relay zurücknehmen

1. Unter DHCP relay Status auf den dokumentierten Ausgangswert Disabled oder Not set setzen.
2. Neu hinzugefügte Zieladresse über das Löschsymbol aus Server IP addresses entfernen.
3. Synchronisationsoption wählen und Save betätigen.
4. Bestätigen, dass der vorherige DHCP-Pfad wieder übernimmt und kein zweiter Relay-Pfad übrig bleibt.

Nach jedem Rollback den Grund, die betroffenen VLANs und Ports, den wirksamen Konfigurationsursprung sowie das Ergebnis eines neuen Lease-Bezugs festhalten. Erst wenn autorisierte DHCP-Vergabe und beabsichtigte Schutzwirkung wieder nachgewiesen sind, ist die Änderung abgeschlossen.