L2TP LAC Tunneling für Anwender

Übersicht über die LAC-Tunnelauswahl

Wenn sich ein Benutzer bei einer Domäne anmeldet, kontaktiert der PPP-Client die LAC und stellt eine Verbindung her. Die LAC muss ein Ziel in der Domäne und einen Tunnel finden, der es erreichen kann. Die Zuordnung zwischen Zielen, Tunneln und Domänen wird durch ein Tunnel-Profil entweder in einer Domänenzuordnung im Zugriffsprofil des Anwenders oder im Tunnelgruppenattribut (VSA 26-64) bereitgestellt, das von einem RADIUS-Server empfangen wird. Das Attribut "RADIUS" hat Vorrang vor einem in einer Domänenzuordnung angegebenen Profil. Das Tunnel-Profil enthält eine Liste von Tunneln. Jeder Tunnel ist einer Ziel-IP-Adresse und einer Tunnel-Präferenzebene zugeordnet.

Mit L2TP können Sie Folgendes angeben:

Bis zu 31 Ziele für eine Domain.
Bis zu acht Ebenen der Tunnel-Präferenz. Die Einstellungsebene bestimmt die Reihenfolge, in der die LAC versucht, einen bestehenden Tunnel zu einem Ziel in der angeforderten Domäne des Benutzers zu verwenden (oder einen neuen einzurichten).

Hinweis:
Null (0) ist die höchste Präferenzstufe; Dies ist die am meisten bevorzugte Stufe.

Wenn beide Tunnel gültige Ziele innerhalb einer Domäne erreichen, wählt der LAC zuerst den Tunnel mit der höchsten Präferenzebene aus. Wenn beispielsweise Tunnel A eine Präferenzebene von 1 und Tunnel B eine Präferenzebene von 4 hat, versucht die LAC, zuerst Tunnel A zu verwenden.
Bis zu 31 Ziele für eine einzige Präferenzstufe.

Wenn die LAC feststellt, dass eine PPP-Sitzung getunnelt werden soll, wählt sie einen Tunnel aus der Gruppe von Tunneln aus, die entweder dem PPP-Benutzer oder der Domäne des PPP-Benutzers durch ein Tunnel-Profil zugeordnet sind.

Die Tunnelauswahl wird durch die folgenden Konfigurationen beeinflusst:

Failover zwischen Präferenzebenen: Wenn ein Tunnel zu einem gültigen Ziel innerhalb einer Präferenzebene nicht ausgewählt wird, wird der Auswahlprozess standardmäßig auf die nächste Ebene umgeleitet. das heißt, die LAC fällt auf die nächstniedrigere Ebene ab, um die Suche nach einem geeigneten Tunnel fortzusetzen. Weitere Informationen finden Sie unter Auswahl, wenn ein Failover zwischen Einstellungsstufen konfiguriert ist .
Failover innerhalb einer Präferenzebene: In diesem Fall beschränkt die LAC ihre Versuche, eine Sitzung einzurichten, nicht auf nur einen einzigen Tunnel auf einer Präferenzebene. Wenn der Versuch über den ausgewählten Tunnel fehlschlägt, führt der Auswahlprozess ein Failover innerhalb derselben Ebene durch, indem ein anderer geeigneter Tunnel zu einem gültigen Ziel ausgewählt wird. Der LAC setzt seine Verbindungsversuche innerhalb der Ebene fort, bis auf dieser Ebene keine Tunnel mehr zu einem gültigen Ziel verfügbar sind. Dann fällt der LAC auf die nächstniedrigere Ebene, um die Suche fortzusetzen. Weitere Informationen finden Sie unter Auswahl, wenn ein Failover innerhalb einer Voreinstellungsstufe konfiguriert ist .
Maximale Anzahl von Sitzungen pro Tunnel: Wenn die maximal zulässige Anzahl von Sitzungen pro Tunnel konfiguriert ist, berücksichtigt die LAC diese Einstellung während des Tunnel-Auswahlprozesses. Die maximale Anzahl von Sitzungen pro Tunnel kann über den RADIUS Tunnel-Max-Sessions VSA [26-33] oder durch die Aufnahme der max-sessions Anweisung in ein Tunnel-Profil konfiguriert werden.

Wenn die aktuelle Sitzungsanzahl eines zufällig ausgewählten Tunnels der maximalen Sitzungsanzahl entspricht, versucht die LAC nicht, eine Verbindung zu einem Ziel mit diesem Tunnel herzustellen. Stattdessen wählt es einen alternativen Tunnel aus der Gruppe von Tunneln auf dieser Einstellungsebene aus, die gültige Ziele in der Domäne haben. Wenn auf der aktuellen Präferenzebene keine solchen Tunnel vorhanden sind, wird die LAC auf die nächste Präferenzebene zurückgesetzt, um die Auswahl zu treffen. Dieser Prozess ist konsistent, unabhängig davon, welches Failover-Schema derzeit auf der LAC ausgeführt wird.

Wenn die maximale Anzahl von Sitzungen nicht für einen Tunnel konfiguriert ist, hat dieser Tunnel keine Obergrenze für die Anzahl der Sitzungen, die er unterstützen kann. Standardmäßig ist der maximale Sitzungswert 0 (null), was unbegrenzte Sitzungen im Tunnel zulässt.
Gewichtetes Load Balancing: Diese Balancing-Methode verwendet eine wahrscheinlichkeitsbasierte Auswertung des Tunnel-Gewichts, um Sitzungen auf Tunnel zu verteilen. Die LAC wählt Tunnel weiterhin nach dem Zufallsprinzip innerhalb einer Präferenzebene aus, aber im Durchschnitt werden die Sitzungen im Verhältnis zum Gewicht der Tunnel auf die Tunnel verteilt. Das Gewicht eines Tunnels wird durch das maximale Sitzungslimit des Tunnels und die maximalen Sitzungslimits der anderen Tunnel auf derselben Präferenzebene bestimmt. Weitere Informationen finden Sie unter Gewichtetes Load Balancing .
Destination-equal Load Balancing: Diese Sitzungsausgleichsmethode wertet Tunnel entsprechend der Anzahl der Sitzungen zum Ziel und der Anzahl der vom Tunnel übertragenen Sitzungen aus, um die Sitzungslast gleichmäßig auf alle Tunnel zu verteilen. Der Tunnel mit einem Ziel mit der niedrigsten Sitzungsanzahl wird als am wenigsten ausgelastet eingestuft. Dieser Prozess wird in Tunneln mit der höchsten verfügbaren Präferenzebene durchgeführt. Weitere Informationen finden Sie unter Destination-Equal Load Balancing .

Berücksichtigen Sie die folgenden Informationen, um den Tunnel- und Zielauswahlprozess und das Failover zu verstehen:

Möglicherweise können mehrere Tunnel ein Ziel erreichen, und diese Tunnel können dieselbe oder unterschiedliche Präferenzebenen haben.
Der Tunnel, der zum Einrichten der Anwender-Sitzung ausgewählt wurde, kann selbst bereits eingerichtet sein. was bedeutet, dass er derzeit aktive Sitzungen hat. Alternativ muss die LAC möglicherweise einen neuen Tunnel zum Ziel einrichten, wenn noch kein Tunnel eingerichtet wurde, der das Ziel erreichen kann.
Ein gültiges Ziel erfüllt die folgenden Kriterien:
- Er ist über einen Tunnel erreichbar, der sein maximales Sitzungslimit noch nicht erreicht hat.
- Es wurde noch nicht für die aktuelle Anmeldeanfrage des Anwenders kontaktiert.
- Es kann entweder gesperrt oder entsperrt werden.
Ein gesperrtes Ziel ist ein Ziel, für das der Zielsperrzeitgeber ausgeführt wird. Gesperrte Ziele werden auf eine Sperrliste gesetzt, bis der Timer abläuft oder gelöscht wird (Zurücksetzen auf Null). Die Ziele auf der Liste können nicht kontaktiert werden, um eine Sitzung einzurichten.
Ein entsperrtes Ziel ist ein Ziel, für das der Zielsperrtimer Null ist.
Wenn die LAC gültige Ziele erkennt, die gesperrt sind, platziert sie sie in der Liste DestinationsLockedNotContacted, die sich von der Sperrliste unterscheidet, die alle gesperrten Ziele enthält. Die Liste DestinationsLockedNotContacted enthält nur gesperrte Ziele, die die LAC noch nicht für die aktuelle, laufende Anmeldung des Anwenders kontaktiert hat. Die Liste DestinationsLockedNotContacted enthält keine Ziele, die die LAC sperrt, nachdem versucht wurde, eine Verbindung herzustellen, und dies fehlgeschlagen ist.
Sie können den clear services l2tp destination lockout Befehl verwenden, um alle gesperrten Ziele oder nur gesperrte Ziele, die mit der angegebenen lokalen oder Remote-Gateway-Adresse übereinstimmen, manuell zu löschen. Sie können den Befehl verwenden, wenn Sie z. B. ein bestimmtes Ziel löschen möchten, damit es innerhalb einer Einstellungsebene Priorität erhält.
Das Failover-Verhalten, das Teil des Tunnel-Auswahlprozesses ist, gilt nur, wenn das Ziel aus einem der folgenden Gründe nicht erreichbar ist:
- Das LNS gibt nach der maximalen Anzahl von Neuübertragungsversuchen keine SCCRP-Nachricht als Antwort auf die SCCRQ-Nachricht von der LAC zurück.
- Der Tunnel wird eingerichtet, aber das LNS gibt nach der maximalen Anzahl von Neuübertragungsversuchen keine ICRP-Nachricht als Antwort auf das ICRQ von der LAC zurück.
Dieses Failover-Verhalten gilt nicht unter den folgenden Umständen:
- Der Client beendet die Verbindung.
- Der Tunnel wird eingerichtet, aber der LNS sendet eine CDN-Nachricht, während der LAC versucht, die Sitzung mit dem LNS aufzubauen, was dazu führt, dass der Anmeldeversuch des Anwenders fehlschlägt.

Auswahl, wenn ein Failover zwischen den Einstellungsebenen konfiguriert ist
Auswahl, wenn ein Failover innerhalb einer Voreinstellungsebene konfiguriert ist
Auswahl bei Verteilung der Sitzungslast auf mehrere LNS

Auswahl, wenn ein Failover zwischen den Einstellungsebenen konfiguriert ist

Wenn ein Benutzer versucht, sich in einer Standardkonfiguration bei einer Domäne anzumelden, d. h. wenn Failover innerhalb einer Einstellungsebene und Load Balancing nicht konfiguriert sind, sucht die LAC nach gültigen Zielen für die angeforderte Domäne, beginnend mit der höchsten Tunnel-Einstellungsebene. Wenn kein gültiges Ziel gefunden wird oder der Versuch, eine Verbindung zu einem Ziel herzustellen, fehlschlägt, wird die LAC auf die nächstniedrigere Ebene heruntergesetzt, um die Suche fortzusetzen. Der Suchprozess ist für alle Ebenen gleich, mit Ausnahme der niedrigsten:

Die Suche beginnt mit der Identifizierung von Tunneln mit gültigen Zielen auf Präferenzebene aus allen Tunneln, die im Tunnel-Profil der Domäne angegeben sind.
Alle gesperrten, gültigen Ziele werden in die Liste DestinationsLockedNotContacted aufgenommen. Es wird kein Versuch unternommen, eines dieser Ziele zu kontaktieren.
Aus den freigeschalteten, gültigen Zielen wählt die LAC nach dem Zufallsprinzip eines aus und versucht, sich über den zugehörigen Tunnel zu verbinden. Wenn der Tunnel keine aktuellen Sitzungen hat, muss die LAC den Tunnel einrichten.

Hinweis:
Die Zufallsauswahl ist das Standardverhalten. Das Verhalten unterscheidet sich, wenn gewichtetes Load Balancing oder zielgleiches Load Balancing konfiguriert ist. Informationen zum Load Balancing finden Sie unter Auswahl beim Verteilen der Sitzungslast auf mehrere LNSs .
- Wenn der Versuch erfolgreich ist, meldet die LAC die erfolgreiche Anmeldung an den PPP-Client. Der LAC löscht auch alle Ziele in der Liste DestinationsLockedNotContacted.
- Wenn der LAC keine Antwort erhält, wird der Versuch bis zur maximalen Anzahl von Wiederholungen wiederholt. Wenn der LAC die Wiederholungen ausschöpft, ohne eine Antwort zu erhalten, wird der Versuch als erfolglos betrachtet, und der LAC markiert das Ziel als unerreichbar, indem er das Ziel sperrt. Es platziert das Ziel auf der Sperrliste und startet den Zielsperrzeitgeber.
Was die LAC als nächstes tut, hängt von der aktuellen Präferenzebene ab.
- Wenn es sich nicht um die niedrigste Präferenzebene handelt, fällt die LAC auf die nächstniedrigere Präferenzebene und setzt den Suchvorgang fort.
- Wenn es sich um die niedrigste Präferenzebene handelt und die Liste DestinationsLockedNotContacted nicht leer ist, entsperrt der LAC alle Ziele in der Liste DestinationsLockedNotContacted und springt zurück zur höchsten Präferenzebene und startet den Suchprozess neu.
- Wenn es sich um die niedrigste Präferenzebene handelt und die Liste DestinationsLockedNotContacted leer ist, was bedeutet, dass alle gültigen Ziele versucht wurden, meldet die LAC eine fehlgeschlagene Anmeldung an den PPP-Client.
Wenn die gültigen Ziele auf einer Ebene alle gesperrt sind, hängt die nächste Aktion der LAC von der aktuellen Präferenzebene ab.
- Wenn es sich nicht um die niedrigste Präferenzebene handelt, fällt die LAC auf die nächstniedrigere Präferenzebene und setzt den Suchvorgang fort.
- Wenn es sich um die niedrigste Präferenzebene handelt, wählt die LAC das gesperrte, gültige Ziel mit der kürzesten verbleibenden Sperrzeit aus. Es löscht den Sperrtimer und versucht, eine Verbindung zum Ziel herzustellen und eine Sitzung aufzubauen.
  - Wenn der Versuch erfolgreich ist, meldet die LAC die erfolgreiche Anmeldung an den PPP-Client.
  - Wenn der Versuch fehlschlägt und die Liste DestinationsLockedNotContacted leer ist, was bedeutet, dass alle gültigen Ziele versucht wurden, meldet die LAC eine fehlgeschlagene Anmeldung an den PPP-Client.
  - Wenn der Versuch fehlschlägt und die Liste DestinationsLockedNotContacted nicht leer ist, entsperrt der LAC alle Ziele in der Liste DestinationsLockedNotContacted, springt zurück zur höchsten Einstellungsebene und startet den Suchvorgang neu.
Wenn keine gültigen Ziele vorhanden sind, hängt das weitere Vorgehen der LAC von der aktuellen Präferenzstufe ab.
- Wenn es sich nicht um die niedrigste Präferenzebene handelt, fällt die LAC auf die nächstniedrigere Präferenzebene und setzt den Suchvorgang fort.
- Wenn es sich um die niedrigste Präferenzebene handelt und die Liste DestinationsLockedNotContacted leer ist, was bedeutet, dass alle gültigen Ziele versucht wurden, meldet die LAC eine fehlgeschlagene Anmeldung an den PPP-Client.
- Wenn es sich um die niedrigste Einstellungsebene handelt und die Liste "DestinationsLockedNotContacted" nicht leer ist, entsperrt die LAC alle Ziele in der Liste "DestinationsLockedNotContacted", springt zurück zur höchsten Einstellungsebene und startet den Prozess neu.
Der Such- und Failoverprozess durchläuft die Ebenen, bis entweder eine Sitzung eingerichtet wird oder alle gültigen Ziele versucht wurden – keine Ziele mehr in der Liste DestinationsLockedNotContacted verbleiben – und die Anmeldung fehlschlägt.

Abbildung 1 veranschaulicht die möglichen Bedingungen und Entscheidungspunkte, die die Auswahl eines Ziels und des entsprechenden Tunnels für den Standardfall bestimmen, in dem das Failover zwischen den Tunnel-Präferenzebenen erfolgt.

Abbildung 1: Ziel- und Tunnelauswahlprozess mit Failover zwischen den Einstellungsebenen Flowchart of a PPP client logging into a domain outlining steps for selecting destinations, checking validity, and establishing sessions, with conditions for successful or failed logins.

Flowchart of a PPP client logging into a domain outlining steps for selecting destinations, checking validity, and establishing sessions, with conditions for successful or failed logins.

Angenommen, das Tunnel-Profil enthält die folgenden Tunnel mit jeweils einem gültigen Ziel:

Präferenz 0, Tunnel 1, 192.168.10.10
Präferenz 1, Tunnel 2, 192.168.22.22
Präferenz 1, Tunnel 3, 192.168.33.33
Präferenz 2, Tunnel 4, 192.168.44.44

Failover innerhalb der Einstellungen und Load Balancing sind nicht konfiguriert.

Wenn ein PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Auf der höchsten Präferenzebene 0 wählt der LAC Tunnel 1 aus, da dies der einzige Tunnel in der Ebene mit einem gültigen Ziel ist. Die LAC versucht, 192.168.10.10 zu erreichen.
Dieser Verbindungsversuch schlägt fehl, sodass die LAC 192.168.10.10 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Die LAC wird auf die nächste Ebene, die Präferenzebene 1, verschoben, um ein Ziel für die Domäne zu erreichen. Die LAC wählt nach dem Zufallsprinzip zwischen 192.168.22.22 durch Tunnel 2 und 192.168.33.33 durch Tunnel 3 aus. Es wählt 192.168.22.22 aus und versucht, eine Verbindung über Tunnel 2 herzustellen.
Der Verbindungsversuch zu 192.168.22.22 schlägt fehl, sodass die LAC 192.168.22.22 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.

Hinweis:
Obwohl Tunnel 3 über ein entsperrtes, gültiges Ziel verfügt, kann die LAC diesen Tunnel jetzt nicht so auswählen, dass er 192.168.33.33 erreicht, da die LAC jedes Mal nur einen Versuch unternehmen kann, ein gültiges Ziel zu erreichen, wenn sie in einer Ebene sucht, wenn die Failover-Methode zwischen den Einstellungsebenen liegt.
Die LAC fällt in diesem Beispiel auf die letzte (niedrigste) Ebene, die Präferenzstufe 2. Der LAC wählt Tunnel 4 aus, weil es der einzige Tunnel in der Ebene mit einem gültigen Ziel ist. Die LAC versucht, 192.168.44.44 zu erreichen.
Der Verbindungsversuch zu 192.168.44.44 schlägt ebenfalls fehl, sodass die LAC 192.168.44.44 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Da dies die niedrigste Ebene ist und die Liste DestinationsLockedNotContacted leer ist, lehnt der LAC die Anmeldeanforderung vom PPP-Client ab.

Die Ziele 192.168.10.10, 192.168.22.22 und 192.168.44.44 wurden gesperrt, aber nicht zur Liste "DestinationsLockedNotContacted" hinzugefügt, da die LAC sie nach dem Verbindungsversuch gesperrt hat. Ziel 192.168.33.33 wurde nicht kontaktiert, aber nicht zur Liste "DestinationsLockedNotContacted" hinzugefügt, da es nicht gesperrt ist.
Der Client versucht, sich erneut anzumelden, und die LAC wiederholt den Tunnel-Auswahlprozess, beginnt bei Präferenzebene 0 von vorne, um nach einem entsperrten, gültigen Ziel zu suchen, und durchläuft die Ebenen nach Bedarf.
Auf Präferenzebene 0 ist 192.168.10.10 das einzig gültige Ziel und immer noch gesperrt, sodass der LAC nicht versuchen kann, eine Verbindung zum Ziel herzustellen. Der LAC fügt der Liste "DestinationsLockedNotContacted" 192.168.10.10 hinzu und fällt dann auf die Präferenzebene 1.

Hinweis:
Denken Sie daran, dass der Timer für die Zielsperre global gilt, sodass er über mehrere Anmeldungen von Anwendern hinweg bestehen bleibt. Die Liste DestinationsLockedNotContacted gilt nur für eine bestimmte Anmeldung eines Anwenders und bleibt nicht erhalten. Obwohl die LAC 192.168.10.10 für diesen Anwender kontaktiert hat, war dies bei einem früheren Anmeldeversuch. Bei diesem Anmeldeversuch kann es das Ziel aufgrund der Sperre nicht kontaktieren und setzt das Ziel folglich auf die Liste DestinationsLockedNotContacted.
Auf Präferenzebene 1 ist 192.168.22.22 immer noch gesperrt, sodass der LAC 192.168.22.22 zur Liste DestinationsLockedNotContacted hinzufügt. 192.168.33.33 ist noch verfügbar. Die LAC versucht, über Tunnel 3 eine Verbindung zu 192.168.33.33 herzustellen.
Dieser Verbindungsversuch schlägt fehl, sodass die LAC 192.168.33.33 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist. Die LAC fällt auf Präferenzstufe 2.
192.168.44.44 ist immer noch gesperrt, daher fügt die LAC 192.168.44.44 zur Liste "DestinationsLockedNotContacted" hinzu.
Dies ist die niedrigste Einstellungsebene, aber dieses Mal ist die Liste DestinationsLockedNotContacted nicht leer. Es enthält 192.168.10.10, 192.168.22.22 und 192.168.44.44. Der LAC entsperrt alle Ziele in der Liste DestinationsLockedNotContacted und springt dann zurück zur höchsten Einstellungsebene.
Auf der Präferenzebene 0 versucht die LAC, eine Verbindung zu 192.168.10.10 herzustellen, da sie entsperrt wurde. Die LAC richtet die Sitzung ein und meldet die erfolgreiche Anmeldung an den PPP-Client.

Obwohl die LAC nicht versucht, ein ausgesperrtes Ziel zu kontaktieren, gibt es einen Sonderfall, wenn die LAC die niedrigste Präferenzstufe erreicht hat. Das Level muss mehr als ein gültiges Ziel haben und alle müssen gesperrt sein. Angenommen, das Tunnel-Profil enthält die folgenden Tunnel mit jeweils einem gültigen Ziel:

Präferenz 0, Tunnel 1, 192.168.10.10
Präferenz 1, Tunnel 2, 192.168.22.22. Das Ziel ist gesperrt, wobei der Sperr-Timer derzeit bei 245 Sekunden liegt.
Präferenz 1, Tunnel 3, 192.168.33.33. Das Ziel ist gesperrt, wobei der Sperrtimer derzeit bei 180 Sekunden liegt.

Failover innerhalb der Einstellungen und Load Balancing sind nicht konfiguriert.

Wenn ein PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Auf der höchsten Präferenzebene 0 wählt der LAC Tunnel 1 aus, da dies der einzige Tunnel in der Ebene mit einem gültigen Ziel ist. Die LAC versucht, 192.168.10.10 zu erreichen.
Dieser Verbindungsversuch schlägt fehl, sodass die LAC 192.168.10.10 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Die LAC fällt auf die nächste Ebene, die Präferenzebene 1, um ein Ziel für die Domäne zu erreichen. Beide gültigen Ziele auf dieser Ebene, 192.168.22.22 und 192.168.33.33, sind gesperrt.
Der LAC fügt beide Ziele der Liste DestinationsLockedNotContacted hinzu.
Da dies die niedrigste Präferenzstufe ist, bestimmt die LAC, welches Ziel eine kürzere verbleibende Sperrzeit hat. Es wählt 192.168.33.33 aus, weil es eine kürzere verbleibende Sperrzeit (180 Sekunden) als 192.168.22.22 (245 Sekunden) hat. Die LAC entsperrt 192.168.33.33 und versucht, über Tunnel 3 eine Verbindung herzustellen. Infolgedessen entfernt die LAC auch 192.168.33.33 aus der DestinationsLockedNotContacted-Liste.
Der Verbindungsversuch ist erfolgreich, und es wird eine Sitzung zu 192.168.33.33 eingerichtet. Die LAC meldet eine erfolgreiche Anmeldung an den PPP-Client.

Auswahl, wenn ein Failover innerhalb einer Voreinstellungsebene konfiguriert ist

Wenn Sie das Failover innerhalb einer Einstellungsebene konfigurieren, ist der Ziel- und Tunnelauswahlprozess derselbe wie bei der Standardkonfiguration, mit einer Ausnahme: Die LAC ist nicht auf nur einen Verbindungsversuch auf einer Einstellungsebene beschränkt.

Wenn die LAC versucht, eine Verbindung zu einem entsperrten, gültigen Ziel herzustellen und dies nicht erfolgreich ist, sperrt sie dieses Ziel, wird aber nicht sofort auf die nächstniedrigere Ebene heruntergesetzt. Wenn stattdessen ein anderes entsperrtes, gültiges Ziel auf derselben Präferenzebene verfügbar ist, versucht die LAC, eine Verbindung zu diesem Ziel herzustellen.

Wenn die LAC keine Verbindung herstellt, versucht sie weiterhin, ein Ziel innerhalb dieser Präferenzebene zu erreichen, bis keine entsperrten, gültigen Ziele mehr versucht werden können. An diesem Punkt fällt die LAC nach unten, um auf der nächstniedrigeren Präferenzebene zu suchen. Auf jeder Ebene sucht die LAC nach einem gültigen Ziel und versucht, eine Verbindung zu diesem herzustellen, bis keine freigeschalteten, gültigen Ziele verfügbar sind.

Wenn die LAC auf die niedrigste Einstellungsebene herunterfällt und keine entsperrten, gültigen Ziele findet, hängt das Verhalten von der Liste DestinationsLockedNotContacted ab:

Wenn die Liste DestinationsLockedNotContacted nicht leer ist, entsperrt die LAC alle Ziele in der Liste DestinationsLockedNotContacted und springt zurück zur höchsten Einstellungsebene und startet den Suchprozess neu.
Wenn DestinationsLockedNotContacted leer ist, was bedeutet, dass alle gültigen Ziele versucht wurden, meldet die LAC eine fehlgeschlagene Anmeldung an den PPP-Client.

Angenommen, das Tunnel-Profil gibt die folgenden Tunnel und Ziele an. Load Balancing ist nicht konfiguriert. Alle Ziele sind gültig; alle außer 192.168.3.3 sind freigeschaltet. Die Präferenzebenen für die Tunnel werden wie folgt zugewiesen:

Einstellung 0, Tunnel 1, 192.168.1.1, entsperrt
Einstellung 0, Tunnel 2, 192.168.2.2, entsperrt
Präferenz 0, Tunnel 3, 192.168.3.3, Sperr-Timer 100 Sekunden
Preference 1, Tunnel 4, 192.168.4.4, entsperrt
Einstellung 1, Tunnel 5, 192.168.5.5, entsperrt

Wenn in diesem Beispiel ein PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Die LAC wählt nach dem Zufallsprinzip zwischen den beiden freigeschalteten, gültigen Zielen auf Präferenzebene 0 aus, 192.168.1.1 durch Tunnel 1 und 192.168.2.2 durch Tunnel 2. Es wählt 192.168.2.2 und versucht, eine Verbindung über Tunnel 2 herzustellen.
Der Verbindungsversuch zu 192.168.2.2 schlägt fehl, sodass der LAC 192.168.2.2 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Der LAC versucht dann, über Tunnel 1 auf Präferenzebene 0 eine Verbindung zu 192.168.1.1 herzustellen.
Der Verbindungsversuch zu 192.168.1.1 schlägt fehl, sodass der LAC 192.168.1.1 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
192.168.3.3 durch Tunnel 3 ist das einzig verbleibende gültige Ziel auf Präferenzstufe 0, aber es ist gesperrt. Die LAC fügt der Liste "DestinationsLockedNotContacted" 192.168.3.3 hinzu. Die LAC fügte 192.168.1.1 und 192.168.2.2 nicht zur Liste "DestinationsLockedNotContacted" hinzu, da sie nach dem Versuch, sie zu kontaktieren, ausgesperrt wurde.
Da Ebene 0 keine freigeschalteten, gültigen Ziele mehr hat, fällt die LAC auf die nächste Ebene, die Präferenzebene 1, um ein Ziel für die Domäne zu erreichen.
Auf Präferenzebene 1 wählt der LAC nach dem Zufallsprinzip 192.168.4.4 aus und versucht, eine Verbindung über Tunnel 4 herzustellen.
Der Verbindungsversuch zu 192.168.4.4 schlägt fehl, sodass die LAC 192.168.4.4 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Die LAC versucht dann, über Tunnel 5 auf Präferenzebene 1 eine Verbindung zu 192.168.5.5 herzustellen.
Der Verbindungsversuch zu 192.168.5.5 schlägt fehl, sodass die LAC 192.168.5.5 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist. Level 1 hat keine freigeschalteten, gültigen Ziele mehr. Da die Liste "DestinationsLockedNotReached" nicht leer ist, entsperrt der LAC alle Ziele in der Liste – in diesem Fall 192.168.3.3 – und springt zurück zur höchsten Einstellungsebene 0.
192.168.3.3 ist jetzt das einzige entsperrte Ziel auf Präferenzebene 0, sodass die LAC versucht, über Tunnel 3 eine Verbindung herzustellen.
Der Verbindungsversuch zu 192.168.3.3 schlägt fehl, sodass der LAC 192.168.3.3 sperrt. Sie wird bei diesem Anmeldeversuch nicht erneut berücksichtigt und kann erst dann für Anmeldeversuche berücksichtigt werden, wenn der Timer für die Zielsperre abgelaufen ist.
Da Level 0 keine freigeschalteten, gültigen Ziele mehr hat, fällt die LAC auf die nächste Ebene, Präferenzlevel 1.
Präferenzebene 1 hat keine freigeschalteten, gültigen Ziele. DestinationsLockedNotContacted ist leer, da die LAC alle gültigen Ziele auf beiden Präferenzebenen kontaktiert hat. Die LAC lehnt die Anmeldeanforderung des PPP-Clients ab.

Auswahl bei Verteilung der Sitzungslast auf mehrere LNS

Auf der LAC können mehrere Tunnel-Profile konfiguriert werden. Einige Tunnel teilen sich möglicherweise Ziele. Wenn die LAC die Sitzung für einen PPP-Anwender auf das LNS tunnelt, muss ein Tunnel für die Anwender-Sitzung ausgewählt werden. Der Tunnel-Auswahlprozess wählt einen Tunnel mit der höchsten Präferenz aus, der ein erreichbares Ziel hat. Standardmäßig wählt die LAC einen Tunnel nach dem Zufallsprinzip aus mehreren Tunneln aus, die dieselben Kriterien erfüllen. Alternativ können Sie das Load Balancing konfigurieren, um verschiedene Auswahloptionen zu aktivieren. Beide Lastausgleichsmethoden wirken sich darauf aus, welche Tunnel und Ziele die LAC auswählt, aber ansonsten bleibt der Auswahl- und Failoverprozess gleich.

Hinweis:

Gewichtetes Load Balancing und zielgleiches Load Balancing schließen sich gegenseitig aus. Sie können nur das eine oder das andere aktivieren.

Gewichtetes Load Balancing
Zielgleiches Load Balancing

Gewichtetes Load Balancing

Beim gewichteten Load Balancing werden Tunnel nach ihrem Gewicht bewertet. Das Gewicht eines Tunnels wird durch das maximale Sitzungslimit des Tunnels und die maximalen Sitzungslimits der anderen Tunnel auf derselben Präferenzebene bestimmt. Der Tunnel mit dem höchsten maximalen Sitzungslimit hat das höchste Gewicht in dieser Präferenzstufe. Der Tunnel mit dem nächsthöheren maximalen Sitzungslimit hat das nächsthöhere Gewicht usw. Der Tunnel mit dem niedrigsten maximalen Sitzungslimit hat das niedrigste Gewicht.

Hinweis:

Die Tunnelauswahl und die Sitzungsverteilung sind wahrscheinlichkeitsbasiert. Die Last wird nicht streng nach Gewicht verteilt.

Wenn Sie gewichtetes Load Balancing konfigurieren, wählt der LAC weiterhin Tunnel nach dem Zufallsprinzip innerhalb einer Präferenzebene aus, aber im Durchschnitt werden die Sitzungen im Verhältnis zur Gewichtung der Tunnel auf Tunnel verteilt.

Beim gewichteten Load Balancing generiert der LAC eine Zufallszahl innerhalb eines Bereichs, der der Summe aller Sitzungslimits für alle Tunnel in der Präferenzstufe entspricht. Er ordnet einen Teil des Bereichs – einen Pool von Zahlen – jedem Tunnel proportional zum Gewicht des Tunnels zu. Ein Tunnel mit einem höheren Gewicht ist mit einem größeren Teil des Bereichs – einem größeren Pool – verbunden als ein Tunnel mit einem geringeren Gewicht. Ein Tunnel 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 ein Tunnel mit einem höheren Gewicht (größerer Pool) eher ausgewählt wird als ein Tunnel mit einem niedrigeren Gewicht (kleinerer Pool).

Betrachten Sie beispielsweise eine Einstellungsebene mit nur zwei Tunneln, 1 und 2. Tunnel 1 hat ein maximales Limit von 1000 Sitzungen und Tunnel 2 ein Limit von 2000 Sitzungen, was insgesamt 3000 Sitzungen ergibt. Der LAC generiert eine Zufallszahl aus einem Pool von 3000 im Bereich von 0 bis 2999. Ein Pool von 1000 Zahlen, der Teil des Bereichs von 0 bis 999, ist Tunnel 1 zugeordnet. Ein Pool von 2000 Zahlen, der Teil des Bereichs von 1000 bis 2999, ist mit Tunnel 2 verbunden.

Wenn die generierte Zahl kleiner als 1000 ist, wird Tunnel 1 ausgewählt, obwohl er ein niedrigeres Gewicht (1000) als Tunnel 2 (2000) hat.
Wenn die generierte Zahl 1000 oder größer ist, wird Tunnel 2 ausgewählt.

Da der Pool der möglichen generierten Zahlen für Tunnel 2 (2000) doppelt so groß ist wie für Tunnel 1 (1000), wird Tunnel 2 im Durchschnitt doppelt so oft ausgewählt wie Tunnel 1.

Zielgleiches Load Balancing

Beim Destination-Equal Load Balancing werden Tunnel nach der Anzahl der Sitzungen zum Ziel und der Anzahl der vom Tunnel übertragenen Sitzungen ausgewertet, um die Sitzungslast gleichmäßig auf alle Tunnel zu verteilen. Der Tunnel mit einem Ziel mit der niedrigsten Sitzungsanzahl gilt als Tunnel mit der geringsten Last. Dieser Prozess wird mit Tunneln auf der höchsten verfügbaren Präferenzebene ausgeführt und verwendet die folgenden Richtlinien:

Wenn jeder Tunnel zu einem separaten Ziel führt und nur ein Ziel die niedrigste Sitzungsanzahl unter allen Zielen aufweist, wählt die LAC den Tunnel zu diesem Ziel aus.
Wenn jeder Tunnel zu einem separaten Ziel führt und mehr als ein Ziel die gleiche niedrigste Sitzungsanzahl aufweist, wählt die LAC nach dem Zufallsprinzip einen Tunnel aus den Tunneln zu diesen Zielen aus.
Wenn mehr als ein Tunnel zum selben Ziel führt und dieses Ziel die niedrigste Anzahl von Zielsitzungen aufweist, wählt die LAC aus diesen Tunneln denjenigen mit der niedrigsten Gesamtzahl von Tunnel-Sitzungen aus. Wenn die Anzahl der Tunnel-Sitzungen für alle diese Tunnel gleich ist, wählt der LAC einen von ihnen nach dem Zufallsprinzip aus.

Betrachten Sie die folgenden Szenarien, um das Verhalten der Tunnelauswahl besser zu verstehen, wenn das zielgleiche Load Balancing aktiviert ist.

In Szenario 1 hat jeder Tunnel ein anderes gültiges Ziel, und es wird nur die Anzahl der Zielsitzungen ausgewertet:

Tunnel 1, Präferenzebene 1, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 2, Präferenzebene 1, 192.168.2.2, Anzahl der Zielsitzungen = 50
Tunnel 3, Präferenzebene 1, 192.168.3.3, Anzahl der Zielsitzungen = 300
Tunnel 4, Präferenzebene 1, 192.168.4.4, Anzahl der Zielsitzungen = 100

Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt der LAC Tunnel 2 aus, da er sich auf der höchsten Präferenzebene 1 befindet und das gültige Ziel B mit der niedrigsten Sitzungsanzahl 50 hat.

Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Tunnel 2 bleibt so lange ausgewählt, bis die Sitzungsanzahl für 192.168.2.2 gleich 100 ist, was der nächstniedrigeren Sitzungsanzahl von 192.168.4.4 in Tunnel 4 entspricht.
Wenn sich der nächste Anwender anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 4 aus, da ihre Ziele die gleiche Anzahl von Sitzungen haben und diese niedriger ist als die für die anderen Ziele.
Unabhängig davon, welcher Tunnel aus diesem Paar ausgewählt wird, beträgt die Sitzungsanzahl für das Ziel jetzt 101. Der andere Tunnel wird ausgewählt, wenn sich der nächste Anwender anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 100 aufweist. Dadurch wird die Anzahl der Zielsitzungen auf 101 erhöht, was dem anderen Tunnel entspricht.
Während sich die Teilnehmer weiterhin anmelden, wiederholt der LAC diesen Vorgang. Dabei wird nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 4 gewählt, wenn die Anzahl der Sitzungen übereinstimmt, und dann der andere Tunnel mit dem nächsten Anwender ausgewählt, bis beide die Anzahl der Zielsitzungen 200 erreichen und damit mit Tunnel 1 übereinstimmen.
Wenn sich der nächste Anwender anmeldet, wählt die LAC jetzt nach dem Zufallsprinzip zwischen Tunnel 1, Tunnel 2 und Tunnel 4 aus, da 192.168.1.1, 192.168.2.2 und 192.168.3.3 alle die gleiche Sitzungsanzahl von 200 haben. Die Anzahl der Zielsitzungen wird für den ausgewählten Tunnel auf 201 erhöht, sodass die LAC für den nächsten Anwender nach dem Zufallsprinzip zwischen den beiden anderen Tunneln auswählt. Jetzt haben zwei Tunnel eine Zielsitzungsanzahl von 201, sodass der LAC den verbleibenden Tunnel für den nächsten Anwender auswählt.
Wenn sich die Abonnenten weiterhin anmelden, wiederholt die LAC diesen Vorgang, indem sie nach dem Zufallsprinzip zwischen Tunnel 1, Tunnel 2 und Tunnel 4 auswählt, wenn ihre Sitzungsanzahl übereinstimmt, zufällig zwischen dem verbleibenden Paar für den nächsten Anwender ausgewählt und dann den verbleibenden Tunnel auswählt, sodass die Anzahl der Zielsitzungen für diese drei Tunnel erneut übereinstimmt. Dieses Muster setzt sich fort, bis die Anzahl der Zielsitzungen für alle drei Tunnel 300 erreicht, was Tunnel 3 entspricht.
Jetzt haben die Ziele für alle vier Tunnel die gleiche Anzahl von Sitzungen. Da es nur vier Tunnel gibt, wird das endgültige Muster festgelegt. Der LAC wählt zuerst nach dem Zufallsprinzip zwischen allen vier Tunneln aus, dann die restlichen drei, dann das verbleibende Paar und wählt schließlich den letzten Tunnel aus. Wenn die Anzahl der Zielsitzungen alle gleich ist, startet der LAC dieses Muster erneut.

In Szenario 2 teilen sich zwei Tunnel dasselbe gültige Ziel. Sowohl die Anzahl der Tunnel-Sitzungen als auch die Anzahl der Zielsitzungen werden ausgewertet:

Tunnel 1, Präferenzebene 1, Anzahl der Tunnel-Sitzungen = 120, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 2, Präferenzebene 1, Anzahl der Tunnel-Sitzungen = 80, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 3, Präferenzebene 1, 192.168.2.2, Anzahl der Zielsitzungen = 300
Tunnel 4, Präferenzebene 2, 192.168.3.3, Anzahl der Zielsitzungen = 100

Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt der LAC zunächst zwischen Zielen aus. Die Tunnel für 192.168.1.1 und 192.168.2.2 entsprechen der Präferenzebene 1. Der LAC wählt 192.168.1.1 aus, da er eine niedrigere Sitzungsanzahl (200) als 192.168.2.2 (300) aufweist. Die LAC muss dann zwischen Tunnel 1 und Tunnel 2 wählen, da beide zu 192.168.1.1 führen. Die LAC wertet die Anzahl der Tunnel-Sitzungen aus. Tunnel 2 hat eine niedrigere Anzahl (80) als Tunnel 1 (120), daher wählt die LAC Tunnel 2 für den ersten Anwender aus.

Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Tunnel 2 bleibt so lange ausgewählt, bis die Anzahl der Tunnel-Sitzungen auf 120 ansteigt, was Tunnel 1 entspricht.
Wenn sich der nächste Anwender anmeldet, wählt der LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da sie dieselbe Anzahl von Tunnel-Sitzungen haben. Die Anzahl der Tunnel-Sitzungen des ausgewählten Tunnels wird auf 121 erhöht.
Wenn sich der nächste Anwender anmeldet, wählt die LAC den anderen Tunnel zu 192.168.1.1 aus, da er eine geringere Anzahl von Tunnel-Sitzungen aufweist. Von diesem Punkt an wechselt die LAC weiter, indem sie zuerst eine zufällige Auswahl zwischen Tunnel 1 und 2 trifft und dann den anderen Tunnel auswählt, bis die Anzahl der Zielsitzungen auf 300 ansteigt, was der Anzahl der Sitzungen für 192.168.2.2 in Tunnel 3 entspricht. (Zu diesem Zeitpunkt beträgt die Anzahl der Tunnel-Sitzungen sowohl für Tunnel 1 als auch für Tunnel 2 150.)
Für den nächsten Anwender wählt die LAC nach dem Zufallsprinzip zwischen den Tunneln 1, 2 und 3 aus.
- Wenn der LAC entweder Tunnel 1 oder Tunnel 2 auswählt, steigt die Anzahl der Sitzungen 192.168.1.1 auf 301. Folglich wählt der LAC Tunnel 3 für den nächsten Anwender aus, da die Anzahl der Sitzungen 192.168.2.2 immer noch 300 beträgt. Zu diesem Zeitpunkt haben beide Ziele wieder die gleiche Anzahl von Sitzungen.
- Wenn der LAC Tunnel 3 auswählt, steigt die Anzahl der Sitzungen 192.168.2.2 auf 301. Für den nächsten Anwender wählt der LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da beide zu 192.168.1.1 gehen. Unabhängig davon, welche Sitzung die LAC auswählt, steigt die Anzahl der Sitzungen 192.168.1.1 auf 301. Zu diesem Zeitpunkt haben beide Ziele wieder die gleiche Anzahl von Sitzungen.
  
  Hinweis:
  Die Anzahl der Tunnelsitzungen für die Tunnel 1 und 2 wird nicht mehr ausgewertet. die LAC berücksichtigt nur die Anzahl der Zielsitzungen für 192.168.1.1 und 192.168.2.2.
  
  Dieses Muster setzt sich für alle nachfolgenden Abonnenten fort.

In Szenario 3 hat jeder Tunnel ein anderes gültiges Ziel, und es wird nur die Anzahl der Zielsitzungen ausgewertet:

Tunnel 1, Präferenzebene 1, 192.168.1.1, Anzahl der Zielsitzungen = 100
Tunnel 2, Präferenzebene 1, 192.168.2.2, Anzahl der Zielsitzungen = 100
Tunnel 3, Präferenzebene 1, 192.168.3.3, Anzahl der Zielsitzungen = 100
Tunnel 4, Präferenzebene 1, 192.168.4.4, Anzahl der Zielsitzungen = 100

Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, stellt die LAC fest, dass die Anzahl der Zielsitzungen für alle Ziele für alle vier Tunnel auf der Präferenzebene gleich ist. Folglich wählt die LAC nach dem Zufallsprinzip zwischen den vier Tunneln aus.

Angenommen, der LAC wählt Tunnel 1 für den ersten Anwender aus.

Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Der LAC wählt nach dem Zufallsprinzip zwischen den Tunneln 2, 3 und 4 aus, da die Ziele 192.168.2.2, 192.168.3.3 und 192.168.4.4 alle die gleiche Sitzungsanzahl von 100 haben, was niedriger ist als die aktuelle Sitzungsanzahl für 192.168.1.1, 101.
Angenommen, der LAC wählt Tunnel 2 aus. Für den nächsten Anwender wählt der LAC nach dem Zufallsprinzip zwischen den Tunneln 3 und 4 aus, da 192.168.3.3 und 192.168.4.4 alle dieselbe Sitzungsanzahl von 100 haben, was niedriger ist als die aktuelle Sitzungsanzahl von 101 für 192.168.1.1 und 192.168.2.2.
Angenommen, der LAC wählt Tunnel 3 aus. Für den nächsten Anwender wählt die LAC Tunnel 4 aus, da 192.168.4.4 eine Sitzungsanzahl von 100 hat und alle anderen Ziele eine Anzahl von 101 haben.
Jetzt haben die Ziele für alle vier Tunnel die gleiche Anzahl von Sitzungen. Da es nur vier Tunnel gibt, wird das endgültige Muster festgelegt. Wenn sich die Abonnenten weiterhin anmelden, wählt der LAC zunächst nach dem Zufallsprinzip zwischen allen vier Tunneln aus, dann die restlichen drei, dann das verbleibende Paar und wählt schließlich den letzten Tunnel aus. Wenn die Anzahl der Zielsitzungen alle gleich ist, startet der LAC dieses Muster erneut.

In Szenario 4 wertet die LAC sowohl die Zielsitzungslimits als auch die maximalen Tunnel-Sitzungslimits aus:

Tunnel 1, Präferenzebene 1, 192.168.1.1, Anzahl der Zielsitzungen = 30, maximale Sitzungsbeschränkung des Tunnels = 200
Tunnel 2, Präferenzebene 1, 192.168.2.2, Anzahl der Zielsitzungen = 40, maximale Sitzungsbeschränkung für den Tunnel = 200
Tunnel 3, Präferenzebene 1, 192.168.3.3, Anzahl der Zielsitzungen = 300, maximale Sitzungsbeschränkung des Tunnels = 1000
Tunnel 4, Präferenzebene 2, 192.168.4.4, Anzahl der Zielsitzungen = 100

Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt der LAC Tunnel 1 aus, da 192.168.1.1 die niedrigste Sitzungsanzahl in der Einstellungsebene hat.

Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:

Der LAC wählt weiterhin Tunnel 1 aus, bis die Anzahl der Zielsitzungen für 192.168.1.1 40 beträgt, was der Anzahl für 192.168.2.2 in Tunnel 2 entspricht.
Wenn sich der nächste Anwender anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da ihre Ziele die gleiche Anzahl von Sitzungen haben und diese niedriger ist als die von Tunnel 3 (300).
Unabhängig davon, welcher Tunnel aus diesem Paar ausgewählt wird, beträgt die Sitzungsanzahl für das Ziel jetzt 41. Der andere Tunnel wird ausgewählt, wenn sich der nächste Anwender anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 40 aufweist. Dadurch wird die Anzahl der Zielsitzungen auf 41 erhöht, was dem anderen Tunnel entspricht.
Wenn sich die Abonnenten weiterhin anmelden, wiederholt die LAC diesen Vorgang. Sie wählt nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, wenn ihre Sitzungsanzahl übereinstimmt, und wählt dann den anderen Tunnel mit dem nächsten Anwender aus, bis die Anzahl ihrer Zielsitzungen 200 erreicht, was ihrem maximalen Sitzungslimit von 200 im Tunnel entspricht. Da beide Tunnel ihr maximales Sitzungslimit erreicht haben, stehen sie nicht zur Auswahl zur Verfügung.
Wenn sich die Teilnehmer weiterhin anmelden, wählt die LAC den verbleibenden Tunnel in der Einstellungsebene Tunnel 3 aus, bis die Sitzungsanzahl für das Ziel das maximale Sitzungslimit für den Tunnel von 1000 erreicht.
Wenn sich der nächste Anwender anmeldet, wird die LAC auf die nächste Präferenzebene zurückgesetzt und Tunnel 4 ausgewählt, da dies der einzige Tunnel auf dieser Ebene ist.
Wenn sich Abonnenten weiterhin anmelden, wählt die LAC weiterhin Tunnel 4 aus, da für diesen Tunnel kein maximales Sitzungslimit konfiguriert ist. Die LAC kann anschließend nur dann einen Tunnel in der höheren Präferenzebene auswählen, wenn eine Sitzung für einen der Tunnel auf dieser Ebene beendet wird, wodurch die Sitzungsanzahl unter die Höchstgrenze fällt.

In Szenario 5 ist eines der Ziele gesperrt:

Tunnel 1, Präferenzebene 1, 192.168.1.1, Anzahl der Zielsitzungen = 100, Ziel gesperrt
Tunnel 2, Präferenzebene 1, 192.168.2.2, Anzahl der Zielsitzungen = 200
Tunnel 3, Präferenzebene 1, 192.168.3.3, Anzahl der Zielsitzungen = 250

Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, kann die LAC Tunnel 1 nicht auswählen, obwohl sein Ziel die niedrigste Sitzungsanzahl hat, da sich der Tunnel im Zielsperrstatus befindet. Tunnel 1 kann erst betrachtet werden, wenn er den gesperrten Zustand verlassen hat. Der LAC wählt Tunnel 2 aus, da die Sitzungsanzahl für 192.168.2.2 niedriger ist als für 192.168.3.3.

Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, hängt das, was als nächstes passiert, davon ab, wann 192.168.1.1 aus dem Sperrzustand auftaucht. Solange 192.168.1.1 gesperrt ist, trifft der LAC die Auswahl wie folgt:

Der LAC wählt weiterhin Tunnel 2 aus, bis die Sitzungsanzahl für 192.168.2.2 gleich 250 ist, was der Anzahl für 192.168.3.3 in Tunnel 3 entspricht.
Wenn sich der nächste Anwender anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 3 aus, da ihre Ziele die gleiche Anzahl von Sitzungen (250) haben.
Unabhängig davon, welcher Tunnel aus diesem Paar ausgewählt wird, beträgt die Sitzungsanzahl für das Ziel jetzt 251. Der andere Tunnel wird ausgewählt, wenn sich der nächste Anwender anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 250 aufweist. Dadurch erhöht sich die Anzahl der Zielsitzungen auf 251, was dem anderen Tunnel entspricht.
Wenn sich die Abonnenten weiterhin anmelden, wiederholt die LAC diesen Vorgang, indem sie nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 3 auswählt, wenn ihre Sitzungsanzahl übereinstimmt, und dann den anderen Tunnel mit dem nächsten Anwender auswählt.

Immer wenn 192.168.1.1 aus dem Sperrzustand hervortritt, wählt der LAC Tunnel 1 für den nächsten Anwender aus, da 192.168.1.1 die niedrigste Sitzungsanzahl aufweist. Der LAC macht dies so lange, bis die Sitzungsanzahl für 192.168.1.1 mit der aktuellen Sitzungsanzahl für eines der anderen Ziele übereinstimmt. Von diesem Zeitpunkt an wählt die LAC abwechselnd eine zufällige Auswahl zwischen Tunneln mit übereinstimmender Anzahl von Zielsitzungen und anschließend den Tunnel mit der niedrigsten Anzahl aus.

Wann immer 192.168.1.1 aus dem Sperrzustand auftaucht,

Der LAC wählt Tunnel 1 für den nächsten Anwender aus, da 192.168.1.1 die niedrigste Anzahl von Sitzungen aufweist.
Der LAC wählt weiterhin Tunnel 1 aus, bis die Sitzungsanzahl für 192.168.1.1 mit der aktuellen Sitzungsanzahl für eines der anderen Ziele übereinstimmt.
Von diesem Zeitpunkt an wählt die LAC abwechselnd eine zufällige Auswahl zwischen Tunneln mit übereinstimmender Anzahl von Zielsitzungen und anschließend den Tunnel mit der niedrigsten Anzahl aus.

L2TP-Sitzungslimits – Übersicht

Wenn eine L2TP-Sitzungsanforderung initiiert wird, vergleicht das LNS oder die LAC die Anzahl der derzeit aktiven Sitzungen mit der maximalen Anzahl von Sitzungen, die für das Gehäuse, Tunnel, eine Tunnel-Gruppe, einen Client (anforderndes Hostgerät) oder eine Gruppe von Clients zulässig sind. Neue Sitzungsanforderungen werden abgelehnt, wenn das konfigurierte Sitzungslimit erreicht ist.

Wenn eine Sitzung angefordert wird, prüft LNS in der folgenden Reihenfolge auf Sitzungslimits:

Gehäuse > Tunnel > Tunnel Gruppe > Sitzungsbegrenzung Gruppe > Client

Auf jeder Ebene ermittelt LNS, ob die aktuelle Sitzungsanzahl kleiner als der konfigurierte Grenzwert ist. Wenn dies der Fall ist oder kein Grenzwert konfiguriert ist, wird die Prüfung erfolgreich durchgeführt, und das LNS fährt mit der Prüfung der nächsten Stufe fort. Wenn die Anzahl der aktuellen Sitzungen auf einer Ebene dem konfigurierten Grenzwert entspricht, lehnt LNS die Sitzungsanforderung ab und prüft keine andere Ebene. Andernfalls kann die Sitzung aufgebaut werden.

Wenn eine Sitzungsanforderung für einen vorhandenen Tunnel abgelehnt wird, wird eine Call-Disconnect-Notify (CDN)-Nachricht mit einem Ergebniscode und einem Fehlercode, die beide auf 4 festgelegt sind, als Antwort auf die eingehende Anrufanforderung (Incoming-Call Request, ICRQ) zurückgegeben. Wenn die abgelehnte Anforderung für einen neuen Tunnel bestimmt ist, wird der Tunnel eingerichtet, aber die Sitzung kann nicht hochgefahren werden, was dazu führt, dass der Tunnel abbricht, weil er keine Sitzungen hat.

Der LAC führt die gleiche Prüfung durch, jedoch nur für die Chassis- und Tunnel-Ebenen. Die LAC lehnt Anforderungen ab, indem sie eine PPP-Beendigungsnachricht an den Client zurückgibt.

Sie können Sitzungslimits für das Gehäuse, alle Tunnel, eine Tunnel-Gruppe, eine Gruppe von Clients oder einen einzelnen Client konfigurieren. In den folgenden Szenarien wird beschrieben, was für verschiedene Konfigurationen von Sitzungslimits geschieht.

Szenario 1: Chassis-Limit
Szenario 2: Tunnellimit
Szenario 3: Tunnelgruppenlimit
Szenario 4: Gruppenlimit für Sitzungslimit
Szenario 5: Individuelles Clientlimit

Szenario 1: Chassis-Limit

In Tabelle 1 beträgt die aktuelle L2TP-Sitzungsanzahl 10.000, und das Sitzungslimit ist auf jeder Ebene auf 10.000 konfiguriert. Wenn eine neue Sitzung angefordert wird, schlägt die erste Prüfung auf Chassis-Ebene fehl, da die aktuelle Sitzungsanzahl dem konfigurierten Grenzwert entspricht. Auf den anderen Ebenen werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt. Auf keiner Ebene sind neue Sitzungen zulässig, bis die aktuelle Anzahl der Sitzungen unter 10.000 fällt.

Tabelle 1: Szenario 1, Chassis-Limit
Stufe	Konfiguriertes Sitzungslimit	Anzahl der aktuellen Sitzungen wird per `show services l2tp summary` Befehl angezeigt	Ergebnis der Überprüfung des Sitzungslimits
Chassis	10,000	10,000	Fehler
Tunnel A	10,000	10,000	–
Tunnelgruppe B	10,000	10,000	–
Sitzungslimit-Gruppe	10,000	10,000	–
Kunde	10,000	10,000	–

Szenario 2: Tunnellimit

In Tabelle 2 beträgt die aktuelle Anzahl der L2TP-Sitzungen 2000. Wenn eine neue Sitzung angefordert wird, besteht die erste Prüfung auf Chassis-Ebene, da der konfigurierte Grenzwert bis zu 10.000 Sitzungen auf dem Chassis zulässt, derzeit aber nur 2000 Sitzungen aktiv sind. Die nächste Überprüfung auf Tunnel-Ebene schlägt fehl, da die aktuelle Sitzungsanzahl mit dem konfigurierten Grenzwert für den Tunnel von 2000 für Tunnel A übereinstimmt.

Auf den anderen Ebenen werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt.

Tabelle 2: Szenario 2, Tunnellimit
Stufe	Konfiguriertes Sitzungslimit	Anzahl der aktuellen Sitzungen wird per `show services l2tp summary` Befehl angezeigt	Ergebnis der Überprüfung des Sitzungslimits
Chassis	10,000	2000	Bestehen
Tunnel A	2000	2000	Fehler
Tunnelgruppe B	10,000	2000	–
Sitzungslimit-Gruppe	6000	2000	–
Kunde	6000	2000	–

Auf Tunnel A werden keine neuen Sitzungen zugelassen, bis die aktuelle Sitzungsanzahl unter 2000 fällt und die Sitzungsprüfung bestanden werden kann. In diesem Fall werden die Prüfungen der anderen Ebene in diesem Szenario bestanden, da ihre konfigurierten Grenzwerte größer sind als ihre aktuelle Anzahl.

Das Sitzungslimit von 2000 gilt für alle Tunnel. Das heißt, jeder aktive Tunnel hat ein unabhängiges Limit von 2000 Sitzungen. Der Ausfall eines Tunnels hat keine Auswirkungen auf andere Tunnel. Eine Sitzungsanforderung für einen anderen Tunnel wird angenommen, solange die aktuelle Sitzungsanzahl für diesen Tunnel weniger als 2000 beträgt.

Szenario 3: Tunnelgruppenlimit

In Tabelle 3 beträgt die aktuelle L2TP-Sitzungsanzahl 2000. Wenn eine neue Sitzung angefordert wird, besteht die erste Prüfung auf Chassis-Ebene, da der konfigurierte Grenzwert bis zu 10.000 Sitzungen auf dem Chassis zulässt, derzeit aber nur 2000 Sitzungen aktiv sind. Die zweite Prüfung auf Tunnel-Ebene wird aus dem gleichen Grund ebenfalls bestanden. Die nächste Prüfung auf Tunnel-Gruppenebene für Tunnel-Gruppe B schlägt fehl, da die aktuelle Sitzungsanzahl für Tunnel-Gruppe B mit dem konfigurierten Grenzwert für Tunnel-Gruppen-Limits von 2000 übereinstimmt.

Auf den anderen Ebenen werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt.

Tabelle 3: Szenario 3, Tunnelgruppenlimit
Stufe	Konfiguriertes Sitzungslimit	Anzahl der aktuellen Sitzungen wird per `show services l2tp summary` Befehl angezeigt	Ergebnis der Überprüfung des Sitzungslimits
Chassis	10,000	2000	Bestehen
Tunnel A	10,000	2000	Bestehen
Tunnelgruppe B	2000	2000	Fehler
Sitzungslimit-Gruppe	6000	2000	–
Kunde	6000	2000	–

In der Tunnel-Gruppe B werden keine neuen Sitzungen zugelassen, bis die aktuelle Sitzungsanzahl unter 2000 fällt und die Sitzungsprüfung bestanden werden kann. In diesem Fall können die Prüfungen der anderen Ebene bestanden werden, da ihre konfigurierten Grenzwerte größer sind als ihre aktuelle Anzahl.

Für Tunnel-Gruppen wird das Sitzungslimit pro Gruppe konfiguriert. Das heißt, Sie können keinen einzigen Grenzwert angeben, der für alle Tunnel-Gruppen gilt. Der Ausfall einer Tunnel-Gruppe hat keine Auswirkungen auf andere Tunnel-Gruppen. In diesem Szenario wird eine Sitzungsanforderung für eine andere Tunnel-Gruppe durchgelassen, wenn die aktuelle Sitzungsanzahl für diese Gruppe kleiner als das konfigurierte Sitzungslimit ist.

Szenario 4: Gruppenlimit für Sitzungslimit

In Tabelle 4 beträgt die aktuelle L2TP-Sitzungsanzahl 6000. Wenn eine neue Sitzung angefordert wird, besteht die Prüfung für die Chassis-, Tunnel- und Tunnel-Gruppe, da der jeweils konfigurierte Grenzwert bis zu 10.000 Sitzungen zulässt, derzeit aber nur 6000 Sitzungen aktiv sind. Die Prüfung bei der Sitzungslimitgruppe schlägt fehl, da die aktuelle Sitzungsanzahl für die Sitzungslimitgruppe slg1 mit dem konfigurierten Grenzwert von 6000 übereinstimmt.

Auf der verbleibenden Ebene werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt.

Tabelle 4: Szenario 4, Sitzungslimit-Gruppenlimit
Stufe	Konfiguriertes Sitzungslimit	Anzahl der aktuellen Sitzungen wird per `show services l2tp summary` Befehl angezeigt	Ergebnis der Überprüfung des Sitzungslimits
Chassis	10,000	6000	Bestehen
Tunnel A	10,000	6000	Bestehen
Tunnelgruppe B	10,000	6000	Bestehen
Session-Limit-Gruppe slg1	6000	6000	Fehler
Kunde	8000	2000	–

Für Clients in der Sitzungslimitgruppe slg1 sind keine neuen Sitzungen zulässig, bis die aktuelle Sitzungsanzahl der Gruppe unter 6000 fällt und die Sitzungsprüfung bestanden werden kann. In diesem Fall kann die Überprüfung des verbleibenden Levels bestanden werden, da der konfigurierte Grenzwert größer ist als die aktuelle Anzahl.

Sie können eine Sitzungslimitgruppe neu konfigurieren, indem Sie Clients entfernen oder hinzufügen, ohne dass sich dies auf aktuelle Sitzungen auswirkt. Die Neukonfiguration wirkt sich auf die Anzahl der Sitzungen aus, die für die Clientgruppe eingerichtet werden können.

Wenn Sie einen Client entfernen, erhöht sich die Anzahl der neuen Sitzungen, die eingerichtet werden können, um die Anzahl der aktuellen Sitzungen dieses Clients.
Wenn Sie einen Client hinzufügen, wird die Anzahl der neuen Sitzungen, die eingerichtet werden können, um die Anzahl der aktuellen Sitzungen dieses Clients reduziert. Die neue Gesamtzahl der aktuellen Sitzungen für vorhandene Clients plus der neue Client kann den konfigurierten Grenzwert für die Sitzungslimitgruppe überschreiten. In diesem Fall werden keine Sitzungen gelöscht, aber es können keine neuen Sitzungen eingerichtet werden, bis die Anzahl der Sitzungen unter das konfigurierte Gruppenlimit fällt.

Um dies weiter zu untersuchen, betrachten Sie die folgende Abfolge von Ereignissen:

Die Sitzungslimitgruppe slg1 verfügt über zwei Clients, ent1-serviceA mit einer aktuellen Sitzungsanzahl von 3500 und ent1-serviceB mit einer aktuellen Sitzungsanzahl von 0. Da die Gruppe slg1 ein Limit von 6000 hat, können für diese Clients nicht mehr als 2500 Sitzungen hinzugefügt werden:

6000 - 3500 = 2500
Dann werden 1000 Sitzungen für den Client ent1-service B angemeldet. Jetzt können nicht mehr als 1500 Sitzungen für diese Clients hinzugefügt werden:

6000 - (3500 + 1000) = 1500
Angenommen, Sie entfernen den Client ent1-serviceA aus der Sitzungslimitgruppe. Die Gruppensitzungskapazität erhöht sich auf 5000 Sitzungen:

6000 - 1000 = 5000
Schließlich fügen Sie der Gruppe "session-limit" einen neuen Client, ent1-serviceC, hinzu. Dieser neue Client verfügt derzeit über 8000 aktive Sitzungen. In diesem Fall hat die Sitzungslimitgruppe jetzt 9000 Sitzungen:

1000 + 8000 = 9000

Es werden keine Sitzungen gelöscht, obwohl das maximale Sitzungslimit für die Gruppe von 6000 überschritten wird. Es können keine neuen Sitzungen hinzugefügt werden, bis die Anzahl der Sitzungen von 9000 auf unter 6000 fällt.

Szenario 5: Individuelles Clientlimit

In Tabelle 5 wird die Sitzungsprüfung für die Chassis-, Tunnel- und Tunnel-Gruppe erfolgreich durchgeführt, da ihre konfigurierten Grenzwerte größer sind als die aktuelle Anzahl der Sitzungen. Der Client ent1-serviceA gehört nicht zu einer Session-Limit-Gruppe. Die Grenzwertprüfung schlägt für den Client fehl, da die aktuelle Sitzungsanzahl mit dem konfigurierten Grenzwert von 6000 übereinstimmt.

Tabelle 5: Szenario 5, Limit für einzelne Clients
Stufe	Konfiguriertes Sitzungslimit	Anzahl der aktuellen Sitzungen wird per `show services l2tp summary` Befehl angezeigt	Ergebnis der Überprüfung des Sitzungslimits
Chassis	10,000	6000	Bestehen
Tunnel A	10,000	6000	Bestehen
Tunnelgruppe B	8000	6000	Bestehen
Client ent1-serviceA	6000	6000	Fehler

Für diesen Client sind keine neuen Sitzungen zulässig, bis die aktuelle Sitzungsanzahl unter 6000 fällt und die Sitzungsprüfung bestanden werden kann. Der Ausfall eines unabhängigen Clients hat keine Auswirkungen auf andere Clients. In diesem Szenario wird eine Sitzungsanforderung für einen anderen unabhängigen Client bestanden, wenn die aktuelle Sitzungsanzahl für diesen Client unter dem konfigurierten Sitzungslimit liegt.

Das Sitzungslimit, das Sie für einen einzelnen Client festlegen – der nicht Teil einer Sitzungslimitgruppe ist – gilt für jede Tunnel-Gruppe. Mehrere LACs mit demselben Quellhostnamen, aber unterschiedlichen Quell-IP-Adressen werden als derselbe Client behandelt.

Angenommen, Sie haben drei LACs, A, B und C. Alle drei haben denselben Quellhostnamen, ce-lac. LAC A und LAC B richten Sitzungen mit einem LNS über die Gateway-Adresse ein, die der Tunnel-Gruppe 1 zugeordnet ist. LAC C richtet Sitzungen über ein anderes Gateway ein, das der Tunnel-Gruppe 2 zugeordnet ist. Da die LACs denselben Hostnamen haben, ist die Clientkonfiguration für alle drei identisch. Das Clientsitzungslimit gilt jedoch aufgrund der Tunnel-Gruppen unterschiedlich für die LACs.

Angenommen, das Clientsitzungslimit beträgt 100. Da sowohl LAC A als auch LAC B Sitzungen in Tunnel-Gruppe 1 erstellen, müssen sie sich das Client-Limit teilen. Das bedeutet, dass die Gesamtzahl der Sitzungen, die für LAC A und LAC B zusammen zulässig sind, 100 beträgt.

LAC C erstellt Sitzungen in einer anderen Tunnel-Gruppe, 2. Da das Clientsitzungslimit pro Tunnelgruppe gilt, sind LAC C 100 Sitzungen erlaubt, unabhängig davon, wie viele Sitzungen LAC A und LAC B bereits eingerichtet haben.

Begrenzung der Anzahl von L2TP-Sitzungen, die von der LAC oder dem LNS zugelassen werden

Sie können die maximale Anzahl von L2TP-Sitzungen begrenzen, die für das Gehäuse, alle Tunnel, eine Tunnel-Gruppe, eine Gruppe von Clients, einen einzelnen Client oder eine einzelne Serviceschnittstelle oder eine aggregierte Serviceschnittstelle zulässig sind. Neue Sitzungsanforderungen werden vom LNS oder LAC abgelehnt, wenn das konfigurierte Sitzungslimit erreicht ist. Sitzungsanforderungen werden auch abgelehnt, wenn der maximale Chassis-Grenzwert erreicht ist, selbst wenn ein konfigurierter Grenzwert nicht überschritten wird. Konfigurierbare Sitzungslimits ermöglichen eine fein abgestufte Steuerung der Anzahl von Sitzungen, die ein Kunde haben kann, während er über LACs an mehreren Standorten verbunden ist.

Hinweis:

Sie können den Grenzwert nicht höher als den standardmäßigen Höchstgrenzwert für das Gehäuse festlegen.

So begrenzen Sie die Anzahl der auf einem Chassis (LAC oder LNS) zulässigen Sitzungen: