Layer 2-Großhandel mit ANCP-getriggerten VLANs – Überblick

RADIUS-Autorisierung für ANCP-getriggerte VLANs

Wenn sich ein Abonnent anmeldet, enthält die Access-Request-Nachricht, die an den RADIUS-Server gesendet wird, einen Benutzernamen und optional ein Kennwort, das lokal auf dem Router generiert wird. Sie können den Router so konfigurieren, dass er einen eindeutigen Benutzernamen mit dem Wert der ANCP-TLVs – Access-Loop-Circuit-ID, Access-Loop-Remote-ID oder beides – erstellt, wie in der ANCP Port Up-Nachricht vom Zugriffsknoten empfangen. Wenn Sie den Router alternativ so konfigurieren, dass er ANCP-bezogene Zugriffsschleifenattribute als Juniper Networks VSAs überträgt – 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 zur Zugriffsleitung, damit der RADIUS-Server bestimmen kann, ob die Zugriffsschleife an einen Einzelhändler weitergegeben 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 VLAN, das durch die Port Up-Nachricht ausgelöst wird, an einen Einzelhandels-NSP weitergeleitet. Die Autorisierung erfolgt ähnlich wie bei PPPoE-Sitzungen. Die Zugriffsakzeptanz enthält den VSA des virtuellen Routers (26-1) mit einem Wert, der der eindeutigen, nicht standardmäßigen Routing-Instanz des NSP entspricht. Die Nachricht kann optional Clientdienste enthalten, z. B. Attribute für parametrisiertes CoS, Firewallfilter und Richtlinien für die logische Schnittstelle sowie Layer 2-Dienstaktivierungen.

• Access-Reject: In diesem Fall ist entweder das VLAN, das durch die Port Up-Meldung ausgelöst wird, ein eigener Abonnent 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 Down-Nachricht empfangen wird, ignoriert der Router nachfolgende Port Up-Nachrichten für diesen Teilnehmer. Die herkömmliche dynamische gestapelte VLAN-Autosensierung kann jedoch durch Aushandlung von Zugriffsprotokollen, wie z. B. PPPoE, initiiert werden.

Instanziierung eines ANCP-getriggerten, dynamischen VLANs mit automatischer Erkennung

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

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

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

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

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

5. Das automatische äußere VLAN-Tag wird mit dem inneren VLAN-Tag vertauscht, wenn nachgeschaltete Pakete vom NSP (die das zugewiesene innere VLAN-Tag enthalten) an den Teilnehmer weitergeleitet werden.

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

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

7. Ein zusätzliches VLAN-Tag, die Trunk-VLAN-ID, wird intern zur Identifizierung der bereitgestellten physischen Core-Schnittstelle verwendet, sodass der Abonnentendatenverkehr per Tunneling zur zugewiesenen Schnittstelle erfolgen kann. Im dynamischen Profil wird diese ID durch die vordefinierte Variable bereitgestellt. $junos-vlan-map-id Diese Kennung unterscheidet zwischen mehreren physischen Core-Trunk-Schnittstellen für denselben NSP.

8. Alle Clientdienste, z. B. CoS oder Firewallfilter, werden auf die Abonnentensitzung 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 für die dynamische VLAN-Sitzung erstellt und konfiguriert wurde. Bei der Sitzungsaktivierung wird eine RADIUS Accounting-Start-Nachricht ausgelöst. Alle Services, die während der Autorisierung von RADIUS empfangen wurden, sind nun aktiviert.

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

Gewichtetes Load Balancing für Abonnentensitzungen über geeignete physische Schnittstellen mit Core-Zugang

Der Router verwendet eine gewichtete Lastverteilung anstelle einer Rundlaufverteilung, um Layer-2-Großhandelsteilnehmersitzungen über mehrere zum Core gerichtete physische Schnittstellen entsprechend dem Gewicht der Schnittstelle zuzuweisen. Die Gewichtung einer Schnittstelle korreliert mit der Anzahl der VLAN-Tags, die aus den aggregierten inneren (Core-orientierten) VLAN-ID-Swap-Bereichen auf der Schnittstelle verfügbar sind.

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

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

• 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 die geringste Gewichtung.

Die Verwendung der verfügbaren inneren VLAN-ID-Tags aus den Swap-Bereichen anstelle der aggregierten gesamten VLAN-Tags bedeutet, dass die relative Gewichtung der Schnittstellen dynamischer ist. Der gewichtete Lastverteilungsmechanismus kann schneller auf Abmeldungen von Abonnenten, die Migration des Anwendereigentums vom Großhändler zum Einzelhändler und vom Einzelhändler zum Großhändler, auf physische Schnittstellenstatusübergänge in der Core-Richtung (einschließlich der Verschiebung zu den verbleibenden geeigneten Core-Schnittstellen, wenn ein Schnittstellenstatus von "Up" zu "Down" wechselt) und auf Ausfälle einer der physischen Core-Schnittstellen reagieren. Wenn eine Schnittstelle wiederhergestellt wird (Übergänge von Down zu Up), begünstigt die gewichtete Lastverteilung im Allgemeinen diese Schnittstelle entweder für ausstehende Sitzungen oder für neue Layer 2-Großhandelssitzungen, die anschließend auftreten.

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

Betrachten Sie zum Beispiel zwei Core-seitige physische Schnittstellen, IFD1 und IFD2. Basierend auf den inneren VLAN-ID-Swap-Bereichen, die für diese beiden Schnittstellen konfiguriert sind, verfügt IFD1 über 1000 verfügbare VLAN-Tags und IFD2 nur über 500 verfügbare Tags. Die Abonnentensitzungen werden basierend auf ihrer relativen Gewichtung nach dem Zufallsprinzip auf die beiden Schnittstellen verteilt. IFD1 hat eine höhere Gewichtung als IFD2. Da IFD1 doppelt so viele Tags zur Verfügung hat wie IFD2, ist der Pool von Zahlen, die IFD1 zugeordnet sind, auch doppelt so groß wie für IFD2. Die vom Router generierte Zufallszahl ist für IFD1 doppelt so wahrscheinlich im Pool wie für IFD2. Folglich wird IFD1 gegenüber IFD2 im Verhältnis 2:1 bevorzugt, und die Wahrscheinlichkeit, dass IFD1 Abonnentensitzungen zugewiesen werden, ist doppelt so hoch wie bei IFD2.

Aktualisierungen der RADIUS-Zwischenabrechnung

Zwischenberichte, die für Out-of-Band-getriggerte, automatische dynamische VLANs mit automatischer Erkennung an AAA gesendet werden, werden auf die gleiche Weise unterstützt wie herkömmliche dynamische und autorisierte Client-Sitzungen (wie 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 der Benachrichtigung von AAA sofort eine Zwischenaktualisierungsmeldung vom Typ Accounting-Request an den RADIUS-Server gesendet wird. Sofortige Zwischenaktualisierungen der Kontoführung können für eine ANCP-ausgelöste dynamische VLAN-Sitzung nur dann gesendet werden, wenn eine Änderung in bestimmten wichtigen ANCP-Attributen für die zugeordnete Zugriffsleitung auftritt, die das Systemverhalten beeinflussen kann. Um eine zusätzliche Belastung des RADIUS-Servers durch Änderungen an weniger kritischen ANCP-Attributen zu verhindern, lösen Änderungen an anderen ANCP-Attributen keine sofortigen Accounting-Interim-Update-Meldungen aus. Stattdessen werden diese Änderungen in der nächsten geplanten Accounting-Interim-Update-Nachricht gemeldet.

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

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

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

Wenn die ancp-speed-change-immediate-update Anweisung 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 der auto-configure-trigger interface interface-name Kontoauszug zusätzlich auf Hierarchieebene [edit protocols ancp neighbor ip-address] konfiguriert ist, werden auch sofortige Zwischenaktualisierungen der Kontoführung für Änderungen an den TLVs Access-Loop-Remote-ID und Access-Aggregation-Circuit-ID-Binary gesendet.

Weitere Informationen zu sofortigen RADIUS-Zwischenkontoaktualisierungen finden Sie unter Konfigurieren sofortiger Zwischenkontoaktualisierungen 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 Zugriffsdienst 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 Abonnentensitzung.

  • Eine entsprechende Abonnentensitzung ist vorhanden, wird aber gerade gelöscht.

  • Die Meldung bezieht sich auf eine herkömmliche Sitzung mit automatischer Erkennung (die durch die normale Protokollverarbeitung entfernt wird).

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

• Das Löschen oder der Übergang in einen betriebsbedingten inaktiven Zustand der physischen Schnittstelle für den Teilnehmer oder der physischen Schnittstelle für den Core.

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

• Die Ausgabe des Befehls zum Abmelden des VLAN oder des clear ancp access-loop Befehls zum Erzwingen eines Zurücksetzens des clear auto-configuration interfaces Teilnehmers.

• Der Empfang einer von RADIUS initiierten Trennungsnachricht.

Jedes dieser Ereignisse deaktiviert auch die Abonnentensitzung, um zukünftige Dienstaktivierungen zu verhindern, und gibt eine RADIUS Accounting-Stop-Nachricht für verwandte Services und für die dynamische VLAN-Abonnentensitzung aus. Das dynamische Profil wird dann deinstanziiert, um zuerst die logische Schnittstelle des dynamischen VLAN und dann den entsprechenden Sitzungseintrag in der VLAN-SDB zu entfernen.

Sie können die Anzahl der miteinander verbundenen Layer-2-Teilnehmersitzungen 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-verbunden) 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-Teilnehmersitzungen auf Ports mit aktiven Sitzungen an.

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

Die ANCP-getriggerte Layer 2-Großhandelsimplementierung berücksichtigt sowohl Abonnenten, die an einen Einzelhändler als auch zum Großhändler gehören, und Abonnenten, die zum Großhändler gehören. Jede Teilnehmersitzung, die auf der physischen Schnittstelle für den Zugriff erkannt wird, kann entweder das eine oder das andere sein. Dies bedeutet, dass eine Überlappung zwischen dem äußeren Tag-Bereich für die Out-of-Band-VLANs mit Autosens und dem für In-Band-VLANs mit Autosense besteht.

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

Die folgende Abfolge von Ereignissen tritt auf, 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 logischen dynamischen 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 zugriffsorientierte 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 aus, solange die PPP-Sitzung (logische PPP-Schnittstelle und zugrunde liegende dynamische VLAN-logische Schnittstelle) aufrechterhalten wird.

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

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 kein Autorisierungsversuch unternommen wurde:

     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 Ergebnis der Autorisierung bestimmt, was als nächstes geschieht:

        • Wenn die Autorisierung erfolgreich ist (RADIUS gibt eine Access-Accept-Nachricht zurück), wird eine dynamische logische Layer-2-Großhandelsschnittstelle innerhalb der Routing-Instanz des NSP des Einzelhändlers 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 PPPoE-PADI-Pakete mit Ausnahme fortgesetzt, die anschließend mit In-Band-VLAN-Autosensing empfangen werden.

   • Wenn zuvor versucht wurde, eine Autorisierung durchzuführen, wird keine Aktion ausgeführt, da davon ausgegangen wird, dass es sich bei dem Fehler der PPP-Sitzungsaushandlung um einen Anmeldefehler außerhalb des Layer2-Großhandelskontexts handelt. Dieses Verhalten verhindert eine unnötige Autorisierung als Reaktion auf die ANCP-Portup-Nachricht jedes Mal, wenn eine PPPoE-Sitzung beendet und von einer normalen Abonnentenabmeldung 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 zugriffsorientierte physische Schnittstelle und dasselbe äußere VLAN-Tag bereits ausgeführt wird.

3. Das Ergebnis der Autorisierung bestimmt, was als nächstes geschieht:

   • 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 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. PPPoE- und PPP-Aushandlungen finden statt und die Ereignisse laufen wie gewohnt für ein herkömmliches, dynamisches VLAN mit Autosens ab.

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

Die großhandelseigenen Teilnehmer werden über dynamische PPPoE-Schnittstellen über dynamische VLANs angebunden. Für jeden Teilnehmer muss die PPPoE-Sitzung getrennt und die entsprechende logische PPP-Schnittstelle gelöscht werden, bevor ANCP-Port-Up-Nachrichten für dieselbe zugrunde liegende physische Schnittstelle und das äußere VLAN-Tag als Out-of-Band-Trigger für die dynamische VLAN-Autosensing dienen können.

Ein Ansatz für die Migration vom Großhandels- zum Einzelhandelsbesitz besteht darin, wie folgt vorzugehen:

1. Aktualisieren Sie die RADIUS-Serverdatenbank so, dass die Teilnehmerauthentifizierung für die relevanten Zugriffsleitungen zu einer RADIUS-Zugriffsablehnungsantwort führt. Dies führt dazu, dass nachfolgende Versuche, PPPoE für die Zugriffsleitung auszuhandeln, fehlschlagen.

2. Initiieren Sie die Abmeldung von den dynamischen PPPoE-Sitzungen; z. B. durch Ausgabe einer von RADIUS initiierten Trennung. Dies löst die Bereinigung der logischen PPPoE-Schnittstelle und der zugehörigen Services aus, einschließlich der Ausgabe von RADIUS Accounting-Stop-Meldungen für die Sitzung und die aktiven Services sowie das Entfernen der logischen dynamischen 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 eine Sitzungsabmeldung aus.

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

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

   • Schalten Sie das CPE mit einer ausreichenden Verzögerung zwischen dem Ausschalten und dem Wiedereinschalten des Geräts ein, sodass eine Port Down-Meldung gefolgt von einer Port Up-Meldung gesendet wird und der Router genügend Zeit erhält, um einen Keepalive-Fehler zu erkennen, der auf den 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 Abonnentenbesitzes vom Einzelhändler zum Großhändler

Ein Ansatz für die Migration vom Einzelhandel zum Großhandelseigentum 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-Antwort mit Zugriffsverweigerung führt. Dies führt dazu, dass nachfolgende ANCP-Port-Up-Meldungen ignoriert werden.

2. Initiieren Sie die Abmeldung von den dynamischen VLAN-Sitzungen, die den Großhandelszugriffsservice unterstützen; z. B. durch Ausgabe einer von RADIUS initiierten Trennung. Dies löst die Bereinigung der Sitzung aus, die die Ausgabe von RADIUS Accounting-Stop-Nachrichten für die Sitzung, das Entfernen der logischen Schnittstelle des dynamischen VLAN und der aktiven Services sowie das Freigeben des zugewiesenen inneren VLAN-Tags, das der zum Core gerichteten physischen Schnittstelle zugeordnet ist, für die Zuweisung zu einer anderen Layer-2-Großhandelsteilnehmersitzung umfasst.

   Wenn für die Migration das Austauschen des aktuellen CPE-Geräts gegen ein anderes erforderlich ist, führt das Deaktivieren des CPE zu einer ANCP-Portdown-Meldung, die die Sitzungsabmeldung und -bereinigung auslöst.

3. Ermöglichen Sie es Abonnenten, sich mit herkömmlichem dynamischem VLAN-Autosensing mit dem Netzwerk des Großhändlers zu verbinden, gefolgt von PPPoE- und PPP-Aushandlung und der Erstellung von logischen PPP-Schnittstellen.

Migration des Abonnentenbesitzes 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 einer sofortigen dynamischen VLAN-Erkennung, Autorisierung und Erstellung innerhalb der Routing-Instanz, die dem neuen NSP entspricht. Ein Neustart ist eine logische Abfolge von Port Down und Port Up für die entsprechende Zugriffsschleife des VLANs. Sie können eine der folgenden Methoden verwenden, um eine bestimmte logische Schnittstelle für dynamische VLANs neu zu starten:

• Initiieren Sie eine RADIUS-Trennungsanforderungsmeldung, oder konfigurieren Sie Ihren RADIUS-Server für das Senden der Nachricht. Für die Nachricht muss das RADIUS-Attribut "Acct-Terminate-Cause" (49) auf den Wert 16 (Rückruf) festgelegt sein. Diese Ursache wird nur bei dynamischen VLANs, die durch eine ANCP-Port-Up-Nachricht erstellt wurden, als Trennung (Logout) gefolgt von einer erneuten Verbindung (Login) 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 anhand der Sitzungskennung oder des Benutzernamens angeben. Mit dieser Option wird versucht, eine gelöschte Sitzung erneut als Layer 2-Großhandelssitzung zu verbinden, wenn die Abonnentensitzung vollständig abgemeldet wurde. Dieses Verhalten entspricht dem Ausgeben einer von RADIUS initiierten Trennung, die für die Wiederherstellung der Verbindung 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 Ausschalten und dem Wiedereinschalten des Geräts ein, sodass eine Port Down-Meldung gefolgt von einer Port Up-Meldung gesendet wird und der Router genügend Zeit erhält, um einen Keepalive-Fehler zu erkennen, der auf den Verlust der Sitzung hinweist.

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

Änderung der Zugriffsleitungskennung oder der Port-VLAN-Kennung

Wenn die Leitungskennung oder die 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 Zugriffsknoten sollte eine Port Down-Nachricht für die Zugriffsschleife senden, bevor er eines der Identifikationsattribute für eine vorhandene Sitzung ändert. Die Meldung "Port down" 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 die gleiche Auswirkung 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-Nachricht für die Zugriffsleitung, die durch die vorherige Access-Loop-Remote-ID identifiziert wird, gefolgt von einer Port Up-Nachricht 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-Nachricht für die Zugriffsleitung, die durch die vorherige Access-Aggregation-Circuit-Id-Binary identifiziert wurde, gefolgt von einer Port Up-Nachricht für die Zugriffslinie, die durch die neue Access-Aggregation-Circuit-Id-Binary identifiziert wurde.

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

1. Meldet sich von der entsprechenden Layer 2-Großhandelssitzung ab.

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

3. Entfernt die logische Schnittstelle des dynamischen VLAN.

4. Versuche, die Layer 2-Großhandelssitzung mithilfe einer Anmeldesequenz wiederherzustellen, einschließlich Authentifizierung, Erstellung der logischen Schnittstelle des dynamischen VLAN, Aktivierung von Diensten und, falls erfolgreich, Senden von RADIUS Accounting-Start-Nachrichten für die Dienst- und Clientsitzungen.

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

Trennen von PPPoE-Sitzungen und automatischer Versuch, die Verbindung wiederherzustellen als Layer 2-Großhandelssitzungen

Sie können RADIUS-initiierte Trennungsnachrichten verwenden, um vorhandene PPPoE-Sitzungen zu trennen und abzumelden und zu versuchen, sie als Layer 2-Großhandelssitzungen wiederherzustellen. Verwenden Sie Access-Reject-Nachrichten, um den PPPoE-Anwenderzugriff zu verhindern, und versuchen Sie, die Verbindung als Layer 2-Großhandelssitzung wiederherzustellen. Verwenden Sie diese Funktion, wenn Sie Sitzungen vom PPPoE- auf den Layer 2-Großhandel migrieren möchten. Sowohl die von RADIUS initiierte Trennungs- als auch die Zugriffsablehnungsmeldung müssen Acct-Terminate-Cause (RADIUS-Attribut 49) mit dem Wert callback (16) enthalten. Der Rückruf bewirkt den erneuten Verbindungsversuch. Die remove-when-no-subscribers Anweisung muss auf der zugrunde liegenden physischen Schnittstelle konfiguriert werden.

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

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

   • RADIUS-initiierte Trennungsmeldung: Wenn eine von RADIUS initiierte Trennungsnachricht für eine vorhandene PPPoE-Sitzung empfangen wird, wird die dynamische PPPoE-Sitzung abgemeldet und die zugrunde liegende 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-Großhandels-VLAN-Schnittstelle anstelle der zugrunde liegenden logischen Schnittstelle für dynamische VLANs zu erstellen, die entfernt wurde.

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

   • Wenn eine 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 zurückgewiesen, vollständig abgemeldet und die zugrunde liegende logische Schnittstelle des dynamischen VLAN wird entfernt.

Wenn die von RADIUS initiierte Meldung zum Trennen oder Zurückweisen des Zugriffs für eine Nicht-PPPoE-Sitzung, z. B. DHCP, empfangen wird, wird die Sitzung getrennt, aber die Anforderung zur Wiederherstellung der Verbindung wird ignoriert. Es wird nicht versucht, eine Layer 2-Großhandelssitzung 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-Portup-Nachricht für die Zugriffsleitung empfangen wird, bevor eine PPPoE-Sitzung eingerichtet wird, wird versucht, eine Layer-2-Großhandelssitzung durchzuführen.

Alternativ zum von RADIUS initiierten Trennen können Sie die PPPoE-Sitzung mit dem clear network-access aaa subscriber Befehl manuell abmelden. Geben Sie den Abonnenten entweder anhand des Benutzernamens oder der Sitzungs-ID an. Wenn Sie die reconnect Option einschließen, wird versucht, die gelöschte Sitzung erneut als Layer 2-Großhandelssitzung zu verbinden, wenn die Abonnentensitzung vollständig abgemeldet wurde.

Folgen eines Zustandsübergangs in der zugriffsorientierten physischen Schnittstelle

Das folgende Verhalten ergibt sich, wenn der Zustand der physischen Schnittstelle für den Zugriff von "Nach oben" in "Unten" übergeht:

• Herkömmliches In-Band-VLAN mit Autosensing stoppt die Schnittstelle.

• ANCP-bezogene Port Up-Nachrichten für die Schnittstelle werden ignoriert. Die Aktion für neue oder unverarbeitete Port-Up-Nachrichten wird zurückgestellt, bis die Schnittstelle in den Up-Zustand übergeht. Wenn die ANCP-Verbindung mit dem Abonnentendatenverkehr auf der Schnittstelle in Band ist, wird der gesamte ANCP-Datenverkehr angehalten. Wenn der Ausfall lange genug dauert, geht die ANCP-Nachbarschaft verloren.

• Alle Layer-2-Großhandelssitzungen, die der Schnittstelle zugewiesen sind, werden so behandelt, als ob der ANCP-Agent eine Port Down-Nachricht für die entsprechende Zugriffsleitung empfangen hätte. Jede Sitzung muss abgemeldet werden. Ob eine Sitzung abgemeldet wird, hängt vom ANCP-Timer für Nachbarschaftsverluste ab. Der Timer wird ausgeführt, wenn der ANCP-Agent den Zustandsübergang in "Inaktiv" erkennt. Der Abonnent verwendet weiterhin die ursprüngliche Sitzung, wenn alle drei der folgenden Bedingungen vor Ablauf des Timers erfüllt sind:

  1. Die physische Schnittstelle wird wieder aktiviert.

  2. Die ANCP-Nachbarschaft wird 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 Clientsitzungen.

  3. Entfernt die logische Schnittstelle des dynamischen VLAN.

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

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

  Bei herkömmlichen dynamischen VLANs mit Autosens 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 höheren logischen Schnittstelle oder Sitzung entfernt werden. Dieser Mechanismus gilt nicht für die ANCP-getriggerten Layer 2-Großhandels-VLANs, da sie keine oberen Sitzungsreferenzen haben.

Das folgende Verhalten ergibt sich, wenn der Zustand der physischen Schnittstelle für den Zugriff von "Herunter" in "Nach oben" übergeht:

1. Die herkömmliche In-Band-VLAN-Autosensorisierung wird für die Schnittstelle fortgesetzt. PPPoE-Sitzungen im Besitz des Access-Providers, die aufgrund des Übergangs von "Up" zu "Down" abgemeldet wurden, können neu ausgehandelt werden und eine vollständige Anmeldesequenz durchlaufen.

2. Für alle ANCP-Port-Up-Nachrichten für die Schnittstelle werden entsprechende Aktionen ausgeführt, einschließlich der Meldungen, die aufgrund des vorherigen Down-Status für die Schnittstelle zurückgestellt wurden. Wenn die ANCP-Verbindung mit dem Abonnentendatenverkehr in Band ist, wird der gesamte ANCP-Datenverkehr fortgesetzt.

3. Die Weiterleitung wird für alle dynamischen, logischen VLAN-Schnittstellen mit automatischer Erkennung fortgesetzt, die nicht gelöscht wurden, als die Schnittstelle ausfiel.

Das Löschen einer physischen Schnittstelle mit Zugriffszugriff löst die Abmeldung und Entfernung aller oberen logischen VLAN-Schnittstellen und der entsprechenden Sitzungen aus.

Folgen eines Zustandsübergangs von oben nach unten in der zum Core gerichteten physischen Schnittstelle

Das folgende Verhalten ergibt sich, wenn der Zustand der physischen Schnittstelle mit Core-Blick von "Up" zu "Down" wechselt:

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

• Alle Layer-2-Großhandelssitzungen, 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 muss abgemeldet werden. Ob eine Sitzung abgemeldet wird, hängt vom ANCP-Timer für Nachbarschaftsverluste ab. Der Timer wird ausgeführt, wenn der ANCP-Agent den Zustandsübergang in "Inaktiv" erkennt. Der Abonnent verwendet weiterhin die ursprüngliche Sitzung, wenn alle drei der folgenden Bedingungen vor Ablauf des Timers erfüllt sind:

  1. Die physische Schnittstelle wird wieder aktiviert.

  2. Die ANCP-Nachbarschaft wird 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 Clientsitzungen.

  4. Entfernt die logische Schnittstelle des dynamischen VLAN.

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

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

  2. Für jede Sitzung wird versucht, eine Anmeldesequenz durchzuführen, einschließlich Authentifizierung, Erstellung dynamischer logischer VLAN-Schnittstellen, Aktivierung beliebiger Services und Senden von RADIUS Accounting-Start-Nachrichten für die Dienst- und Clientsitzungen.

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

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

  Wenn alle verfügbaren Verbindungen genutzt sind, wenn keine VLAN-Tags mehr aus den konfigurierten inneren VLAN-ID-Swap-Bereichen verfügbar sind, wird aufgrund erfolgreicher Wiederverbindungen kein Versuch unternommen, eine Verbindung zu den verbleibenden Layer-2-Großhandelssitzungen herzustellen. 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 beendet, der Sitzungseintrag wird aus der SDB entfernt, und die entsprechende Zugriffsleitung wird auf den Status "Ausstehend" 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. Dies kann beispielsweise durch eine Konfigurationsänderung geschehen, die entweder den inneren VLAN-ID-Swap-Bereich für eine oder mehrere verbleibende physische Core-Schnittstellen vergrößert oder neue physische Core-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 zum Core gerichteten physischen Schnittstelle

Das folgende Verhalten ergibt sich, wenn der Zustand der physischen Schnittstelle für den Core von "Down" in "Up" übergeht:

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

• Der ANCP-Agent benachrichtigt den Autokonfigurations-Daemon (autoconfd), der versucht, die Layer-2-Großhandelssitzungen, 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 beliebiger Services und das Senden von RADIUS Accounting-Start-Nachrichten für die Dienst- und Clientsitzungen.

• Ausstehende Sitzungen werden so lange wiederhergestellt, bis keine mehr übrig sind oder ein Fehler auftritt, der in der Regel auf die Erschöpfung der inneren VLAN-Tags aus den Auslagerungsbereichen auf der Schnittstelle zurückzuführen ist. Im letzteren Fall werden die Sitzungen abgemeldet, der Sitzungseintrag wird aus der SDB entfernt, und die Zugriffsleitung wird auf den Status "Ausstehend" 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-Swap-Bereich für eine oder mehrere verbleibende physische Core-Schnittstellen vergrößert oder neue physische Core-Schnittstellen hinzufügt. Die neu hinzugefügte physische Schnittstelle muss sich im Status "Up" befinden, um Layer 2-Großhandelssitzungen annehmen zu können.

• Eine von RADIUS initiierte Trennung wird empfangen, wenn eine vorhandene Layer-2-Großhandelssitzung, die dieser Routing-Instanz zugewiesen ist, abgemeldet wird (nur Trennung). Bei einer Trennung der Verbindung mit einem Qualifizierer für die erneute Verbindung erhält die betroffene Sitzung Vorrang bei der Wiederherstellung der Verbindung über ausstehende Zugriffsleitungen.

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

Verlust der ANCP-TCP-Nachbarschaft

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

• Der Zugangsknoten handelt die Verbindung neu aus. z. B. durch den Verlust der Synchronisation. Die Neuverhandlung löst den Wechsel des lokalen Zustands von etabliert zu nicht etabliert aus. Der Status wechselt wieder in den Status "Etabliert", wenn die Sitzung erfolgreich neu ausgehandelt wurde.

• Auf dem Socket wird eine EOF-Meldung (End-of-File) 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 als 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 Portdown-Nachricht erhalten. Der Agent benachrichtigt autoconfd, das die folgenden Aktionen ausführt:

• Meldet alle Layer 2-Großhandelssitzungen ab, die durch diese ANCP-Verbindung ausgelöst wurden.

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

• Entfernt die logische Schnittstelle des dynamischen VLAN.

Wenn sich die zugewiesene zugriffs- oder Core-seitige physische Schnittstelle im Status "Down" befindet, können alle ausstehenden Sitzungen, die von dieser ANCP-Verbindung ausgelöst wurden, nicht wiederhergestellt werden, wenn die Schnittstelle wieder in den Up-Zustand versetzt wird.

Dynamische, konventionell automatische VLAN-Schnittstellen, wie sie PPPoE-Sitzungen unterstützen, sind durch den Verlust der TCP-Nachbarschaft nicht betroffen.

Wenn die Nachbarschaft wiederhergestellt wird, ist das erwartete Verhalten eine vollständige Wiederholung der Meldungen "Port down" und "Port up" für alle zugeordneten konfigurierten Zugriffsleitungen. Die Layer 2-Großhandelssitzungen, für die der ANCP-Agent Port-Up-Nachrichten empfängt, werden neu eingerichtet.

Sie können die Auswirkungen kurzfristiger Nachbarschaftsverluste abmildern, indem Sie eine Haltezeit für Nachbarschaftsverluste konfigurieren. Der Timer startet, wenn die Nachbarschaft unterbrochen wird. Auch wenn die Nachbarschaft unterbrochen wird, werden etablierte Sitzungen aufrechterhalten, während der Timer läuft, es sei denn, es wird eine Port Down-Nachricht 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-Down-Nachricht für die Leitung erhalten. Der ANCP-Agent benachrichtigt autoconfd, das die folgenden Aktionen ausführt:

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

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

• Entfernt die logische Schnittstelle des dynamischen VLAN.

Port-Up-Nachrichten, die nach Ablauf des Timers empfangen werden, füllen Sie die SDB-Zugriffsleitungstabelle erneut auf und richten Sie die Layer-2-Großhandelssitzungen wieder her

Der Timer für das Halten von Nachbarschaftsverlusten dient den folgenden Zwecken:

• Dämpft die Auswirkungen von Nachbarschaftsverlusten von kurzer Dauer, wodurch bestehende Layer 2-Großhandelssitzungen aufrechterhalten werden.

• Erkennt das Entfernen einer Zugriffsleitungskonfiguration auf dem Zugriffsknoten. Unter bestimmten Umständen kann es z. B. sinnvoll sein, die Konfiguration einer Zugriffsleitung auf einem Nachbarn zu entfernen. Sie trennen zunächst 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ßhandelssitzung aus.