Layer 2-Großhandel mit ANCP-getriggerten VLANs Übersicht

RADIUS-Autorisierung für ANCP-getriggerte VLANs

Wenn sich ein Anwender anmeldet, enthält die Access-Request-Nachricht, die an den RADIUS-Server gesendet wird, einen Benutzernamen und optional ein Kennwort, die lokal auf dem Router generiert werden. Sie können den Router so konfigurieren, dass er einen eindeutigen Benutzernamen mit dem Wert von ANCP TLVs – Access-Loop-Circuit-ID, Access-Loop-Remote-ID oder beides – erstellt, wie er in der ANCP-Port-Up-Nachricht vom Zugriffsknoten empfangen wird. Wenn Sie den Router alternativ so konfigurieren, dass er ANCP-bezogene Zugriffsschleifenattribute als Juniper Networks VSAs übermittelt – in diesem Fall Acc-Loop-Cir-Id (26-110) und Acc-Loop-Remote-Id (26-182) –, enthält die Access-Request-Nachricht genügend eindeutige Informationen über die Zugriffsleitung für den RADIUS-Server, um zu bestimmen, ob die Zugriffsschleife für einen Einzelhändler im Großhandel oder für den Großhändler aufbewahrt wird.

Der RADIUS-Server antwortet auf den Access-Request mit einer der folgenden Meldungen:

• Access-Accept: In diesem Fall wird das durch die Port-Up-Nachricht ausgelöste VLAN auf einen Einzelhandels-NSP übertragen. Die Autorisierung ist ähnlich wie bei PPPoE-Sitzungen. Access-Accept enthält den virtuellen Router VSA (26-1) mit einem Wert, der der eindeutigen, nicht standardmäßigen Routing-Instanz des NSP entspricht. Die Nachricht kann optional Client-Services enthalten, wie z. B. Attribute für parametrisiertes CoS, Firewall-Filter und Richtlinien für die logische Schnittstelle sowie Layer-2-Serviceaktivierungen.

• Access-Reject: In diesem Fall ist entweder das VLAN, das durch die Port-Up-Meldung ausgelöst wird, einer der eigenen Teilnehmer des Großhändlers oder RADIUS verweigert den Zugriff auf das Netzwerk. In beiden Fällen wird der VLAN-Eintrag aus der ANCP-SDB entfernt. Wenn nicht zuerst eine Port-Up-Nachricht empfangen wird, ignoriert der Router nachfolgende Port-Up-Nachrichten für diesen Anwender. Herkömmliches dynamisches Stacked VLAN-Autosensing kann jedoch durch Zugriffsprotokollaushandlung wie PPPoE initiiert werden.

Instanziierung eines ANCP-getriggerten, automatischen und dynamischen VLANs

Wenn der RADIUS-Server eine Access-Accept-Nachricht zurückgibt, wird das dynamische Profil, das dem automatisch erkannten VLAN-Bereich zugewiesen ist, mit den folgenden Ergebnissen instanziiert:

1. Die dynamische logische VLAN-Schnittstelle, die den Layer-2-Großhandels-Service innerhalb der eindeutigen Routing-Instanz des NSP darstellt, wird erstellt.

2. Eine dem Core zugewandte physische Schnittstelle wird durch eine gewichtete Lastverteilungsmethode aus dem Satz geeigneter Schnittstellen ausgewählt, die der Routing-Instanz des NSP zugewiesen sind. Eine physische Schnittstelle ist teilnahmeberechtigt, wenn sie betriebsbereit ist und über mindestens ein VLAN-Tag verfügt, das zur Zuweisung zur Verfügung steht.

3. Das zugriffsorientierte, automatische äußere VLAN-Tag wird einem eindeutigen inneren VLAN-Tag zugeordnet. Das äußere VLAN-Tag wird vom Access-Aggregation-Circuit-ID-Binary TLV abgeleitet, das in der ANCP-Port-Up-Nachricht enthalten ist. Das innere VLAN-Tag wird aus dem VLAN-Bereich zugewiesen, der für die Core-seitige physische Schnittstelle konfiguriert ist.

4. Das innere VLAN-Tag wird mit dem äußeren VLAN-Tag ausgetauscht (ersetzt), wenn der Datenverkehr des Anwenders zum NSP getunnelt wird. Im dynamischen Profil wird das innere VLAN-Tag durch die vordefinierte Variable bereitgestellt. $junos-inner-vlan-map-id

5. Das automatisch erkannte äußere VLAN-Tag wird mit dem inneren VLAN-Tag getauscht, wenn Downstream-Pakete vom NSP (einschließlich des zugewiesenen inneren VLAN-Tags) an den Anwender weitergeleitet werden.

   Sie können jede Core-seitige physische Schnittstelle mit einem Bereich von bis zu 4094 VLAN-IDs konfigurieren. Der innere VLAN-Auslagerungsbereich wird der physischen Schnittstelle lokal zugewiesen. Das bedeutet, dass sich die inneren VLAN-Bereiche für verschiedene physische Schnittstellen vollständig, teilweise oder gar nicht überlappen können.

6. Bevor die Anwender-Pakete an einen NSP weitergeleitet werden, kann optional der äußere VLAN-Tag-Protokoll-Identifier (TPID) in den Anwender-Paketen mit einer TPID ausgetauscht werden, um die Anforderungen eines einzelnen NSP zu erfüllen. In diesem Fall wird der ursprüngliche Wert mit der NSP-TPID für Pakete vertauscht, die an den Anwender weitergeleitet werden.

7. Ein zusätzliches VLAN-Tag, die Trunk-VLAN-ID, wird intern verwendet, um die bereitgestellte Core-seitige physische Schnittstelle zu identifizieren, damit der Datenverkehr des Anwenders zur zugewiesenen Schnittstelle getunnelt werden kann. Im dynamischen Profil wird diese ID durch die vordefinierte Variable bereitgestellt. $junos-vlan-map-id Diese Kennung unterscheidet zwischen mehreren physischen Core-orientierten Trunk-Schnittstellen für denselben NSP.

8. Alle Clientservices, wie z. B. CoS oder Firewallfilter, werden auf die Anwendersitzung angewendet. Diese Services werden optional in der RADIUS-Konfiguration angegeben und in der RADIUS-Nachricht als Juniper Networks VSAs übermittelt.

9. Die VLAN-Sitzung wird aktiviert, nachdem die logische Schnittstelle erstellt und für die dynamische VLAN-Sitzung konfiguriert wurde. Die Sitzungsaktivierung initiiert eine RADIUS Accounting-Start-Nachricht. Alle Services, die während der Autorisierung von RADIUS empfangen wurden, sind jetzt aktiviert.

10. Nachdem das dynamische VLAN erstellt wurde, führen nachfolgende ANCP-Port-Up-Meldungen nicht zu einer erneuten Autorisierung der dynamischen VLAN-Sitzung. Wenn der ANCP-Agent stattdessen eine weitere Port-Up-Nachricht für die Zugriffsschleife empfängt, aktualisiert er die ANCP-SDB mit allen Änderungen der ANCP-Attribute.

Gewichtetes Load Balancing für Anwendersitzungen über berechtigte physische Schnittstellen mit Core-Ausrichtung

Der Router verwendet eine gewichtete Lastverteilung anstelle einer Rundlaufverteilung, um Layer-2-Großhandels-Anwender-Sitzungen entsprechend dem Gewicht der Schnittstelle auf mehrere Core-seitige physische Schnittstellen zuzuweisen. Das Gewicht einer Schnittstelle korreliert mit der Anzahl der VLAN-Tags, die in den aggregierten inneren (Core-seitigen) VLAN-ID-Auslagerungsbereichen auf der Schnittstelle verfügbar sind.

Die Konfiguration der inneren VLAN-ID-Auslagerungsbereiche bestimmt die relative Gewichtung der Schnittstellen:

• Die Schnittstelle mit der höchsten Anzahl verfügbarer innerer VLAN-ID-Tags hat das höchste Gewicht.

• Die Schnittstelle mit der nächsthöheren Anzahl von Tags hat die nächsthöhere Gewichtung usw.

• Die Schnittstelle mit der geringsten Anzahl verfügbarer Tags hat das niedrigste Gewicht.

Die Verwendung der verfügbaren inneren VLAN-ID-Tags aus den Swap-Bereichen anstelle der aggregierten VLAN-Tags insgesamt bedeutet, dass die relativen Gewichtungen der Schnittstellen dynamischer sind. Der gewichtete Lastverteilungsmechanismus kann schneller auf die Abmeldung von Anwendern, die Migration des Eigentums der Anwender vom Großhändler zum Einzelhändler und vom Einzelhändler zum Großhändler, auf den Core ausgerichtete physische Schnittstellenzustandsübergänge (einschließlich der Bewegung zu den verbleibenden berechtigten Core-Schnittstellen, wenn ein Schnittstellenstatus von "Up" zu "Down" übergeht) und Ausfälle einer der Core-orientierten physischen Schnittstellen reagieren. Wenn sich eine Schnittstelle erholt (Übergang von "Down" zu "Up"), begünstigt die gewichtete Lastverteilung diese Schnittstelle im Allgemeinen entweder für ausstehende Sitzungen oder für neue Layer-2-Großhandels-Sitzungen, die später auftreten.

Bei der gewichteten Lastverteilung wählt der Router Schnittstellen nach dem Zufallsprinzip aus, die Sitzungen werden jedoch proportional zum Gewicht der Schnittstellen auf die Schnittstellen verteilt. Der Router generiert eine Zufallszahl innerhalb eines Bereichs, der der Summe aller verfügbaren inneren VLAN-ID-Tags aus den Swap-Bereichen aller Core-orientierten physischen Schnittstellen entspricht. Der Router ordnet dann einen Teil des Bereichs – einen Pool von Zahlen – jeder Schnittstelle proportional zum Gewicht der Schnittstelle zu. Eine Schnittstelle mit einem höheren Gewicht ist mit einem größeren Teil des Bereichs – einem größeren Pool – verbunden als eine Schnittstelle mit einem niedrigeren Gewicht. Eine Schnittstelle wird ausgewählt, wenn sich die Zufallszahl im zugehörigen Zahlenpool befindet. Die Zufallszahl befindet sich im Durchschnitt eher in einem größeren Pool, sodass eine Schnittstelle mit einem höheren Gewicht (größerer Pool) eher ausgewählt wird als eine Schnittstelle mit einem niedrigeren Gewicht (kleinerer Pool).

Betrachten wir zum Beispiel zwei Core-seitige physische Schnittstellen, IFD1 und IFD2. Basierend auf den für diese beiden Schnittstellen konfigurierten internen VLAN-ID-Swap-Bereichen verfügt IFD1 über 1000 verfügbare VLAN-Tags und IFD2 über nur 500 verfügbare Tags. Die Sitzungen der Anwender werden basierend auf ihren relativen Gewichtungen nach dem Zufallsprinzip auf die beiden Schnittstellen verteilt. IFD1 hat ein höheres Gewicht als IFD2. Da IFD1 doppelt so viele Tags zur Verfügung hat wie IFD2, ist der Pool von Zahlen, der IFD1 zugeordnet ist, auch doppelt so groß wie für IFD2. Die vom Router generierte Zufallszahl ist für IFD1 doppelt so wahrscheinlich im Pool enthalten wie für IFD2. Folglich wird IFD1 2:1 gegenüber IFD2 bevorzugt, und Sitzungen der Anwender werden IFD1 doppelt so häufig zugewiesen wie IFD2.

RADIUS Interim Accounting Updates

Zwischenbilanzierungsberichte, die für Out-of-Band-ausgelöste, dynamische Autosensed-VLANs an die AAA gesendet werden, werden auf die gleiche Weise unterstützt wie für herkömmliche Autosensed-, dynamische, autorisierte VLANs oder Client-Sitzungen (z. B. PPPoE-Sitzungen). Der ANCP-Agent sendet eine Benachrichtigung an AAA, wenn er eine Aktualisierung vom Zugriffsknoten erhält. Standardmäßig meldet AAA die Aktualisierung nur im konfigurierten Intervall an den RADIUS-Server.

Sie können den ANCP-Agent so konfigurieren, dass bei einer Benachrichtigung von AAA sofort eine vorläufige Accounting-Request-Nachricht an den RADIUS-Server gesendet wird. Sofortige vorläufige Accounting-Updates können nur dann für eine ANCP-getriggerte dynamische VLAN-Sitzung gesendet werden, wenn eine Änderung in bestimmten wichtigen ANCP-Attributen für die zugehörige Zugriffsleitung auftritt, die das Systemverhalten beeinflussen kann. Um eine zusätzliche Belastung des RADIUS-Servers durch Änderungen an weniger kritischen ANCP-Attributen zu vermeiden, lösen Änderungen an anderen ANCP-Attributen keine sofortigen Accounting-Interim-Update-Nachrichten aus. Stattdessen werden diese Änderungen in der nächsten geplanten Accounting-Interim-Update-Nachricht gemeldet.

Sofortige vorläufige Accounting-Updates können für Änderungen an einem der folgenden ANCP-Attribute für eine bestehende Sitzung gesendet werden, die der Zugriffsleitung entspricht (basierend auf der Access-Loop-Circuit-ID TLV):

• Actual-Net-Data-Rate-Upstream: Wenn die berechnete (bereinigte) Upstream-Rate zu einer Änderung dieses Attributs führt, wird das Attribut in der Juniper Networks Act-Data-Rate-Up VSA (26-113) gemeldet. Die berechnete Geschwindigkeitsänderung wird in der Upstream-Calculated-QoS-Rate VSA (26-142) angegeben.

• Ist-Netto-Datenrate-Downstream: Wenn die berechnete (bereinigte) Downstream-Rate zu einer Änderung dieses Attributs führt, meldet die Buchhaltungsmeldung das Attribut in der Juniper Networks Act-Data-Rate-Dn VSA (26-114). Die berechnete Geschwindigkeitsänderung wird in der Downstream-Calculated-QoS-Rate VSA (26-141) angegeben.

Wenn der ancp-speed-change-immediate-update Auszug auf Hierarchieebene [edit access profile profile-name accounting] konfiguriert ist, werden sofortige RADIUS-Zwischenbuchhaltungsaktualisierungen für Änderungen an den TLVs "Actual-net-data-rate-Upstream" und "Actual-net-data-rate-downstream" gesendet.

Wenn die auto-configure-trigger interface interface-name Anweisung zusätzlich auf Hierarchieebene [edit protocols ancp neighbor ip-address] konfiguriert ist, werden auch sofortige vorläufige Buchhaltungsaktualisierungen für Änderungen an den TLVs Access-Loop-Remote-ID und Access-Aggregation-Circuit-ID-Binary gesendet.

Weitere Informationen zu sofortigen zwischenzeitlichen Accounting-Updates von RADIUS finden Sie unter Konfigurieren sofortiger vorläufiger Accounting-Updates für RADIUS als Reaktion auf ANCP-Benachrichtigungen.

Entfernung des Layer 2-Großhandelsservice

Jedes der folgenden Ereignisse kann die logische Schnittstelle für das dynamische VLAN entfernen, das den vom Layer-2-Großhändler bereitgestellten Zugriffsservice darstellt:

• Der Empfang einer ANCP-Port-Down-Nachricht für die entsprechende Zugriffsschleife. Dieselben ANCP-Attribute, die die dynamische VLAN-Erstellung initiieren, initiieren auch die dynamische VLAN-Zerstörung.

  Für eine ANCP-Port-Down-Nachricht, für die eine der folgenden Bedingungen zutrifft, wird keine Aktion ausgeführt:

  • Es existiert keine entsprechende Anwendersitzung.

  • Eine entsprechende Anwender-Sitzung ist vorhanden, wird aber gerade gelöscht.

  • Die Nachricht bezieht sich auf eine herkömmliche Autosensed-Sitzung (die von der normalen Protokollverarbeitung entfernt wird).

• Ein explizites Zurücksetzen der Verbindung zwischen dem ANCP-Agenten und dem Zugriffsknoten, wodurch eine Massenabmeldung aller betroffenen dynamischen VLAN-Sitzungen ausgelöst wird, die die großhandelsüblichen Layer-2-Zugriffsverbindungen unterstützen. Sitzungen für die eigenen Abonnenten des Großhändlers sind nicht betroffen.

• Das Löschen oder der Übergang der dem Anwender zugewandten physischen Schnittstelle oder der Core-seitigen physischen Schnittstelle in einen betriebsbedingten Betriebszustand.

• Der Verlust der Nachbarschaft zwischen dem Nachbarn und dem ANCP-Agenten.

• Die Ausgabe des clear auto-configuration interfaces Befehls zum Abmelden des VLAN oder des clear ancp access-loop Befehls zum Erzwingen eines Anwender-Resets.

• Der Empfang einer von RADIUS initiierten Trennungsmeldung.

Jedes dieser Ereignisse deaktiviert auch die Anwender-Sitzung, um zukünftige Serviceaktivierungen zu verhindern, und gibt eine RADIUS-Accounting-Stop-Meldung für zugehörige Services und für die dynamische VLAN-Anwender-Sitzung aus. Das dynamische Profil wird dann deinstanziiert, um zuerst die dynamische logische VLAN-Schnittstelle und dann den entsprechenden Sitzungseintrag in der VLAN-SDB zu entfernen.

Sie können die Anzahl der mit Cross-2 verbundenen Layer-2-Anwender-Sitzungen pro Port überwachen. Verwenden Sie den show subscribers summary port extensive Befehl, um die Anzahl der Teilnehmer pro Port nach Client-Typ (VLAN-OOB) und Verbindungstyp (Corss-connected) anzuzeigen. Darüber hinaus zeigt die Objekt-ID jnxSubscriberPortL2CrossConnectCounter in der jnxSubscriberPortCountTable in der unternehmensspezifischen Subscriber MIB von Juniper Networks die Anzahl der miteinander verbundenen Layer-2-Anwender-Sitzungen auf Ports mit aktiven Sitzungen an.

Interaktionen zwischen In-Band- und Out-of-Band-VLAN-Autosensing

Die ANCP-ausgelöste Layer-2-Implementierung für den Großhandel eignet sich sowohl für Abonnenten, die bei einem Einzelhändler als auch für Abonnenten des Großhändlers angemeldet sind. Jede Anwender Sitzung, die auf der zugriffsorientierten physischen Schnittstelle erkannt wird, kann entweder das eine oder das andere sein. Das bedeutet, dass eine Überlappung zwischen dem äußeren Tag-Bereich für die Out-of-Band-Autosensed-VLANs und dem für In-Band-, Autosensed- und Stacked-VLANs besteht.

Sowohl eine PPPoE-Sitzung als auch eine Großhandelssitzung können für dieselbe Zugriffsschleife versucht werden. Um eine unerwünschte Belastung des Routers und des RADIUS-Servers zu vermeiden, wird die Reihenfolge der Sitzungsaushandlung durch die Reihenfolge bestimmt, in der Pakete (PPPoE-, PADI- oder ANCP-Port-Up-Nachricht) für dieselbe physische Schnittstelle und dasselbe äußere VLAN-Tag empfangen werden.

Die folgende Abfolge von Ereignissen tritt ein, wenn ein PPPoE-PADI-Paket auf einem In-Band-Steuerkanal empfangen wird, bevor eine ANCP-Port-Up-Nachricht auf einem Out-of-Band-Steuerkanal für dieselbe Zugriffsschleife empfangen wird:

1. Die PADI-Quittung löst die Erstellung einer dynamischen logischen VLAN-Schnittstelle aus. PPPoE- und PPP-Verhandlungen sind im Gange.

2. Die ANCP-Port-Up-Nachricht wird für die Zugriffsschleife empfangen. Da die entsprechende logische In-Band-VLAN-Schnittstelle bereits für dieselbe physische Schnittstelle und dasselbe äußere VLAN-Tag vorhanden ist, speichert der ANCP-Agent einfach die ANCP-Zugriffsleitungsattribute und den Namen der physischen Schnittstelle in der Sitzungsdatenbank. Der Agent führt keine weiteren Aktionen für die Nachricht durch, solange die PPP-Sitzung (logische PPP-Schnittstelle und die zugrunde liegende logische VLAN-Schnittstelle) aufrechterhalten wird.

3. Die PPP-Aushandlung wird aufgrund eines Authentifizierungsfehlers (RADIUS Access-Reject-Antwort) oder einer normalen Abmeldung beendet, wodurch die Bereinigung der PPP-Sitzung und das Entfernen der logischen PPP-Schnittstelle ausgelöst werden.

4. Weil die remove-when-no-subscribers Anweisung konfiguriert ist. Das Löschen der logischen PPP-Schnittstelle führt zur Löschung des dynamischen gestapelten VLANs.

5. Das nächste Ereignis hängt davon ab, ob zuvor versucht wurde, die ANCP-Port-Up-Nachricht zu autorisieren.

   • Wenn zuvor noch nicht versucht wurde, die Autorisierung durchzuführen:

     1. Eine VLAN-OOB-SDB-Sitzung wird erstellt und die Autorisierung der Zugriffsschleife wird initiiert.

     2. Alle ausgenommenen PPPoE-PADI-Pakete, die von der automatischen In-Band-VLAN-Erkennung empfangen werden, werden ignoriert, bis RADIUS auf die Autorisierungsanforderung antwortet.

     3. Das Autorisierungsergebnis bestimmt, was als nächstes passiert:

        • Wenn die Autorisierung erfolgreich ist (RADIUS gibt eine Access-Accept-Nachricht zurück), wird eine dynamische logische Layer-2-Schnittstelle für den Großhandel innerhalb der Routing-Instanz des Einzelhändler-NSP erstellt.

        • Wenn die Autorisierung fehlschlägt (RADIUS gibt eine Access-Reject-Nachricht zurück), wird die VLAN-OOB-Sitzung bereinigt. Die Verarbeitung wird für alle ausgenommenen PPPoE PADI-Pakete fortgesetzt, die anschließend von der In-Band-VLAN-Autosensing empfangen werden.

   • Wenn zuvor eine Autorisierung versucht wurde, wird keine Aktion ausgeführt, da davon ausgegangen wird, dass es sich bei dem Fehler bei der PPP-Sitzungsaushandlung um einen Anmeldefehler außerhalb des Layer2-Großhandels-Kontexts handelt. Dieses Verhalten verhindert eine unnötige Autorisierung als Reaktion auf die ANCP-Port-Up-Meldung jedes Mal, wenn eine PPPoE-Sitzung beendet und von einer normalen Abmeldung des Anwenders bereinigt wird.

Die folgende Abfolge von Ereignissen tritt auf, wenn eine ANCP-Port-Up-Nachricht auf einem Out-of-Band-Steuerkanal empfangen wird, bevor ein PPPoE-PADI-Paket für eine Zugriffsschleife auf einem In-Band-Steuerkanal empfangen wird, beide für dieselbe Zugriffsschleife:

1. Der Empfang der ANCP-Port-Up-Nachricht löst die Autorisierung der Zugriffsschleife aus.

2. Ein PPPoE PADI-Paket wird empfangen. Das Paket wird ignoriert, da die Autorisierung für dieselbe physische Schnittstelle und dasselbe äußere VLAN-Tag bereits im Gange ist.

3. Das Autorisierungsergebnis bestimmt, was als nächstes passiert:

   • Wenn die Autorisierung erfolgreich ist (RADIUS gibt eine Access-Accept-Nachricht zurück) (dargestellt durch eine VLAN-OOB-Sitzung in der SDB) wird die dynamische Erstellung der logischen VLAN-Schnittstelle für eine Layer-2-Großhandelssitzung initiiert. Wenn die Schnittstelle erstellt wird, werden nachfolgende PPPoE-PADI-Pakete, die von der In-Band-VLAN-Autosensing erkannt werden, ignoriert und nicht mehr ausgenommen.

   • Wenn die Autorisierung fehlschlägt (RADIUS gibt eine Access-Reject-Nachricht zurück), wird die VLAN-OOB-Sitzung bereinigt.

     1. Der Empfang eines nachfolgenden PPPoE-PADI-Pakets initiiert die Erstellung eines dynamischen gestapelten VLANs.

     2. Die PPPoE- und PPP-Aushandlung findet statt und die Ereignisse werden wie gewohnt für ein herkömmliches, dynamisches Autosensed-VLAN ablaufen.

Migration des Anwendereigentums vom Großhändler zum Einzelhändler

Die Abonnenten im Besitz des Großhändlers sind über dynamische PPPoE-Schnittstellen über dynamische VLANs verbunden. Für jeden Anwender muss die PPPoE-Sitzung getrennt und die entsprechende logische PPP-Schnittstelle gelöscht werden, bevor ANCP-Port-Up-Meldungen für dieselbe zugrunde liegende physische Schnittstelle und dasselbe äußere VLAN-Tag als Out-of-Band-Auslöser für dynamisches VLAN-Autosensing dienen können.

Ein Ansatz für die Migration vom Großhandel zum Einzelhandel besteht darin, Folgendes zu tun:

1. Aktualisieren Sie die RADIUS-Serverdatenbank so, dass die Authentifizierung des Anwenders für die relevanten Zugriffsleitungen zu einer RADIUS-Access-Reject-Antwort führt. Dies führt dazu, dass nachfolgende Versuche, PPPoE für die Zugriffsleitung auszuhandeln, fehlschlagen.

2. Initiieren der Abmeldung von den dynamischen PPPoE-Sitzungen; zum Beispiel durch eine von RADIUS initiierte Trennung. Dies löst die Bereinigung der logischen PPPoE-Schnittstelle und der zugehörigen Services aus, einschließlich der Ausgabe von RADIUS Accounting-Stop-Nachrichten für die Sitzung und die aktiven Services sowie das Entfernen der dynamischen logischen PPPoE-Schnittstelle.

   Wenn die Migration den Austausch des aktuellen CPE-Geräts gegen ein anderes erfordert und die PPPoE-Sitzung nicht anderweitig ordnungsgemäß abgemeldet wird, führt das Deaktivieren des CPE zu einem PPP-Keepalive-Fehler auf dem Router und löst die Sitzungsabmeldung aus.

3. Entfernen Sie die zugrunde liegende logische VLAN-Schnittstelle. Dies geschieht automatisch, wenn die remove-when-no-subscribers Anweisung auf der [edit interfaces interface-name auto-configure] Hierarchieebene für die zugriffsorientierte physische Schnittstelle enthalten ist. Andernfalls geben Sie den clear auto-configuration interfaces interface-name Befehl ein, um die dynamische logische VLAN-Schnittstelle zu entfernen.

4. Lösen Sie eine Port-Up-Benachrichtigung aus, um die dynamische VLAN-Erkennung, -Autorisierung und -Erstellung mit einer der folgenden Methoden zu initiieren:

   • Schalten Sie das CPE mit einer ausreichenden Verzögerung zwischen dem Aus- und Einschalten des Geräts aus und wieder ein, sodass eine Port Down-Meldung gefolgt von einer Port Up-Nachricht gesendet wird und der Router genügend Zeit hat, einen Keepalive-Fehler zu erkennen, der auf einen Verlust der Sitzung hinweist.

   • Geben Sie einen clear ancp access-loop Befehl aus.

   • Geben Sie einen request ancp oam port-up Befehl aus.

Migration des Anwendereigentums vom Einzelhändler zum Großhändler

Ein Ansatz für die Migration vom Einzelhandel zum Großhandel besteht darin, Folgendes zu tun:

1. Aktualisieren Sie die RADIUS-Serverdatenbank so, dass die dynamische VLAN-Autorisierung für die relevanten Zugriffsleitungen zu einer RADIUS-Access-Reject-Antwort führt. Dies führt dazu, dass nachfolgende ANCP-Port-Up-Meldungen ignoriert werden.

2. Initiieren der Abmeldung von den dynamischen VLAN-Sitzungen, die den Großhandels-Zugriffsservice unterstützen; zum Beispiel durch eine von RADIUS initiierte Trennung. Dies löst eine Bereinigung der Sitzung aus, die das Ausstellen von RADIUS Accounting-Stop-Meldungen für die Sitzung, das Entfernen der dynamischen logischen VLAN-Schnittstelle und der aktiven Services sowie das Freigeben des zugewiesenen inneren VLAN-Tags, das der Core-orientierten physischen Schnittstelle zugeordnet ist, für die Zuweisung zu einer anderen Layer-2-Großhandels-Anwender-Sitzung umfasst.

   Wenn die Migration den Austausch des aktuellen CPE-Geräts gegen ein anderes erfordert, führt das Deaktivieren des CPE zu einer ANCP-Port-Down-Meldung, die die Sitzungsabmeldung und -bereinigung auslöst.

3. Ermöglichen Sie den Teilnehmern, sich über herkömmliches dynamisches VLAN-Autosensing mit dem Netzwerk des Großhändlers zu verbinden, gefolgt von PPPoE- und PPP-Verhandlungen und der Erstellung logischer PPP-Schnittstellen.

Migration der Anwendereigentümerschaft zwischen Einzelhändlern

In der Regel migrieren Sie den Zugriff zwischen NSP-Einzelhändlern, indem Sie einen Neustart der vorhandenen dynamischen VLAN-Sitzung auslösen. Der Neustart initiiert eine Abmeldung von der Sitzung, gefolgt von der sofortigen dynamischen VLAN-Erkennung, Autorisierung und Erstellung innerhalb der Routing-Instanz, die dem neuen NSP entspricht. Ein Neustart ist eine logische Port-Down- und Port-Up-Sequenz für die entsprechende Zugriffsschleife des VLANs. Sie können eine der folgenden Methoden verwenden, um eine bestimmte dynamische logische VLAN-Schnittstelle neu zu starten:

• Initiieren Sie eine RADIUS Disconnect-Request-Nachricht, oder konfigurieren Sie den RADIUS-Server so, dass die Nachricht gesendet wird. Für die Nachricht muss das RADIUS-Attribut Acct-Terminate-Cause (49) auf den Wert 16 (Rückruf) festgelegt sein. Diese Ursache wird nur für dynamische VLANs, die durch eine ANCP-Port-Up-Nachricht erstellt wurden, als Trennung (Abmeldung) und unmittelbar gefolgt von einer erneuten Verbindung (Anmeldung) verarbeitet. Andere Clients reagieren auf diesen Wert nur mit einer Trennung.

• Schließen Sie die reconnect Option ein, wenn Sie Abonnenten mit dem clear network-access aaa subscriber Befehl abmelden. Sie können Abonnenten entweder über die Sitzungs-ID oder den Benutzernamen angeben. Diese Option versucht, eine gelöschte Sitzung wieder als Layer-2-Großhandels-Sitzung zu verbinden, wenn die Anwender-Sitzung vollständig abgemeldet wurde. Dieses Verhalten entspricht dem Ausgeben einer von RADIUS initiierten Trennung, die für die Wiederverbindung konfiguriert ist. Das heißt, wenn die Nachricht Acct-Terminate-Cause (RADIUS-Attribut 49) mit dem Wert callback (16) enthält.

• Lösen Sie eine Port Down-Nachricht gefolgt von einer Port UP-Nachricht mit einer der folgenden Methoden aus:

  • Schalten Sie das CPE mit einer ausreichenden Verzögerung zwischen dem Aus- und Einschalten des Geräts aus und wieder ein, sodass eine Port Down-Meldung gefolgt von einer Port Up-Nachricht gesendet wird und der Router genügend Zeit hat, einen Keepalive-Fehler zu erkennen, der auf einen Verlust der Sitzung hinweist.

  • Geben Sie einen clear ancp access-loop Befehl aus.

Änderung des Access Line Identifier oder Port VLAN Identifier

Wenn die Leitungskennung oder Port-VLAN-Kennung für eine Zugriffsschleife geändert wird, meldet der Zugriffsknoten die Änderung in einer Port-Up-Nachricht an den ANCP-Agenten. Die Nachricht übermittelt die Leitungs-ID im Access-Loop-Remote-ID TLV und die Port-VLAN-ID im Access-Aggregation-Circuit-ID-Binary TLV.

Der Access-Knoten sollte eine Port-Down-Nachricht für die Zugriffsschleife senden, bevor er eines der Identifikationsattribute für eine vorhandene Sitzung ändert. Die Meldung "Port ausgefallen" löst die Bereinigung der entsprechenden Layer 2-Großhandelssitzung aus. Wenn der Zugriffsknoten in diesem Fall keinen "Port Down" sendet, hat das folgende Verhalten den gleichen Effekt wie das Einfügen der "Port Down"-Nachricht, die der Zugriffsknoten nicht senden konnte:

• Bei einer Änderung der Leitungs-ID behandelt der ANCP-Agent die Neukonfiguration als logische Port-Down-Meldung für die Zugriffsleitung, die durch die vorherige Access-Loop-Remote-ID identifiziert wurde, gefolgt von einer Port-Up-Meldung für die Zugriffsleitung, die durch die neue Access-Loop-Remote-ID identifiziert wird.

• Bei einer Änderung der Port-VLAN-ID behandelt der ANCP-Agent die Neukonfiguration als logische Port-Down-Meldung für die Zugriffsleitung, die durch die vorherige Access-Aggregation-Circuit-Id-Binärdatei identifiziert wurde, gefolgt von einer Port-Up-Meldung für die Zugriffslinie, die durch die neue Access-Aggregation-Circuit-Id-Binärdatei identifiziert wurde.

In beiden Fällen benachrichtigt der ANCP-Agent den Autokonfigurations-Daemon (autoconfd), der die folgenden Aktionen ausführt:

1. Meldet die entsprechende Layer-2-Großhandels-Sitzung ab.

2. Sendet eine RADIUS Accounting-Stop-Nachricht mit den endgültigen Statistiken für die zugeordneten Dienstsitzungen und die Clientsitzung.

3. Entfernt die dynamische logische VLAN-Schnittstelle.

4. Versuche, die Layer-2-Großhandelssitzung mithilfe einer Anmeldesequenz wiederherzustellen, einschließlich Authentifizierung, Erstellung der logischen VLAN-Schnittstelle, Aktivierung von Services und bei Erfolg Senden von RADIUS Accounting-Start-Nachrichten für die Service- und Client-Sitzungen.

Sie müssen jede PPPoE-Sitzung, die der Zugriffsleitung mit den vorherigen Bezeichnern entspricht, manuell abmelden, auch wenn der Zugriffsknoten die entsprechende Port Down-Nachricht sendet, wenn sich die Werte ändern.

PPPoE-Sitzungen trennen und automatisch versuchen, die Verbindung als Layer 2-Großhandelssitzungen wiederherzustellen

Sie können von RADIUS initiierte Trennungsmeldungen verwenden, um vorhandene PPPoE-Sitzungen zu trennen und abzumelden und zu versuchen, sie als Layer-2-Großhandels-Sitzungen wiederherzustellen. Verwenden Sie Access-Ablehnungsmeldungen, um den Zugriff von PPPoE-Anwendern zu verhindern, und versuchen Sie, die Verbindung als Layer-2-Großhandelssitzung wiederherzustellen. Verwenden Sie diese Funktion, wenn Sie Sitzungen von PPPoE auf Layer 2-Großhandel migrieren möchten. Sowohl die von RADIUS initiierte Trennungs- als auch die Access-Reject-Nachricht müssen Acct-Terminate-Cause (RADIUS-Attribut 49) mit dem Wert callback (16) enthalten. callback bewirkt den Wiederverbindungsversuch. Die remove-when-no-subscribers Anweisung muss auf der zugrunde liegenden physischen Schnittstelle konfiguriert sein.

1. Das anfängliche Verhalten für die Nachrichten ist das folgende:

   • Access-Reject-Nachricht: Wenn ein PPPoE-PADI empfangen und eine neue PPPoE-Sitzung angefordert wird, antwortet RADIUS auf die Access-Request-Nachricht mit einer Access-Reject-Nachricht. Die Sitzung wird abgelehnt, vollständig abgemeldet und die zugrunde liegende logische VLAN-Schnittstelle wird entfernt.

   • RADIUS-initiierte Trennungsmeldung: Wenn eine von RADIUS initiierte Trennungsmeldung für eine vorhandene PPPoE-Sitzung empfangen wird, wird die dynamische PPPoE-Sitzung abgemeldet und die zugrunde liegende dynamische logische VLAN-Schnittstelle entfernt.

2. Die nächste Aktion ist für beide Nachrichten gleich:

   • Wenn eine ANCP-Port-Up-Nachricht für die entsprechende Zugriffsleitung empfangen wurde, versucht der Router, die Zugriffsleitung zu autorisieren und eine dynamische logische Layer-2-VLAN-Schnittstelle für den Großhandel anstelle der zugrunde liegenden dynamischen logischen VLAN-Schnittstelle zu erstellen, die entfernt wurde.

   • Wenn keine Port-Up-Nachricht empfangen wurde, wird diese Aktion zurückgestellt, bis die Nachricht empfangen wurde.

   • Wenn ein PPPoE PADI vor einer ANCP Port Up-Nachricht empfangen wird, antwortet RADIUS auf den Access-Request für eine neue PPPoE-Sitzung mit einer Access-Reject-Nachricht. Die Sitzung wird abgelehnt, vollständig abgemeldet und die zugrunde liegende logische VLAN-Schnittstelle wird entfernt.

Wenn die von RADIUS initiierte Trennungs- oder Zugriffsablehnungsnachricht für eine Nicht-PPPoE-Sitzung empfangen wird, z. B. DHCP, wird die Sitzung getrennt, aber die Anforderung zum erneuten Verbinden wird ignoriert. Es wird kein Versuch unternommen, eine Layer-2-Großhandels-Sitzung einzurichten.

Wenn die von RADIUS initiierte Trennung nicht Acct-Terminate-Cause mit dem Wert callback enthält, kann die PPPoE-Neuverhandlung nach der Trennung erfolgreich sein, aber wenn eine ANCP-Port-Up-Nachricht für die Zugriffsleitung empfangen wird, bevor eine PPPoE-Sitzung eingerichtet wird, wird eine Layer-2-Großhandelssitzung versucht.

Alternativ zum RADIUS-initiierten Trennen können Sie die PPPoE-Sitzung mit dem clear network-access aaa subscriber Befehl manuell abmelden. Geben Sie den Anwender entweder mit Benutzername oder Sitzungs-ID an. Wenn Sie die reconnect Option angeben, wird versucht, die gelöschte Sitzung erneut als Layer-2-Großhandels-Sitzung zu verbinden, wenn die Anwender-Sitzung vollständig abgemeldet wurde.

Folgen eines Zustandsübergangs in der zugriffsorientierten physischen Schnittstelle

Das folgende Verhalten tritt auf, wenn der Status der zugriffsorientierten physischen Schnittstelle von "Up" auf "Down" übergeht:

• Herkömmliche In-Band-VLAN-Autosensing-Stopps für die Schnittstelle.

• ANCP-bezogene Port-Up-Meldungen für die Schnittstelle werden ignoriert. Aktionen für neue oder nicht verarbeitete Port-Up-Nachrichten werden zurückgestellt, bis die Schnittstelle in den Status "Up" übergeht. Wenn die ANCP-Verbindung im Band mit dem Anwender-Datenverkehr auf der Schnittstelle ist, wird der gesamte ANCP-Datenverkehr gestoppt. Wenn der Ausfall lange genug dauert, geht die ANCP-Nachbarschaft verloren.

• Alle Layer-2-Großhandels-Sitzungen, die der Schnittstelle zugewiesen sind, werden so behandelt, als ob der ANCP-Agent eine Port-Down-Nachricht für die entsprechende Zugriffsleitung erhalten hätte. Jede Sitzung unterliegt der Abmeldung. Ob eine Sitzung abgemeldet wird, hängt vom ANCP-Haltetimer für den Nachbarschaftsverlust ab. Der Timer wird ausgeführt, wenn der ANCP-Agent den Zustandsübergang zu "Inaktiv" erkennt. Der Anwender verwendet weiterhin die ursprüngliche Sitzung, wenn alle drei der folgenden Ereignisse vor Ablauf des Timers eintreten:

  1. Die physische Schnittstelle wird wieder aktiviert.

  2. Die ANCP-Nachbarschaft ist wiederhergestellt.

  3. Auf der Schnittstelle wird eine Port-Up-Meldung empfangen.

  Andernfalls führt autoconfd die folgenden Aktionen aus:

  1. Meldet die Sitzung ab.

  2. Sendet eine RADIUS Accounting-Stop-Nachricht mit den endgültigen Statistiken für die zugeordneten Dienstsitzungen und die Clientsitzung.

  3. Entfernt die dynamische logische VLAN-Schnittstelle.

  Diese Sitzungen können wiederhergestellt werden, wenn die physische Schnittstelle wiederhergestellt ist, es sei denn, es wird eine ANCP-Port-Down-Nachricht empfangen.

• Der Autokonfigurations-Daemon löscht dynamische, automatisch erkannte logische VLAN-Schnittstellen. Die Schnittstellen für die ANCP-getriggerten Layer-2-VLANs für den Großhandel bleiben erhalten, da davon ausgegangen wird, dass ein Ausfall nur von kurzer Dauer ist. Wenn der Ausfall nicht von kurzer Dauer ist, beendet eine nachfolgende Port-Down-Meldung die Sitzung und entfernt die Schnittstelle.

  Bei herkömmlichen dynamischen Autosensed-VLANs wird die Schnittstelle nur entfernt, wenn die remove-when-no-subscribers Anweisung auf der zugriffsorientierten physischen Schnittstelle konfiguriert ist und alle Verweise auf die logische VLAN-Schnittstelle von einer übergeordneten logischen Schnittstelle oder Sitzung entfernt werden. Dieser Mechanismus gilt nicht für die ANCP-getriggerten Layer-2-VLANs im Großhandel, da sie keine oberen Sitzungsreferenzen haben.

Das folgende Verhalten tritt auf, wenn der Status der zugriffsorientierten physischen Schnittstelle von "Down" zu "Up" wechselt:

1. Die herkömmliche In-Band-VLAN-Autosensing für die Schnittstelle wird fortgesetzt. PPPoE-Sitzungen im Besitz des Zugriffsanbieters, die aufgrund des Übergangs von "Nach oben" nach "Abwärts" abgemeldet wurden, können neu verhandelt werden und eine vollständige Anmeldesequenz durchlaufen.

2. Für alle ANCP-Port-Up-Nachrichten für die Schnittstelle werden geeignete Maßnahmen ergriffen, einschließlich Nachrichten, die aufgrund des vorherigen Down-Status für die Schnittstelle zurückgestellt wurden. Wenn die ANCP-Verbindung im Band mit dem Datenverkehr des Anwenders ist, wird der gesamte ANCP-Datenverkehr fortgesetzt.

3. Die Weiterleitung wird für alle dynamischen, automatisch erkannten logischen VLAN-Schnittstellen fortgesetzt, die beim Ausfall der Schnittstelle nicht gelöscht wurden.

Das Löschen einer zugriffsorientierten physischen Schnittstelle löst die Abmeldung und Entfernung aller logischen Schnittstellen im oberen dynamischen VLAN und der entsprechenden Sitzungen aus.

Folgen eines Zustandsübergangs von oben nach unten in der Core-orientierten physischen Schnittstelle

Das folgende Verhalten tritt auf, wenn der Zustand der Core-orientierten physischen Schnittstelle von "Up" zu "Down" wechselt:

• Die dem Core zugewandte physische Schnittstelle ist nicht mehr berechtigt, neue oder ausstehende Zugriffsleitungen in dieser Routing-Instanz auf der Grundlage der ursprünglichen RADIUS-Autorisierung zuzuweisen.

• Alle Layer-2-Großhandels-Sitzungen, die der Schnittstelle zugewiesen sind, werden so behandelt, als ob der ANCP-Agent eine Port-Down/Port-Up-Nachrichtensequenz für die entsprechende Zugriffsleitung erhalten hätte. Jede Sitzung unterliegt der Abmeldung. Ob eine Sitzung abgemeldet wird, hängt vom ANCP-Haltetimer für den Nachbarschaftsverlust ab. Der Timer wird ausgeführt, wenn der ANCP-Agent den Zustandsübergang zu "Inaktiv" erkennt. Der Anwender verwendet weiterhin die ursprüngliche Sitzung, wenn alle drei der folgenden Ereignisse vor Ablauf des Timers eintreten:

  1. Die physische Schnittstelle wird wieder aktiviert.

  2. Die ANCP-Nachbarschaft ist wiederhergestellt.

  3. Auf der Schnittstelle wird eine Port-Up-Meldung empfangen.

  Andernfalls führt autoconfd die folgenden Aktionen aus:

  1. Meldet die Sitzung ab.

  2. Entfernt den Sitzungseintrag aus der SDB.

  3. Sendet eine RADIUS Accounting-Stop-Nachricht mit den endgültigen Statistiken für die zugeordneten Dienstsitzungen und die Clientsitzung.

  4. Entfernt die dynamische logische VLAN-Schnittstelle.

• Als Nächstes versucht autoconfd, die Sitzungen zu verfügbaren Verbindungen auf allen verbleibenden berechtigten physischen Core-Schnittstellen zu migrieren, die derselben Routing-Instanz zugewiesen sind:

  1. Die ursprüngliche Anforderung wird in eine Wiederholungswarteschlange gestellt.

  2. Für jede Sitzung wird eine Anmeldesequenz versucht, einschließlich der Authentifizierung, der Erstellung dynamischer logischer VLAN-Schnittstellen, der Aktivierung von Diensten und des Sendens von RADIUS Accounting-Start-Nachrichten für die Dienst- und Client-Sitzungen.

     • Wenn die Anmeldesequenz erfolgreich ist, wird die Anforderung aus der Wiederholungswarteschlange entfernt.

     • Wenn die Anmeldung fehlschlägt, wird die Sitzung abgemeldet, der Sitzungseintrag aus der SDB entfernt und die entsprechende Zugriffsleitung auf einen ausstehenden Status gesetzt.

  Wenn alle verfügbaren Verbindungen verwendet sind – wenn keine VLAN-Tags mehr aus den konfigurierten inneren VLAN-ID-Auslagerungsbereichen verfügbar sind – wird aufgrund erfolgreicher Wiederverbindungen kein Versuch unternommen, verbleibende Layer-2-Großhandelssitzungen zu verbinden. Obwohl die Authentifizierung erfolgreich sein kann, schlägt die Erstellung dynamischer logischer VLAN-Schnittstellen während der Profilinstanziierung fehl. In diesem Fall ist die Sitzung ausgefallen, der Sitzungseintrag wird aus der SDB entfernt und die entsprechende Zugriffsleitung auf einen ausstehenden Status gesetzt.

• Die ausstehenden Zugriffsleitungen, die diese nicht migrierten Sitzungen darstellen, können wiederhergestellt werden, wenn die Schnittstelle wiederhergestellt wird oder wenn zusätzliche VLAN-Verbindungen verfügbar werden. beispielsweise durch eine Konfigurationsänderung, die entweder den inneren VLAN-ID-Auslagerungsbereich für eine oder mehrere verbleibende Core-seitige physische Schnittstellen vergrößert oder neue Core-basierte physische Schnittstellen hinzufügt. Wenn der ANCP-Agent jedoch eine Port-Down-Nachricht für eine ausstehende Zugriffsleitung empfängt, wird die entsprechende Sitzung nicht wiederhergestellt.

Sie können den show auto-configuration out-of-band pending Befehl verwenden, um die Anzahl der ausstehenden Zugriffsleitungen pro Routing-Instanz anzuzeigen.

Folgen eines Zustandsübergangs von unten nach oben in der Core-orientierten physischen Schnittstelle

Das folgende Verhalten tritt auf, wenn der Core-zugewandte Zustand der physischen Schnittstelle von "Down" zu "Up" wechselt:

• Die physische Schnittstelle ist jetzt berechtigt, neue Layer-2-Großhandels-Anwender-Sitzungen zuzuweisen.

• Der ANCP-Agent benachrichtigt den Autokonfigurations-Daemon (autoconfd), der versucht, die Layer-2-Großhandels-Sitzungen, die der ausstehenden Zugriffsleitung entsprechen, wiederherzustellen, indem er eine herkömmliche Anmeldesequenz initiiert. Diese Sequenz umfasst die Authentifizierung, die Erstellung dynamischer logischer VLAN-Schnittstellen, die Aktivierung von Services und das Senden von RADIUS Accounting-Start-Nachrichten für die Service- und Client-Sitzungen.

• Ausstehende Sitzungen werden so lange wiederhergestellt, bis keine mehr vorhanden sind oder ein Fehler auftritt, typischerweise aufgrund der Erschöpfung der inneren VLAN-Tags aus den Auslagerungsbereichen auf der Schnittstelle. Im letzteren Fall werden die Sitzungen abgemeldet, der Sitzungseintrag aus der SDB entfernt und die Zugriffsleitung auf einen ausstehenden Status gesetzt.

Sie können den show auto-configuration out-of-band pending Befehl verwenden, um die Anzahl der ausstehenden Zugriffsleitungen pro Routing-Instanz anzuzeigen.

Diese Verhaltensweisen treten auch in den folgenden Fällen auf:

• Zusätzliche VLAN-Verbindungsressourcen werden durch eine Konfigurationsänderung verfügbar, die entweder den inneren VLAN-ID-Auslagerungsbereich für eine oder mehrere verbleibende Core-orientierte physische Schnittstellen vergrößert oder neue Core-basierte Schnittstellen hinzufügt. Die neu hinzugefügte physische Schnittstelle muss sich im Status "Aktiv" befinden, um Layer-2-Großhandelssitzungen annehmen zu können.

• Eine von RADIUS initiierte Trennung wird für eine vorhandene Layer-2-Großhandels-Sitzung empfangen, die dieser Routing-Instanz zugewiesen ist, wird abgemeldet (nur trennen). Bei einer Trennung mit einem Reconnect-Qualifizierer erhält die betroffene Sitzung den Vorzug, die Verbindung über ausstehende Zugriffsleitungen wiederherzustellen.

• Sie geben den request auto-configuration reconnect-pendingBefehl , clear ancp access-loopoder request ancp oam port-up ein.

Verlust der ANCP-TCP-Nachbarschaft

Der ANCP-Agent kann seine TCP-Nachbarschaft zu einem Nachbarn unter folgenden Umständen verlieren:

• Der Zugangsknoten handelt die Verbindung neu; z. B. als Folge eines Verlusts der Synchronisation. Die Neuverhandlung löst aus, dass der lokale Zustand von "Etabliert" in "Nicht etabliert" geändert wird. Der Status wechselt zurück zu "Etabliert", wenn die Sitzung erfolgreich neu ausgehandelt wurde.

• Eine End-of-File-Nachricht (EOF) wird auf dem Socket empfangen, die angibt, dass die Nachbarschaft geschlossen ist. Dies kann auftreten, wenn die ANCP-Konfiguration auf dem Zugriffsknoten gelöscht wird.

• Es tritt ein Adjacency-Keepalive-Fehler auf. Wenn bei drei aufeinanderfolgenden Umfragen keine Antwort eingeht, wird die Nachbarschaft für verloren erklärt.

Der ANCP-Agent behandelt den Verlust der Nachbarschaft so, als hätte er für jede Zugriffsschleife, die durch die ANCP-Verbindung dargestellt wird, eine Port Down-Nachricht erhalten. Der Agent benachrichtigt autoconfd, das die folgenden Aktionen ausführt:

• Meldet alle Layer-2-Großhandels-Sitzungen ab, die von dieser ANCP-Verbindung ausgelöst wurden.

• Sendet eine RADIUS Accounting-Stop-Nachricht mit den endgültigen Statistiken für die zugeordneten Dienstsitzungen und die Clientsitzung.

• Entfernt die dynamische logische VLAN-Schnittstelle.

Wenn sich die zugewiesene physische Schnittstelle mit Zugriff oder Core im Status "Inaktiv" befindet, können alle ausstehenden Sitzungen, die von dieser ANCP-Verbindung ausgelöst wurden, nicht wiederhergestellt werden, wenn die Schnittstelle wieder in den Status "Aktiv" zurückkehrt.

Dynamische, konventionell automatisch erkannte logische VLAN-Schnittstellen, wie z. B. solche, die PPPoE-Sitzungen unterstützen, sind vom Verlust der TCP-Nachbarschaft nicht betroffen.

Wenn die Nachbarschaft wiederhergestellt ist, ist das erwartete Verhalten eine vollständige Wiederholung der Port-Down- und Port-Up-Meldungen für alle zugehörigen konfigurierten Zugriffsleitungen. Die Layer-2-Großhandels-Sitzungen, für die der ANCP-Agent Port-Up-Nachrichten empfängt, werden wiederhergestellt.

Sie können die Auswirkungen kurzfristiger Nachbarschaftsverluste abmildern, indem Sie eine Haltezeit für Nachbarschaftsverluste konfigurieren. Der Timer startet, wenn die Nachbarschaft verloren geht. Auch wenn die Nachbarschaft verloren geht, werden etablierte Sitzungen beibehalten, während der Timer läuft, es sei denn, es wird eine Port-Down-Meldung für die entsprechende Zugriffsleitung empfangen.

Jede Zugriffsleitung, für die der ANCP-Agent bis zum Ablauf des Timers keine Port-Up-Nachricht erhalten hat, wird so behandelt, als hätte der Agent eine Port-Up-Nachricht für die Leitung erhalten. Der ANCP-Agent benachrichtigt autoconfd, das die folgenden Aktionen ausführt:

• Meldet alle Layer-2-Großhandels-Sitzungen ab, die der Zugriffsleitung entsprechen.

• Sendet eine RADIUS Accounting-Stop-Nachricht mit den endgültigen Statistiken für die zugeordneten Dienstsitzungen und die Clientsitzung.

• Entfernt die dynamische logische VLAN-Schnittstelle.

Nach Ablauf des Timers empfangene Port-Up-Nachrichten füllen die SDB-Zugriffsleitungstabelle neu auf und stellen die Layer-2-Großhandels-Sitzungen wieder her

Der Hold-Timer für den Nachbarschaftsverlust dient folgenden Zwecken:

• Dämpft die Auswirkungen eines kurzzeitigen Nachbarschaftsverlusts und behält so bestehende Layer-2-Großhandels-Sitzungen bei.

• Erkennt das Entfernen einer Zugriffsleitungskonfiguration auf dem Zugriffsknoten. Unter bestimmten Umständen möchten Sie beispielsweise die Konfiguration einer Zugangsleitung auf einem Nachbarn entfernen. Sie trennen zuerst die ANCP-Sitzung zwischen einem Nachbarn und dem BNG, entfernen die Konfiguration auf dem Nachbarn und stellen dann die ANCP-Verbindung mit dem BNG wieder her. Der Nachbar gibt keine Port-Down-Meldung aus. Wenn der Adjacency-Loss Hold-Timer konfiguriert ist, erkennt der ANCP-Agent eine Zugriffsleitung, für die er keine Port-Up- oder Port-Down-Nachricht erhalten hat, und löst folglich die Abmeldung und Entfernung der entsprechenden Layer-2-Großhandels-Sitzung aus.