M:N Subscriber Redundancy auf BNG

Vorteile der M:N Subscriber Redundanz auf BNG

• Bietet eine leichtgewichtige Anwenderredundanz auf Anwendungsebene. Sie können es verwenden, um mehrere verschiedene Teilnehmergruppen auf mehreren verschiedenen BNG-Gehäusen zu sichern. Jede Teilnehmergruppe verfügt über eine Backups im Hot-Standby-Modus.

• Mehrere BNGs fungieren gleichzeitig als aktives BNG für eine oder mehrere Anwenderredundanzgruppen und als Backup-BNG für andere Anwenderredundanzgruppen.

• Die M:N-Redundanz ist komplementär zur Virtual Chassis-Redundanz der MX-Serie. M:N-Redundanz ist für verteilte Umgebungen geeignet. Virtual Chassis der MX-Serie, erfordert ein dediziertes Gehäuse für Redundanz. Es bietet 1:1-Redundanz und wird am häufigsten in zentralisierten Bereitstellungen eingesetzt.

• M:N-Redundanz mit DHCP Active LeaseQuery Topology Discovery schützt die Teilnehmer vor verschiedenen Hardware- und Software-Single-Points-of-Failure. Dazu gehören Ausfälle bei Zugriffsverbindungen (auf Abonnentenseite) oder Core-Verbindungen sowie in einem Zugriffsschnittstellenmodul oder im Gehäuse. Außerdem schützt es vor Netzwerkausfällen mit teilweisem Zugriff und teilweisem Core-Netzwerk.

• Sie können die M:N-Redundanz für aktive Abonnenten aktivieren oder deaktivieren. Wenn Sie die Redundanzkonfiguration entfernen, bleiben Abonnenten, bei denen die Konfiguration vorhanden war, sowohl auf den primären als auch auf den Backup-BNGs intakt.

• Sie können M:N-Redundanz mit einer einzigen Core-Schnittstelle bereitstellen. Das bedeutet, dass sich mehrere Anwenderredundanzgruppen eine gemeinsame Core-Konnektivität teilen können.

• M:N-Redundanz-Abonnenten können mit Nicht-Redundanz-Abonnenten koexistieren. Das bedeutet, dass Sie keine BNGs haben müssen, die für Anwenderredundanz vorgesehen sind.

• Sie können M:N-Redundanz-Abonnenten zur Laufzeit konfigurieren, auch nachdem die Abonnenten aktiv sind. Dies ist nützlich für Softwareaktualisierungen, da Sie Abonnenten migrieren können, um BNGs zu sichern und dann die Software zu aktualisieren.

Grundlagen der M:N-Redundanz

Anmerkung:

Der Einfachheit halber wird in dieser Dokumentation hauptsächlich die Verwendung von DHCP-Abonnenten in statischen VLANs erläutert.

Die Grundlage der M:N-Redundanz besteht darin, dass mehrere (M) Teilnehmergruppen auf einem bestimmten BNG-Chassis auf mehreren (N) verschiedenen Chassis-Zielen gesichert werden können. Wir bezeichnen diese Gruppen als Abonnentenredundanzgruppen.

Eine Abonnentengruppe besteht aus allen Abonnenten, die die folgenden Kriterien erfüllen:

• (Statische VLANs) Die Teilnehmer gehören zu einem bestimmten statischen VLAN und verwenden dieselbe logische Zugriffsschnittstelle, z. B. ge-1/0/10/1. Ein Zugriffsgerät, z. B. ein Switch, DSLAM oder OLT, fasst die Teilnehmer im gemeinsamen VLAN zusammen.

• (Dynamische VLANs) Die Teilnehmer gehören demselben dynamischen VLAN an und verwenden dieselbe physische Zugriffsschnittstelle, z. B. ge-1/0/0.

• (Statische IP-Demo) Die Teilnehmer verfügen alle über eine Quell-IP-Adresse, die mit dem konfigurierten Subnetz übereinstimmt.

Wenn Sie die Redundanz für eine Abonnentengruppe konfigurieren, wird diese zu einer Abonnentenredundanzgruppe. Eine bestimmte Abonnentenredundanzgruppe verwendet jeweils nur eine BNG. Wir nennen dies BNG die primäre. Für jede Subscriber-Redundanzgruppe fungiert nur eine der anderen BNGs als Backup im Hot-Standby-Modus. Wenn einer der in Tabelle 1 aufgeführten Fehler für die primäre BNG auftritt, wird ein Failover auf die entsprechende Sicherungs-BNG für die betroffene Redundanzgruppe ausgeführt. Diese Backup-BNG ist jetzt die neue primäre BNG für diese Gruppe. Alle aktiven Abonnentensitzungen für diese Abonnentenredundanzgruppe werden während des Failovers auf die Sicherungs-BNG beibehalten.

Abbildung 2 ist ein konzeptionelles Diagramm, das die M:N-Primär-/Backup-Beziehungen veranschaulicht. Es zeigt fünf BNGs in einer M:N-Primär-/Backup-Topologie, wobei jede BNG eine Beziehung zu jeder anderen BNG hat. Wenn BNG 1 der primäre Anbieter ist, können Sie BNG 2, 3, 4 und 5 als Sicherungs-BNG für verschiedene Abonnentenredundanzgruppen konfigurieren. Wenn BNG 2 der primäre Server ist, können Sie BNG 1, 3, 4 und 5 als Backup-BNG konfigurieren usw.

Für die M:N-Redundanz ist es wichtig zu verstehen, dass Sie Folgendes konfigurieren können:

• Nur eine Sicherungs-BNG für jede Abonnentenredundanzgruppe.

• Ein BNG als Backup-Router für mehr als eine Redundanzgruppe.

Das bedeutet, dass ein bestimmter BNG gleichzeitig sowohl der primäre Router für viele Redundanzgruppen als auch der Backup-Router für viele verschiedene Redundanzgruppen sein kann. Wenn eine primäre BNG ausfällt, führt sie ein Failover auf den Backup-Router durch, den Sie für jede seiner Redundanzgruppen konfigurieren. Die Abonnentensitzungen für alle Redundanzgruppen auf der primären BNG werden auf allen Backup-BNGs beibehalten, die zu neuen primären Gruppen für die Gruppen werden.

Abbildung 3 zeigt eine einfache Konfiguration von Teilnehmergruppen und Teilnehmerredundanzgruppen auf drei DHCP-Relay-Agenten, die auf drei BNGs gehostet werden. Die BNGs können direkt miteinander verbunden sein oder über das Zugangs- oder Kernnetzwerk verbunden sein.

• Der Relay-Agent RA1 ist für die Anwenderredundanzgruppen SRG 1 und SRG 2 sowie die Anwendergruppe SG A konfiguriert.

• Der Relay-Agent RA2 ist für SRG 2 und SRG 3 konfiguriert.

• Der Relay-Agent RA3 ist für SRG 1, SRG 3 und SG B konfiguriert.

Man kann es auch so sehen:

• SRG 1 kann auf RA1 und RA3 aktiv sein oder gesichert werden.

• SRG 2 kann auf RA1 und RA2 aktiv sein oder gesichert werden.

• SRG 3 kann auf RA2 und RA3 aktiv sein oder gesichert werden.

• SG A und SG B werden nicht gesichert.

Betrachten Sie nun Abbildung 4, die die gleiche Topologie zeigt, aber angibt, welche BNG primär und welche für jede Redundanzgruppe ein Backup ist. Die BNG, die RA 1 hostet, ist die primäre BNG für SRG 1 und SRG 2.

Wenn diese BNG fehlschlägt, wird ein Failover auf eine andere Sicherungs-BNG für SRG 1 und SRG 2 ausgeführt, wie in Abbildung 5 dargestellt.

• Für SRG 1 wird ein Failover auf die BNG ausgeführt, die RA 3 hostet. Die RA 3 BNG wird die neue Vorwahl für SRG 1.

• Für SRG 2 wird ein Failover auf die BNG ausgeführt, die RA 2 hostet. Der RA 2 BNG wird der neue Primär für SRG 2.

Der Ausfall hat keine Auswirkungen auf SRG 3.

Abonnentensitzungen und Hot-Standby-Modus

Jede Sicherungs-BNG befindet sich im Hot-Standby-Modus für die entsprechende primäre BNG für jede Abonnenten-Redundanzgruppe in der Sicherung. Das bedeutet, dass die Backup-BNG bei einem Failover sofort und ohne Unterbrechung die primäre BNG ersetzen kann. Die folgenden Verhaltensweisen der primären und Backup-BNG ermöglichen die Funktion des Hot-Standby-Modus.

• Abonnentenbindungen und der Abonnentenstatus werden synchron in die Sicherungs-BNG gespiegelt, ebenso wie die ARP- und Nachbarermittlungsinformationen der primären BNG. Jeder Abonnent wird auf der Backup-BNG aktiviert und sein Status ist Aktiv. Da die Abonnenten gleichzeitig auf der primären und der Backup-BNG aktiv sind, führt die Backup-BNG während eines Failover-Ereignisses keine Abonnentenverarbeitung durch.

• Jede Abonnentensitzung wird vor, während und nach einem Failover als kontinuierliche Sitzung behandelt. Bei der ersten Teilnehmeranmeldung senden die primären und Backup-BNGs jeweils eine RADIUS Accounting-Start-Nachricht oder OCS CCR-I-Nachricht für den Abonnenten.

  Während des Failovers sendet der fehlerhafte primäre Server nach bestem Bemühen eine Accounting-Stop- oder CCR-T-Nachricht. Er sendet z. B. die Nachricht, ob die Kernverbindung noch aktiv ist oder wenn das Chassis noch ausgeführt wird. Wenn die Core-Verbindung oder das gesamte Gehäuse ausgefallen ist, kann der fehlerhafte primäre Server keine Accounting-Stop- oder CCR-T-Nachricht senden.

  Wenn die Backup-BNG zur primären wird, sendet sie keine Accounting-Start- oder CCR-I-Nachricht, da die Abonnenten während des Failovers aktiv sind. Die Buchhaltungsstatistik wird von der neuen primären Datenbank erhöht.

• Bei der ersten Anmeldung für einen Teilnehmer fügt das BNG seiner Routing-Tabelle Anwenderrouten hinzu und gibt die Routen an das Kernnetzwerk weiter. Wenn die primäre BNG ein Failover durchführt, löscht sie keine Anwenderrouten aus ihrer eigenen Routing-Tabelle und zieht die Routen nicht aus dem Kernnetzwerk zurück. Nach dem Failover fügt der ausgefallene primäre Server keine Routen hinzu und gibt diese auch nicht weiter. Alternativ können Sie die Anwenderrouten so konfigurieren, dass sie basierend auf der primären BNG-Rolle zum Core angekündigt oder ihm entzogen werden, sodass es durch das Failover zu keinem Datenverkehrsverlust kommt.

Anmerkung:

Die Zustandssynchronisierung gilt nur für den Abonnentenstatus. Der Dienststatus ist nicht synchronisiert. Abhängig von Ihrer Dienstkonfiguration kann der BNG Dienste für die Abonnenten sowohl auf aktiven als auch auf Backup-Abonnenten anfügen. Alternativ können die Dienste nach einem Failover auf dem neuen aktiven BNG erneut angefügt werden.

Anmerkung:

Die M:N-Abonnentenredundanz synchronisiert die Buchhaltungsstatistiken nicht von der primären BNG mit der Backup-BNG. Es wird nach bestem Wissen und Gewissen versucht, Buchhaltungsinformationen an einen Buchhaltungsserver zu übermitteln. Wenn ein Failover auftritt, beginnen die Buchhaltungsstatistiken mit der inkrementellen Abrechnung ab der neuen primären Datenbank und werden ab der fehlerhaften primären Datenbank beendet. Je nach Schwere des Fehlers können Failover zum Verlust von Buchhaltungsinformationen führen.

M:N-Redundanz mit Virtual Router Redundancy Protocol (VRRP)

Sie können VRRP verwenden, um M:N-Redundanz in einem Netzwerk bereitzustellen. M:N-Redundanz verwendet VRRP, um eine virtuelle IP- und MAC-Adresse bereitzustellen, die von zwei BNGs in einer VRRP-Gruppe (manchmal auch als VRRP-Instanz bezeichnet) gemeinsam genutzt werden. Die VRRP-Gruppe entspricht einem einzelnen virtuellen Router. Sie konfigurieren die VRRP-Gruppe auf der jeweiligen Zugriffsschnittstelle auf jedem BNG. Die Zugriffsschnittstelle ist die dem Teilnehmer zugewandte logische Schnittstelle, die mit dem Zugriffsnetzwerk verbunden ist.

Die virtuelle IP-Adresse wird zur Standard-Gateway-Adresse für die BNGs in der Gruppe. Nur der BNG, der als primärer Server fungiert, sendet VRRP-Ankündigungen oder reagiert auf Datenverkehr, der für die Adresse des virtuellen Routers bestimmt ist. Das BNG kündigt den Anwenderhosts nur die Adresse des virtuellen Gateways und die virtuelle MAC-Adresse an. Da beide Router in der Gruppe dieselbe Adresse des virtuellen Gateways verwenden, ist keine Interaktion mit den Hosts erforderlich, und das Failover vom primären zum Backup erfolgt innerhalb weniger Sekunden.

Anmerkung:

Die VRRP-Lösung für M:N-Redundanz ist auf ein N:1-Anwenderzugriffsmodell ausgerichtet, das statische, zugrunde liegende logische Schnittstellen verwendet.

Ausführliche Informationen zur Funktionsweise von VRRP im Allgemeinen finden Sie unter Grundlegendes zu VRRP und verwandten Themen im Benutzerhandbuch für hohe Verfügbarkeit.

Sie konfigurieren unterschiedliche Prioritäten für die beiden Router in einer VRRP-Gruppe, um zu bestimmen, welchen Router die Gruppe als primären Router auswählt:

1. Der Router mit der höheren Priorität für die Gruppe ist der primäre. Je größer die Zahl, desto höher die Priorität. Beispielsweise ist zwischen zwei Gruppenmitgliedern mit den Prioritäten 100 bzw. 50 der Router mit der Priorität 100 der primäre Router.

2. Wenn der primäre Router ausfällt, wählt das Protokoll den Backup-Router als neuen primären Router aus. Der neue primäre Server übernimmt den Besitz der virtuellen IP- und MAC-Adressen. Ein Failover hat keine Auswirkungen auf den Datenverkehr.

3. Wenn die ursprüngliche primäre Datenbank wieder online geschaltet wird, stellt das Protokoll fest, dass sie eine höhere Priorität hat als die aktuelle primäre Datenbank (vorherige Sicherung). Der ursprüngliche primäre Server nimmt dann die primäre Rolle wieder auf, ohne dass dies Auswirkungen auf den Datenverkehr hat.

   Anmerkung:

   Bei der Verwendung von VRRP für M:N-Abonnentenredundanz ist die Anzahl der Teilnehmerredundanzgruppen auf die Anzahl der unterstützten VRRP-Sitzungen auf dem Gerät beschränkt. Für Dual-Stack erfordert diese Funktion separate VRRP-Sitzungen für IPv4 und IPv6, daher halbiert sich die Anzahl der Anwenderredundanzgruppen.

Abbildung 6 zeigt eine Beispieltopologie mit zwei BNGs und die Konfiguration für die entsprechenden Schnittstellen auf jedem Router:

• Die beiden logischen Schnittstellen befinden sich im selben VLAN (1).

• Die Schnittstellenadressen befinden sich im selben Subnetz (203.0.113.1/24 und 203.0.113.2/24).

• Die Schnittstellenadressen befinden sich in derselben VRRP-Gruppe (27) und teilen sich dieselbe virtuelle IP-Adresse (203.0.113.25).

• Die BNG mit der höheren Priorität (254) wird in den Vorwahlen gewählt; der BNG mit der niedrigeren Priorität (200) ist das Backup.

Abbildung 7 zeigt, wie die konfigurierte VRRP-Priorität bestimmt, welche BNG als primäre oder Sicherung für eine Abonnentenredundanzgruppe fungiert.

Die Topologie umfasst drei Anwenderredundanzgruppen (M), SRG 1, SRG 2 und SRG 3 auf drei BNGs (N). Jede Abonnentenredundanzgruppe entspricht einer anderen VRRP-Gruppe. Die Pfeile zeigen den primären Router und den Backup-Router für jede Gruppe an

• Für SRG 1 hat BNG 1 die höhere Priorität, 250. BNG 3 hat eine niedrigere Priorität, 200. Dies bedeutet, dass BNG 1 die primäre Lösung für SRG 1 und BNG 3 die Sicherung ist, sodass BNG 1 ein Failover auf BNG 3 durchführt. Wenn sich BNG 1 erholt, wird es primär für SRG 1 wiedergewählt, da es eine höhere Priorität als BNG 3 hat.

• Für SRG 2 hat BNG 1 ebenfalls die höhere Priorität, 180, und ist die primäre. BNG 2 hat eine niedrigere Priorität, 150, und ist das Backup.

• Für SRG 3 hat BNG 2 die höhere Priorität, 100, und ist die primäre. BNG 3 hat eine niedrigere Priorität, 75, und ist das Backup.

VRRP-Failover und Umkehrungs-Timing

Nehmen Sie unter Verwendung der in Abbildung 7 gezeigten Redundanzkonfiguration an, dass BNG 1 für SRG 1 ein Failover auf BNG 3 durchführt, sodass BNG 3 der neue primäre Schlüssel für die Gruppe ist. Die primäre Rolle wird automatisch auf BNG 1 zurückgesetzt, wenn sie wieder aktiviert wird. Wenn die Verbindung zwischen den beiden BNGs über das Zugriffsnetzwerk verläuft (im Vergleich zu einer direkten Verbindung zwischen den BNGs), werden die Teilnehmerzustände möglicherweise nicht zwischen den beiden BNGs synchronisiert, wenn die primäre Rolle wiederhergestellt wird. Der VRRP-Status ist unabhängig von der aktiven DHCP-LeaseQuery-Synchronisierung.

Wenn der Zugriffslink auf BNG 1 wiederhergestellt wird, stellt die aktive DHCP-Leasequery die Verbindung für die Abonnentensynchronisierung zwischen den BNGs wieder her. DHCP beginnt mit der Neusynchronisierung des Abonnentenstatus und der Bindungsinformationen vom aktuellen primären Netzwerk (BNG 3) mit dem wiederhergestellten ursprünglichen primären Netzwerk (BNG 1).

Buchhaltungsstatistiken können beeinträchtigt werden, wenn die primäre Rolle vor Abschluss der Neusynchronisierung auf BNG 1 zurückgesetzt wird. Beispielsweise werden Buchhaltungsstatistiken für Abonnenten, die sich anmelden, der Datenbank erst nach Abschluss der Neusynchronisierung hinzugefügt. Abmeldemeldungen für Abonnenten, die sich abmelden, werden erst verarbeitet, wenn die Synchronisierung abgeschlossen ist und die Abonnenten auf BNG 1 wiederhergestellt sind.

Sie können diese Auswirkungen abmildern, indem Sie den VRRP-Haltetimer (manchmal auch als Umkehr-Timer bezeichnet) so konfigurieren, dass die Neusynchronisierung abgeschlossen wird, bevor der ursprüngliche primäre Timer die primäre Rolle wieder übernimmt. Verwenden Sie die hold-time Anweisung auf der [edit interfaces] Hierarchieebene.

Beste Praxis:

Es wird empfohlen, die VRRP-Redundanz im nicht rückgängig zu machenden Modus zu konfigurieren, wenn Sie mit hoher Skalierung arbeiten. Für Systeme, die nicht in großem Maßstab arbeiten, können Sie entweder den nicht-revertiven Modus verwenden oder den VRRP-Hold-Timer (manchmal auch als Reverse-Timer bezeichnet) mit Werten konfigurieren, die hoch genug sind, dass die Neusynchronisierung abgeschlossen ist, bevor der ursprüngliche primäre Timer die primäre Rolle wieder aufnimmt.

M:N-Redundanz mit Pseudowire-Redundanz

Ab Junos OS Version 20.1R1 können Sie Pseudowire-Redundanz verwenden, um M:N-Redundanz bereitzustellen, wenn das Zugriffsnetzwerk aus Layer-2-Verbindungen (L2) über IP/MPLS besteht. In dieser Art von Zugangsnetzwerk ist LDP das Signalisierungsprotokoll, das Labels zwischen L2-Leitungsnachbarn verteilt. Jede L2-Verbindung ist ein Punkt-zu-Punkt-Pseudowire-Tunnel zwischen dem Zugangsknoten (oder dem Edge-Gerät des Kunden) und einem BNG. Das Netzwerk kann eine heterogene Mischung aus L2- oder L3-Geräten umfassen.

Anmerkung: Bei Verwendung von Pseudowire-Redundanz für M:N-Teilnehmerredundanz ist die Anzahl der Teilnehmerredundanzgruppen auf die Anzahl der unterstützten Pseudowire-Teilnehmerschnittstellen auf dem Gerät beschränkt.

Abbildung 8 zeigt eine einfache Topologie, bei der Zugriffsknoten den Datenverkehr aggregieren und über das Netzwerk an einen DHCP-Relay-Agenten auf dem primären BNG senden. Die Pseudowire-Redundanzkonfiguration spezifiziert einen aktiven Pseudowire (zum primären BNG) und einen Backup-Pseudowire (zum Backup-BNG).

Bei L2-Verbindungen konfigurieren Sie die Pseudowires als zugrunde liegende (zugriffsorientierte) Schnittstellen auf den BNGs. Anschließend konfigurieren Sie die Schnittstellen mit L2-Verbindungen wie Ethernet, dynamischen VLANs mit automatischer Erkennung oder statischen VLANs. Die Pseudowire-Schnittstellen für DHCP-Clients werden gebündelt und zu einer L2-Verbindung (dem Pseudowire-Tunnel) hinzugefügt. In der Regel enthält das Paket eine Reihe dynamischer VLAN-Schnittstellen. Das Bundle kann jedoch eine beliebige Kombination aus einzelnen logischen VLAN-Schnittstellen, Listen von VLAN-Schnittstellen und physischen Schnittstellen enthalten.

Eine L2-Leitung verläuft zwischen zwei L2-Nachbarn; in diesem Fall zwischen einem Zugriffsknoten und einem BNG. Jeder Nachbar dient als Endpunktziel für einen MPLS Label-Switched Path (LSP). Sie erstellen die Verbindung, indem Sie sie auf einer Schnittstelle für jeden Nachbarn konfigurieren:

• Auf dem BNG geben Sie den Zugriffsknoten als Nachbarn und eine lokale Pseudowire-Schnittstelle auf dem BNG an, die den L2-Circuit beendet.

• Auf dem Zugriffsknoten geben Sie die BNG als Nachbarn und eine lokale Schnittstelle an, die den Clients auf dem Knoten am anderen Ende der L2-Verbindung zugewandt ist.

• Sowohl auf dem BNG- als auch auf dem Zugriffsknoten konfigurieren Sie einen eindeutigen Virtual Circuit Identifier (VCI), der diese L2-Verbindung von allen anderen L2-Verbindungen unterscheidet, die auf dem Gerät enden.

Diese L2-Verbindung ist jetzt der primäre Pseudodraht zum BNG. Um Redundanz herzustellen, konfigurieren Sie die Backup-Pseudowire auf dem Zugriffsknoten. Auf derselben lokalen Schnittstelle geben Sie eine andere BNG als Backup-Nachbar an und geben an, dass sich der Backup-Pseudowire im Hot-Standby-Modus befindet.

Der Hot-Standby-Modus stellt sicher, dass der Backup-Nachbar vollständig bereit ist, die Rolle des Primäranbieters zu übernehmen, wenn der aktuelle Primärkreis ausfällt. Ein LSP zum Backup-Nachbarn wird bereits von LDP eingerichtet.

Der Status der Pseudowire-Schnittstelle auf dem primären BNG ist UP. Der Status der Pseudowire-Schnittstelle ist Remote Standby (RS) auf der Backup-BNG. (Sie können den show l2circuit connections brief Befehl verwenden, um den Verbindungsstatus anzuzeigen.) Sie müssen Ihre Routing-Richtlinien so konfigurieren, dass Subnetzrouten für diese Redundanzgruppe nur auf der primären BNG angekündigt werden. Dadurch wird sichergestellt, dass nur der primäre Datenverkehr den Downstream-Datenverkehr empfängt.

LDP verfügt über einen Keepalive-Mechanismus zur Erkennung von Fehlern. Ein Fehler führt dazu, dass die L2-Verbindung ein Failover vom primären Pseudowire und primären BNG auf den Backup-Pseudowire und den Backup-BNG durchführt. Wenn ein Fehler erkannt wird, schaltet LDP die Verbindung vom primären LSP (auf der primären Pseudowire) auf den Backup-LSP (auf der Backup-Pseudowire) um. Die Backup-BNG übernimmt die primäre Rolle und ihr Status wechselt in "Up".

Wenn die alte Primärredundanz wieder verfügbar ist, gelten für Pseudowire-Redundanz die gleichen Überlegungen zur Synchronisierung wie bei VRRP als Redundanzmethode.

Beste Praxis:

Es wird empfohlen, die Pseudowire-Redundanz im nicht rückgängig auszuführenden Modus zu konfigurieren, wenn Sie mit hoher Skalierung arbeiten. Für Systeme, die nicht in großem Maßstab arbeiten, können Sie entweder den nicht rückgängig verwendeten Modus verwenden oder das revert-time Intervall auf der Schnittstelle des Zugriffsknotens mit Werten konfigurieren, die hoch genug sind, dass die Neusynchronisierung abgeschlossen ist, bevor der ursprüngliche primäre Server die primäre Rolle wieder übernimmt.

DHCP Active Leasequery, Topologieerkennung und M:N-Abonnentenredundanz

Für DHCP-Abonnenten ermöglichen DHCP Active LeaseQuery und Topologieermittlung die Synchronisierung von Anwenderstatus und Bindungsinformationen zwischen Peer-DHCP-Relay-Agents für alle Abonnentenredundanzgruppen auf den Peers. Auf diese Weise können Leasingverträge und Datenverkehr ohne Unterbrechung fortgesetzt werden, sowohl wenn die primäre BNG ein Failover auf das Backup durchführt als auch wenn sie die primäre Rolle wieder einnimmt.

Obwohl Sie die Primär-/Backup-Redundanz auf Schnittstellenebene für BNG-Paare konfigurieren, entspricht sie in gewisser Weise auch den DHCP-Relay-Agenten, die auf den primären und Backup-BNGs gehostet werden. Sie können sich den DHCP-Relay-Agent auf der primären BNG als primären Relay-Agent für eine Abonnentenredundanzgruppe vorstellen. Ebenso können Sie sich den DHCP-Relay-Agent auf der Backup-BNG für eine Gruppe als Backup-Relay-Agent für die Gruppe vorstellen.

Jeder Relay-Agent, den Sie mit der Topologieermittlung konfigurieren, tauscht Nachrichten mit seinen konfigurierten aktiven leasequery-Peers aus, um den Namen der Zugriffsschnittstellen auf seinen Relay-Agent-Peers zu ermitteln, die seinen eigenen lokalen Zugriffsschnittstellen entsprechen und eine Verbindung zu diesen herstellen. Bei den Zugriffsschnittstellen handelt es sich um die Schnittstellen, die von den Anwenderredundanzgruppen verwendet werden.

1. Wenn ein Relay-Agent eine Topologieerkennungsabfrage an einen Peer sendet, enthält diese Nachricht DHCP-Optionen, die den Namen der Zugriffsschnittstelle (Agent-Circuit-ID), das Subnetz/die Maske für die Schnittstelle und die VLAN-ID für die Redundanzgruppe angeben. DHCP generiert außerdem eine zufällige Transaktions-ID für den Austausch, die im Paket-Header übermittelt wird. Die Transaktions-ID ist für diese Zugriffsschnittstelle eindeutig.

2. Der empfangende Peer-Relay-Agent verwendet das Subnetz/die Maske und die VLAN-ID, um zu bestimmen, ob er über eine lokale Zugriffsschnittstelle für diese Werte verfügt. Wenn dies der Fall ist, sendet der Peer über diese Schnittstelle eine Topologieermittlungsantwort an die Zugriffsschnittstelle des abfragenden Relay-Agenten. Die Antwortnachricht enthält das Subnetz/die Maske, die VLAN-ID und die Transaktions-ID, die sie in der Abfrage erhalten hat.

3. Der abfragende Relay-Agent überprüft, ob die Transaktions-ID in der Antwort mit der Zugriffsschnittstelle übereinstimmt, bei der er die Antwort erhalten hat. Die Transaktions-ID in der Antwort muss mit der Transaktions-ID übereinstimmen, die sie an den Peer für diese Zugriffsschnittstelle gesendet hat. Wenn die Transaktions-ID übereinstimmt, kann der Relay-Agent einen Eintrag zu seiner Übersetzungstabelle hinzufügen, um die beiden verknüpften Schnittstellen zuzuordnen.

4. Der abfragende Agent wiederholt diesen Vorgang für jede seiner lokalen Zugriffsschnittstellen.

Abbildung 9 zeigt diese Abfrage und Antwort für zwei BNGs, wenn Sie VRRP-Redundanz verwenden. BNG 1 sendet die Abfrage für seine Zugriffsschnittstelle ge-10/1/2 über die TCP-Verbindung an BNG 2. BNG 2 antwortet über die UDP-Verbindung von der zugehörigen Schnittstelle, ge-2/3/9.

BNG 2 sendet über die TCP-Verbindung eine Abfrage für seine Zugriffsschnittstelle an BNG 1. BNG 1 antwortet über die UDP-Verbindung von der zugehörigen Schnittstelle ge-10/1/2.

Abbildung 10 zeigt eine Abfrage und Antwort für zwei DHCP-Relay-Agents auf BNGs, wenn Sie Pseudowire-Redundanz verwenden. R1 sendet die Abfrage für seine Zugriffsschnittstelle ps2.0 über die TCP-Verbindung an BNG 2. R2 antwortet über dieselbe TCP-Verbindung. R2 sendet auch eine Abfrage an R1 für seine Zugriffsschnittstelle ps5.0. R1 antwortet dann über die TCP-Verbindung auf diese Abfrage. Die Topologieerkennung für Pseudowire-Redundanz verwendet einen statisch konfigurierten, gemeinsam genutzten gemeinsamen Schlüssel für BNG-Paare als Abgleichskriterium. Dies steht im Gegensatz zur VRRP-Redundanz, bei der der Abgleich für Subnetz/Maske und VLAN-ID durchgeführt wird.

Jeder Peer-Agent sendet Abfragen an seine Peers, damit er seine eigene Übersetzungstabelle mit den entsprechenden lokalen und RAS-Schnittstellen erstellen kann. Auf diese Weise lernen alle Relay-Agents, die Sie sowohl als Peers als auch für die Topologieerkennung konfigurieren, den vollständigen Satz von RAS-Schnittstellen für ihre lokalen Schnittstellen kennen. Die Übersetzungstabellen ermöglichen es den Peers, die Teilnehmerinformationen für jede Abonnentenredundanzgruppe entsprechend zu synchronisieren.

Nachdem die Topologieermittlung abgeschlossen ist, führt active leasequery die Abonnentensynchronisierung durch. Active leasequery führt seine Abfragen per giaddr (DHCPv4) oder linkaddr (DHCPv6) aus. Dieser Abfragetyp stellt sicher, dass DHCP nur die Informationen für Teilnehmer in einer Redundanzgruppe für jede Schnittstelle synchronisiert.

Sie können diesen Abfragetyp nicht konfigurieren. Es handelt sich um eine Funktion der Konfiguration der Topologieerkennung. Wenn Sie die Topologieermittlung konfigurieren, wird das Vorhandensein von query-by-relay-id und giaddr in DHCPv4-Option 82 oder linkaddr in DHCPv6-Option 18 als Abfrage von giaddr bzw. als Abfrage von linkaddr interpretiert.

Der Relay-Agent verwendet die Zugriffsschnittstelle als Wert für sein Gateway-IP-Adressfeld (giaddr oder linkaddr), wenn er im Namen eines Clients Pakete an den lokalen Server sendet. Der lokale Server gibt giaddr/linkaddr zurück, wenn er auf den Relay-Agenten antwortet. Der Relay-Agent verwendet dann diesen Wert, um zu bestimmen, wohin die Informationen nachgelagert gesendet werden sollen. giaddr/linkaddr zeigt an, dass das Paket für eine bestimmte logische Zugriffsschnittstelle gesendet wurde, sodass der Relay-Agent die Informationen an den DHCP-Client auf dieser Schnittstelle weiterleitet.

Dies bedeutet für die Anwenderredundanz, dass bei Verwendung der giaddr- oder 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 query-by-relay-id-Methode verwenden würde, die Informationen für alle Abonnenten auf dem gesamten Chassis zurückgeben würde.

Das Ergebnis dieses Prozesses ist, dass jeder Peer-Agent die Abonnenten für jede Redundanzgruppe installiert, die er verarbeitet. Wenn für den primären BNG/Relay-Agent ein Failover ausgeführt wird, verfügt die Sicherung bereits über die erforderlichen Abonnenteninformationen, um die Sitzung ohne Unterbrechung aufrechtzuerhalten.

Beispiel für Topologieerkennung mit VRRP-Redundanz

Abbildung 11 zeigt eine einfache Topologie, bei der eine aktive leasequery mit Topologieerkennung für die DHCP-Relay-Agent-Peers auf zwei BNGs konfiguriert ist, die über das Zugriffsnetzwerk verbunden sind. Die konfigurierten Peeradressen sind 192.0.2.1 und 192.0.2.2. Wir verwenden diese Abbildung, um zu verstehen, wie die Topologieerkennung funktioniert, wenn Sie VRRP als Redundanzprotokoll konfigurieren, und wie die Übersetzungstabellen für jeden Peer-Relay-Agent erstellt werden.

1. Nach der TCP-Synchronisierung sendet Peer 192.0.2.1 eine Topologieermittlungsabfrage an Peer 192.0.2.2, um die passende Remoteschnittstelle für seine eigene lokale Schnittstelle (ge-10/1/2.0) zu ermitteln. Da es sich um eine DHCPv4-Topologie handelt, ist die gesendete Nachricht eine DHCPLEASEQUERY. Die Abfrage wird über die TCP-Verbindung gesendet und enthält die folgenden Informationen:

   • Die IP-Subnetzadresse und -Maske (203.0.113.1/24) der lokalen Zugriffsschnittstelle, übermittelt in DHCPv4 Option 43, Unteroption 2.

   • Die VLAN-ID (10), die auf der Zugriffsschnittstelle konfiguriert ist, wird in DHCPv4 Option 43, Unteroption 4 übermittelt.

   • Eine temporäre Transaktions-ID oder xid (15), die im Paket-Header übermittelt wird. DHCP generiert für jede Zugriffsschnittstelle eine zufällige xid. Die xid ist im gesamten Chassis einzigartig.

   Ebenfalls in der Abfrage enthalten, aber nicht in der Abbildung dargestellt:

   • Die Client-ID, die in DHCPv4 Option 61 übermittelt wird.

2. Peer 192.0.2.2 empfängt die Abfrage und gleicht die empfangene Subnetzadresse, Maske und VLAN-ID mit einer seiner lokalen Zugriffsschnittstellen ab. In diesem Fall ist die Übereinstimmung mit der Schnittstelle ge-2/3/9.0.

3. Peer 192.0.2.2 sendet eine Antwort an Peer 192.0.2.1 über die UDP-Verbindung von der entsprechenden Zugriffsschnittstelle ge-2/3/9.0 zurück. Die Antwort ist eine DHCPLEASEACTIVE-Nachricht und enthält die folgenden Informationen:

   • IP-Subnetzadresse und -Maske (203.0.113.2/24) der lokalen Zugriffsschnittstelle, übermittelt in DHCPv4 Option 43, Unteroption 2.

   • Die VLAN-ID (10), die auf der Zugriffsschnittstelle konfiguriert ist, wird in DHCPv4 Option 43, Unteroption 4 übermittelt.

   • Der Name der passenden Schnittstelle (ge-2/3/9.0), der in Option 82 übermittelt wird.

   • Die gleiche temporäre Transaktions-ID, die in der Abfrage empfangen wurde, wird im IP-Header übermittelt.

   Die folgenden Informationen sind ebenfalls in der Antwort enthalten, werden aber in der Abbildung nicht dargestellt:

   • Die Client-ID mit dem gleichen Wert wie in der Abfrage in DHCPv4-Option 61.

   • Die Server-ID in DHCPv4-Option 54.

   • Die IP-Zieladresse im IP-Header. Dies ist die Subnetzadresse, die von Peer 192.0.2.1 (203.0.113.1/24) empfangen wurde.

   • Die IP-Quelladresse im IP-Header. Dies ist die Subnetzadresse (203.0.113.2/24) für diesen Relay-Agenten für die passende Schnittstelle (ge-2/3/9.0).

4. Peer 192.0.2.1 empfängt die Antwort über seine Zugriffsschnittstelle. Es bestätigt, dass die Transaktions-ID der Antwort mit der in der Abfrage gesendeten übereinstimmt. Die Transaktions-ID und die anbieterspezifischen Unteroptionen, die in der Antwort empfangen werden, liefern dem Relay-Agenten die Informationen, die er benötigt, um die beiden Zugriffsschnittstellen in seiner Übersetzungstabelle abzubilden.

Peer 192.0.2.2 führt die gleichen vier Schritte aus, damit er seine eigene Übersetzungstabelle aktualisieren kann. Jeder der zugeordneten Peers initiiert die Topologieerkennung für alle seine lokalen Zugriffsschnittstellen. Auf diese Weise erstellt jeder Peer eine vollständige Übersetzungstabelle für alle seine Schnittstellen.

Abbildung 11 zeigt die Übersetzungstabelle für jeden Peer, die sich aus dem Austausch von Nachrichten zwischen den einzelnen Peer-Paaren ergibt:

• Der Relay-Agent auf BNG 1 initiiert die Topologieerkennung für seine drei Zugriffsschnittstellen.

• Der Relay-Agent auf BNG 2 initiiert die Topologieerkennung für seine drei Zugriffsschnittstellen.

• Der Relay-Agent auf BNG 3 initiiert die Topologieerkennung für seine beiden Zugriffsschnittstellen.

Anmerkung:

Da die Transaktions-ID nur für eine Zugriffsschnittstelle generiert wird, ist die Topologieerkennung auch dann erfolgreich, wenn sich mehrere Schnittstellen dasselbe Subnetz und dieselbe VLAN-ID teilen.

Angenommen, zwei Schnittstellen auf Peer 192.0.2.2 (ge-2/3/9 und ge-11/0/7) stimmen mit dem Subnetz und der VLAN-ID überein, die er in der Abfrage erhalten hat.

Dieser Relay-Agent sendet von jeder dieser Schnittstellen eine separate Antwort an die Schnittstellen ge-10/1/2.0 und ge-4/2/3.0 von Peer 192.0.2.1. Die Transaktions-ID stimmt nicht mit der Schnittstelle ge-4/2/3.0 überein, da der abfragende Peer (192.0.2.1) die ID für die Schnittstelle ge-10/1/2.0 generiert hat. Folglich aktualisiert der abfragende Peer seine Übersetzungstabelle nur für die Schnittstelle ge-10/1/2.0.

Ausführliche Informationen zur aktiven DHCP-Leasequery, zur Topologieerkennung und zur Funktionsweise mit M:N-Subscriberredundanz finden Sie unter DHCP Active Leasequery und Konfigurieren und Verwenden von DHCP Active Leasequery. Der Abschnitt Topologieermittlungsmeldungen in DHCP Active Leasequery enthält Beschreibungen der Informationen und Optionen, die in der DHCP-Abfrage und den Antwortnachrichten enthalten sind.

Beispiel für Topologieerkennung mit Pseudowire-Redundanz

Abbildung 12 zeigt eine einfache Topologie, bei der eine aktive leasequery mit Topologieerkennung für die DHCP-Relay-Agent-Peers auf zwei BNGs konfiguriert ist, die über ein IP/MPLS-Zugriffsnetzwerk verbunden sind. Die konfigurierten Peer-Adressen sind 198.51.100.1 und 198.51.100.5. Wir verwenden diese Illustration, um zu verstehen, wie die Topologieerkennung funktioniert, wenn das Zugriffsnetzwerk Pseudowire-Tunnel über das IP/MPLS-Netzwerk verwendet. Die Topologieerkennung für Pseudowire-Redundanz verwendet einen statisch konfigurierten, gemeinsam genutzten gemeinsamen Schlüssel für BNG-Paare als Abgleichskriterium. Dies steht im Gegensatz zur VRRP-Redundanz, bei der der Abgleich für Subnetz/Maske und VLAN-ID durchgeführt wird. In diesem Beispiel wird auch beschrieben, wie die Übersetzungstabellen für die einzelnen Peer-Relay-Agents erstellt werden.

Anmerkung:

Die Topologie zeigt nur eine TCP-Verbindung an, da die Pseudowire M:N-Redundanz UDP nicht für die Topologieerkennung verwendet. Im Gegensatz dazu verwendet die VRRP M:N-Redundanz sowohl TCP- als auch UDP-Verbindungen.

1. Nach der TCP-Synchronisierung sendet Peer 198.51.100.1 eine Topologieermittlungsabfrage an Peer 198.51.100.5, um die passende Remoteschnittstelle für seine eigene lokale Schnittstelle, ps2.0, zu ermitteln. Da es sich um eine DHCPv4-Topologie handelt, ist die gesendete Nachricht eine DHCPLEASEQUERY. Die Abfrage wird über die TCP-Verbindung gesendet und enthält die folgenden Informationen:

   • Der gemeinsam genutzte gemeinsame Schlüssel (PseudoWireKey-100.1), der auf der lokalen Schnittstelle konfiguriert ist und in DHCPv4 Option 43, Unteroption 6 übermittelt wird.

   • Eine temporäre Transaktions-ID oder xid (15), die im Paket-Header übermittelt wird. DHCP generiert für jede Zugriffsschnittstelle eine zufällige xid. Die xid ist im gesamten Chassis einzigartig.

   Ebenfalls in der Abfrage enthalten, aber nicht in der Abbildung dargestellt:

   • Die Client-ID, die in DHCPv4 Option 61 übermittelt wird.

2. Peer 198.51.100.5 empfängt die Abfrage und gleicht den empfangenen gemeinsamen Schlüssel mit einer seiner lokalen Zugriffsschnittstellen ab. In diesem Fall ist die Übereinstimmung mit der Schnittstelle ps5.0.

3. Peer 198.51.100.5 sendet eine Antwort über die TCP-Verbindung zurück an Peer 198.51.100.1. Die Antwort ist eine DHCPLEASEACTIVE-Nachricht und enthält die folgenden Informationen:

   • Der gemeinsame gemeinsame Schlüssel (PseudoWireKey-100.1), den er in der Abfrage empfangen hat, übermittelt in DHCPv4 Option 43, Unteroption 6.

   • Die gleiche temporäre Transaktions-ID, die in der Abfrage empfangen wurde, wird im IP-Header übermittelt.

   • Der Name der passenden Schnittstelle (ps5.0), der in Option 82 übermittelt wird.

   Die folgenden Informationen sind ebenfalls in der Antwort enthalten, werden aber in der Abbildung nicht dargestellt:

   • Die Client-ID mit dem gleichen Wert wie in der Abfrage in DHCPv4-Option 61.

   • Die Server-ID in DHCPv4-Option 54.

4. Peer 198.51.100.1 empfängt die Antwort über die In-Band-TCP-Verbindung. Es bestätigt, dass die Transaktions-ID der Antwort mit der in der Abfrage gesendeten übereinstimmt. Die Transaktions-ID und die anbieterspezifischen Unteroptionen, die in der Antwort empfangen werden, liefern dem Relay-Agenten die Informationen, die er benötigt, um die beiden Zugriffsschnittstellen (lokale Schnittstelle ps2.0 und Remote-Schnittstelle ps5.0) in seiner Übersetzungstabelle abzubilden.

Jeder der zugeordneten Peers in einer Topologie initiiert die Topologieermittlung für jede seiner lokalen Zugriffsschnittstellen. Jeder Peer verwendet die gleichen vier Schritte, die oben beschrieben wurden, um eine vollständige Übersetzungstabelle zu erstellen, die seine lokalen Schnittstellen Peerschnittstellen zuordnet. In dieser Beispieltopologie bedeutet dies:

• Der DHCP-Relay-Agent (R1) auf BNG 1 initiiert die Topologieerkennung für seine beiden Zugriffsschnittstellen ps2.0 und ps3.0.

• Der DHCP-Relay-Agent (R2) auf BNG 2 initiiert die Topologieerkennung für seine beiden Zugriffsschnittstellen ps4.0 und ps5.0.

In Abbildung 12 sehen Sie die Übersetzungstabelle für jeden Peer, die sich aus dem Austausch von Nachrichten zwischen dem Peer-Paar ergibt. Auf beiden Pseudowire-Schnittstellen wird für jedes Paar derselbe gemeinsame Schlüssel konfiguriert. Beispielsweise haben ps2.0 und ps5.0 den Schlüssel PseudoWireKey-100.1. Die Schnittstellen ps3.0 und ps4.0 teilen sich einen anderen Schlüssel (in der Abbildung nicht dargestellt).

Betrachten Sie nun die etwas komplexere Topologie mit drei Peers (siehe Abbildung 13). Drei DHCP-Relay-Agenten auf drei BNGs führen alle eine Topologieerkennung für ihre Pseudowire-Schnittstellen durch. Die resultierenden Übersetzungstabellen werden unter jedem Relaisagenten angezeigt.

Vergleichen Sie die Übersetzungstabellen und farbigen Pseudowire-Verbindungslinien in Abbildung 13 mit den Konfigurationsausschnitten für die einzelnen Relay-Agenten in Abbildung 14.

Sie können sehen, dass die Schnittstelle ps1.0 auf R1 den gleichen gemeinsamen Schlüssel hat wie die Schnittstelle ps8.0 auf R3. Die Übersetzungstabellen für R1 und R3 zeigen, dass diese Beziehung durch den Topologieermittlungsprozess ermittelt wurde.

In ähnlicher Weise haben die Schnittstellen ps2.0 auf R1 und ps5.0 auf R2 denselben gemeinsamen Schlüssel. Auch hier wurde diese Beziehung durch die Topologieerkennung bestimmt, und jeder Agent aktualisierte seine Übersetzungstabelle entsprechend. Die anderen Zeilen in den Übersetzungstabellen wurden auf die gleiche Weise aufgefüllt.

Ausführliche Informationen zur aktiven DHCP-Leasequery, zur Topologieerkennung und zur Funktionsweise mit M:N-Subscriberredundanz finden Sie unter DHCP Active Leasequery und Konfigurieren und Verwenden von DHCP Active Leasequery. Der Abschnitt Topologieermittlungsmeldungen in DHCP Active Leasequery enthält Beschreibungen der Informationen und Optionen, die in den Abfrage- und Antwortnachrichten von DHCPv4 und DHCPv6 enthalten sind.

Statische Abonnenten und M:N-Redundanz

M:N-Subscriber-Redundanz unterstützt zwei Kategorien von Abonnenten:

• Teilnehmer, die das DHCP-Clientprotokoll über ein statisches VLAN verwenden. Dies ist der gebräuchlichste Anwendertyp für M:N-Anwenderredundanz.

• Abonnenten auf statischen Schnittstellen, auf denen kein Clientprotokoll ausgeführt wird. Dieser Teilnehmertyp ist typisch für kleine bis mittlere Unternehmen, die über eine eigene statische IP-Adresse verfügen und keine DHCP-Lösung verwenden.

Statische Abonnenten bestehen aus den folgenden Typen:

• VLAN-basierte, statische Abonnenten: Abonnenten werden über der logischen VLAN-Schnittstelle erstellt. Sie konfigurieren die VRRP-Attribute auf der logischen VLAN-Schnittstelle.

• IP-Demux-basierte statische Abonnenten: Sie erstellen Abonnenten auf einer IP-Demux-Schnittstelle über eine zugrunde liegende Schnittstelle. Der Datenverkehr für diese Teilnehmer umfasst eine Quell-IP-Adresse, die mit dem konfigurierten Subnetz für die Teilnehmerschnittstelle übereinstimmt. Sie konfigurieren VRRP-Attribute auf der zugrunde liegenden logischen Schnittstelle.

Diese beiden statischen Abonnententypen werden vom jsscd-Daemon verwaltet. Sie werden manchmal auch als statische JSSCD-Abonnenten bezeichnet.

Die folgenden Beispielkonfigurationsausschnitte zeigen Ihnen, wie Sie eine statische Abonnentengruppe mit zwei Schnittstellen erstellen, die für VRRP auf einer primären BNG und einer Backup-BNG konfiguriert sind. Eine Schnittstelle ist eine IP-Demux-Schnittstelle und die andere ist eine VLAN-Schnittstelle. Die Konfiguration zeigt, wie VRRP auf jeder Schnittstelle konfiguriert ist.

Primäre BNG-Konfiguration:

1. Der folgende Codeausschnitt konfiguriert die zugrunde liegende Schnittstelle für die logische IP-Demux-Schnittstelle, ge-1/1/9.11. Die VLAN-ID wird als 11 angegeben. Das Subnetz der Zugriffsschnittstelle ist auf 203.0.113.1/24 festgelegt. Die VRRP-Konfiguration in diesem Subnetz legt die Gruppe (die Teilnehmerredundanzgruppe) auf 11 fest und gibt die Adresse für den virtuellen Router an. Der virtuelle Router besteht aus den primären und Backup-BNGs für diese Anwenderredundanzgruppe. Die VRRP-Priorität beträgt 230. Wenn für die primäre Datenbank ein Failover zur Sicherung ausgeführt wird, verzögert sich die Übernahme der primären Rolle durch die Sicherung um 30 Sekunden.

2. Der folgende Codeausschnitt konfiguriert die logische VLAN-Schnittstelle, ge-1/1/9.20. Die VLAN-ID wird als 20 angegeben. Das Subnetz für die Zugriffsschnittstelle ist auf 192.0.2.1/24 festgelegt. Die VRRP-Konfiguration in diesem Subnetz legt die Gruppe (die Teilnehmerredundanzgruppe) auf 20 fest und gibt die Adresse für den virtuellen Router an. Der virtuelle Router besteht aus den primären und Backup-BNGs für diese Anwenderredundanzgruppe. Die VRRP-Priorität beträgt 230. Wenn für die primäre Datenbank ein Failover zur Sicherung ausgeführt wird, verzögert sich die Übernahme der primären Rolle durch die Sicherung um 30 Sekunden.

3. Der folgende Codeausschnitt konfiguriert die logische IP-Demux-Schnittstelle, demux0.1, über die zugrunde liegende Schnittstelle, ge-1/1/9.11. Außerdem konfiguriert sie die Loopback-Schnittstelle und ermöglicht es, die lokale Adresse für die IP-Demux-Schnittstelle von der Loopback-Schnittstelle abzuleiten.

4. Im folgenden Codeausschnitt wird eine statische Anwendergruppe (static-ifl) konfiguriert, die sowohl die statische IP-Demux-Anwenderschnittstelle (demux0.1) als auch die statische VLAN-Anwenderschnittstelle (ge-1/1/9.20) umfasst. Es ordnet der Gruppe ein Zugriffsprofil zu, legt das Kennwort und ein Präfix für den Benutzernamen fest.

5. Mit dem folgenden Codeausschnitt wird ein Zugriffsprofil für die Gruppe der statischen Abonnenten konfiguriert.

Backup-BNG-Konfiguration:

Anmerkung:

In diesem Beispiel sind einige Konfigurationsdetails unterschiedlich und andere müssen identisch sein.

• Die Zugriffsschnittstellen sind unterschiedlich. Alternativ können Sie die Zugriffsschnittstellen so konfigurieren, dass sie auf der primären Schnittstelle und in der Sicherung identisch sind.

• Die VRRP-Priorität ist für beide Schnittstellen auf 200 festgelegt. Dieser Wert macht dies zum Backup-BNG, da er niedriger ist als die Priorität auf dem anderen BNG (230).

• Die Schnittstellenadressen sind unterschiedlich. Die virtuelle Adresse ist für beide gleich, und sie muss auch sein, damit sich beide BNGs im selben virtuellen Router befinden.

• Die Zugriffsschnittstellen befinden sich im selben Subnetz.

1. Der folgende Codeausschnitt konfiguriert die zugrunde liegende Schnittstelle für die logische IP-Demux-Schnittstelle, ge-3/0/1.11. Die VLAN-ID wird als 11 angegeben. Das Subnetz für die Zugriffsschnittstelle ist auf 203.0.113.2/24 festgelegt. Die VRRP-Konfiguration in diesem Subnetz legt die Gruppe (die Teilnehmerredundanzgruppe) auf 11 fest und gibt die Adresse für den virtuellen Router an. Der virtuelle Router besteht aus den primären und Backup-BNGs für diese Anwenderredundanzgruppe. Die VRRP-Priorität beträgt 200. Wenn für die primäre Datenbank ein Failover zur Sicherung ausgeführt wird, verzögert sich die Übernahme der primären Rolle durch die Sicherung um 30 Sekunden.

2. Der folgende Codeausschnitt konfiguriert die logische VLAN-Schnittstelle, ge-3/0/1.20. Die VLAN-ID wird als 20 angegeben. Das Subnetz für die Zugriffsschnittstelle ist auf 192.0.2.2/24 festgelegt. Die VRRP-Konfiguration in diesem Subnetz legt die Gruppe (die Teilnehmerredundanzgruppe) auf 20 fest und gibt die Adresse für den virtuellen Router an. Der virtuelle Router besteht aus den primären und Backup-BNGs für diese Anwenderredundanzgruppe. Die VRRP-Priorität beträgt 200. Wenn für die primäre Datenbank ein Failover zur Sicherung ausgeführt wird, verzögert sich die Übernahme der primären Rolle durch die Sicherung um 30 Sekunden.

3. Der folgende Codeausschnitt konfiguriert die logische IP-Demux-Schnittstelle, demux0.1, über die zugrunde liegende Schnittstelle, ge-3/0/1.11. Außerdem konfiguriert sie die Loopback-Schnittstelle und ermöglicht es, die lokale Adresse für die IP-Demux-Schnittstelle von der Loopback-Schnittstelle abzuleiten.

4. Der folgende Codeausschnitt konfiguriert eine statische Anwendergruppe, static-ifl, die sowohl die statische IP-Demux-Anwenderschnittstelle (demux0.1) als auch die statische VLAN-Anwenderschnittstelle (ge-3/0/1.20) umfasst. Es ordnet der Gruppe ein Zugriffsprofil zu, legt das Kennwort und ein Präfix für den Benutzernamen fest.

5. Mit dem folgenden Codeausschnitt wird ein Zugriffsprofil für die Gruppe der statischen Abonnenten konfiguriert.

Konvergenz und M:N-Subscriber-Redundanz

Konvergenz ist der Prozess, bei dem Router in einem Netzwerk ihre individuellen Routing-Tabellen aktualisieren, wenn Routen auf einem Router hinzugefügt oder entfernt werden oder aufgrund eines Verbindungsfehlers nicht mehr erreichbar sind. Die Routing-Protokolle auf den Routern kündigen die Routenänderungen im gesamten Netzwerk an. Wenn jeder Router die Updates erhält, berechnet er die Routen neu und erstellt dann basierend auf den Ergebnissen neue Routing-Tabellen.

Ein Netzwerk ist konvergiert , wenn sich alle Routing-Tabellen auf die gesamte Netzwerktopologie einigen. Dies bedeutet beispielsweise, dass die Router ein gemeinsames Verständnis darüber haben, welche Verbindungen verfügbar oder inaktiv sind und so weiter. Wie lange es dauert, bis die Router einen Konvergenzzustand erreichen, wird als Konvergenzzeit bezeichnet. Die Länge der Konvergenzzeit hängt von verschiedenen Faktoren ab, z. B. von der Größe und Komplexität des Netzwerks und der Leistung der Routing-Protokolle.

M:N-Anwenderredundanz unterstützt sowohl zugriffsseitige (Upstream) als auch Core-seitige (Downstream) Routenkonvergenz. Da jeder Abonnent gleichzeitig auf der primären und der Backup-BNGs aktiv ist, kann die Datenverkehrskonvergenz sehr schnell erfolgen. Bei der Routenkonvergenz handelt es sich jedoch um Best-Effort-Maßnahmen, die vom Grad des Failovers abhängen. Das heißt, ob ein teilweiser oder vollständiger Gehäuseausfall auftritt.

Es liegt an Ihnen, zu bestimmen, wie Sie die Konvergenz des Upstream- und Downstream-Datenverkehrs für Ihr Netzwerk nach einem Failover von Primär- zu Backup-BNG verwalten.

• Upstream-Traffic-Konvergenz (VRRP-Redundanz)
• Upstream-Datenverkehrskonvergenz (Pseudowire-Redundanz)
• Konvergenz des Downstream-Datenverkehrs

Zweck

Ermitteln Sie Statusinformationen und Statistiken für Zugriffsschnittstellen, Relay-Agents und Teilnehmer, die Teil Ihrer Topologie für M:N-Redundanz sind, mit DHCP Active LeaseQuery Topology Discovery.

Aktion

• So überprüfen Sie den VRRP-Redundanzstatus von Zugriffsschnittstellen:

• Gehen Sie wie folgt vor, um zu überprüfen, ob sich der Redundanzstatus einer angegebenen logischen Zugriffsschnittstelle auf dem primären Relay-Agent und Backup auf dem Backup-Relay-Agent befindetMaster:

  Bei dieser Schnittstelle kann es sich entweder um eine Teilnehmerschnittstelle oder um die zugrunde liegende VLAN-Schnittstelle handeln. Bei der VRRP-Redundanz ist der Redundanzzustand identisch mit dem VRRP-Zustand der zugrunde liegenden logischen Schnittstelle. Bei der Pseudowire-Redundanz basiert der Redundanzstatus auf dem Zustand der Pseudowire-Schnittstelle.

• So stellen Sie sicher, dass Abonnenten in einer Redundanzgruppe sowohl auf dem primären als auch auf dem Backup-Relay-Agent aktiv sind:

  Der show subscribers Befehl verfügt über eine Reihe von Optionen: Sie können Teilnehmer nach IP-Adresse, Schnittstellenname, VLAN-ID, Agenten-Circuit-ID, Teilnehmerstatus usw. anzeigen.

• Gehen Sie wie folgt vor, um zu überprüfen, ob die DHCP-Relay-Bindungsinformationen für die Teilnehmer in einer Redundanzgruppe sowohl auf dem primären als auch auf dem Backup-Relay-Agent identisch sind:

  Sie können auch Ergebnisse für eine IP-Adresse oder eine Schnittstelle angeben.

• So zeigen Sie eine Liste aller aktiven leasequery-Peers an:

• So zeigen Sie die Übersetzungstabelle für die Topologieerkennung für einen Peer-Relay-Agent an, einschließlich der lokalen und Remote-Circuit-IDs (Zugriffsschnittstellen), der Adresse der lokalen Zugriffsschnittstelle, der Transaktions-ID (xid) und des Status der Topologieerkennung, Redundanz und Teilnehmersynchronisierung:

• Zum Anzeigen aktiver leasequery-Statistiken, z. B. der Anzahl der für eine Schnittstelle oder einen Peer gesendeten oder empfangenen DHCP-Bindungen.

• So löschen Sie aktive leasequery-Statistiken.