DHCP-Leasequery-Methoden
In einem Teilnehmerzugriffsnetzwerk verwaltet ein lokaler DHCP-Server eine beträchtliche Menge an Bindungsinformationen in Bezug auf die IP-Adressen oder delegierten DHCPv6-Präfixe, die der Server an DHCP-Clients geleast 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, wie z. B. die IP-Adresse, die erforderlich sind, um den Endpunkt zu erreichen. Der Relay-Agent verwaltet die für die DHCP-Clients relevanten Lease- und Routing-Informationen. Der Relay-Agent verwendet diese Informationen, wenn er Abonnentendienste für die Clients bereitstellt. Wenn der Relay-Agent neu gestartet wird oder wenn das Agent-Hostgerät neu gestartet oder ausgetauscht wird, verliert der Relay-Agent diese Informationen. Sie können einen request Befehl verwenden, um den Relay-Agent auszulösen, 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 Abonnentenverwaltung unterstützt die folgenden Arten von leasequery-Vorgängen:
Individuelle leasequery: Stellt Leaseinformationen für eine einzelne Bindung auf Anforderung (Abfrage- und Antwortmodus) bereit.
Bulk leasequery: Stellt Lease-Informationen für mehrere Bindungen auf Anforderung bereit (Abfrage- und Antwortmodus).
Active leasequery: Bietet bei Konfiguration einen Stream von Live-Updates für mehrere Bindungen.
Vorteile von DHCP Leasequery
Leasequery bietet eine einfache Möglichkeit für einen DHCPv4- oder DHCPv6-Relay-Agenten, 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 ersetzt wurde.
Durch die Massenleaseabfrage entfällt die Notwendigkeit, einzelne Bindungen für bestimmte Clients abzufragen, sodass mit einer einzelnen Anforderung Informationen für Hunderte oder Tausende von Abonnenten zurückgegeben werden können. Diese Methode wartet nicht, bis der Datenverkehr eine Abfrage auslöst, sodass sie besser skaliert werden kann als einzelne leasequery, wenn der Agent über Tausende von Clients verfügt. Im Fall von DHCPv6 ist der Relay-Agent möglicherweise nicht in der Lage, einzelne Abfragen zu erstellen.
Active leasequery stellt bei der Konfiguration kontinuierliche Liveaktualisierungen von Bindungsinformationen für einen oder mehrere Relay-Agents bereit. Zusätzlich zu den Aktualisierungen zwischen dem Relay-Agent und dem lokalen Server können Sie eine Peering-Beziehung zwischen Relay-Agents konfigurieren. Auf diese Weise können die Peers ihre Bindungsinformationen kontinuierlich miteinander synchronisieren und Redundanz bereitstellen, wenn ein Peer ausfällt oder neu gestartet wird. Der aktive Peer verwaltet sofort den Dienst für die Clients, die den betroffenen Relay-Agent verwendet haben.
Dank der Topologieerkennung können Relay-Agent-Peers auf BNGs, die für M:N-Abonnentenredundanz konfiguriert sind, automatisch Übersetzungstabellen erstellen, sodass Abonnentenredundanzgruppen auch dann weiterhin bedient werden, wenn ein primäres BNG ein Failover auf eine Sicherung durchführt. Dieses automatische Verhalten befreit Sie von der Notwendigkeit, Tabellen statisch zu erstellen. Statische Konfiguration ist in skalierten Netzwerken fehleranfällig und passt sich nicht dynamisch an Änderungen im Netzwerk an.
Individuelle DHCP-Leasequery
Ab Junos OS Version 16.1 unterstützt die Abonnentenverwaltung die Funktion "Individual leasequery", 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 Relay-Agent anschließend Datenverkehr von einem Client zur Weiterleitung erhält, 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 für den DHCP-Relay-Agent als auch für den 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 ausgeben, um den Relay-Agent zum Senden der Abfrage zu veranlassen.
Standardmäßig sendet der Relay-Agent die Abfrage an alle bekannten lokalen Server. Sie können die Server, mit denen kommuniziert wird, 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 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. Sie bestimmen den Abfragetyp, wenn Sie die Abfrage durch das Ausführen 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 eines Client-Leases: 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 gesamten 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 (Option 92) zurück.
MAC-Adresse des Client-Geräts: Der lokale Server gibt Bindungsinformationen für den neuesten Client mit dieser MAC-Adresse zurück. 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 (Option 92) zurück.
Der DHCP-Relay-Agent enthält die Option für die Parameteranforderungsliste (Option 55) in der DHCPLEASEQUERY-Nachricht. Diese Liste enthält spezifische Optionen im Zusammenhang mit den Bindungsinformationen für die IP-Adresse, die vom lokalen Server zurückgegeben wird. Beispielsweise enthält die Anforderungsliste in der Regel die Option Relay Agent Information (Option 82). Der lokale Server schließt die angeforderten Informationen in ein DHCPLEASEACTIVE-Protokoll ein, das an den Relay-Agent gesendet wird.
Die DHCPLEASEACTIVE-Nachricht enthält die Option für die letzte Transaktionszeit 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 dem Client und dem Server verwendet wurde, und dem Zeitpunkt, zu dem der serer eine 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.
Nachrichtentyp |
Option 53 Typ Wert |
Beschreibung |
|---|---|---|
DHCPLEASEQUERY |
10 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Informationen wiederherzustellen. |
DHCPLEASEUNASSIGNED |
11 |
Antwort des lokalen Servers, wenn die dem Client zugeordnete IP-Adresse vom Server gesteuert, aber derzeit nicht geleast wird. 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 des lokalen Servers, wenn er eine Adresse an den Client vermietet hat. Die Antwort enthält vollständige verbindliche Informationen zu dieser 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. Sie bestimmen den Abfragetyp, wenn Sie die Abfrage durch das Ausführen 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 der Option request-Option (Option 6) enthält, damit der lokale Server die vom Agent angeforderten Bindungsinformationen identifizieren kann:
IPv6-Adresse eines Client-Leases: 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 gesamten 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 Feld "query-options" 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 angefordert werden.
Die LEASEQUERY-REPLY-Nachricht enthält die Clientdatenoption (Option 45), um Informationen für einen einzelnen Client auf einer einzelnen Verbindung bereitzustellen. Diese Informationen werden als DHCPv6-Optionen im Feld Client-Optionen übermittelt. Option 45 enthält mindestens die folgenden Optionen und alle anderen Optionen, die vom Relay-Agent 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 Server das letzte Mal über diese Verbindung mit dem Client interagiert hat. 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-Relaydatenoption (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 options (Option 6) angefordert wird.
LQ-Client-Link-Option (Option 48): Identifiziert die Link-Adressen, 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 gibt keine Verbindungsadresse an und der Client wird auf mehr als einer Verbindung gefunden. Wenn der Relay-Agent diese Informationen erhält, kann er für jede in Option 48 aufgeführte Adresse eine neue LEASEQUERY senden.
In Tabelle 2 werden die Nachrichtentypen für DHCPv6-LeaseQuery beschrieben.
Nachrichtentyp |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
LEASEQUERY |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Informationen wiederherzustellen. Enthält die LQ-Option (Option 44) zum Angeben des Abfragetyps, einer Verbindungsadresse und aller bestimmten Optionsinformationen, die vom lokalen Server benötigt werden. |
LEASEQUERY-REPLY |
15 |
Antwort des lokalen Servers, wenn die dem Client zugeordnete IP-Adresse vom Server gesteuert, aber derzeit nicht geleast wird. 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.
Code |
Status |
Beschreibung |
|---|---|---|
7 |
UnknownQueryType |
Der Server erkennt die Abfrage nicht oder unterstützt sie nicht. |
8 |
MalformedQuery |
Die Abfrage ist ungültig. Beispielsweise könnte eine erforderliche Option fehlen. |
9 |
NotConfigured |
Der lokale Server hat nicht die erforderliche Adresse in seiner Konfiguration. |
10 |
NotAllowed |
Der lokale Server lässt nicht zu, dass der Relay-Agent diesen Abfragetyp sendet. |
DHCP-Massenleaseabfrage
Ab Junos OS Version 16.1 unterstützt die Abonnentenverwaltung die Funktion "Bulk leasequery", mit der jede Anforderung vom DHCP-Relay-Agenten Lease-Informationen für mehrere Teilnehmer in großen Mengen von einem konfigurierten DHCP-Server auf programmierte Weise abrufen kann. Die Lease-Massenabfrage ist ressourceneffizienter als die Verwendung mehrerer einzelner leaseabfragen, um dieselben Informationen zu sammeln. Dies ist besonders nützlich in skalierten Umgebungen mit Tausenden von Clients pro Relay-Agent.
Bei der Massenleaseabfrage wird eine TCP-Verbindung zwischen dem DHCP-Relay-Agent und einem konfigurierten DHCP-Server im selben logischen System/derselben Routing-Instanz verwendet. Die TCP-Verbindung ist zuverlässiger und verbraucht weniger Ressourcen als die UDP-Verbindung, die für den einzelnen leasequery-Prozess verwendet wird. Bulk leasequery erweitert auch die einzelne leasequery, indem zusätzliche Abfrageoptionen und -funktionen bereitgestellt werden.
Um Lease-Bulkquery-Vorgänge zu konfigurieren, aktivieren Sie die Unterstützung sowohl für den DHCP-Relay-Agent als auch für den 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 ausgeben, um den Relay-Agent zum Senden der leasequery zu veranlassen.
Standardmäßig sendet der Relay-Agent die Abfrage an alle bekannten lokalen Server. Sie können die Server, mit denen kommuniziert wird, 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 Routing-Instanz oder einer LS:RI-Kombination beschränken.
DHCPv4 Bulk Leasequery
Bei DHCPv4-Lease-Massenabfragen öffnet der DHCPv4-Relay-Agent über Port 67 eine TCP-Verbindung 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 Agenten 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 gesamten administrativen Domäne des Servers eindeutig.
Anmerkung:Im Gegensatz zu Individual leasequery verwendet der Server die zugeordnete IP-Option (Option 92) nicht, 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 Client-Geräts: Der lokale Server gibt Bindungsinformationen für den neuesten Client mit dieser MAC-Adresse zurück.
Anmerkung:Im Gegensatz zu Individual leasequery verwendet der Server die zugeordnete IP-Option (Option 92) nicht, 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 mit der angegebenen Relay-Agent-ID zugewiesen sind (Option 82, Unteroption 12). Der Bezeichner ist in der gesamten administrativen Domäne des Servers eindeutig.
Remote-ID einer Zugriffsverbindung, die vom Client verwendet wird, um die Verbindung zum DHCP-Client zu identifizieren: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die Clients zugewiesen sind, die diese Agenten-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 nicht konsolidierte Leasinginformationen für alle Clients in einer Verbindung zurück.
Der lokale DHCPv4-Server antwortet dem Relay-Agent mit denselben 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 durch die Abfrage identifiziert wird.
Wenn der Server alle Bindungen zurückgegeben hat, die der Anforderung zugeordnet sind, sendet er eine DHCPLEASEQUERYDONE-Nachricht an den Relay-Agent. Wenn eine Verbindung während der Verarbeitung einer Lease-Massenabfrage unterbrochen wird, kann DHCP nicht ermitteln, 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 an oder nach der in der Abfrage angegebenen Zeit geändert haben.
query-end-time: Gibt Bindungen zurück, die sich an oder vor der in der Abfrage angegebenen Zeit geändert haben.
Diese Abfragezeiten ermöglichen es einem Agenten, nur Bindungsinformationen wiederherzustellen, die er verloren hat, seit er das letzte Mal alle seine Informationen in einen stabilen Speicher übertragen hat.
In Tabelle 4 werden die Nachrichtentypen beschrieben, die für die DHCPv4-Lease-Massenabfrage spezifisch sind.
Nachrichtentyp |
Option 53 Typ Wert |
Beschreibung |
|---|---|---|
DHCPBULKLEASE-Abfrage |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Informationen wiederherzustellen. |
DHCPLEASEQUERYDONE |
15 |
Antwort des lokalen Servers, 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 lease-Massenanforderung als Ganzes. Tabelle 5 listet die Statuscodes auf.
Code |
Status |
Beschreibung |
|---|---|---|
0 |
Erfolg |
Die Anforderung wurde erfolgreich abgeschlossen. Auch das Fehlen von Option 151 deutet auf Erfolg hin. |
1 |
UnSpecFail |
Die Anforderung ist aus einem nicht näher angegebenen Grund fehlgeschlagen. |
2 |
QueryTerminated |
Der lokale Server konnte die Abfrage entweder nicht ausführen oder beendete die Abfrage vorzeitig. 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-Lease-Abfrage
Bei DHCPv6-Lease-Massenabfragen öffnet der DHCPv6-Relay-Agent über Port 67 eine TCP-Verbindung zum 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 gesamten administrativen Domäne des Servers eindeutig.
Anmerkung:Im Gegensatz zu Individual leasequery verwendet der Server die zugeordnete IP-Option (Option 92) nicht, 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 Client-Geräts: Der lokale Server gibt Bindungsinformationen für den neuesten Client mit dieser MAC-Adresse zurück.
Anmerkung:Im Gegensatz zu Individual leasequery verwendet der Server die zugeordnete IP-Option (Option 92) nicht, 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 mit der angegebenen Relay-Agent-ID zugewiesen sind (Option 82, Unteroption 12). Der Bezeichner ist in der gesamten administrativen Domäne des Servers eindeutig.
Remote-ID einer Zugriffsverbindung, die vom Client verwendet wird, um die Verbindung zum DHCP-Client zu identifizieren: Der lokale Server gibt Bindungsinformationen für alle derzeit aktiven Leases zurück, die Clients zugewiesen sind, die diese Agenten-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 nicht konsolidierte Leasinginformationen für alle Clients in einer Verbindung zurück.
Für eine DHCPv6-Lease-Massenabfrage können Sie optional die Option angeben, den trigger automatic DHCPv6-Relay-Agent so zu konfigurieren, dass der LeaseQuery-Massenvorgang automatisch initiiert wird, wenn der jdhcpd Prozess eine Verbindung mit der Sitzungsdatenbank (SDB) herstellt und keine gebundenen Abonnenten in der Datenbank vorhanden sind. Der automatische Prozess würde z. B. sicherstellen, dass die Massenleasequery die DHCP-Relayinformationen immer nach einem Neustart-, GRES- oder ISSU-Vorgang aktualisiert und wenn keine gebundenen Abonnenten vorhanden sind.
Bei der DHCPv6-Lease-Massenabfrage werden die LEASEQUERY- und LEASEQUERY-REPLY-Nachrichten verwendet, die von der einzelnen DHCPv6-Leasequery verwendet werden, deren Verhalten und Bedeutung sich jedoch bei der Lease-Massenabfrage geringfügig unterscheidet. In Tabelle 6 sind diese Nachrichten aufgeführt und es werden zwei weitere Nachrichtentypen beschrieben, die für DHCPv6-Leasequery spezifisch sind.
Nachrichtentyp |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
LEASEQUERY |
14 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Informationen wiederherzustellen. |
LEASEQUERY-REPLY |
15 |
Antwort des lokalen Servers, die den Erfolg oder Misserfolg der Abfrage angibt. 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 bei der Abfrage ein Fehler auftritt, wird eine einzelne LEASEQUERY-REPLY ohne Bindungsinformationen zurückgegeben. |
LEASEQUERY-ERLEDIGT |
16 |
Antwort des lokalen Servers, die das Ende einer Gruppe verwandter leasequery-Antworten angibt. 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-Agenten und dem Server wird geschlossen, wenn diese Nachricht empfangen wird. |
LEASEQUERY-DATA |
17 |
Antwort des lokalen Servers mit Informationen zu den Leases für einen einzelnen DHCPv6-Client oder zu Präfixdelegierungsbindungen für einen einzelnen Link. Diese Nachricht wird nur gesendet, wenn die Lease-Massenabfrage Daten für mehrere Clients zurückgibt. In diesem Fall übermittelt die LEASEQUERY-REPLY-Nachricht Informationen für den ersten Client, dann wird eine LEASEQUERY-DATA-Nachricht für jeden der anderen Clients 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 leasequery-Massenanforderung als Ganzes. LEASEQUERY-DATA-Nachrichten enthalten keinen Statuscode. Die DHCPv6-Lease-Massenabfrage unterstützt die DHCPv6-Statuscodes für einzelne Leasequerys, die unter DHCPv6 Individual Leasequery Status Codes aufgeführt sind. Die Nachrichten können auch den in Tabelle 7 beschriebenen Statuscode für die Massenleasequery enthalten.
Code |
Status |
Beschreibung |
|---|---|---|
11 |
QueryTerminated |
Der lokale Server kann keine Abfrage ausführen oder hat die Abfrage aus irgendeinem Grund vorzeitig beendet. Angenommen, der lokale Server wird 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 die Situation, in der es für den Relay-Agent wünschenswert ist, regelmäßige Aktualisierungen der Clientinformationen zu erhalten, um mit der dynamischen DHCP-Bindungsaktivität Schritt zu halten. Einzel- und Massenmietabfragen 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 es Servern, Liveaktualisierungen von Clientinformationen bereitzustellen, wenn sich der Bindungszustand ändert. Optional können Sie Active leaseQuery so konfigurieren, dass die Live-Aktualisierungen der Bindungsinformationen an mehrere Relay-Agent-Peers gesendet werden, wobei die Redundanz auf Relay-Agent-Chassis-Ebene 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 geöffnet bleiben muss.
DHCP schließt die TCP-Verbindung nur, wenn bestimmte Bedingungen eintreten, die sich meist auf die konfigurierbare Zeitüberschreitung oder die Leerlaufzeitüberschreitung beziehen:
Wenn eine Verbindungsanforderung in einem logischen System oder einer Routinginstanz empfangen wird, die nicht für aktive leasequery konfiguriert ist.
Wenn die Verbindung während TCP-Lese-/Schreibvorgängen so lange blockiert wird, dass die Zeitüberschreitung abläuft, wird die Verbindung geschlossen und kann neu gestartet werden. Beim Lesevorgang versucht der Relay-Agent, Antworten auf die Abfrage zu lesen. Der Schreibvorgang erfolgt, wenn der Server oder Peer-Relay-Agent versucht, Antworten an einen Relay-Agent zu senden
Wenn für die Dauer des Leerlauftimeouts kein Datenverkehr über die Verbindung empfangen wird.
Bei aktiven leasequery-Vorgängen 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 DHCPLEASEACTIVE- (DHCPv4) oder LEASEQUERY-DATA-Nachrichten (DHCPv6) in Intervallen, die der Hälfte des Leerlauftimeouts entsprechen. Diese Nachrichten enthalten keine Bindungsinformationen, da sie gesendet werden, wenn keine Updates verfügbar sind. Diese Nachrichten halten die Verbindung aufrecht, indem sie als Hallo- oder Keepalive-Nachrichten dienen und 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 enthalten 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 auch als Nachholinformationen bezeichnet. Die Option gibt den absoluten Zeitstempel an, zu dem die Verbindung beendet wird. d. h. 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 Peerrelay-Agent seit dem Zeitstempel nicht über alle Informationen für Bindungsänderungen. Beispielsweise verfügt das Gerät möglicherweise nicht über genügend Arbeitsspeicher, 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 die aktive leasequery konfigurieren, müssen Sie zuerst die Bulk-LeaseQuery konfigurieren, da die aktive LeaseQuery den Bulk-LeaseQuery-Mechanismus verwendet. Die aktive leasequery-Konfiguration schlägt bei der Commit-Prüfung fehl, wenn keine Bulk-leasequery 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-Agenten als auch für den lokalen Server konfigurieren. Im Gegensatz zu Einzel- und Massen-LeaseQuery hat Active LeaseQuery keine Abfragetypen. Sie lösen keine aktive leasequery mit einem request Befehl aus. Stattdessen erfolgt der Auslöser automatisch, wenn eine aktive leasequery konfiguriert ist.
- DHCPv4 Active Leasequery
- DHCPv6 Active Leasequery
- Redundanz auf Gehäuseebene mit aktiver Leasequery
- Redundanz auf Schnittstellenebene mit aktiver Leasequery-Topologieerkennung
DHCPv4 Active Leasequery
Bei DHCPv4 Active leasequery öffnet der DHCPv4-Relay-Agent über Port 67 eine TCP-Verbindung 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. Er wird nur aufgrund einer Zeitüberschreitung geschlossen.
Der lokale DHCPv4-Server antwortet dem Relay-Agent mit denselben 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 durch die Abfrage identifiziert wird. Der lokale DHCP-Server sendet die Antwortnachrichten weiterhin, wenn sich die Bindungsinformationen ändern. In Tabelle 8 werden die Nachrichtentypen beschrieben, die für DHCPv4 Active leasequery spezifisch sind.
Nachrichtentyp |
Option 53 Typ Wert |
Beschreibung |
|---|---|---|
DHCPACTIVELEASEQUERY |
16 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Liveaktualisierung der Bindungsinformationen auf dem Relay-Agent zu ermöglichen, wenn sich diese Informationen auf dem lokalen Server ändern. Kann auch zwischen Peer-Relay-Agents gesendet werden, um Hot-Standby-Redundanz für Bindungsinformationen bereitzustellen. |
DHCPLEASEQUERYSTATUS |
17 |
Antwort des lokalen Servers, 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 sich die Verbindung im Leerlauf befindet (es werden keine Bindungsupdates gesendet). In diesem Fall enthält die Nachricht einen ConnectionActive-Statuscode (6), um den Relay-Agenten darüber zu informieren, dass die Verbindung weiterhin besteht. |
Die vom lokalen Server gesendeten Nachrichten können die Option Statuscode (Option 151) zurückgeben. In DHCPLEASEACTIVE- und DHCPLEASEUNASSIGNED-Nachrichten entspricht der Code dem Status der einzelnen Antwort. In DHCPLEASEQUERYSTATUS-Nachrichten entspricht der Code dem Nachrichtenstream für die aktive leasequery-Anforderung als Ganzes. DHCPv4 Active leasequery unterstützt die Bulk-Leasequery-Statuscodes, die unter DHCPv4-Bulk-Leasequery-Statuscodes aufgeführt sind. Die Meldungen können auch die Statuscodes enthalten, die für die aktive leasequery hinzugefügt wurden, wie inTabelle 9 beschrieben.
Code |
Status |
Beschreibung |
|---|---|---|
5 |
DatenFehlende |
Die angeforderten verbindlichen Informationen liegen nicht vor. Wenn z. B. der lokale Server oder Peer nicht über genügend Daten verfügt, wie mit der Option query-start-time angefordert, wird dieser Statuscode sofort in einer LEASEQUERY-REPLY-Nachricht gesendet. |
6 |
ConnectionActive |
Die TCP-Verbindung ist noch aktiv. |
7 |
NachholenAbschließen |
Der lokale Server hat alle gespeicherten Daten gesendet, die vom Relay-Agenten angefordert wurden. |
DHCPv6 Active Leasequery
Bei DHCPv6 Active leasequery öffnet der DHCPv6-Relay-Agent über Port 67 eine TCP-Verbindung 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. Er wird nur aufgrund einer Zeitüberschreitung geschlossen.
Der lokale DHCPv6-Server antwortet dem Relay-Agent mit denselben LEASEQUERY-REPLY-, LEASEQUERY-DATA- und LEASEQUERY-DONE-Nachrichten, die für die Lease-Massenabfrage verwendet werden. Jede Nachricht entspricht einer einzelnen Bindung, die durch die Abfrage identifiziert wird. Der lokale DHCP-Server sendet die Antwortnachrichten weiterhin, wenn sich die Bindungsinformationen ändern. In Tabelle 10 sind diese Meldungen und der Abfragemeldungstyp aufgeführt, der für die aktive DHCPv6-Leasequery spezifisch ist.
Nachrichtentyp |
DHCPv6-Typwert |
Beschreibung |
|---|---|---|
ACTIVELEASEQUERY |
22 |
Wird vom Relay-Agent an den lokalen DHCP-Server gesendet, um die Liveaktualisierung der Bindungsinformationen auf dem Relay-Agent zu ermöglichen, wenn sich diese Informationen auf dem lokalen Server ändern. Kann auch zwischen Peer-Relay-Agents gesendet werden, um Hot-Standby-Redundanz für Bindungsinformationen bereitzustellen. |
LEASEQUERY-REPLY |
15 |
Antwort des lokalen Servers, die den Erfolg oder Misserfolg der Abfrage angibt. 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 bei der Abfrage ein Fehler auftritt, wird eine einzelne LEASEQUERY-REPLY ohne Bindungsinformationen zurückgegeben. |
LEASEQUERY-ERLEDIGT |
16 |
Antwort des lokalen Servers, die angibt, dass die Verbindung beendet werden soll. Der Server kann dies z. B. mit dem Statuscode QueryTerminated (11) senden, wenn der Server heruntergefahren wird. |
LEASEQUERY-DATA |
17 |
Antwort des lokalen Servers mit Informationen zu den Leases für einen einzelnen DHCPv6-Client oder zu Präfixdelegierungsbindungen für einen einzelnen Link. Diese Nachricht wird nur gesendet, wenn leasequery Daten für mehrere Clients zurückgibt. In diesem Fall übermittelt die LEASEQUERY-REPLY-Nachricht Informationen für den ersten Client, dann wird eine LEASEQUERY-DATA-Nachricht für jeden der anderen Clients gesendet. |
Die vom lokalen DHCPv6-Server gesendeten Nachrichten können die Statuscodeoption (Option 13) zurückgeben. DHCPv6 Active LeaseQuery unterstützt die einzelnen LeaseQuery- und Bulk LeaseQuery-Statuscodes, die unter 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 aktive leasequery hinzugefügt wurden, wie in Tabelle 11 beschrieben.
Code |
Status |
Beschreibung |
|---|---|---|
12 |
DatenFehlende |
Die angeforderten verbindlichen Informationen liegen nicht vor. |
13 |
NachholenAbschließen |
Der lokale Server hat alle gespeicherten Daten gesendet, die vom Relay-Agenten angefordert wurden. |
14 |
Nicht unterstützt |
Der lokale Server hat alle gespeicherten Daten gesendet, die vom Relay-Agenten angefordert wurden. |
Redundanz auf Gehäuseebene mit aktiver Leasequery
Sie können active leasequery verwenden, um die Synchronisierung von Bindungsinformationen zwischen mehreren DHCP-Relay-Agent-Peers zu aktivieren. Der Einfachheit halber wird in dieser Diskussion das Verhalten mit nur zwei Peers erläutert. Wenn ein Peer-Relay-Agent neu gestartet wird oder sein Gerät neu gestartet wird, kann das andere Relay die Dienste für alle DHCP-Clients ohne sichtbaren Ausfall bereitstellen. Wenn der Peer-Relay-Agent erneut aktiviert wird, 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 stellt eine Verbindung zu beiden Relay-Agents her.
Beide Relay-Agents stellen eine Verbindung mit demselben DHCP-Server her.
Wenn Sie die
active leasequeryAnweisung auf jedem Relay-Agent konfigurieren, geben Sie auch den anderen Relay-Agent als Peer an.Die Peers verwenden die gleichen aktiven leasequery-Nachrichten für die Kommunikation, wie in Tabelle 8 und Tabelle 10 erläutert. Obwohl es hier nicht angezeigt wird, gibt es keine Unterschiede bei 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 freigeben, wenn active leasequery für beide 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 für die Konfiguration ein Commit ausgeführt wird. Angenommen, der 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 zu den Bindungen in seiner Abonnentendatenbank an Relay-Agent 1. Außerdem wird eine eigene ACTIVELEASEQUERY-Nachricht an Relay-Agent 1 gesendet, um die Clientinformationen des Peers zu erfassen.
Relay-Agent 1 sendet seine Bindungsinformationen an Relay-Agent 2. Relay-Agent 1 und Relay-Agent 2 verarbeiten jeweils die empfangenen Bindungsinformationen und übertragen sie an ihre jeweiligen Datenbanken.
Wenn jeder Relay-Agent Bindungsinformationen für seine eigenen Clients aktualisiert, z. B. Lizenzverlängerungen, neue Anforderungen, Lease-Abläufe 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-Abonnentendatenverkehr, der früher über Relay-Agent 1 geflossen ist, jetzt ohne Unterbrechung über Relay-Agent 2.
Active leasequery wird auf Relay Agent 1 ausgelöst, wenn es 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 kann. Relay-Agent 2 sendet alle aktuellen Bindungsinformationen an Relay-Agent 1. Diese Informationen können sich geändert haben, während Relay Agent 1 außer Betrieb war. Das Ergebnis ist, dass beide Relay-Agents jetzt über synchronisierte Datenbanken verfügen.
Redundanz auf Schnittstellenebene mit aktiver Leasequery-Topologieerkennung
Ab Junos OS Version 19.2R1 können DHCP-Relay-Peers mithilfe der Topologieerkennung Informationen über die Teilnehmerschnittstellen der jeweils anderen Seite ermitteln. Die Topologieermittlung ist in einer Netzwerktopologie mit einer M:N-Subscriber-Gruppen-Redundanzkonfiguration erforderlich. In dieser Konfiguration fungiert ein BNG, der einen DHCP-Relay-Agent hostet, als primärer Router für eine Abonnentenredundanzgruppe. Der primäre Router verarbeitet den Datenverkehr für die Anwenderredundanzgruppe. Eine oder mehrere andere BNGs, die Peer-Relay-Agents hosten, dienen als Backups für Abonnenten-Redundanzgruppen auf dem primären Netzwerk.
Eine bestimmte BNG kann als Sicherung für mehrere Abonnentenredundanzgruppen dienen, aber jede Redundanzgruppe wird nur mit einer BNG gesichert. Wenn die primäre BNG ausfällt, wird die Sicherungs-BNG für jede Abonnentenredundanzgruppe, die von dem Ausfall betroffen ist, als neue primäre Gruppe für diese Redundanzgruppe ausgewählt. Die neue primäre Datenbank bedient weiterhin nahtlos und ohne Unterbrechung die Abonnentenredundanzgruppe. Weitere Informationen zur M :N-Redundanz finden Sie unter Übersicht über M:N-Abonnentenredundanz .
Die Teilnehmerredundanz auf Schnittstellenebene basiert auf der logischen Schnittstelle für die Zugriffsverbindung. In diesem Fall muss der Schnittstellenname der Zugriffsschnittstelle für eine Teilnehmerredundanzgruppe auf dem primären Peer und dem Sicherungspeer nicht identisch sein. Dieses Verhalten unterscheidet sich von dem bei der Relay-Agent-Redundanz auf Chassis-Ebene, bei der die Namen der Zugriffsschnittstellen auf den Relay-Agent-Peers identisch sein müssen.
Da die Schnittstellennamen für den primären und den Backup-Relay-Agent unterschiedlich sein können, muss DHCP die Beziehung zwischen der Schnittstelle für jede Teilnehmerredundanzgruppe auf dem primären Server und der entsprechenden Schnittstelle für die Backups ermitteln. Topologieerkennung stellt diese Informationen zur Verfügung.
Die Topologieerkennung ermöglicht es dem primären Relay-Agent und dem Backup-Relay-Agenten, automatisch eine Übersetzungstabelle zu erstellen, die die lokalen und RAS-Schnittstellen für jede Abonnentenredundanzgruppe zuordnet. Wenn die primäre Datenbank ausfällt, verwendet die Sicherung, die als neue primäre Datenbank ausgewählt wurde, ihre Übersetzungstabelle, um die von dem Fehler betroffenen Abonnentenredundanzgruppen sofort zu verwalten. Das Failover selbst ist für die DHCP-Clients transparent, die den Abonnentenredundanzgruppen zugeordnet sind.
Die Topologieermittlung ist eine aktive leasequery-Option. Active leasequery ermöglicht es den Peers, die Bindungsinformationen für Abonnenten in den Abonnentenredundanzgruppen zu synchronisieren, die den Schnittstellen entsprechen, die der Übersetzungstabelle hinzugefügt wurden. DHCP übersetzt die Bindungsinformationen so, dass die lokale Schnittstelle auf der Sicherung anstelle der Schnittstelle auf der primären Schnittstelle verwendet wird.
Wenn Sie die Topologieermittlung konfigurieren, besteht der gesamte DHCP-Leasequery-Prozess aus vier Verbindungsphasen, wie in Abbildung 2 dargestellt.
der Topologieermittlung
TCP-Verbindungsphase: Zwischen den Peer-Relay-Agents wird eine TCP-Verbindung hergestellt.
Topologieerkennungsphase: Die Peers tauschen Topologieermittlungsnachrichten aus, um die übereinstimmenden Zugriffsschnittstellen für jede Teilnehmerredundanzgruppe auf den Peers zu ermitteln. Der Remote-Peer stimmt mit einer Schnittstelle basierend auf der VLAN-ID und dem Subnetz überein. Jeder Peer sendet eine Abfrage für alle seine Zugriffsschnittstellen und erhält eine Antwort, sodass alle Peers eine Übersetzungstabelle der verbundenen lokalen und Remoteschnittstellenpaare für die Anwenderredundanzgruppen erstellen können.
Bulk leasequery-Phase: Die Peers stellen die Bulk-leasequery-Beziehung her, die für den Betrieb der aktiven leasequery erforderlich ist. Mit der Bulk-Lease-Abfrage können die Relay-Agents Lease-Informationen für mehrere Teilnehmer von einem konfigurierten DHCP-Server in großen Mengen abrufen, anstatt in einer Reihe einzelner Abfragen und Antworten. In dieser Phase sammelt DHCP zum ersten Mal alle Bindungsinformationen in großen Mengen.
Aktive leasequery-Phase: Active leasequery stellt sicher, dass Bindungsinformationen synchronisiert werden, wenn sie sich ändern, ohne dass nachfolgende Abfragen erforderlich sind. Der primäre Relay-Agent sendet die Bindungen relativ zu seiner lokalen Agent-Circuit-ID (dem Namen der Zugriffsschnittstelle). Der Backup-Relay-Agent verwendet seine Übersetzungstabelle, um die entsprechende Agent-Circuit-ID für die Sicherung abzurufen und die Abonnenten zu installieren.
Um die Informationen, die synchronisiert werden, auf die Teilnehmer zu beschränken, die eine bestimmte Zugriffsschnittstelle verwenden, d. h. eine Abonnentenredundanzgruppe, verwendet Active leaseQuery die Abfrage nach giaddr (DHCPv4) oder linkaddr (DHCPv6)-Methode, wenn Sie die Topologieermittlung konfigurieren. Die Gateway-IP-Adresse (giaddr oder linkaddr) wird von einem Relay-Agent verwendet, um zu bestimmen, wohin Informationen nachgelagert werden sollen. Der Wert des giaddr ist die Zugriffsschnittstelle. Der Relay-Agent wertet giaddr/linkaddr aus und sendet Informationen an den DHCP-Client, der die Zugriffsschnittstelle verwendet, die mit giaddr/linkaddr übereinstimmt.
Dies bedeutet für die Anwenderredundanz, dass bei Verwendung der giaddr/linkaddr-Abfrage aktive leasequery nur Informationen für Abonnenten auf dieser Zugriffsschnittstelle anfordert. Folglich werden nur diese Teilnehmerinformationen vom primären Relay-Agent mit dem Backup-Relay-Agent synchronisiert. Dies ist eine viel kleinere Gruppe von Abonnenten, als wenn die aktive leasequery die Abfrage nach relay-id-Methode verwendet, die Informationen für alle Abonnenten auf dem gesamten Chassis zurückgibt.
Das Ergebnis dieses Prozesses ist, dass jeder Peer-Agent die Abonnenten für jede Redundanzgruppe installiert, die er verarbeitet. Wenn der primäre Relay-Agent ein Failover durchführt, verfügt die Sicherung bereits über die erforderlichen Teilnehmerinformationen, um die betroffenen Abonnentensitzungen ohne Unterbrechung aufrechtzuerhalten.
Die Bulk-LeaseQuery-Phasen und die aktive LeaseQuery-Verbindung werden über die TCP-Verbindung ausgeführt. Im Gegensatz dazu sendet DHCP während der Topologieermittlungsphase die Abfragenachrichten über TCP, die Antwortnachrichten für die Topologieermittlung jedoch über UDP. Der TCP-Pfad kann ein beliebiger Pfad sein, aber der UDP-Pfad muss über die Zugriffsschnittstelle führen. Auf diese Weise bestätigen die Peers, dass ihre Zugriffsschnittstellen verbunden sind.
Topologieermittlungsmeldungen
Die Topologieermittlung verwendet die standardmäßigen einzelnen leasequery-Nachrichten. Für DHCPv4 sind dies DHCPLEASEQUERY und DHCPLEASEACTIVE. Für DHCPv6 sind dies LEASEQUERY und LEASEQUERY-REPLY. Der Unterschied, der diese Nachrichten speziell zu Topologieermittlungsnachrichten macht, besteht darin, dass jede Nachricht einen proprietären Unteroptionswert in der herstellerspezifischen Option enthält (Option 43 für DHCPv4 und Option 17 für DHCPv6). Der proprietäre Wert ist eine Zeichenfolge, topology_discover_lq. Tabelle 12 listet die Informationen auf, die in den Abfrage- und Antwortnachrichten enthalten sind.
Die Topologieerkennung für die VRRP-M:N-Redundanz verwendet TCP für die Abfrage und UDP für die Antwort. Bei der Topologieerkennung für die Pseudowire M:N-Redundanz wird TCP sowohl für die Abfrage als auch für die Antwort verwendet.
Frage |
Antwort |
|---|---|
Transaktions-ID (xid): Diese Nummer ist für jedes Gehäuse eindeutig. DHCP generiert die xid für eine Zugriffsschnittstelle, die von einer Anwenderredundanzgruppe verwendet wird. Die xid wird im DHCP-Header geführt. |
Transaktions-ID (xid): Derselbe Wert, der in der Anforderungsnachricht empfangen wurde. |
Client-Kennung (DHCPv4 Option 61; DHCPv6-Option 1): Eine Zeichenfolge, die den DHCP-Client basierend auf der LACP-MAC-Adresse identifiziert. |
Client-Kennung (DHCPv4 Option 61; DHCPv6-Option 1): Derselbe Wert, der in der Anforderungsnachricht empfangen wurde. |
N/A |
Serverkennung (DHCPv4 Option 54; DHCPv6, Option 2): Eine Zeichenfolge, die den Relay-Agent basierend auf der LACP-MAC-Adresse identifiziert |
Agenten-Circuit-ID (DHCPv4 Option 82; DHCPv6-Option 18): Schnittstellenname der Zugriffsschnittstelle, für die die Abfrage durchgeführt wird. Dies wird für die Übersetzung der lokalen und der Peer-Schnittstellen-ID verwendet. |
Agenten-Circuit-ID (DHCPv4 Option 82; DHCPv6-Option 18): Schnittstellenname der übereinstimmenden Zugriffsschnittstelle auf dem Peer. Dies wird für die Übersetzung der lokalen und der Peer-Schnittstellen-ID verwendet. |
Anbieterspezifische Option (DHCPv4 Option 43; DHCPv6-Option 17): Diese Option enthält die folgenden Informationen, die spezifisch für den Anbieter Juniper Networks sind:
|
Anbieterspezifische Option (DHCPv4 Option 43; DHCPv6-Option 17): Diese Option enthält die folgenden Informationen:
Bei M:N-Redundanz mit VRRP basiert der Abgleich auf dem Namen und der Subnetzadresse der abfragenden Schnittstelle, der VLAN-ID und der Transaktions-ID, die in der Anforderung empfangen wurden. Bei M:N-Redundanz mit Pseudowires basiert der Abgleich auf dem gemeinsamen gemeinsamen Schlüssel und der Transaktions-ID der Abfrageschnittstelle, die in der Anforderung empfangen wurden. |
Die Peer-Relay-Agents tauschen Topologieermittlungsnachrichten aus, wenn eine der folgenden Situationen eintritt:
Sie konfigurieren einen neuen Peer-Relay-Agent.
Der Router stellt die Verbindung einer Zugriffsschnittstelle wieder her, sodass die Verbindung hergestellt wird.
Der Router wird gestartet.
Der jdhcpd-Prozess wird neu gestartet.
Sie konfigurieren die aktive leasequery.
Die Topologie ändert sich. Der Relay-Agent erkennt diese Änderung, wenn eine Topologieermittlungsabfrage für eine Verbindung eingeht, die zuvor erkannt wurde.
Eine ausführliche Erläuterung der Funktionsweise der Topologie mit M: N-Subscriber-Redundanz finden Sie unter Übersicht über M:N-Subscriber-Redundanz.
Richtlinien für die Konfiguration der Unterstützung für einzelne, Massen- und aktive leasequery-Vorgänge
Beachten Sie bei der Konfiguration der Unterstützung für Einzel-, Massen- oder aktive leasequery die folgenden Richtlinien:
Der Router unterstützt die gleichzeitige Konfiguration von einzelnen leasequery, bulk leasequery und active leasequery. Für die aktive leasequery muss eine bulk-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 DHCPv4- und DHCPv6-Einzel-LeaseQuery- oder Bulk-LeaseQuery-Vorgänge separat auslösen.
Der DHCP-Relay-Agent unterstützt einzelne LeaseQuery- oder Massen-LeaseQuery über statische und dynamische Schnittstellen. Active leasequery wird nur auf statischen Serverschnittstellen oder statischen Peer-Schnittstellen für Gehäuseredundanz unterstützt.
Der lokale DHCP-Server unterstützt Bulk-Lease-Abfragen nur für statische Schnittstellen mit Relay-Schnittstellen.
Der lokale DHCP-Server überwacht die TCP-Verbindung an Port 67 für DHCPv4 und an Port 547 für DHCPv6 auf bulk-leasequery- und aktive leasequery-Anforderungen vom DHCP-Relay-Agenten.
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 über statische Schnittstellen (ge/ae/xe/irb/ps) (Unterstützung für ps-Schnittstellen in Junos OS Version 20.1R1 hinzugefügt.)
DHCP-over-IP-Demux-Schnittstellen
DHCP-over-VLAN-Demux-Schnittstellen
DHCP over IP over VLAN Demux-Schnittstellen
Ab Junos OS Version 19.1R1 fügt der DHCPv4-Relay-Agent die Option "Relay-ID" wie folgt in jedes Paket ein, das er an den lokalen DHCP-Server weiterleitet:
Der Relay-Agent fügt die Option immer in nicht ausgeschnüffelte Pakete ein.
Der Relay-Agent fügt die Option nur dann in Snooped-Pakete ein, wenn Bulk leasequery in dieser LS:RI konfiguriert ist.
Wenn das Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie den DHCP-Relay-Agent so konfigurieren, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.
Konfigurieren und Verwenden von DHCP Individual Leasequery
Der einzelne leasequery-Vorgang aktualisiert die Leasedatenbank eines DHCP-Relay-Agents mit Informationen, die sich auf einen einzelnen, angegebenen Abonnenten beziehen. 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. Weitere Informationen finden Sie unter Verwenden von DHCP Relay Agent Option 82-Informationen.
Wenn das Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die Anweisung
include-irb-and-l2einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCP-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Namen der Layer-2-Schnittstelle, wenn die Lease-Datenbank mithilfe von LeaseQuery oder Bulk LeaseQuery wiederhergestellt wird.[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 zur Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Weitere Informationen finden Sie unter Überschreiben von Option 82-Informationen.
[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. Weitere Informationen finden Sie unter Einfügen der DHCPv6-Schnittstellen-ID-Option (Option 18) in DHCPv6-Pakete.
Wenn Ihr Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCPv6-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.[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 unterstützten show und-Befehle clear , um Informationen zum Massenleasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen. Weitere Informationen finden Sie unter Überprüfen und Verwalten von DHCP-Einzel- und Massen-Lease-Abfragekonfigurationen.
Konfigurieren und Verwenden von DHCP Bulk Leasequery
Der Leasequery-Massenvorgang aktualisiert die Leasedatenbank 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 einzelne leasequery, indem zusätzliche Abfrageoptionen und -funktionen bereitgestellt werden.
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. Weitere Informationen finden Sie unter Verwenden von DHCP Relay Agent Option 82-Informationen.
Wenn das Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die Anweisung
include-irb-and-l2einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCPv6-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.[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 zur Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Weitere Informationen finden Sie unter Überschreiben von Option 82-Informationen.
[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. Weitere Informationen finden Sie unter 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 IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCPv6-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.[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 LeaseQuery-Massenvorgang zu konfigurieren und zu verwenden.
Verwenden Sie die unterstützten show und-Befehle clear , um Informationen zum Massenleasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen. Weitere Informationen finden Sie unter Überprüfen und Verwalten von DHCP-Einzel- und Massen-Lease-Abfragekonfigurationen.
Konfigurieren und Verwenden 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. Weitere Informationen finden Sie unter Verwenden von DHCP Relay Agent Option 82-Informationen.
Wenn das Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die Anweisung
include-irb-and-l2einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCPv6-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.[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 zur Option 82 in den DHCP-Paketen, die das Relay an DHCP-Server weiterleitet. Weitere Informationen finden Sie unter Überschreiben von Option 82-Informationen.
[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. Weitere Informationen finden Sie unter Einfügen der DHCPv6-Schnittstellen-ID-Option (Option 18) in DHCPv6-Pakete.
Wenn Ihr Netzwerk IRB-Schnittstellen (Integrated Routing and Bridging) enthält, müssen Sie auch die
include-irb-and-l2Anweisung einschließen, wie im folgenden Beispiel gezeigt. Mit dieser Anweisung wird der DHCPv6-Relay-Agent so konfiguriert, dass der Name der Layer-2-Schnittstelle zusammen mit dem IRB-Namen in der Circuit-ID von Option 82 enthalten ist. Der DHCP-Relay-Agent verwendet den Layer-2-Schnittstellennamen, wenn LeaseQuery oder Bulk LeaseQuery zum Wiederherstellen der Leasedatenbank verwendet wird.[edit forwarding-options dhcp-relay dhcpv6] user@host# set relay-agent-interface-id include-irb-and-l2
Für die Redundanz des DHCP-Relay-Agents auf Gehäuseebene gelten die folgenden Richtlinien:
Die DHCP-Relay-Agent-Redundanzpeers müssen alle identische Teilnehmerkonfigurationen aufweisen, um synchronisierte Datenbanken zu erhalten.
Die vollständigen Schnittstellennamen für die Zugriffsschnittstellen (
ge,xeoderae), auf denen die Teilnehmer angezeigt werden, müssen auf den DHCP-Relay-Agent-Redundanz-Peers identisch sein.
Für die primäre/Backup-Redundanz des DHCP-Relay-Agenten auf Schnittstellenebene müssen die Schnittstellennamen auf den Redundanzpeers nicht identisch sein. Der primäre Agent und der Backup-Relay-Agent verwenden die Topologieerkennung, um Übersetzungstabellen zu erstellen, die lokale und Remoteschnittstellen (Peer-Schnittstellen) für Abonnentenredundanzgruppen zuordnen.
Anmerkung:Wenn Sie die Topologieerkennung auf allen verfügbaren logischen Schnittstellen konfigurieren, wird Redundanz auf Gehäuseebene unterstützt, wenn die Schnittstellennamen und Teilnehmerkonfigurationen auf den Redundanzpeers übereinstimmen.
Da active leasequery eine Erweiterung von bulk leasequery ist, müssen Sie bulk leasequery konfigurieren, damit active leasequery ausgeführt werden kann. Weitere Informationen finden Sie unter Konfigurieren und Verwenden von DHCP-Massenleasequery.
Der aktive leasequery-Vorgang sendet Liveaktualisierungen an DHCP-Relay-Agents für mehrere Teilnehmer, 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.
Mit diesen Schritten wird keine der LeaseQuery-Massenkonfigurationen dupliziert. Die Schritte umfassen z. B. nicht die Konfiguration der maximalen Anzahl von TCP-Verbindungen, da dies Teil der erforderlichen Konfiguration der Massenleasequery ist.
Verwenden Sie die unterstützten show und-Befehle clear , um Informationen zum Massenleasequery-Vorgang für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen. Weitere Informationen finden Sie unter Überprüfen und Verwalten von DHCP-Einzel- und Massen-Lease-Abfragekonfigurationen.
EVPN-MPLS DHCPv6-PD Stateful-Relais-Synchronisation für Aktiv-Aktiv-Modus (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024 und ACX7024X)
Diese DHCPv6-PD-Funktion für die zustandsbehaftete Relaysynchronisierung bietet Unterstützung für die DHCPv6-Präfixdelegierungskonfiguration, die Folgendes umfasst:
-
Synchronisierung zwischen zwei Leaf-Knoten von EVPN-MPLS für Aktiv/Aktiv-Modus
-
DHCPv6-Präfixdelegierung, um die Delegierung von IPv6-Präfixen an das CPE zu automatisieren.
- Unterstützung für Lease-Massenabfragen 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/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) ]
Konfigurationsbeispiel:
Im folgenden Beispiel wird eine Aktiv-Aktiv-Konfiguration mit veralteter Timereinstellung angezeigt. Die veraltete Timerkonfiguration ist erforderlich, um eine Aktiv-Aktiv-Leaseabfrage zu unterstützen. Diese Konfiguration optimiert die Synchronisierungszeit, wenn beide Peers die Anforderungspakete 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-Lease-Abfrage zum Aktualisieren der DHCP-Relay-Agent-Lease-Datenbank
Sie müssen einen Anforderungsbefehl ausgeben, um den DHCP-Relay-Agent dazu zu veranlassen, einen einzelnen leasequery- oder bulk-leasequery-Vorgang zu initiieren, der aktuelle lease-Informationen von lokalen DHCP-Servern anfordert. Jede einzelne leasequery aktualisiert die Leasedatenbank des DHCP-Relay-Agents mit Informationen für einen einzelnen Client. Bei jeder Lease-Massenabfrage wird die Leasedatenbank des Relay-Agents für mehrere Clients aktualisiert. In Tabelle 13 sind die verschiedenen Abfrageoptionen aufgeführt, die für DHCPv4, DHCPv6, einzelne leasequery und bulk leasequery verfügbar sind.
Abfrageoption |
DHCPv4 – Individuelle Leasequery |
DHCPv4 Bulk Leasequery |
DHCPv6 Individuelle Leasequery |
DHCPv6-Massen-Lease-Abfrage |
|---|---|---|---|---|
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-Massenleasequery auf einem Relay-Agent mit der bulk-leasequery Anweisung und der trigger automatic Option konfiguriert haben, initiieren 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 des Relay-Agent-Geräts, einem ordnungsgemäßen Umschalten der Routing-Engine oder einer einheitlichen ISSU) und keine gebundenen Abonnenten in der Sitzungsdatenbank vorhanden sind. Die automatische Bulk-Lease-Abfrage basiert immer auf der Relay-ID-Option des Relay-Agenten (Option 53).
Wenn die Unterstützung für automatische Auslöser konfiguriert ist, können Sie den request Befehl weiterhin verwenden, um von den automatischen Abfragen getrennte Massenleaseabfragen manuell auszulösen.
Für die aktive leasequery ist kein Befehl für die request Initiierung erforderlich. Stattdessen wird sie automatisch initiiert, wenn Sie sie konfigurieren. Bei Active leasequery müssen Sie bulk leasequery konfigurieren.
DHCPv4-Relay-Agents können über mehrere Schnittstellen mit unterschiedlichen IP-Adressen verfügen, 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 einzelne DHCPv4-Leasequery zum Aktualisieren von Bindungsinformationen zu initiieren, müssen Sie immer die Gateway-IP-Adresse des Relay-Agents angeben. Sie müssen auch den Typ der Abfrage angeben:
Geben Sie eine IP-Adresse an, die für den Client geleast ist.
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-Lease-Massenabfrage zum Aktualisieren von Bindungsinformationen zu initiieren, können Sie Folgendes tun:
Geben Sie eine IP-Adresse an, die für den Client geleast ist.
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 Option für die Client-ID an (Option 61).
user@host> request dhcp relay bulk-leasequery client-id
Geben Sie die Unteroption Relay-Agent-Kennung (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 Lease-Massenabfragevorgang die Relay-ID des DHCPv4-Relay-Agents, wenn Sie keine der folgenden Optionen explizit angeben: client-id, ipv4-address, relay-idmac-address, oder 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 einzelne DHCPv6-Leasequery zum Aktualisieren von Bindungsinformationen zu initiieren, können Sie Folgendes tun:
Geben Sie die Client-ID an (Option 1).
user@host> request dhcpv6 relay leasequery client-id
Geben Sie eine IPv6-Adresse an, die für den Client geleast ist.
user@host> request dhcpv6 relay leasequery ipv6-prefix
Um eine DHCPv6-Massenleasequery zu initiieren, um Bindungsinformationen zu aktualisieren, 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-Verbindungsadresse 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 Bulkleasequery-Vorgang die Relay-ID des DHCPv6-Relay-Agents, wenn Sie keine der folgenden Optionen explizit angeben: client-id, ipv6-prefix, relay-idipv6-link-address, oder 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 einzelne und Massenleasequery-Anforderung 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 dies eine beliebige konfigurierbare Option, option wie zuvor gezeigt. Der Kürze halber zeigt das Beispiel nur eine einzelne 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 Routinginstanz 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 DHCP-Einzel- und Massen-Leasequery-Konfigurationen
Zweck
Zeigen Sie Informationen zu DHCP-Einzel-LeaseQuery- und Bulk-LeaseQuery-Vorgängen an oder löschen Sie sie. Verwenden Sie die unterstützten show und-Befehle clear , um Informationen zu den leasequery- und leasebulkquery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen.
Informationen zu active leasequery finden Sie unter Überprüfen und Verwalten aktiver DHCP-Leasequery-Vorgänge.
Aktion
Verwenden Sie die unterstützten show und-Befehle clear , um Informationen zu den leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen.
So zeigen Sie leasequery-Informationen für den 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 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 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 zu aktiven DHCP-leasequery-Vorgängen an oder löschen Sie sie. Verwenden Sie die unterstützten show und-Befehle clear , 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-Lease-Abfragen finden Sie unter Überprüfen und Verwalten von DHCP-Einzel- und Massen-Leasequery-Konfigurationen.
Aktion
Verwenden Sie die unterstützten show und-Befehle clear , um Informationen zu den leasequery-Vorgängen für den DHCP-Relay-Agent und den lokalen DHCP-Server zu verwalten und anzuzeigen.
So zeigen Sie aktiveLeaseabfrageinformationen 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 der 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 : Yes State : Done 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 : Yes State : Done 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 Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.