M:N Subscriber Service Redundanz auf DHCP-Server

Sie können die M:N-Abonnentendienstredundanz auf einem DHCP-Server konfigurieren, der auf einem Breitband-Netzwerk-Gateway (BNG) der MX-Serie ausgeführt wird. Der DHCP-Server verwaltet eine beträchtliche Menge an verlässlichen Informationen über die Adresse, die er an die DHCP-Clients vermietet hat. Um BNG-Redundanz auf Gehäuseebene der MX-Serie für Breitband-Abonnenten zu erreichen, sollte das Backup-Gerät der MX-Serie, auf dem der DHCP-Server ausgeführt wird, über alle maßgeblichen Teilnehmerinformationen verfügen. Der Sicherungsserver stellt einen unterbrechungsfreien Abonnentendienst sicher, wenn Sie den primären DHCP-Server neu starten oder ersetzen oder der primäre Server Hardwarefehler aufweist, z. B. Fehler bei Zugriffsverbindungen, Zugriffsleitungskarten oder Gehäusefehlern.

Die Abonnentendienstredundanz auf dem DHCP-Server konzentriert sich auf die Anwendersynchronisierung zwischen den Peerservern mithilfe von Active leaseQuery. Liveaktualisierungen von Bindungsinformationen zwischen den beiden Peerservern tragen dazu bei, die Server im Hot-Standby-Modus zu halten.

Bei der 1:1-Teilnehmerdienstredundanz wird ein DHCP-Server (primärer DHCP-Server) auf einem anderen DHCP-Server (Backup-DHCP-Server) für Anwenderschnittstellen gesichert. Sowohl der primäre als auch der Backup-Server verfügen über die gleichen Konfigurationen. Ab Junos OS Version 24.4R1 bietet die gehäusebasierte DHCP-Redundanzfunktion für MX480-Zugriffsmodelle die zusätzliche Funktionalität einer 1:1-Chassis-basierten aktiven Lease-Abfrage unterhalb der Quantifizierungsgrenze (ALQ/BLQ) für nicht teilnehmende zugrunde liegende Anwenderschnittstellen, ohne dass eine Topologieerkennung konfiguriert werden muss. Diese Funktion wird für Stacks und DHCP-Konfigurationen, BBE und Nicht-BBE-DHCP ohne Topologieermittlung, für die folgenden Szenarien unterstützt:

• Abonnentenverwaltung aktiviert.
• Die Abonnentenverwaltung ist deaktiviert.
• IP-Demux/ IP-Demux Lite.
• Dual Stack und Dual Stack in einer Sitzung.
• Pseudo Wire Access-Modell PS-Schnittstelle (L2 Circuit / EVPN VPWS / L2VPN).
• VRRP-Zugangsmodell GE-, XE- und AE-Schnittstellen.
• Nicht standardmäßige Routinginstanz.

• DHCP-Relay und DHCP-Server.

  Details zur Konfiguration finden Sie unter Konfigurationsbeispiel: ALQ/BLQ für 1:1 DHCP-Redundanz.

Bei der M:N-Abonnentendienstredundanz werden mehrere (M) DHCP-Server (primärer DHCP-Server) auf mehreren (N) DHCP-Servern (Backup-DHCP-Server) gesichert. Die Redundanz des M:N-Abonnentendiensts erfordert eine Topologieerkennung, um die Schnittstellen zwischen den Peer-Servern zuzuordnen. Um die Abonnenten auf der Schnittstelle zu replizieren, verwendet Gi-Address die aktive leasequery query query für IPv4 und link-address query für IPv6.

Wenn die Abonnenten die leasequery-Antwort erhalten, schaltet der entsprechende Zustandsautomat den Abonnenten auf dem Sicherungsserver ein. Anschließend werden die DHCP-Adresse und die Lease-Informationen zwischen den Servern synchronisiert. Wenn sich die Lease- oder Adressinformationen ändern, durchläuft die Backup-BNG den entsprechenden Zustandsautomaten, um den Abonnentenstatus hoch- oder herunterzufahren.

Derzeit unterstützt die Abonnentendienstredundanz auf DHCP das Pseudowire-Redundanzprotokoll und die Topologieerkennung über Pseudowire zwischen den Peerservern. Die Teilnehmerdienstredundanz unterstützt die in Tabelle 1 aufgeführten Protokolle.

Tabelle 1: Redundanz für Abonnentendienste

Unterstützte Protokolle	Abonnentendienste Redundanzmodus	Zusätzliche Details
IPoE-DHCP-Relay, statisches VLAN	M:N Stateful mit VRRP und aktiver leasequery	Für dynamische VLAN-Unterstützung muss PWHT verwendet werden
IPoE-DHCP-Relay über PWHT	M:N Stateful mit aktiver leasequery
IPoE-DHCP-Server über PWHT	M:N zustandsbehaftet	Unterstützung für dynamische oder statische VLANs

Abbildung 1 zeigt die Topologie für L2-Circuit-basiertes IP/MPLS PWHT im Client-Server-Modus.

Abbildung 2 zeigt die Topologie für L2-Circuit-basiertes IP/MPLS PWHT im Client-Relay-Server-Modus.

Sowohl im Client-Server-Modus als auch in der Client-Relay-Server-Modustopologie verwenden BNG-Server die TCP-Verbindung für eine aktive leasequery, um Bindungsdetails zu synchronisieren. Die Abonnentendienstredundanz auf dem DHCP-Server erfolgt in der folgenden Reihenfolge:

1. Active Pseudowire Link empfängt Pakete vom Client.
2. Der Abonnent stellt eine Verbindung zum primären BNG her.
3. Primäres BNG synchronisiert die Abonnentenbindungsdetails mit Backup-BNG über eine TCP-Verbindung.
4. Wenn Sie die primäre BNG neu starten oder ersetzen oder die primäre BNG einen Gehäuseausfall aufweist, wird die Backup-Pseudowire-Verbindung aktiv.
5. Die Backup-BNG empfängt Pakete vom Client.
6. Da sich Backup-BNG bereits im Hot-Standby-Modus befand, kann es Pakete für aktive leasequery erneuern oder neu binden und auch Abonnenten synchronisieren.

Für die Redundanz des M:N-Abonnentendiensts müssen Sie die Teilnehmerschnittstelle auf dem Sicherungs-DHCP-Server sichern. Die Schnittstelle kann unterschiedliche Namen haben. Der primäre DHCP-Server verwendet die Topologieermittlung, um die Schnittstellen zwischen Peer-DHCP-Servern zuzuordnen.

Der DHCP-Server verwendet die Gi-Adress- oder Link-Adressabfrage, um die Teilnehmerinformationen auf dem Sicherungs-DHCP-Server zu replizieren. Im Server werden Clients mit unterschiedlicher Gi-Adresse oder Link-Adresse auf einer einzigen Schnittstelle angezeigt, daher sollte der primäre BNG die Anfrage mit allen Teilnehmern beantworten, die unterschiedliche Gi-Adressen oder Link-Adressen auf der Schnittstelle haben. Um diese Funktionalität zu unterstützen, erstellt der Server eine neue Tabelle, in der die Clients basierend auf der eingehenden Schnittstelle gespeichert werden. Wenn der Server eine Gi-Adress- oder Link-Adress-Abfrage empfängt, antwortet der Server auf die Abfrage aus der neuen Tabelle wie folgt:

• Wenn der Server eine Anforderung sendet, überprüft er die Konfiguration der Topologieerkennung und sendet eine GI-Adress- oder Link-adress-basierte Abfrage mit der IP-Adresse der Schnittstelle.
• Wenn der Server eine auf GI-Adresse oder Link-Adresse basierende Abfrage empfängt, überprüft der Server die vorhandene Serverkonfiguration. Wenn eine aktive leasequery-Konfiguration verfügbar ist, antwortet der Server auf die Abfrage basierend auf der neuen Datenbank.

Eine aktive Leasequery kann jederzeit zwischen Relay zu Relay oder Server zu Server durchgeführt werden. Der DHCP-Server akzeptiert möglicherweise nicht gleichzeitig eine Verbindung vom Peer-Server oder Relay, daher kann die Konfiguration im DHCP-Server entweder active-leasequery oder allow-active-leasequery, allow-bulk-leasequery oder allow-leasequery sein.