DHCP-Leasequery-Methoden
In einem Netzwerk mit Anwenderzugriff verwaltet ein lokaler DHCP-Server eine beträchtliche Menge an Bindungsinformationen zu den IP-Adressen oder delegierten DHCPv6-Präfixen, die der Server an DHCP-Clients vermietet hat. Wenn DHCP-Clients über einen DHCP-Relay-Agent mit dem DHCP-Server verbunden sind, erfasst der DHCP-Relay-Agent Daten aus den weitergeleiteten DHCP-Paketen, z. B. IP-Adressen, die zum Erreichen des Endgeräts erforderlich sind. Der Relay-Agent verwaltet Lease- und Routing-Informationen, die für die DHCP-Clients relevant sind. Der Relay-Agent verwendet diese Informationen, wenn er Anwender-Services für die Clients bereitstellt. Wenn der Relay-Agent neu gestartet wird oder wenn das Hostgerät des Agenten neu gestartet oder ausgetauscht wird, verliert der Relay-Agent diese Informationen. Sie können einen request Befehl verwenden, um den Relay-Agent dazu zu bringen, eine leasequery-Nachricht an den lokalen Server zu senden, um die Bindungsinformationen für DHCP-Clients wiederherzustellen, damit der Relay-Agent seine Lease-Informationsdatenbank wiederherstellen kann.
Die Anwenderverwaltung unterstützt die folgenden Arten von leasequery-Vorgängen:
Individuelle Leasequery: Stellt Lease-Informationen für eine einzelne Bindung auf Anfrage bereit (Abfrage- und Antwortmodus).
Bulk-Leasequery: Stellt auf Anfrage Lease-Informationen für mehrere Bindungen bereit (Abfrage- und Antwortmodus).
Aktive Leasequery: Bietet einen Stream von Live-Updates für mehrere Bindungen, wenn diese konfiguriert sind.
Vorteile von DHCP Leasequery
-
Leasequery bietet einem DHCPv4- oder DHCPv6-Relay-Agent eine einfache Möglichkeit, die autorisierenden Standortinformationen im Zusammenhang mit geleasten DHCP-IP/IPv6-Adressen und delegierten Präfixen vom lokalen DHCP-Server wiederherzustellen, wenn der Relay-Agent neu gestartet oder ausgetauscht wurde.
-
Bulk leasequery macht die Abfrage einzelner Bindungen für bestimmte Clients überflüssig, sodass eine einzige Anforderung Informationen für Hunderte oder Tausende von Abonnenten zurückgeben kann. Diese Methode wartet nicht darauf, dass der Datenverkehr eine Abfrage auslöst, sodass sie besser skaliert werden kann als eine einzelne leasequery, wenn der Agent Tausende von Clients hat. Im Fall von DHCPv6 kann der Relay-Agent möglicherweise keine einzelnen Abfragen erstellen.
-
Active leasequery bietet kontinuierliche Live-Updates von Bindungsinformationen für einen oder mehrere Relay-Agenten, wenn konfiguriert. Zusätzlich zu den Aktualisierungen zwischen Relay-Agent und lokalem Server können Sie eine Peering-Beziehung zwischen Relay-Agents konfigurieren. Auf diese Weise können die Peers ihre Bindungsinformationen kontinuierlich miteinander synchronisieren, was für Redundanz sorgt, wenn ein Peer ausfällt oder neu gestartet wird. Der aktive Peer hält sofort den Dienst für die Clients aufrecht, die den betroffenen Relay-Agent verwendet haben.
DHCP Individuelle Leasequery
Ab Junos OS Version 16.1 unterstützt die Anwender-Verwaltung die individuelle leasequery-Funktion, mit der der DHCPv4- oder DHCPv6-Relay-Agent schnell und effizient die aktuellen Lease-Informationen von einem lokalen DHCP-Server abrufen kann. Der Relay-Agent kann lokal gespeicherte Lease-Informationen aus verschiedenen Gründen verlieren, z. B. weil das Relay-Agent-Gerät neu gestartet wurde. Wenn der Relaisagent anschließend Datenverkehr von einem Client zur Weiterleitung empfängt, verfügt er nicht mehr über die Informationen dazu. Eine Leasequery-Interaktion mit dem lokalen Server kann die Informationen wiederherstellen, sodass der Relay-Agent seine Clients ordnungsgemäß bedienen kann.
Um einzelne leasequery-Vorgänge zu konfigurieren, aktivieren Sie die Unterstützung sowohl auf dem DHCP-Relay-Agent als auch auf dem DHCP-Server. Sie können Details der Kommunikation zwischen dem Relay-Agent und dem Server konfigurieren. Sie müssen den request dhcp leasequery Befehl or request dhcpv6 leasequery ausführen, damit der Relay-Agent die Abfrage sendet.
Standardmäßig sendet der Relay-Agent die Anfrage an alle bekannten lokalen Server. Sie können die Server, mit denen es kommuniziert, einschränken, indem Sie eine Serveradresse oder eine benannte Gruppe von Servern angeben. Sie können die Abfrage auch auf Server in einem bestimmten logischen System, einer bestimmten Routing-Instanz oder einer LS:RI-Kombination beschränken.
DHCPv4 Individuelle Leasequery
Die DHCPv4-Leasequery kann einer von mehreren Typen sein, eine Abfrage nach Adresse, Client-ID oder MAC-Adresse. Den Abfragetyp legen Sie fest, wenn Sie die Abfrage durch Absetzen des request dhcp relay leasequery Befehls auslösen. Sie geben an, dass der DHCPv4-Relay-Agent in der DHCPLEASEQUERY-Nachricht einen der folgenden Werte enthält, damit der lokale Server die vom Agent angeforderten Bindungsinformationen identifizieren kann:
IP-Adresse einer Clientlease: Der lokale Server gibt Bindungsinformationen für den letzten Client zurück, dem diese IP-Adresse zugewiesen wurde.
Client-ID des Client-Geräts: Der lokale Server gibt Bindungsinformationen für die IP-Adresse zurück, die zuletzt von einem Client mit der angegebenen Client-ID verwendet wurde (Option 61). Der Bezeichner ist in der administrativen Domäne des Servers eindeutig. Wenn dieser Client über diesen Server auf andere IP-Adressen zugegriffen hat, gibt der Server eine Liste dieser Adressen in der zugehörigen IP-Option zurück (Option 92).
MAC-Adresse des Clientgeräts: Der lokale Server gibt Bindungsinformationen für den letzten Client zurück, der über diese MAC-Adresse verfügt. Wenn dieser Client über diesen Server auf andere IP-Adressen zugegriffen hat, gibt der Server eine Liste dieser Adressen in der zugehörigen IP-Option zurück (Option 92).
Der DHCP-Relay-Agent enthält die Option für die Parameteranforderungsliste (Option 55) in der DHCPLEASEQUERY-Nachricht. Diese Liste enthält spezifische Optionen für die Bindungsinformationen für die IP-Adresse, die vom lokalen Server zurückgegeben wird. Beispielsweise enthält die Anforderungsliste typischerweise die Option "Relay Agent-Informationen" (Option 82). Der lokale Server enthält die angeforderten Informationen in einem DHCPLEASEACTIVE, der an den Relay-Agent gesendet wird.
Die DHCPLEASEACTIVE-Nachricht enthält die Option für die Zeit der letzten Transaktion des Clients (Option 91). Der Wert dieser Option ist das Intervall in Sekunden zwischen dem Zeitpunkt, an dem die IP-Adresse zuletzt in einer Interaktion zwischen Client und Server verwendet wurde, und dem Zeitpunkt, zu dem der Serer die DHCPLEASEACTIVE-Nachricht sendet. Wenn die letzte Interaktion beispielsweise um 08:00:00 Uhr war und die Nachricht um 09:00:00 Uhr gesendet wird, lautet der Optionswert 3600.
In Tabelle 1 werden die Nachrichtentypen für DHCPv4 individual leasequery beschrieben.
Art der Nachricht |
Option 53 Typwert |
Beschreibung |
|---|---|---|
DHCPLEASEQUERY |
10 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um Informationen wiederherzustellen. |
DHCPLEASENICHT zugewiesen |
11 |
Antwort vom lokalen Server, wenn die dem Client zugeordnete IP-Adresse vom Server gesteuert, aber derzeit nicht gemietet ist. Diese Antwort wird nur für eine Abfrage nach IP-Adresse gesendet. |
DHCPLEASEUNKNOWN |
12 |
Antwort des lokalen Servers, wenn der Server keine Kenntnis von den Informationen in der Abfrage hat. |
DHCPLEASEACTIVE |
13 |
Antwort vom lokalen Server, wenn er eine Adresse an den Client vermietet hat. Die Antwort enthält vollständige verbindliche Informationen über diese Adresse. |
DHCPv6 Individuelle Leasequery
Der Abfragetyp wird in der Option LQ_Query (Option 44) vermittelt. Der DHCPv6-Relay-Agent-Abfragetyp kann nach Adresse oder Client-ID erfolgen. Den Abfragetyp legen Sie fest, wenn Sie die Abfrage durch Absetzen des request dhcpv6 relay leasequery Befehls auslösen. Sie geben an, dass der DHCPv6-Relay-Agent in der LEASEQUERY-Nachricht einen der folgenden Werte in die Option request option (Option 6) einschließt, damit der lokale Server die vom Agenten angeforderten Bindungsinformationen identifizieren kann:
IPv6-Adresse einer Clientlease: Der lokale Server gibt Bindungsinformationen für den letzten Client zurück, der an diese Adresse gebunden ist oder an den ein Präfix delegiert wurde, das die Adresse enthält. Das Feld query-options in Option 44 enthält die Option IAADDR (Option 5).
DHCP Unique Identifier (DUID) des Clientgeräts: Der lokale Server gibt Bindungsinformationen für die IP-Adresse zurück, die zuletzt von einem Client mit der angegebenen DUID verwendet wurde. Die DUID ist die IPv6-Kennung für den Client. Der Bezeichner ist in der administrativen Domäne des Servers eindeutig. Der lokale Server kann eine Liste von Adressen zurückgeben, wenn der Client auf mehr als einer Verbindungsadresse gefunden wird. Das Feld query-options in Option 44 enthält die Option Client-ID (Option 1).
Das Abfrageoptionsfeld in Option 44 kann auch die Option request option (Option 6) enthalten, um DHCPv6-Optionscodes für bestimmte Informationen aufzulisten, die vom lokalen Server für jeden Client gewünscht werden.
Die LEASEQUERY-REPLY-Nachricht enthält die Client-Datenoption (Option 45), um Informationen für einen einzelnen Client über eine einzelne Verbindung bereitzustellen. Diese Informationen werden als DHCPv6-Optionen im Feld client-options übermittelt. Option 45 enthält mindestens die folgenden Optionen und alle anderen Optionen, die vom Relay-Agenten in der Option LEASEQUERY-Optionsanforderung (Option 6) angefordert werden:
Client-ID (Option 1): DUID, die den DHCPv6-Client identifiziert.
IAADDR (Option 5) – Adresse in einer Identitätszuordnung für temporäre Adressen (IA_TA) oder nicht temporäre Adressen (IA_NA). Kann in die IAPREFIX-Option aufgenommen werden.
IAPREFIX (Option 26): Präfix in einer Identitätszuordnung für die Präfixdelegierung (IA_PD). Kann in die IAADDR-Option aufgenommen werden.
CLT-Option (Option 46): Die Zeit in Sekunden seit der letzten Interaktion des Servers mit dem Client über diese Verbindung. Diese Option entspricht der DHCPv4-Clientoption für die letzte Transaktionszeit.
Die folgenden Optionen sind Beispiele für zusätzliche Optionen, die in die LEASEQUERY-REPLY-Nachricht aufgenommen werden können:
LQ-Relay-Datenoption (Option 47): Die vollständigen Relay-Agent-Informationen, die bei der letzten Kommunikation des Clients mit diesem Server verwendet wurden. Der lokale Server gibt diese Option nur zurück, wenn sie in der Anforderungsoption LEASEQUERY-Optionen (Option 6) angefordert wird.
LQ-Client-Verbindungsoption (Option 48): Identifiziert die Verbindungsadressen, für die der Client mindestens eine Bindung hat. Die LEASEQUERY-REPLY-Nachricht enthält diese Option, wenn die beiden folgenden Bedingungen erfüllt sind: Die LEASEQUERY-Abfrage gibt keine Linkadresse an, und der Client wird auf mehr als einer Verbindung gefunden. Wenn der Relay-Agent diese Informationen erhält, kann er für jede Adresse, die in Option 48 aufgeführt ist, eine neue LEASEQUERY senden.
In Tabelle 2 werden die Nachrichtentypen für DHCPv6 individual leasequery beschrieben.
Art der Nachricht |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
LEASEQUERY |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um Informationen wiederherzustellen. Enthält die LQ-Option (Option 44), um den Typ der Abfrage, eine Verbindungsadresse und alle speziellen Optionsinformationen anzugeben, die vom lokalen Server benötigt werden. |
LEASEQUERY-REPLY |
15 |
Antwort vom lokalen Server, wenn die dem Client zugeordnete IP-Adresse vom Server gesteuert, aber derzeit nicht gemietet ist. Diese Antwort wird nur für eine Abfrage nach IP-Adresse gesendet. |
Die vom lokalen DHCPv6-Server gesendete LEASEQUERY-REPLY-Nachricht kann die Statuscodeoption (Option 13) zurückgeben, um Informationen über den Status der Abfrage bereitzustellen. Tabelle 3 listet die Statuscodes auf.
Kodex |
Status |
Beschreibung |
|---|---|---|
7 |
Unbekannter Abfragetyp |
Der Server erkennt die Abfrage nicht oder unterstützt sie nicht. |
8 |
MalformedQuery |
Die Abfrage ist ungültig. Zum Beispiel könnte eine erforderliche Option fehlen. |
9 |
NotConfigured |
Der lokale Server verfügt nicht über die erforderliche Adresse in seiner Konfiguration. |
10 |
NotAllowed |
Der lokale Server lässt nicht zu, dass der Relay-Agent diesen Abfragetyp sendet. |
DHCP Massen-Leasequery
Ab Junos OS Version 16.1 unterstützt die Anwender-Verwaltung die Bulk-Leasequery-Funktion, mit der jede Anforderung vom DHCP-Relay-Agent Lease-Informationen für mehrere Abonnenten in großen Mengen von einem konfigurierten DHCP-Server auf programmierte Weise abrufen kann. Bulk-Leasequery ist ressourceneffizienter als die Verwendung mehrerer einzelner Leasequeries, um dieselben Informationen zu sammeln. Dies ist besonders in skalierten Umgebungen mit Tausenden von Clients pro Relay-Agent nützlich.
Bulk leasequery verwendet eine TCP-Verbindung zwischen dem DHCP-Relay-Agent und einem konfigurierten DHCP-Server in derselben logischen System-/Routing-Instanz. Die TCP-Verbindung ist zuverlässiger und verbraucht weniger Ressourcen als die UDP-Verbindung, die für den individuellen leasequery-Prozess verwendet wird. Bulk leasequery erweitert auch die individuelle Leasequery um zusätzliche Abfrageoptionen und -funktionen.
Um Leasequery-Vorgänge zu konfigurieren, aktivieren Sie die Unterstützung sowohl auf dem DHCP-Relay-Agent als auch auf dem DHCP-Server. Sie können Details der Kommunikation zwischen dem Relay-Agent und dem Server konfigurieren. Sie müssen den request dhcp bulk-leasequery Befehl or request dhcpv6 bulk-leasequery ausführen, um den Relay-Agent zum Senden der leasequery auszulösen.
Standardmäßig sendet der Relay-Agent die Anfrage an alle bekannten lokalen Server. Sie können die Server, mit denen es kommuniziert, einschränken, indem Sie eine Adresse für einen Server oder eine benannte Gruppe von Servern angeben. Sie können die Abfrage auch auf Server in einem bestimmten logischen System, einer bestimmten Routing-Instanz oder einer LS:RI-Kombination beschränken.
DHCPv4 Massen-Leasequery
Für die DHCPv4-Massenleaseabfrage öffnet der DHCPv4-Relay-Agent eine TCP-Verbindung über Port 67 zum lokalen DHCPv4-Server. Wenn die Verbindung hergestellt ist, sendet der Relay-Agent eine DHCPBULKLEASEQUERY-Nachricht an den Server. Die Abfrage kann eine der folgenden Angaben enthalten, damit der lokale Server die vom Agent benötigten Informationen identifizieren kann:
Alle konfigurierten IP-Adressen: Der lokale Server gibt Bindungsinformationen für alle IP-Adressen zurück, die auf dem lokalen Server konfiguriert sind. Die Informationen werden unabhängig davon zurückgegeben, ob die IP-Adressen Teil einer derzeit aktiven Bindung sind. Auf diese Weise kann der Relay-Agent seine Datenbank mit allen Adressänderungen aktualisieren, die nach einem bestimmten Zeitpunkt aufgetreten sind.
Client-ID des Client-Geräts: Der lokale Server gibt Bindungsinformationen für die IP-Adresse zurück, die zuletzt von einem Client mit der angegebenen Client-ID verwendet wurde (Option 61). Der Bezeichner ist in der administrativen Domäne des Servers eindeutig.
Hinweis:Im Gegensatz zu einer einzelnen leasequery verwendet der Server nicht die zugehörige IP-Option (Option 92), um eine Liste anderer IP-Adressen zurückzugeben, auf die der Client über diesen Server zugegriffen hat. Stattdessen gibt der Server Bindungsinformationen für alle diese IP-Adressen zurück
MAC-Adresse des Clientgeräts: Der lokale Server gibt Bindungsinformationen für den letzten Client zurück, der über diese MAC-Adresse verfügt.
Hinweis:Im Gegensatz zu einer einzelnen leasequery verwendet der Server nicht die zugehörige IP-Option (Option 92), um eine Liste anderer IP-Adressen zurückzugeben, auf die der Client über diesen Server zugegriffen hat. Stattdessen gibt der Server Bindungsinformationen für alle diese IP-Adressen zurück
Relay-Agent-ID: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die dem Client zugewiesen sind, der über die angegebene Relay-Agent-ID verfügt (Option 82, Unteroption 12). Der Bezeichner ist in der administrativen Domäne des Servers eindeutig.
Remote-ID eines Zugriffscircuits, der vom Client verwendet wird, um den Circuit zum DHCP-Client zu identifizieren: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die Clients zugewiesen sind, die diese Agent-Remote-ID verwenden (Option 82, Unteroption 2). Diese Abfrage ist besonders nützlich in skalierten Umgebungen mit Tausenden von Clients pro Relay-Agent. Die anderen Abfragen geben keine konsolidierten Leaseinformationen für alle Clients in einer Verbindung zurück.
Der lokale DHCPv4-Server antwortet dem Relay-Agent mit den gleichen DHCPLEASEACTIVE- und DHCPLEASEUNASSIGNED-Nachrichten, die für einzelne leasequery verwendet werden, wie unter DHCPv4 Individual leasequery message types beschrieben. Jede Nachricht entspricht einer einzelnen Bindung, die von der Abfrage identifiziert wird.
Wenn der Server alle der Anforderung zugeordneten Bindungen zurückgegeben hat, sendet er eine DHCPLEASEQUERYDONE-Nachricht an den Relay-Agent. Wenn eine Verbindung während der Verarbeitung einer Massen-Lease-Abfrage unterbrochen wird, kann DHCP nicht bestimmen, wie viele der angeforderten Informationen der Relay-Agent erhalten hat, bevor die Verbindung unterbrochen wurde. Folglich muss der Relay-Agent die Abfrage wiederholen.
Für jede der Abfragemethoden kann der DHCP-Relay-Agent den folgenden Qualifizierer enthalten:
query-start-time: Gibt Bindungen zurück, die sich am oder nach der in der Abfrage angegebenen Zeit geändert haben.
query-endtime: Gibt Bindungen zurück, die sich am oder vor dem in der Abfrage angegebenen Zeitpunkt geändert haben.
Diese Abfragezeiten ermöglichen es einem Agenten, nur Bindungsinformationen wiederherzustellen, die er verloren hat, seit er alle seine Informationen in den stabilen Speicher übertragen hat.
In Tabelle 4 werden die für DHCPv4 Bulk leasequery spezifischen Nachrichtentypen beschrieben.
Art der Nachricht |
Option 53 Typwert |
Beschreibung |
|---|---|---|
DHCPBULKLEASEQUERY |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um Informationen wiederherzustellen. |
DHCPLEASEQUERYDONE |
15 |
Antwort vom lokalen Server, wenn er alle Bindungsinformationen zurückgegeben hat, die der Massenanforderung zugeordnet sind. |
Die vom lokalen DHCPv4-Server gesendeten Nachrichten können die Statuscodeoption (Option 151) zurückgeben, um Informationen über den Status der Abfrage bereitzustellen. In DHCPLEASEACTIVE- und DHCPLEASEUNASSIGNED-Nachrichten entspricht der Code dem Status für die einzelne Bindungsanforderung. In DHCPLEASEQUERYDONE-Nachrichten entspricht der Code der Massen-Leasequery-Anforderung als Ganzes. Tabelle 5 listet die Statuscodes auf.
Kodex |
Status |
Beschreibung |
|---|---|---|
0 |
Erfolg |
Die Anfrage wurde erfolgreich abgeschlossen. Das Fehlen von Option 151 deutet ebenfalls auf einen Erfolg hin. |
1 |
UnSpecFail |
Die Anforderung ist aus einem nicht näher angegebenen Grund fehlgeschlagen. |
2 |
Abfrage beendet |
Der lokale Server konnte die Abfrage entweder nicht ausführen oder er hat die Abfrage vorzeitig beendet. Im letzteren Fall gibt eine Textzeichenfolge die Ursache an. |
3 |
MalformedQuery |
Die Abfrage wurde vom lokalen Server nicht verstanden. |
4 |
NotAllowed |
Die Abfrage wurde verstanden, aber nicht zugelassen. |
DHCPv6 Massen-Leasequery
Für die DHCPv6-Massenleaseabfrage öffnet der DHCPv6-Relay-Agent eine TCP-Verbindung über Port 67 mit dem lokalen DHCPv6-Server. Wenn die Verbindung hergestellt ist, sendet der Relay-Agent eine LEASEQUERY-Nachricht an den Server. Der Abfragetyp wird in der Option LQ_Query (Option 44) vermittelt. Der Abfragetyp kann einer der folgenden sein, damit der lokale Server die vom Agent benötigten Informationen identifizieren kann:
Alle konfigurierten IP-Adressen: Der lokale Server gibt Bindungsinformationen für alle IP-Adressen zurück, die auf dem lokalen Server konfiguriert sind. Die Informationen werden unabhängig davon zurückgegeben, ob die IP-Adressen Teil einer derzeit aktiven Bindung sind. Auf diese Weise kann der Relay-Agent seine Datenbank mit allen Adressänderungen aktualisieren, die nach einem bestimmten Zeitpunkt aufgetreten sind.
Client-ID des Client-Geräts: Der lokale Server gibt Bindungsinformationen für die IP-Adresse zurück, die zuletzt von einem Client mit der angegebenen Client-ID verwendet wurde (Option 61). Der Bezeichner ist in der administrativen Domäne des Servers eindeutig.
Hinweis:Im Gegensatz zu einer einzelnen leasequery verwendet der Server nicht die zugehörige IP-Option (Option 92), um eine Liste anderer IP-Adressen zurückzugeben, auf die der Client über diesen Server zugegriffen hat. Stattdessen gibt der Server Bindungsinformationen für alle diese IP-Adressen zurück
MAC-Adresse des Clientgeräts: Der lokale Server gibt Bindungsinformationen für den letzten Client zurück, der über diese MAC-Adresse verfügt.
Hinweis:Im Gegensatz zu einer einzelnen leasequery verwendet der Server nicht die zugehörige IP-Option (Option 92), um eine Liste anderer IP-Adressen zurückzugeben, auf die der Client über diesen Server zugegriffen hat. Stattdessen gibt der Server Bindungsinformationen für alle diese IP-Adressen zurück
Relay-Agent-ID: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die dem Client zugewiesen sind, der über die angegebene Relay-Agent-ID verfügt (Option 82, Unteroption 12). Der Bezeichner ist in der administrativen Domäne des Servers eindeutig.
Remote-ID eines Zugriffscircuits, der vom Client verwendet wird, um den Circuit zum DHCP-Client zu identifizieren: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die Clients zugewiesen sind, die diese Agent-Remote-ID verwenden (Option 82, Unteroption 2). Diese Abfrage ist besonders nützlich in skalierten Umgebungen mit Tausenden von Clients pro Relay-Agent. Die anderen Abfragen geben keine konsolidierten Leaseinformationen für alle Clients in einer Verbindung zurück.
Für eine DHCPv6-Massen-Leasequery können Sie optional die trigger automatic Option angeben, den DHCPv6-Relay-Agent so zu konfigurieren, dass der Bulk-Leasequery-Vorgang automatisch initiiert wird, wenn der jdhcpd Prozess eine Verbindung mit der Sitzungsdatenbank (SDB) startet und keine gebundenen Abonnenten in der Datenbank vorhanden sind. Der automatische Prozess würde beispielsweise sicherstellen, dass die Bulk-Lease-Abfrage die DHCP-Relayinformationen immer nach einem Neustart, GRES- oder ISSU-Vorgang aktualisiert und wenn keine gebundenen Abonnenten vorhanden sind.
Die DHCPv6-Massen-Leasequery verwendet die LEASEQUERY- und LEASEQUERY-REPLY-Nachrichten, die von der DHCPv6-Einzel-Leasequery verwendet werden, aber ihr Verhalten und ihre Bedeutung unterscheiden sich bei der Massen-Leasequery geringfügig. Tabelle 6 listet diese Nachrichten auf und beschreibt zwei weitere Nachrichtentypen, die für DHCPv6-Massenleaseabfragen spezifisch sind.
Art der Nachricht |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
LEASEQUERY |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um Informationen wiederherzustellen. |
LEASEQUERY-REPLY |
15 |
Antwort des lokalen Servers, um den Erfolg oder Misserfolg der Abfrage anzuzeigen. Außerdem werden Informationen wie die Server-ID und die Client-ID übermittelt, die sich im Kontext einer einzelnen Abfrage und Antwort nicht ändern. Wenn die Abfrage erfolgreich ist, wird nur eine einzige LEASEQUERY-REPLY zurückgegeben. Diese Nachricht enthält auch die Bindungsinformationen für den ersten Client. Zusätzliche Bindungsdaten werden in der LEASEQUERY-DATA-Nachricht zurückgegeben. Wenn die Abfrage fehlschlägt, wird eine einzelne LEASEQUERY-REPLY ohne Bindungsinformationen zurückgegeben. |
LEASEQUERY-DONE |
16 |
Antwort vom lokalen Server, die das Ende einer Gruppe verwandter leasequery-Antworten anzeigt. Eine einzelne LEASEQUERY-DONE-Nachricht wird gesendet, nachdem alle Antworten auf die Anforderung an den Relay-Agent gesendet wurden. Die TCP-Verbindung zwischen dem Relay-Agent und dem Server wird geschlossen, wenn diese Nachricht empfangen wird. |
LEASEQUERY-DATEN |
17 |
Antwort vom lokalen Server mit Informationen zu den Leases für einen einzelnen DHCPv6-Client oder zu Präfixdelegierungsbindungen für eine einzelne Verbindung. Diese Nachricht wird nur gesendet, wenn die Massen-Leasequery Daten für mehrere Clients zurückgibt. In diesem Fall übermittelt die LEASEQUERY-REPLY-Nachricht Informationen für den ersten Mandanten, dann wird eine LEASEQUERY-DATA-Nachricht für jeden der anderen Mandanten gesendet. |
Die vom lokalen DHCPv6-Server gesendeten Nachrichten können die Statuscodeoption (Option 13) zurückgeben, um Informationen über den Status der Abfrage bereitzustellen. In LEASEQUERY-REPLY-Nachrichten entspricht der Code dem Status für die einzelne Bindungsanforderung. In LEASEQUERY-DONE-Nachrichten entspricht der Code der gesamten Leasequery-Massenanforderung. LEASEQUERY-DATA-Nachrichten enthalten keinen Statuscode. Die DHCPv6-Massen-Leasequery unterstützt die DHCPv6-Statuscodes für individuelle Leasequerys, die unter DHCPv6 Individual Leasequery Status Codes aufgeführt sind. Die Nachrichten können auch den Statuscode enthalten, der für die in Tabelle 7 beschriebene Massen-Leasequery hinzugefügt wurde.
Kodex |
Status |
Beschreibung |
|---|---|---|
11 |
Abfrage beendet |
Der lokale Server kann keine Abfrage ausführen oder hat die Abfrage aus irgendeinem Grund vorzeitig beendet. Beispielsweise wird der lokale Server heruntergefahren oder verfügt nicht über ausreichende Ressourcen, um die angeforderten Informationen zu sammeln. |
DHCP Active Leasequery
Ab Junos OS Version 19.1R1 behebt die aktive DHCP-Leasequery das Problem, in dem es für den Relay-Agent wünschenswert ist, regelmäßige Aktualisierungen der Client-Informationen zu erhalten, um mit der dynamischen DHCP-Bindungsaktivität Schritt zu halten. Einzel- und Massenmietanfragen liefern Informationen nur, wenn sie angefordert werden; Wenn die Clientinformationen später auf dem lokalen Server aktualisiert werden, werden diese Informationen nicht an den Relay-Agent übergeben, es sei denn, der Relay-Agent sendet eine weitere Abfrage an den lokalen Server.
Active leasequery ermöglicht Servern die Bereitstellung von Liveupdates von Clientinformationen, wenn sich der Bindungsstatus ändert. Optional können Sie active leasequery so konfigurieren, dass die Live-Aktualisierungen von Bindungsinformationen an mehrere Relay-Agent-Peers gesendet werden, wobei die Relay-Agent-Chassis-Level-Redundanz unterstützt wird. Die Liveaktualisierung wird initiiert, wenn der Relay-Agent eine TCP-Verbindung mit einem Server- oder Relay-Agent-Peer startet und die ACTIVELEASEQUERY-Nachricht sendet, um anzugeben, dass die Verbindung offen bleiben muss.
DHCP schließt die TCP-Verbindung nur, wenn bestimmte Bedingungen eintreten, die meist mit den konfigurierbaren Timeout- oder Leerlauf-Timeout-Zeiträumen zusammenhängen:
-
Wenn eine Verbindungsanforderung in einem logischen System oder einer Routing-Instanz empfangen wird, die nicht für die aktive leasequery konfiguriert ist.
-
Wenn die Verbindung während TCP-Lese-/Schreibvorgängen lange genug blockiert wird, bis der Timeoutzeitraum abgelaufen ist, wird die Verbindung geschlossen und kann neu gestartet werden. Der Lesevorgang ist, wenn der Relay-Agent versucht, Antworten auf die Abfrage zu lesen. Der Schreibvorgang liegt vor, wenn der Server- oder Peer-Relay-Agent versucht, Antworten an einen Relay-Agenten zu senden
-
Wenn für die Dauer des Leerlauf-Timeouts kein Datenverkehr über die Verbindung empfangen wird.
Während aktiver leasequery-Vorgänge werden Bindungsinformationen nur aktualisiert, wenn sie sich ändern. Folglich gibt es Zeiträume, in denen der Server oder Peer-Relay-Agent keine Informationen sendet. Wenn der Zeitraum länger als das Leerlauf-Timeout ist, wird die Verbindung unterbrochen. Um unangemessene Verbindungsabbrüche zu vermeiden, sendet der Server- oder Peer-Relay-Agent DHCPv4- (DHCPv4) oder LEASEQUERY-DATA (DHCPv6)-Nachrichten in Intervallen, die der Hälfte der Leerlaufzeit entsprechen. Diese Nachrichten enthalten keine verbindlichen Informationen, da sie gesendet werden, wenn keine Aktualisierungen verfügbar sind. Diese Nachrichten halten die Verbindung aufrecht, indem sie als Hallo- oder Keepalive-Nachrichten dienen, die signalisieren, dass der Mangel an Aktivität kein Problem darstellt.
Wenn die TCP-Verbindung geschlossen wird, versucht der Relay-Agent, die Verbindung wiederherzustellen. Die Wiederholungsversuche umfassen eine Option, die dem Server oder Peer-Relay-Agent signalisiert, Bindungsinformationen zu senden, die sich seit dem Beenden der TCP-Verbindung geändert haben. Diese Informationen werden manchmal als Nachholinformationen bezeichnet. Die Option gibt den absoluten Zeitstempel an, wenn die Verbindung beendet wird. Das heißt, der Zeitpunkt der letzten erfolgreichen Kommunikation mit dem Server oder Peer-Relay-Agenten. DHCPv4 verwendet die Option query-start-time (Option 154). DHCPv6 verwendet die Option LQ_START_TIME (Option 101).
In einigen Fällen verfügt der Server- oder Peer-Relay-Agent nicht über alle Informationen für Bindungsänderungen seit dem Zeitstempel. Beispielsweise verfügt das Gerät möglicherweise nicht über genügend Speicher, um alles zu speichern. In diesen Fällen gibt das Gerät eine DHCPLEASEQUERYSTATUS (DHCPv4)- oder LEASEQUERY-REPLY (DHCPv6)-Nachricht mit dem Statuscode DataMissing (5) zurück.
Bevor Sie Active LeaseQuery konfigurieren, müssen Sie zuerst Bulk-LeaseQuery konfigurieren, da Active LeaseQuery den Bulk-LeaseQuery-Mechanismus verwendet. Die aktive Leasequery-Konfiguration schlägt die Commit-Prüfung fehl, wenn die Massen-Leasequery nicht konfiguriert ist.
Um aktive leasequery-Vorgänge zu konfigurieren, aktivieren Sie die Unterstützung sowohl auf dem DHCP-Relay-Agent als auch auf dem DHCP-Server. Sie können Details der Kommunikation sowohl für den Relay-Agent als auch für den lokalen Server konfigurieren. Im Gegensatz zu Einzel- und Massen-Leasequery hat Active Leasequery keine Abfragetypen. Sie lösen die aktive leasequery nicht mit einem request Befehl aus. Stattdessen wird automatisch ausgelöst, wenn die aktive leasequery konfiguriert ist.
- DHCPv4 Active Leasequery
- DHCPv6 Active Leasequery
- Redundanz auf Chassis-Ebene mit aktiver Leasequery
DHCPv4 Active Leasequery
Bei DHCPv4 Active leasequery öffnet der DHCPv4-Relay-Agent eine TCP-Verbindung über Port 67 zum lokalen DHCPv4-Server. Wenn die Verbindung hergestellt ist, sendet der Relay-Agent eine DHCPACTIVELEASEQUERY-Nachricht an den Server. Die Meldung signalisiert, dass es sich um eine langfristige Verbindung handelt. Sie wird nur aufgrund einer Zeitüberschreitung geschlossen.
Der lokale DHCPv4-Server antwortet dem Relay-Agent mit den gleichen DHCPLEASEACTIVE- und DHCPLEASEUNASSIGNED-Nachrichten, die für einzelne leasequery verwendet werden, wie unter DHCPv4 Individual leasequery message types beschrieben. Jede Nachricht entspricht einer einzelnen Bindung, die von der Abfrage identifiziert wird. Der lokale DHCP-Server sendet weiterhin die Antwortnachrichten, wenn sich die Bindungsinformationen ändern. In Tabelle 8 werden die Nachrichtentypen beschrieben, die für DHCPv4 Active leasequery spezifisch sind.
| Art der Nachricht |
Option 53 Typwert |
Beschreibung |
|---|---|---|
| DHCPACTIVELEASEQUERY |
16 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Live-Aktualisierung von Bindungsinformationen auf dem Relay-Agent zu ermöglichen, wenn sich diese Informationen auf dem lokalen Server ändern. Kann auch zwischen Peer-Relay-Agenten gesendet werden, um Hot-Standby-Redundanz für Bindungsinformationen bereitzustellen. |
| DHCPLEASEQUERYSTATUS |
17 |
Antwort vom lokalen Server, wenn er Bindungsinformationen zurückgegeben hat, die der Anforderung zugeordnet sind. Da die TCP-Verbindung langlebig ist, wird diese Nachricht auch regelmäßig gesendet, wenn die Verbindungen im Leerlauf sind (es werden keine Bindungsaktualisierungen gesendet). In diesem Fall enthält die Nachricht einen ConnectionActive-Statuscode (6), um den Relay-Agenten darüber zu informieren, dass die Verbindung noch besteht. |
Die vom lokalen Server gesendeten Nachrichten können die Statuscodeoption (Option 151) zurückgeben. In DHCPLEASEACTIVE- und DHCPLEASEUNASSIGNED-Nachrichten entspricht der Code dem Status der einzelnen Antwort. In DHCPLEASEQUERYSTATUS-Nachrichten entspricht der Code dem Nachrichtenstrom für die aktive leasequery-Anforderung als Ganzes. DHCPv4 Active leasequery unterstützt die in DHCPv4 Bulk leasequery Statuscodes aufgeführten Statuscodes. Die Meldungen können auch die Statuscodes enthalten, die für die inTabelle 9 beschriebene aktive leasequery hinzugefügt wurden.
| Kodex |
Status |
Beschreibung |
|---|---|---|
| 5 |
Daten fehlen |
Die angeforderten verbindlichen Auskünfte liegen nicht vor. Wenn der lokale Server oder Peer beispielsweise nicht über genügend Daten verfügt, die mit der Option query-start-time angefordert werden, wird dieser Statuscode sofort in einer LEASEQUERY-REPLY-Nachricht gesendet. |
| 6 |
ConnectionActive |
Die TCP-Verbindung ist noch aktiv. |
| 7 |
CatchUpComplete |
Der lokale Server hat alle vom Relay-Agenten angeforderten gespeicherten Daten gesendet. |
DHCPv6 Active Leasequery
Bei aktiver DHCPv6-Leasequery öffnet der DHCPv6-Relay-Agent eine TCP-Verbindung über Port 67 zum lokalen DHCPv4-Server. Wenn die Verbindung hergestellt ist, sendet der Relay-Agent eine ACTIVELEASEQUERY-Nachricht an den Server. Die Meldung signalisiert, dass es sich um eine langfristige Verbindung handelt. Sie wird nur aufgrund einer Zeitüberschreitung geschlossen.
Der lokale DHCPv6-Server antwortet dem Relay-Agent mit den gleichen LEASEQUERY-REPLY-, LEASEQUERY-DATA- und LEASEQUERY-DONE-Nachrichten, die für die Massen-Leasequery verwendet werden. Jede Nachricht entspricht einer einzelnen Bindung, die von der Abfrage identifiziert wird. Der lokale DHCP-Server sendet weiterhin die Antwortnachrichten, wenn sich die Bindungsinformationen ändern. Tabelle 10 listet diese Meldungen und den Abfragenachrichtentyp auf, der für DHCPv6 Active leasequery spezifisch ist.
| Art der Nachricht |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
| ACTIVELEASEQUERY |
22 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Live-Aktualisierung von Bindungsinformationen auf dem Relay-Agent zu ermöglichen, wenn sich diese Informationen auf dem lokalen Server ändern. Kann auch zwischen Peer-Relay-Agenten gesendet werden, um Hot-Standby-Redundanz für Bindungsinformationen bereitzustellen. |
| LEASEQUERY-REPLY |
15 |
Antwort des lokalen Servers, um den Erfolg oder Misserfolg der Abfrage anzuzeigen. Außerdem werden Informationen wie die Server-ID und die Client-ID übermittelt, die sich im Kontext einer einzelnen Abfrage und Antwort nicht ändern. Wenn die Abfrage erfolgreich ist, wird nur eine einzige LEASEQUERY-REPLY zurückgegeben. Diese Nachricht enthält auch die Bindungsinformationen für den ersten Client. Zusätzliche Bindungsdaten werden in der LEASEQUERY-DATA-Nachricht zurückgegeben. Wenn die Abfrage fehlschlägt, wird eine einzelne LEASEQUERY-REPLY ohne Bindungsinformationen zurückgegeben. |
| LEASEQUERY-DONE |
16 |
Antwort des lokalen Servers, die angibt, dass die Verbindung beendet werden soll. Der Server kann dies beispielsweise mit dem Statuscode QueryTerminated (11) senden, wenn der Server heruntergefahren wird. |
| LEASEQUERY-DATEN |
17 |
Antwort vom lokalen Server mit Informationen zu den Leases für einen einzelnen DHCPv6-Client oder zu Präfixdelegierungsbindungen für eine einzelne Verbindung. Diese Nachricht wird nur gesendet, wenn die leasequery Daten für mehrere Clients zurückgibt. In diesem Fall übermittelt die LEASEQUERY-REPLY-Nachricht Informationen für den ersten Mandanten, dann wird eine LEASEQUERY-DATA-Nachricht für jeden der anderen Mandanten gesendet. |
Die vom lokalen DHCPv6-Server gesendeten Nachrichten können die Statuscodeoption zurückgeben (Option 13). DHCPv6 Active leasequery unterstützt die Statuscodes für individuelle Leasequery und Bulk-Leasequery, die in DHCPv6 Individual Leasequery Status Codes bzw. DHCPv6 Bulk Leasequery Status Code aufgeführt sind. Die Meldungen können auch die Statuscodes enthalten, die für die in Tabelle 11 beschriebene aktive leasequery hinzugefügt wurden.
| Kodex |
Status |
Beschreibung |
|---|---|---|
| 12 |
Daten fehlen |
Die angeforderten verbindlichen Auskünfte liegen nicht vor. |
| 13 |
CatchUpComplete |
Der lokale Server hat alle vom Relay-Agenten angeforderten gespeicherten Daten gesendet. |
| 14 |
NotSupported |
Der lokale Server hat alle vom Relay-Agenten angeforderten gespeicherten Daten gesendet. |
Redundanz auf Chassis-Ebene mit aktiver Leasequery
Sie können active leasequery verwenden, um die Synchronisierung von Bindungsinformationen zwischen mehreren DHCP-Relay-Agent-Peers zu ermöglichen. Der Einfachheit halber wird in dieser Diskussion das Verhalten mit nur zwei Peers erläutert. Wenn ein Peer-Relay-Agent neu startet oder sein Gerät neu gestartet wird, kann das andere Relay ohne sichtbaren Ausfall übernehmen und Dienste für alle DHCP-Clients bereitstellen. Wenn der Peer-Relay-Agent wieder hochfährt, stellt er die TCP-Verbindung mit dem aktiven Peer wieder her. Die Peers synchronisieren dann die Bindungsinformationen. Abbildung 1 zeigt eine einfache DHCP-Topologie zur Unterstützung der Relay-Agent-Redundanz mit den folgenden Merkmalen:
-
Jeder DHCP-Client verbindet sich mit beiden Relay-Agents.
-
Beide Relay-Agents verbinden sich mit demselben DHCP-Server.
-
Wenn Sie die
active leasequeryAnweisung auf jedem Relay-Agent konfigurieren, geben Sie auch den anderen Relay-Agent als Peer an. -
Die Peers verwenden für die Kommunikation die gleichen aktiven leasequery-Nachrichten, wie in Tabelle 8 und Tabelle 10 erläutert. Obwohl es hier nicht dargestellt wird, gibt es keine Unterschiede in den Interaktionen mit dem RADIUS-Server, wenn ein externer RADIUS-Server Teil der Topologie ist.
In der folgenden Sequenz wird beschrieben, wie die Relay-Agents die Peer-Beziehung herstellen und Bindungsinformationen austauschen, wenn die aktive leasequery auf beiden konfiguriert ist. Dieses Beispiel gilt für DHCPv4, aber der Mechanismus ist für DHCPv6 derselbe.
-
Beide Relay-Agents verfügen über aktive DHCP-Clientbindungen, aber die aktive leasequery ist noch nicht konfiguriert.
-
Sie konfigurieren die aktive leasequery auf beiden Relay-Agents, geben sich gegenseitig als Peers an und bestätigen die Konfiguration.
-
Beide Peer-Agents versuchen, eine TCP-Verbindung herzustellen, wenn die Konfiguration festgeschrieben wird. Angenommen, Relay-Agent Relay Agent 1 stellt die Verbindung erfolgreich her. Der Versuch von Peer-Relay-Agent 2 wird abgebrochen.
-
Relay Agent 1 sendet dann eine ACTIVELEASEQUERY-Nachricht an Relay Agent 2.
-
Relay Agent 2 sendet Informationen über die Bindungen in seiner Anwender-Datenbank an Relay Agent 1. Außerdem sendet er eine eigene ACTIVELEASEQUERY-Nachricht an Relay Agent 1, um die Clientinformationen des Peers zu sammeln.
-
Relaisagent 1 sendet seine Bindungsinformationen an Relaisagent 2. Relais-Agent 1 und Relais-Agent 2 verarbeiten jeweils die empfangenen Bindungsinformationen und übertragen sie in ihre jeweiligen Datenbanken.
-
Wenn jeder Relay-Agent Bindungsinformationen für seine eigenen Clients aktualisiert – z. B. Lizenzverlängerungen, neue Anfragen, Ablauf von Leases usw. –, sendet er bei jeder Änderung eine leasequery-Antwortnachricht mit den aktualisierten Informationen an seinen Peer.
-
Nehmen wir nun an, Relay Agent 1 wird neu gestartet. Die TCP-Verbindung wird unterbrochen. Relay Agent 2 versucht, die Verbindung mit Relay Agent 1 wiederherzustellen. In der Zwischenzeit fließt der DHCP-Anwender-Datenverkehr, der früher durch Relay Agent 1 floss, jetzt ohne Unterbrechung durch Relay Agent 2.
-
Die aktive Leasequery wird auf Relay Agent 1 ausgelöst, wenn er wieder hochgefahren wird. Die TCP-Verbindung wird wiederhergestellt und die Peers tauschen ACTIVELEASEQUERY-Nachrichten aus. Relay Agent 1 hat zu diesem Zeitpunkt keine verbindlichen Informationen, die er weitergeben könnte. Relaisagent 2 sendet alle aktuellen Bindungsinformationen an Relaisagent 1. Diese Informationen könnten sich geändert haben, während Relay Agent 1 außer Betrieb war. Das Ergebnis ist, dass beide Relay-Agenten jetzt über synchronisierte Datenbanken verfügen.
Richtlinien für die Konfiguration der Unterstützung für Einzel-, Bulk- und aktive Leasequery-Vorgänge
Beachten Sie bei der Konfiguration der Unterstützung für Einzel-, Massen- oder aktive LeaseQueries die folgenden Richtlinien:
Der Router unterstützt die gleichzeitige Konfiguration von individuellen Leasequeries, Bulk-Leasequeries und aktiven Leasequeries. Für die aktive Leasequery muss eine Massen-Leasequery konfiguriert werden.
Der Router unterstützt die gleichzeitige Dual-Stack-Konfiguration für DHCPv4 und DHCPv6. Für Dual-Stack-Umgebungen müssen Sie jedoch die einzelnen DHCPv4- und DHCPv6-Leasequery- oder Massen-Leasequery-Vorgänge separat auslösen.
Der DHCP-Relay-Agent unterstützt individuelle Lease-Abfragen oder Massen-Lease-Abfragen über statische und dynamische Schnittstellen. Active leasequery wird nur auf serverseitigen statischen Schnittstellen oder statischen Peer-Schnittstellen für Chassis-Redundanz unterstützt.
Der lokale DHCP-Server unterstützt Massen-Leasequery nur auf statischen Schnittstellen mit Relaisverbindung.
Der lokale DHCP-Server lauscht auf Massen-Leasequery- und aktive Leasequery-Anfragen vom DHCP-Relay-Agent auf der TCP-Verbindung auf Port 67 für DHCPv4 und auf Port 547 für DHCPv6.
Massen-Leasequery und aktive Leasequery werden für DHCP über PPP/PPPoE nicht unterstützt.
Active leasequery wird über die folgenden Stack-Kombinationen unterstützt:
DHCP over static interfaces (ge/ae/xe/irb/ps) (Unterstützung für ps-Schnittstellen in Junos OS Version 20.1R1 hinzugefügt.)
DHCP über IP Demux-Schnittstellen
DHCP über VLAN Demux-Schnittstellen
DHCP über IP über VLAN Demux-Schnittstellen
Ab Junos OS Version 19.1R1 fügt der DHCPv4-Relay-Agent die Relay-ID-Option in jedes Paket ein, das er wie folgt an den lokalen DHCP-Server weiterleitet:
Der Relay-Agent fügt die Option immer in nicht snooped Pakete ein.
Der Relay-Agent fügt die Option nur dann in Snooped-Pakete ein, wenn in diesem LS:RI eine Massen-Leasequery konfiguriert ist.
Wenn das Netzwerk über integrierte Routing- und Bridging-Schnittstellen (IRB) verfügt, müssen Sie den DHCP-Relay-Agent so konfigurieren, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID von Option 82 aufgenommen wird. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.
Konfiguration und Verwendung von DHCP Individual Leasequery
Der einzelne leasequery-Vorgang aktualisiert die lease-Datenbank eines DHCP-Relay-Agenten mit Informationen zu einem einzelnen, angegebenen Anwender. Sie identifizieren DHCPv4-Abonnenten anhand der IPv4-Adresse, MAC-Adresse oder Client-ID des DHCP-Clients. Sie identifizieren DHCPv6-Abonnenten anhand der IPv6-Adresse oder Client-ID des DHCP-Clients.
Bevor Sie beginnen, lesen Sie Richtlinien für die Konfiguration der Unterstützung für Einzel-, Massen- und aktive Leasequery-Vorgänge und stellen Sie sicher, dass die folgende erforderliche Unterstützung auf dem DHCP-Relay-Agent konfiguriert ist.
(Nur DHCPv4) Der DHCP-Relay-Agent fügt Option 82 Unteroption 1 (Agent-Circuit-ID) in die DHCP-Pakete ein, die das Relay an DHCP-Server weiterleitet. Siehe Verwenden des DHCP Relay Agent Option 82 Informationen.
Wenn das Netzwerk integrierte Routing- und Bridging-Schnittstellen (IRB) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCP-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID von Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei der Wiederherstellung der Lease-Datenbank mithilfe von LeaseQuery oder Bulk LeaseQuery.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(Nur DHCPv4) Der DHCP-Relay-Agent enthält immer die neuen Informationen der Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Siehe Informationen zum Überschreiben von Option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(Nur DHCPv6) Der DHCP-Relay-Agent fügt die DHCPv6-Schnittstellen-ID (Option 18) in die Pakete ein, die das Relay an DHCPv6-Server weiterleitet. Siehe Einfügen der DHCPv6-Schnittstellen-ID-Option (Option 18) in DHCPv6-Pakete.
Wenn Ihr Netzwerk über integrierte Routing- und Bridging-Schnittstellen (IRB) verfügt, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCPv6-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID der Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Führen Sie die folgenden Schritte aus, um den einzelnen leasequery-Vorgang zu konfigurieren und zu verwenden.
Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen über den Massen-Leasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server. Siehe Überprüfen und Verwalten von DHCP-Einzel- und Massen-Leasequery-Konfigurationen.
Konfiguration und Verwendung von DHCP Bulk Leasequery
Der Massen-Leasequery-Vorgang aktualisiert die Lease-Datenbank eines DHCP-Relay-Agents mit Informationen für mehrere Abonnenten, im Gegensatz zur einzelnen Leasequery, bei der einzelne Bindungen nur für bekannte Ziele abgefragt werden. Bulk leasequery erweitert auch die individuelle Leasequery um zusätzliche Abfrageoptionen und -funktionen.
Bevor Sie beginnen, lesen Sie Richtlinien für die Konfiguration der Unterstützung für Einzel-, Massen- und aktive Leasequery-Vorgänge und stellen Sie sicher, dass die folgende erforderliche Unterstützung auf dem DHCP-Relay-Agent konfiguriert ist.
(Nur DHCPv4) Der DHCP-Relay-Agent fügt Option 82 Unteroption 1 (Agent-Circuit-ID) in die DHCP-Pakete ein, die das Relay an DHCP-Server weiterleitet. Siehe Verwenden des DHCP Relay Agent Option 82 Informationen.
Wenn das Netzwerk integrierte Routing- und Bridging-Schnittstellen (IRB) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCPv6-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID der Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
(Nur DHCPv4) Der DHCP-Relay-Agent enthält immer die neuen Informationen der Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Siehe Informationen zum Überschreiben von Option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
(Nur DHCPv6) Der DHCP-Relay-Agent fügt die DHCPv6-Schnittstellen-ID (Option 18) in Pakete ein, die an DHCPv6-Server weitergeleitet werden. Siehe Einfügen der DHCPv6-Schnittstellen-ID-Option (Option 18) in DHCPv6-Pakete.
[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id
Wenn Ihr Netzwerk über integrierte Routing- und Bridging-Schnittstellen (IRB) verfügt, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCPv6-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID der Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Führen Sie die folgenden Schritte aus, um den Massen-Leasequery-Vorgang zu konfigurieren und zu verwenden.
Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen über den Massen-Leasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server. Siehe Überprüfen und Verwalten von DHCP-Einzel- und Massen-Leasequery-Konfigurationen.
Konfiguration und Verwendung von DHCP Active Leasequery
Bevor Sie beginnen, lesen Sie Richtlinien für die Konfiguration der Unterstützung für Einzel-, Massen- und aktive Leasequery-Vorgänge und stellen Sie sicher, dass die folgende erforderliche Unterstützung auf dem DHCP-Relay-Agent konfiguriert ist.
-
(Nur DHCPv4) Der DHCP-Relay-Agent fügt Option 82 Unteroption 1 (Agent-Circuit-ID) in die DHCP-Pakete ein, die das Relay an DHCP-Server weiterleitet. Siehe Verwenden des DHCP Relay Agent Option 82 Informationen.
Wenn das Netzwerk integrierte Routing- und Bridging-Schnittstellen (IRB) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCPv6-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID der Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.[edit forwarding-options dhcp-relay] user@host# set relay-option-82 circuit-id include-irb-and-l2
-
(Nur DHCPv4) Der DHCP-Relay-Agent enthält immer die neuen Informationen der Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Siehe Informationen zum Überschreiben von Option 82.
[edit forwarding-options dhcp-relay] user@host# set overrides always-write-option-82
-
(Nur DHCPv6) Der DHCP-Relay-Agent fügt die DHCPv6-Schnittstellen-ID (Option 18) in Pakete ein, die an DHCPv6-Server weitergeleitet werden. Siehe Einfügen der DHCPv6-Schnittstellen-ID-Option (Option 18) in DHCPv6-Pakete.
Wenn Ihr Netzwerk über integrierte Routing- und Bridging-Schnittstellen (IRB) verfügt, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Diese Anweisung konfiguriert den DHCPv6-Relay-Agent so, dass er den Namen der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in die Leitungs-ID der Option 82 einschließt. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle bei Verwendung von leasequery oder bulk leasequery zur Wiederherstellung der lease-Datenbank.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
-
Für die Redundanz von DHCP-Relay-Agents auf Chassis-Ebene gelten die folgenden Richtlinien:
-
Die DHCP-Relay-Agent-Redundanz-Peers müssen alle über identische Anwenderkonfigurationen verfügen, um synchronisierte Datenbanken zu haben.
-
Die vollständigen Schnittstellennamen für die Zugriffsschnittstellen (
ge,xe, oderae), auf denen die Teilnehmer auftauchen, müssen auf den DHCP-Relay-Agent-Redundanz-Peers identisch sein.
-
-
Da Active LeaseQuery eine Erweiterung von Bulk LeaseQuery ist, müssen Sie Bulk LeaseQuery konfigurieren, damit Active LeaseQuery ausgeführt werden kann. Siehe Konfigurieren und Verwenden von DHCP Bulk Leasequery.
Der aktive leasequery-Vorgang sendet Liveupdates an DHCP-Relay-Agents für mehrere Abonnenten, wenn sich die DHCP-Bindungsinformationen auf dem lokalen Server ändern. Sie können active leasequery auch als Teil einer Konfiguration verwenden, um Redundanz von Bindungsinformationen zwischen Peer-Relay-Agents bereitzustellen.
Führen Sie die folgenden Schritte aus, um den aktiven leasequery-Vorgang zu konfigurieren und zu verwenden.
Diese Schritte duplizieren keine der Massen-Leasequery-Konfigurationen. Die Schritte umfassen beispielsweise nicht die Konfiguration der maximalen Anzahl von TCP-Verbindungen, da dies Teil der erforderlichen Bulk-Leasequery-Konfiguration ist.
Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen über den Massen-Leasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server. Siehe Überprüfen und Verwalten von DHCP-Einzel- und Massen-Leasequery-Konfigurationen.
EVPN-MPLS DHCPv6-PD Stateful Relay-Synchronisation für Aktiv-Aktiv-Modus (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024 und ACX7024X)
Diese DHCPv6-PD Stateful Relay-Synchronisationsfunktion bietet Unterstützung für die DHCPv6-Präfixdelegierungskonfiguration, einschließlich:
-
Synchronisation zwischen zwei Leaf-Knoten von EVPN-MPLS für den Aktiv-Aktiv-Modus
-
DHCPv6-Präfixdelegierung zur automatischen Delegierung von IPv6-Präfixen an das CPE.
- Unterstützung für Massen-Leasequery auf einem DHCPv6-Relay-Agent.
- Konfigurieren von Parametern, die der DHCP-Relay-Agent beim Senden von DHCP-Massen-Leasequery-Nachrichten verwendet, um Lease-Informationen von den lokalen DHCP-Servern im logischen System/in der Routing-Instanz abzurufen.
-
EVPN-VXLAN-DHCPv6-Statussynchronisierung mit Active-lease-query/Bulk-lease-query über IRB.
[ Siehe Unterstützte Protokolle auf einer IRB-Schnittstelle in EVPN-VXLAN, DHCP-Leasequery-Methoden, active-leasequery (DHCP Relay Agent) und bulk-leasequery (DHCP Relay Agent) . ]
Beispiel für eine Konfiguration:
Im folgenden Beispiel wird eine Aktiv-Aktiv-Konfiguration mit veralteter Timereinstellung angezeigt. Die Konfiguration des veralteten Zeitgebers ist erforderlich, um eine Aktiv-Aktiv-Leaseabfrage zu unterstützen. Diese Konfiguration optimiert die Synchronisationszeit, wenn beide Peers die angeforderten Pakete gleichzeitig erhalten.
dhcp-relay
{
dhcpv6
{
group v6relay
{
active-server-group v6server;
interface irb.0;
}
relay-agent-interface-id
{
include-irb-and-l2;
}
server-group
{
v6server
{
1000::1;
}
}
bulk-leasequery;
active-leasequery
{
peer-address
{
1003::1;
}
}
}
overrides
{
always-write-option-82;
}
relay-option-82
{
circuit-id
{
include-irb-and-l2;
}
}
server-group {
v4server {
100.0.0.1;
}
}
group v4relay {
active-server-group v4server;
interface irb.0;
}
stale-timer 20;
bulk-leasequery;
active-leasequery {
peer-address {
103.0.0.1;
}
}
}
dhcp-relay {
dhcpv6 {
group v6relay {
active-server-group v6server;
interface irb.0;
}
relay-agent-interface-id {
include-irb-and-l2;
}
server-group {
v6server {
1000::1;
}
}
bulk-leasequery;
active-leasequery {
peer-address {
1002::1;
}
}
}
overrides {
always-write-option-82;
}
relay-option-82 {
circuit-id {
include-irb-and-l2;
}
}
server-group {
v4server {
100.0.0.1;
}
}
group v4relay {
active-server-group v4server;
interface irb.0;
}
stale-timer 20;
bulk-leasequery;
active-leasequery {
peer-address {
102.0.0.1;
}
}
}
Initiieren einer DHCP-Leasequery zum Aktualisieren der DHCP Relay Agent-Lease-Datenbank
Sie müssen einen Anforderungsbefehl ausgeben, um den DHCP-Relay-Agent auszulösen, um eine einzelne Leasequery- oder Massen-Leasequery-Operation zu initiieren, die aktuelle Lease-Informationen von lokalen DHCP-Servern anfordert. Jede einzelne leasequery aktualisiert die Lease-Datenbank des DHCP-Relay-Agenten mit Informationen für einen einzelnen Client. Jede Massen-Leasequery aktualisiert die Lease-Datenbank des Relay-Agenten für mehrere Clients. Tabelle 12 listet die verschiedenen Abfrageoptionen auf, die für DHCPv4, DHCPv6, individuelle Leasequery und Massen-Leasequery verfügbar sind.
Abfrage-Option |
DHCPv4 Individuelle Leasequery |
DHCPv4 Massen-Leasequery |
DHCPv6 Individuelle Leasequery |
DHCPv6 Massen-Leasequery |
|---|---|---|---|---|
Remote-ID des Agenten |
– |
✓ |
– |
✓ |
Client-ID |
✓ |
✓ |
– |
– |
Client-ID (DUID) |
– |
– |
✓ |
✓ |
Gateway-Adresse |
✓ obligatorisch |
– |
– |
– |
IPv4-Adresse |
✓ |
✓ |
– |
– |
IPv6-Präfix |
– |
– |
✓ |
✓ |
Link-Adresse |
– |
– |
– |
✓ |
MAC-Adresse |
✓ |
✓ |
– |
– |
Relay-Agent-ID |
– |
✓ |
– |
✓ |
Wenn Sie die DHCPv6-Massenleaseabfrage auf einem Relay-Agent mit der bulk-leasequery Anweisung und der trigger automatic Option konfiguriert haben, starten Sie die Abfrage nicht mit einem request Befehl. Stattdessen wird die Abfrage automatisch ausgelöst, wenn der jdhcpd-Prozess auf dem Relay-Agent gestartet wird (z. B. nach einem JDHCPD-Neustart, einem Neustart eines Relay-Agent-Geräts, einem Graceful Routing-Engine-Switchover oder einem einheitlichen ISSU) und keine gebundenen Abonnenten in der Sitzungsdatenbank vorhanden sind. Die automatische Massen-Lease-Abfrage basiert immer auf der Relay-ID-Option des Relay-Agenten (Option 53).
Wenn die Unterstützung für automatische Trigger konfiguriert ist, können Sie den request Befehl weiterhin verwenden, um Massen-Lease-Abfragen getrennt von den automatischen Abfragen manuell auszulösen.
Active leasequery erfordert keinen request Befehl für die Initiierung. Stattdessen wird sie automatisch initiiert, wenn Sie sie konfigurieren. Für Active leasequery müssen Sie die Massen-Leasequery konfigurieren.
DHCPv4-Relay-Agents können mehrere Schnittstellen mit unterschiedlichen IP-Adressen haben, sodass jede Schnittstelle als Gateway für verschiedene Gruppen von Clients fungieren kann. Das bedeutet, dass Sie in Ihrer Anfrage immer die Gateway-Adresse angeben müssen.
Um eine individuelle DHCPv4-Leasequery zum Aktualisieren von Bindungsinformationen zu initiieren, müssen Sie immer die Gateway-IP-Adresse des Relay-Agenten angeben. Sie müssen auch den Typ der Abfrage angeben:
Geben Sie eine IP-Adresse an, die an den Client vermietet wird.
user@host> request dhcp relay leasequery ipv4-address gateway-address giaddr
Geben Sie die MAC-Adresse des Clients an.
user@host> request dhcp relay leasequery mac-address gateway-address giaddr
Geben Sie die Client-ID an (Option 61).
user@host> request dhcp relay leasequery client-id gateway-address giaddr
Um eine DHCPv4-Massenleaseabfrage zum Aktualisieren von Bindungsinformationen zu initiieren, können Sie Folgendes tun:
Geben Sie eine IP-Adresse an, die an den Client vermietet wird.
user@host> request dhcp relay bulk-leasequery ipv4-address
Geben Sie die MAC-Adresse des Clients an.
user@host> request dhcp relay bulk-leasequery mac-address
Geben Sie die Client-ID-Option an (Option 61).
user@host> request dhcp relay bulk-leasequery client-id
Geben Sie die Unteroption Relay Agent Identifier (Unteroption 12) der DHCP Relay Agent-Informationsoption (Option 82) an.
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
Standardmäßig verwendet der Massen-Leasequery-Vorgang die Relay-ID des DHCPv4-Relay-Agents, wenn Sie keine der folgenden Optionen explizit angeben: client-id, ipv4-address, mac-address, relay-idoder remote-id.
user@host> request dhcpv6 relay bulk-leasequery
Geben Sie die Remote-ID des Agenten (Unteroption 2) der DHCPv4-Relay-Agent-Informationsoption (Option 82) an.
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
Um eine individuelle DHCPv6-Leasequery zum Aktualisieren von Bindungsinformationen zu initiieren, haben Sie folgende Möglichkeiten:
Geben Sie die Client-ID an (Option 1).
user@host> request dhcpv6 relay leasequery client-id
Geben Sie eine IPv6-Adresse an, die an den Client vermietet wird.
user@host> request dhcpv6 relay leasequery ipv6-prefix
Um eine DHCPv6-Massenleaseabfrage zum Aktualisieren von Bindungsinformationen zu initiieren, können Sie Folgendes tun:
Geben Sie die Client-ID an (Option 1).
user@host> request dhcpv6 relay bulk-leasequery client-id
Geben Sie das IPv6-Präfix an.
user@host> request dhcpv6 relay bulk-leasequery ipv6-prefix
Geben Sie die IPv6-Linkadresse an.
user@host> request dhcpv6 relay bulk-leasequery link-address ipv6-link-address
Geben Sie die Option Relay-ID an (Option 53).
user@host> request dhcpv6 relay bulk-leasequery relay-id relay-id
Standardmäßig verwendet der Massen-Leasequery-Vorgang die Relay-ID des DHCPv6-Relay-Agents, wenn Sie keine der folgenden Optionen explizit angeben: client-id, ipv6-prefix, ipv6-link-address, relay-idoder remote-id.
user@host> request dhcpv6 relay bulk-leasequery
Geben Sie die Option Relay Agent Remote-ID an (Option 37).
user@host> request dhcpv6 relay bulk-leasequery remote-id remote-id
Für jede Einzel- und Massen-Leasequery-Anfrage können Sie zusätzlich zu den oben aufgeführten Optionen optional Qualifizierer angeben, um die Abfrage auf bestimmte DHCP-Server zu beschränken. Andernfalls wird die Abfrage an alle DHCP-Server gesendet, die dem Relay-Agent bekannt sind.
Sie können eine Adresse für den lokalen Server oder den Namen einer Gruppe lokaler Server angeben. Sie können ein logisches System, eine Routing-Instanz oder beides angeben, entweder allein oder zusätzlich zur Serveradresse oder -gruppe.
Im folgenden Beispiel bedeutet jede konfigurierbare Option, option wie zuvor gezeigt. Der Kürze halber zeigt das Beispiel nur eine individuelle DHCPv4-Leasequery und nur einige der Möglichkeiten. Weitere Informationen finden Sie in den einzelnen Befehlsthemen: request dhcp relay leasequery, request dhcpv6 relay leasequery, request dhcp relay bulk-leasequery und request dhcpv6 relay bulk-leasequery.
Geben Sie eine Adresse für den lokalen Server an.
user@host> request dhcp relay leasequery option server-address address
Geben Sie ein logisches System an.
user@host> request dhcp relay leasequery option logical-system logical-system-name
Geben Sie eine Routing-Instanz und eine benannte Gruppe lokaler Server an.
user@host> request dhcp relay leasequery option routing-instance routing-instance-name server-group group-name
Überprüfen und Verwalten von individuellen DHCP- und Massen-Leasequery-Konfigurationen
Zweck
Zeigen Sie Informationen zu DHCP-, individuellen Leasequery- und Massen-Leasequery-Operationen an oder löschen Sie sie. Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen zu leasequery- und Massen-leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server.
Informationen zur aktiven Leasequery finden Sie unter Überprüfen und Verwalten aktiver DHCP-Leasequery-Vorgänge.
Aktion
Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen zu den leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server.
So zeigen Sie Leasequery-Informationen für DHCPv4- oder DHCPv6-Relay-Agent an:
user@host> show dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> show dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
So löschen Sie die Leasequery-Informationen für den DHCPv4- oder DHCPv6-Relay-Agent:
user@host> clear dhcp relay statistics (leasequery | bulk-leasequery-connections) user@host> clear dhcpv6 relay statistics (leasequery | bulk-leasequery-connections)
So zeigen Sie Leasequery-Informationen für den lokalen DHCPv4- oder DHCPv6-Server an:
user@host> show dhcp server statistics bulk-leasequery-connections user@host> show dhcpv6 server statistics bulk-leasequery-connections
So löschen Sie die Leasequery-Informationen für den lokalen DHCPv4- oder DHCPv6-Server:
user@host> clear dhcp server statistics bulk-leasequery-connections user@host> clear dhcpv6 server statistics bulk-leasequery-connections
Überprüfen und Verwalten aktiver DHCP-Leasequery-Vorgänge
Zweck
Zeigen Sie Informationen über aktive DHCP-Leasequery-Vorgänge an oder löschen Sie sie. Verwenden Sie die show unterstützten und clear Befehle, um Informationen zu den aktiven leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen.
Informationen zu DHCP-Einzel- und Massen-Leasequery finden Sie unter Überprüfen und Verwalten von DHCP-Einzel- und Massen-Leasequery-Konfigurationen.
Aktion
Verwenden Sie die Befehle supported show und clear zum Verwalten und Anzeigen von Informationen zu den leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server.
So zeigen Sie aktive Leasequery-Informationen für DHCPv4- oder DHCPv6-Peer-Relay-Agents an:
user@host> show dhcp relay active-leasequery user@host> show dhcpv6 relay active-leasequery
So löschen Sie aktive leasequery-Informationen für den DHCPv4- oder DHCPv6-Relay-Agenten:
user@host> clear dhcp relay active-leasequery statistics user@host> clear dhcpv6 relay active-leasequery statistics
So zeigen Sie Informationen zu aktiven leasequery-Nachbarn an:
user@host> show dhcp active-leasequery neighbors user@host> show dhcpv6 active-leasequery neighbors
Sie können allgemeine Informationen für alle Peers anzeigen. Sie können auch Statistiken für bestimmte Peers und bestimmte Zugriffsschnittstellen anzeigen. Zum Beispiel:
Zeigen Sie für jede Pseudowire-Schnittstelle auf dem BNG die IP-Adresse des BNG-Nachbarn an, der der Schnittstelle zugeordnet ist.
user@host> show dhcp active-leasequery neighbors Interface Neighbor Address ps2.0 198.51.100.5 ps1.0 198.51.100.7Zeigen Sie Statistiken für DHCPv4- und DHCPv6-Peers an.
user@host> show dhcp relay active-leasequery statistics peer 198.51.100.1 peer : 198.51.100.1 Topology-Discover Configured : No State : Connected Bindings Sent : 0 Bindings Received : 0 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : None ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2user@host> show dhcpv6 relay active-leasequery statistics peer 2001:db8::2 peer : 2001:db8::2 Topology-Discover Configured : No State : Connected Bindings Sent : 8112 Bindings Received : 12382 Bindings Installed Successfully : 0 Bindings Failed to install : 0 Last Synchronization Time : 2020-02-05 01:27:54 IST ALQ Transmit Buffer count : 0x ffff Max Leasequery Transmit Rate : 60 Local Interface count : 2 Remote Interface count : 2
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.