AUF DIESER SEITE
Begrenzung der Anzahl von L2TP-Sitzungen, die vom LAC oder LNS zugelassen werden
Konfigurieren des LAC-Tunnelauswahl-Failovers innerhalb einer Präferenzebene
Konfigurieren des gewichteten Lastenausgleichs für LAC-Tunnelsitzungen
Konfigurieren von Destination-Equal Load Balancing für LAC-Tunnelsitzungen
L2TP LAC-Tunneling für Teilnehmer
Übersicht über die LAC-Tunnelauswahl
Wenn sich ein Benutzer bei einer Domäne anmeldet, kontaktiert der PPP-Client die LAC, um eine Verbindung herzustellen. Die LAC muss ein Ziel in der Domäne und einen Tunnel finden, der sie erreichen kann. Die Zuordnung zwischen Zielen, Tunneln und Domänen wird durch ein Tunnelprofil bereitgestellt, das sich entweder in einer Domänenzuordnung im Zugriffsprofil des Abonnenten oder im Tunnelgruppenattribut (VSA 26-64) befindet, das von einem RADIUS-Server empfangen wird. Das RADIUS-Attribut hat Vorrang vor einem Profil, das in einer Domänenzuordnung angegeben ist. Das Tunnelprofil enthält eine Liste von Tunneln. Jeder Tunnel ist einer Ziel-IP-Adresse und einer Tunnelpräferenzebene zugeordnet.
Mit L2TP können Sie Folgendes angeben:
Bis zu 31 Ziele für eine Domäne.
Bis zu acht Stufen der Tunnelpräferenz. Die Präferenzebene bestimmt die Reihenfolge, in der die LAC versucht, einen vorhandenen 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 häufigsten bevorzugte Stufe.
Wenn zwei Tunnel beide gültige Ziele innerhalb einer Domäne erreichen, wählt die LAC zuerst den Tunnel mit der höchsten Präferenzstufe aus. Wenn z. B. Tunnel A die Präferenzstufe 1 und Tunnel B die Präferenzstufe 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 Tunnelprofil zugeordnet sind.
Die Tunnelauswahl wird von den folgenden Konfigurationen beeinflusst:
Failover zwischen Einstellungsebenen: Wenn ein Tunnel zu einem gültigen Ziel nicht innerhalb einer Einstellungsebene ausgewählt wird, wird standardmäßig ein Failover des Auswahlprozesses auf die nächste Ebene durchgeführt. Das heißt, der LAC sinkt auf die nächstniedrigere Ebene ab, um die Suche nach einem geeigneten Tunnel fortzusetzen. Weitere Informationen finden Sie unter Auswahl bei Konfiguration des Failovers zwischen Einstellungsebenen .
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 durch den ausgewählten Tunnel fehlschlägt, wird der Auswahlprozess innerhalb derselben Ebene fortgesetzt, indem ein anderer geeigneter Tunnel zu einem gültigen Ziel ausgewählt wird. Die LAC setzt ihre Verbindungsversuche innerhalb des Levels fort, bis auf diesem Level keine Tunnel mehr zu einem gültigen Ziel verfügbar sind. Dann sinkt der LAC auf die nächstniedrigere Ebene, um die Suche fortzusetzen. Weitere Informationen finden Sie unter Auswahl bei Konfiguration eines Failovers innerhalb einer Präferenzebene .
Maximale Anzahl von Sitzungen pro Tunnel: Wenn die maximal zulässige Anzahl von Sitzungen pro Tunnel konfiguriert ist, berücksichtigt die LAC diese Einstellung bei der Tunnelauswahl. Die maximale Anzahl von Sitzungen pro Tunnel kann mit Hilfe des RADIUS Tunnel-Max-Sessions VSA [26-33] oder durch Einbinden der
max-sessionsAnweisung in ein Tunnelprofil konfiguriert werden.Wenn die aktuelle Sitzungsanzahl eines zufällig ausgewählten Tunnels der maximalen Sitzungsanzahl entspricht, versucht die LAC nicht, mit diesem Tunnel eine Verbindung zu einem Ziel herzustellen. Stattdessen wird ein alternativer Tunnel aus der Gruppe von Tunneln auf dieser Einstellungsebene ausgewählt, die gültige Ziele in der Domäne haben. Wenn auf der aktuellen Präferenzebene keine derartigen Tunnel vorhanden sind, wird die LAC auf die nächste Präferenzebene abgeschaltet, 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 eine unbegrenzte Anzahl von Sitzungen im Tunnel ermöglicht.
Gewichteter Lastenausgleich: Diese Ausgleichsmethode verwendet eine wahrscheinlichkeitsbasierte Auswertung des Tunnelgewichts, um Sitzungen auf Tunnel zu verteilen. Die LAC wählt die Tunnel immer noch nach dem Zufallsprinzip innerhalb einer Präferenzstufe aus, aber im Durchschnitt werden die Sitzungen im Verhältnis zum Gewicht der Tunnel auf die Tunnel verteilt. Die Gewichtung eines Tunnels wird durch das maximale Sitzungslimit des Tunnels und die maximalen Sitzungsgrenzen der anderen Tunnel auf derselben Präferenzebene bestimmt. Weitere Informationen finden Sie unter Weighted Load Balancing .
Destination-equal load balancing: Bei dieser Sitzungsausgleichsmethode werden Tunnel anhand 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 geringsten Sitzungsanzahl weist die geringste Last auf. Dieser Prozess arbeitet mit Tunneln auf der höchsten verfügbaren Präferenzstufe. 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:
Es kann sein, dass mehr als ein Tunnel ein Ziel erreichen kann, und diese Tunnel können dieselbe oder unterschiedliche Präferenzebenen haben.
Der Tunnel, der zum Einrichten der Abonnentensitzung ausgewählt wurde, kann bereits selbst eingerichtet sein. Das bedeutet, dass derzeit aktive Sitzungen vorhanden sind. Alternativ muss die LAC möglicherweise einen neuen Tunnel zum Ziel einrichten, wenn noch kein Tunnel eingerichtet ist, 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 Abonnenten-Anmeldeanfrage kontaktiert.
Es kann entweder verriegelt oder entriegelt werden.
Ein gesperrtes Ziel ist ein Ziel, für das der Timer für die Zielsperre ausgeführt wird. Gesperrte Ziele werden in eine Sperrliste aufgenommen, bis der Timer abläuft oder gelöscht wird (Zurücksetzen auf Null). Ziele auf der Liste können nicht kontaktiert werden, um eine Sitzung einzurichten.
Ein entsperrtes Ziel ist ein Ziel, für das der Timer für die Zielsperre Null ist.
Wenn die LAC gültige Ziele erkennt, die gesperrt sind, platziert sie sie in der DestinationsLockedNotContacted-Liste, 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 versucht hat, für die aktuelle, laufende Abonnentenanmeldung zu kontaktieren. Die Liste "DestinationsLockedNotContacted" enthält keine Ziele, die die LAC sperrt, nachdem sie versucht hat, eine Verbindung herzustellen, und dabei fehlgeschlagen ist.
Sie können den
clear services l2tp destination lockoutBefehl 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 Präferenzebene Priorität erhält.Das Failover-Verhalten, das Teil des Tunnelauswahlprozesses ist, gilt nur, wenn das Ziel aus einem der folgenden Gründe nicht erreichbar ist:
Das LNS kann nach der maximalen Anzahl von Wiederholungsversuchen keine SCCRP-Nachricht als Antwort auf die SCCRQ-Nachricht von der LAC zurückgeben.
Der Tunnel wird eingerichtet, aber das LNS gibt nach der maximalen Anzahl von Wiederholungsversuchen keine ICRP-Nachricht als Antwort auf die ICRQ von der LAC zurück.
Dieses Failoververhalten gilt nicht unter den folgenden Umständen:
Der Client beendet die Verbindung.
Der Tunnel wird eingerichtet, aber das LNS sendet eine CDN-Nachricht, während der LAC versucht, die Sitzung mit dem LNS aufzubauen, was dazu führt, dass der Anmeldeversuch des Abonnenten fehlschlägt.
- Auswahl bei Konfiguration des Failovers zwischen Einstellungsebenen
- Auswahl, wenn Failover innerhalb einer Einstellungsebene konfiguriert ist
- Auswahl bei der Verteilung der Sitzungslast auf mehrere LNSs
Auswahl bei Konfiguration des Failovers zwischen Einstellungsebenen
Wenn ein Benutzer versucht, sich in einer Standardkonfiguration bei einer Domäne anzumelden, d. h., wenn kein Failover innerhalb einer Präferenzebene und kein Load Balancing konfiguriert sind, sucht die LAC nach gültigen Zielen in der angeforderten Domäne, beginnend mit der höchsten Tunnelpräferenzebene. 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 heruntergestuft, um die Suche fortzusetzen. Der Suchvorgang ist für alle Ebenen gleich, mit Ausnahme der untersten:
Die Suche beginnt mit der Identifizierung von Tunneln mit gültigen Zielen auf der Präferenzebene aus allen Tunneln, die im Tunnelprofil der Domäne angegeben sind.
Alle gesperrten, gültigen Ziele werden in die Liste DestinationsLockedNotContacted aufgenommen. Es wird kein Versuch unternommen, mit einem dieser Ziele Kontakt aufzunehmen.
Aus den freigeschalteten, gültigen Zielen wählt der LAC nach dem Zufallsprinzip eines aus und versucht, eine Verbindung durch den zugehörigen Tunnel herzustellen. Wenn der Tunnel keine aktuellen Sitzungen hat, muss die LAC den Tunnel einrichten.
Hinweis:Die Zufallsauswahl ist das Standardverhalten. Das Verhalten ist anders, wenn gewichteter Lastenausgleich oder zielgleicher Lastenausgleich konfiguriert ist. Weitere 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. Die LAC löscht auch alle Ziele in der Liste DestinationsLockedNotContacted.
Wenn die LAC keine Antwort erhält, wird der Versuch bis zur maximalen Wiederholungszahl wiederholt. Wenn die LAC die Wiederholungsversuche ausschöpft, ohne eine Antwort zu erhalten, gilt der Versuch als erfolglos und die LAC markiert das Ziel als nicht erreichbar, indem sie das Ziel sperrt. Das Ziel wird in die Sperrliste aufgenommen und der Zielsperrtimer gestartet.
Was der LAC als nächstes tut, hängt von der aktuellen Präferenzstufe ab.
Wenn es sich nicht um die niedrigste Präferenzstufe handelt, sinkt 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 die LAC alle Ziele in der Liste DestinationsLockedNotContacted, springt zurück zur höchsten Präferenzebene und startet den Suchvorgang neu.
Wenn es sich um die niedrigste Präferenzstufe handelt und die Liste DestinationsLockedNotContacted leer ist – was bedeutet, dass alle gültigen Ziele versucht wurden –, meldet die LAC eine fehlgeschlagene Anmeldung beim PPP-Client.
Wenn die gültigen Ziele auf einer Ebene alle gesperrt sind, hängt das nächste Vorgehen der LAC von der aktuellen Präferenzstufe ab.
Wenn es sich nicht um die niedrigste Präferenzstufe handelt, sinkt die LAC auf die nächstniedrigere Präferenzebene und setzt den Suchvorgang fort.
Wenn es sich um die niedrigste Präferenzstufe handelt, wählt die LAC das gesperrte, gültige Ziel mit der kürzesten verbleibenden Sperrzeit aus. Der Sperrtimer wird gelöscht und es wird versucht, eine Verbindung zum Ziel herzustellen und eine Sitzung einzurichten.
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 beim PPP-Client.
Wenn der Versuch fehlschlägt 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 Suchvorgang neu.
Wenn keine gültigen Ziele vorhanden sind, hängt die nächste Maßnahme der LAC von der aktuellen Präferenzstufe ab.
Wenn es sich nicht um die niedrigste Präferenzstufe handelt, sinkt die LAC auf die nächstniedrigere Präferenzebene und setzt den Suchvorgang fort.
Wenn es sich um die niedrigste Präferenzstufe handelt und die Liste DestinationsLockedNotContacted leer ist – was bedeutet, dass alle gültigen Ziele versucht wurden –, meldet die LAC eine fehlgeschlagene Anmeldung beim PPP-Client.
Wenn es sich um die niedrigste Präferenzebene handelt und die Liste DestinationsLockedNotContacted nicht leer ist, entsperrt die LAC alle Ziele in der Liste DestinationsLockedNotContacted, springt zurück zur höchsten Präferenzebene und startet den Prozess neu.
Der Such- und Failover-Prozess durchläuft die Ebenen, bis entweder eine Sitzung eingerichtet ist oder alle gültigen Ziele versucht wurden (es verbleiben keine Ziele mehr in der Liste DestinationsLockedNotContacted – 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 ein Failover zwischen Tunnelpräferenzebenen auftritt.
Angenommen, das Tunnelprofil 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 Lastenausgleich 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 die 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, Einstellungsebene 1, verworfen (führt ein Failover durch), um ein Ziel für die Domäne zu erreichen. Das LAC wählt nach dem Zufallsprinzip zwischen 192.168.22.22 durch Tunnel 2 und 192.168.33.33 durch Tunnel 3. Er 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 bei jeder Suche in einer Ebene nur einen Versuch unternehmen kann, ein gültiges Ziel zu erreichen, wenn die Failover-Methode zwischen den Präferenzebenen liegt.
Die LAC sinkt in diesem Beispiel auf die letzte (niedrigste) Ebene, Präferenzstufe 2. Das LAC wählt Tunnel 4 aus, da es der einzige Tunnel im Level 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 unterste Ebene ist und die Liste DestinationsLockedNotContacted leer ist, lehnt die 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. Das Ziel 192.168.33.33 wurde nicht kontaktiert, aber nicht zur Liste DestinationsLockedNotContacted hinzugefügt, da es nicht gesperrt ist.
Der Client versucht erneut, sich anzumelden, und der LAC wiederholt den Tunnelauswahlprozess, indem er bei der Präferenzstufe 0 beginnt, um nach einem entsperrten, gültigen Ziel zu suchen, und die Ebenen nach Bedarf durchläuft.
Auf der Präferenzebene 0 ist 192.168.10.10 das einzige gültige Ziel und immer noch gesperrt, sodass die LAC nicht versuchen kann, eine Verbindung zum Ziel herzustellen. Die LAC fügt 192.168.10.10 zur Liste "DestinationsLockedNotContacted" hinzu und wird dann auf Präferenzebene 1 abgesetzt.
Hinweis:Denken Sie daran, dass der Timer für die Zielsperrung global gilt, sodass er über mehrere Abonnentenanmeldungen hinweg bestehen bleibt. Die Liste "DestinationsLockedNotContacted" gilt nur für eine bestimmte Abonnentenanmeldung und bleibt nicht erhalten. Obwohl die LAC für diesen Abonnenten 192.168.10.10 kontaktiert hat, war dies bei einem früheren Anmeldeversuch. Bei diesem Anmeldeversuch kann das Ziel aufgrund der Sperre nicht kontaktiert werden, und folglich wird das Ziel in die Liste DestinationsLockedNotContacted aufgenommen.
Auf Präferenzebene 1 ist 192.168.22.22 immer noch gesperrt, sodass die LAC 192.168.22.22 zur Liste DestinationsLockedNotContacted hinzufügt. 192.168.33.33 ist weiterhin verfügbar. Der 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 sinkt auf Präferenzstufe 2.
192.168.44.44 ist immer noch gesperrt, sodass die LAC 192.168.44.44 zur Liste DestinationsLockedNotContacted hinzufügt.
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. Die LAC entsperrt alle Ziele in der Liste "DestinationsLockedNotContacted" und springt dann zurück zur höchsten Präferenzebene.
Auf Präferenzebene 0 versucht die LAC, eine Verbindung zu 192.168.10.10 herzustellen, da sie entsperrt wurde. Der LAC richtet die Sitzung ein und meldet die erfolgreiche Anmeldung an den PPP-Client.
Obwohl die LAC nicht versucht, ein Ziel zu kontaktieren, das gesperrt ist, 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 Tunnelprofil 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 Sperrtimer 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 Lastenausgleich 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 die 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, Präferenzstufe 1, herabgesetzt, 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.
Die LAC fügt beide Ziele der Liste "DestinationsLockedNotContacted" hinzu.
Da es sich hierbei um die niedrigste Präferenzstufe handelt, 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. Der LAC entsperrt 192.168.33.33 und versucht, eine Verbindung durch Tunnel 3 herzustellen. Infolgedessen entfernt die LAC auch 192.168.33.33 aus der Liste DestinationsLockedNotContacted.
Der Verbindungsversuch ist erfolgreich und es wird eine Sitzung mit 192.168.33.33 aufgebaut. Die LAC meldet eine erfolgreiche Anmeldung am PPP-Client.
Auswahl, wenn Failover innerhalb einer Einstellungsebene konfiguriert ist
Wenn Sie Failover innerhalb einer Präferenzebene konfigurieren, ist der Ziel- und Tunnelauswahlprozess derselbe wie bei der Standardkonfiguration, mit einer Ausnahme: Die LAC ist nicht auf nur einen Verbindungsversuch auf einer Präferenzebene beschränkt.
Wenn die LAC versucht, eine Verbindung zu einem entsperrten, gültigen Ziel herzustellen, und dies nicht erfolgreich ist, sperrt sie dieses Ziel, fällt aber nicht sofort auf die nächstniedrigere Ebene herunter. 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 der LAC keine Verbindung herstellt, versucht er weiterhin, ein Ziel innerhalb dieser Präferenzstufe zu erreichen, bis keine freigeschalteten, gültigen Ziele mehr versucht werden müssen. An diesem Punkt fällt die LAC herunter, 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 entsperrten, gültigen Ziele mehr 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", springt wieder auf die höchste Präferenzebene und startet den Suchvorgang neu.
Wenn DestinationsLockedNotContacted leer ist, was bedeutet, dass alle gültigen Ziele versucht wurden, meldet die LAC eine fehlgeschlagene Anmeldung beim PPP-Client.
Angenommen, das Tunnelprofil gibt die folgenden Tunnel und Ziele an. Der Lastenausgleich ist nicht konfiguriert. Alle Ziele sind gültig; Alle außer 192.168.3.3 sind freigeschaltet. Die Präferenzstufen für die Tunnel werden wie folgt zugewiesen:
Präferenz 0, Tunnel 1, 192.168.1.1, entsperrt
Präferenz 0, Tunnel 2, 192.168.2.2, entsperrt
Einstellung 0, Tunnel 3, 192.168.3.3, Sperrtimer 100 Sekunden
Präferenz 1, Tunnel 4, 192.168.4.4, entsperrt
Präferenz 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 der Präferenzstufe 0 aus, 192.168.1.1 bis Tunnel 1 und 192.168.2.2 bis Tunnel 2. Er wählt 192.168.2.2 aus und versucht, eine Verbindung über Tunnel 2 herzustellen.
Der Verbindungsversuch zu 192.168.2.2 schlägt fehl, sodass die 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.
Die 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 die 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 einzige verbleibende gültige Ziel auf Präferenzebene 0, aber es ist gesperrt. Die LAC fügt 192.168.3.3 zur Liste DestinationsLockedNotContacted hinzu. Die LAC hat 192.168.1.1 und 192.168.2.2 nicht zur Liste DestinationsLockedNotContacted hinzugefügt, da sie nach dem Versuch, sie zu kontaktieren, gesperrt wurden.
Da es auf Ebene 0 keine freigeschalteten, gültigen Ziele mehr gibt, wird die LAC auf die nächste Ebene, Präferenzstufe 1, herabgesetzt, um ein Ziel für die Domäne zu erreichen.
Bei Präferenzstufe 1 wählt die 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 "DestinationsLockedNotContacted" nicht leer ist, entsperrt die LAC alle Ziele in der Liste – in diesem Fall 192.168.3.3 – und springt wieder auf die höchste Präferenzebene (0).
192.168.3.3 ist jetzt das einzige freigeschaltete Ziel auf Präferenzebene 0, daher versucht der LAC, sich über Tunnel 3 mit ihm zu verbinden.
Der Verbindungsversuch zu 192.168.3.3 schlägt fehl, sodass die 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 es auf Ebene 0 keine freigeschalteten, gültigen Ziele mehr gibt, sinkt die LAC auf die nächste Ebene, Präferenzstufe 1.
Präferenzstufe 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 der Verteilung der Sitzungslast auf mehrere LNSs
Auf dem LAC können mehrere Tunnelprofile konfiguriert werden. Einige Tunnel teilen sich möglicherweise Ziele. Wenn die LAC die Sitzung für einen PPP-Abonnenten an das LNS tunnelt, muss ein Tunnel für die Abonnentensitzung ausgewählt werden. Bei der Tunnelauswahl wird ein Tunnel mit der höchsten Präferenz ausgewählt, der über ein erreichbares Ziel verfügt. Standardmäßig wählt die LAC einen Tunnel nach dem Zufallsprinzip aus mehreren Tunneln aus, die die gleichen Kriterien erfüllen. Alternativ können Sie den Lastenausgleich so konfigurieren, dass verschiedene Auswahlmöglichkeiten aktiviert werden. Beide Load-Balancing-Methoden wirken sich darauf aus, welche Tunnel und Ziele die LAC auswählt, aber der Auswahl- und Failover-Prozess bleibt ansonsten gleich.
Gewichteter Lastenausgleich und zielgleicher Lastenausgleich schließen sich gegenseitig aus. Sie können nur das eine oder das andere aktivieren.
Gewichtetes Load Balancing
Beim gewichteten Load Balancing werden Tunnel nach ihrer Gewichtung ausgewertet. Die Gewichtung eines Tunnels wird durch das maximale Sitzungslimit des Tunnels und die maximalen Sitzungsgrenzen der anderen Tunnel auf derselben Präferenzebene bestimmt. Der Tunnel mit dem höchsten maximalen Sitzungslimit hat die höchste Gewichtung in dieser Präferenzebene. Der Tunnel mit dem nächsthöheren maximalen Sitzungslimit hat die nächsthöhere Gewichtung usw. Der Tunnel mit dem niedrigsten maximalen Sitzungslimit hat das geringste Gewicht.
Tunnelauswahl und Sitzungsverteilung sind wahrscheinlichkeitsbasiert. Die Last wird nicht streng nach Gewicht verteilt.
Wenn Sie den gewichteten Lastenausgleich konfigurieren, wählt die LAC die Tunnel weiterhin nach dem Zufallsprinzip innerhalb einer Präferenzebene aus, aber im Durchschnitt werden die Sitzungen im Verhältnis zur Gewichtung der Tunnel auf die Tunnel verteilt.
Beim gewichteten Load Balancing generiert die LAC eine Zufallszahl innerhalb eines Bereichs, der der Gesamtsumme aller Sitzungslimits für alle Tunnel in der Präferenzebene entspricht. Er ordnet jedem Tunnel einen Teil des Bereichs – einen Pool von Zahlen – proportional zum Tunnelgewicht 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. Es ist wahrscheinlicher, dass sich die Zufallszahl im Durchschnitt in einem größeren Pool befindet, sodass ein Tunnel mit einem höheren Gewicht (größerer Pool) eher ausgewählt wird als ein Tunnel mit einem geringeren Gewicht (kleinerer Pool).
Stellen Sie sich beispielsweise eine Präferenzebene vor, die nur über zwei Tunnel verfügt, 1 und 2. Für Tunnel 1 gilt ein maximales Limit von 1000 Sitzungen und für Tunnel 2 ein Limit von 2000 Sitzungen, was insgesamt 3000 Sitzungen ergibt. Die 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 Tunnel 2 zugeordnet.
Wenn die generierte Zahl kleiner als 1000 ist, wird Tunnel 1 ausgewählt, obwohl er eine geringere Gewichtung (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 Nummern für Tunnel 2 (2000) doppelt so hoch ist wie für Tunnel 1 (1000), wird Tunnel 2 im Durchschnitt doppelt so oft ausgewählt wie Tunnel 1.
Destination Equal Load Balancing (Lastenausgleich am Zielort)
Beim Destination-Equal-Load-Balancing werden Tunnel anhand 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 geringsten Sitzungsanzahl gilt als der Tunnel mit der geringsten Last. Dieser Prozess arbeitet mit Tunneln auf der höchsten verfügbaren Präferenzstufe 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 niedrige 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 geringsten Gesamtzahl von Tunnelsitzungen aus. Wenn die Anzahl der Tunnelsitzungen für alle diese Tunnel gleich ist, wählt die LAC einen von ihnen nach dem Zufallsprinzip aus.
Betrachten Sie die folgenden Szenarien, um das Verhalten der Tunnelauswahl besser zu verstehen, wenn der zielgleiche Lastenausgleich 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äferenzstufe 1, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 2, Präferenzstufe 1, 192.168.2.2, Anzahl der Zielsitzungen = 50
Tunnel 3, Präferenzstufe 1, 192.168.3.3, Anzahl der Zielsitzungen = 300
Tunnel 4, Präferenzstufe 1, 192.168.4.4, Anzahl der Zielsitzungen = 100
Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt die 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 wird weiterhin ausgewählt, bis die Sitzungsanzahl für 192.168.2.2 gleich 100 ist, was der nächstniedrigeren Sitzungsanzahl (192.168.4.4) in Tunnel 4 entspricht.
Wenn sich der nächste Teilnehmer anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 4 aus, da ihre Ziele die gleiche Sitzungsanzahl 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 sein Ziel jetzt 101. Der andere Tunnel wird ausgewählt, wenn sich der nächste Abonnent anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 100 aufweist. Dadurch erhöht sich die Anzahl der Zielsitzungen auf 101 und entspricht damit der des anderen Tunnels.
Während sich die Teilnehmer weiterhin anmelden, wiederholt der LAC diesen Vorgang, indem er nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 4 auswählt, wenn die Anzahl ihrer Sitzungen übereinstimmt, und dann den anderen Tunnel mit dem nächsten Teilnehmer auswählt, bis beide die Anzahl ihrer Zielsitzungen 200 erreichen und damit mit Tunnel 1 übereinstimmen.
Wenn sich der nächste Teilnehmer 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, 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 Abonnenten nach dem Zufallsprinzip zwischen den beiden anderen Tunneln wählt. Jetzt haben zwei Tunnel eine Zielsitzungsanzahl von 201, sodass die LAC den verbleibenden Tunnel für den nächsten Abonnenten auswählt.
Während 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 Teilnehmer ausgewählt und dann den verbleibenden Tunnel auswählt, sodass die Zielsitzungszählungen für diese drei Tunnel erneut übereinstimmen. Dieses Muster wird so lange fortgesetzt, 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 Sitzungsanzahl. Da es nur vier Tunnel gibt, wird das endgültige Muster festgelegt. Der LAC wählt zuerst zufällig aus allen vier Tunneln aus, dann die verbleibenden drei, dann das verbleibende Paar und schließlich den letzten Tunnel. Wenn die Anzahl der Zielsitzungen alle gleich sind, startet die LAC dieses Muster erneut.
In Szenario 2 teilen sich zwei Tunnel dasselbe gültige Ziel. Sowohl die Anzahl der Tunnelsitzungen als auch die Anzahl der Zielsitzungen werden ausgewertet:
Tunnel 1, Präferenzstufe 1, Anzahl der Tunnelsitzungen = 120, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 2, Präferenzstufe 1, Anzahl der Tunnelsitzungen = 80, 192.168.1.1, Anzahl der Zielsitzungen = 200
Tunnel 3, Präferenzstufe 1, 192.168.2.2, Anzahl der Zielsitzungen = 300
Tunnel 4, Präferenzstufe 2, 192.168.3.3, Anzahl der Zielsitzungen = 100
Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt die LAC zunächst zwischen den Zielen aus. Die Tunnel für 192.168.1.1 und 192.168.2.2 befinden sich auf Präferenzstufe 1. Die LAC wählt 192.168.1.1 aus, da sie eine niedrigere Sitzungsanzahl (200) als 192.168.2.2 (300) aufweist. Das LAC muss sich dann zwischen Tunnel 1 und Tunnel 2 entscheiden, da beide zu 192.168.1.1 gehen. Die LAC wertet die Anzahl der Tunnelsitzungen aus. Tunnel 2 hat eine niedrigere Anzahl (80) als Tunnel 1 (120), sodass die LAC Tunnel 2 für den ersten Teilnehmer auswählt.
Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:
Tunnel 2 wird so lange ausgewählt, bis die Anzahl der Tunnelsitzungen auf 120 ansteigt, was Tunnel 1 entspricht.
Wenn sich der nächste Teilnehmer anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da sie die gleiche Anzahl von Tunnelsitzungen haben. Die Anzahl der Tunnelsitzungen des ausgewählten Tunnels wird auf 121 erhöht.
Wenn sich der nächste Abonnent anmeldet, wählt die LAC den anderen Tunnel auf 192.168.1.1 aus, da er eine geringere Anzahl von Tunnelsitzungen aufweist. Von diesem Punkt an wechselt sich die LAC weiter ab, indem sie zuerst eine zufällige Auswahl zwischen den Tunneln 1 und 2 trifft und dann den anderen Tunnel auswählt, bis die Anzahl der Zielsitzungen auf 300 ansteigt, was der Sitzungsanzahl für 192.168.2.2 in Tunnel 3 entspricht. (Zu diesem Zeitpunkt beträgt die Anzahl der Tunnelsitzungen sowohl für Tunnel 1 als auch für Tunnel 2 150.)
Für den nächsten Abonnenten wählt die LAC nach dem Zufallsprinzip zwischen den Tunneln 1, 2 und 3 aus.
Wenn die LAC entweder Tunnel 1 oder Tunnel 2 auswählt, erhöht sich die Anzahl der Sitzungen 192.168.1.1 auf 301. Folglich wählt die LAC Tunnel 3 für den nächsten Teilnehmer aus, da die Anzahl der Sitzungen 192.168.2.2 immer noch 300 beträgt. Zu diesem Zeitpunkt haben beide Ziele wieder die gleiche Sitzungsanzahl.
Wenn die LAC Tunnel 3 auswählt, erhöht sich die Anzahl der Sitzungen 192.168.2.2 auf 301. Für den nächsten Abonnenten wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da beide zu 192.168.1.1 wechseln. Unabhängig davon, welche das LAC auswählt, steigt die Anzahl der Sitzungen 192.168.1.1 auf 301. Zu diesem Zeitpunkt haben beide Ziele wieder die gleiche Sitzungsanzahl.
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äferenzstufe 1, 192.168.1.1, Anzahl der Zielsitzungen = 100
Tunnel 2, Präferenzstufe 1, 192.168.2.2, Anzahl der Zielsitzungen = 100
Tunnel 3, Präferenzstufe 1, 192.168.3.3, Anzahl der Zielsitzungen = 100
Tunnel 4, Präferenzstufe 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 das LAC nach dem Zufallsprinzip aus den vier Tunneln aus.
Angenommen, die LAC wählt Tunnel 1 für den ersten Teilnehmer aus.
Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:
Die 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 (100) haben, die niedriger ist als die aktuelle Sitzungsanzahl für 192.168.1.1, 101.
Angenommen, die LAC wählt Tunnel 2 aus. Für den nächsten Abonnenten wählt die LAC nach dem Zufallsprinzip zwischen den Tunneln 3 und 4 aus, da 192.168.3.3 und 192.168.4.4 alle die gleiche Sitzungsanzahl (100) haben, die 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 Abonnenten wählt die LAC Tunnel 4 aus, da 192.168.4.4 eine Sitzungsanzahl von 100 und alle anderen Ziele eine Anzahl von 101 haben.
Jetzt haben die Ziele für alle vier Tunnel die gleiche Sitzungsanzahl. Da es nur vier Tunnel gibt, wird das endgültige Muster festgelegt. Während sich die Abonnenten weiterhin anmelden, wählt die LAC zuerst nach dem Zufallsprinzip alle vier Tunnel aus, dann die verbleibenden drei, dann das verbleibende Paar und schließlich den letzten Tunnel. Wenn die Anzahl der Zielsitzungen alle gleich sind, startet die LAC dieses Muster erneut.
In Szenario 4 wertet die LAC sowohl die Zielsitzungslimits als auch die maximalen Tunnelsitzungslimits aus:
Tunnel 1, Präferenzstufe 1, 192.168.1.1, Anzahl der Zielsitzungen = 30, maximales Sitzungslimit des Tunnels = 200
Tunnel 2, Präferenzstufe 1, 192.168.2.2, Anzahl der Zielsitzungen = 40, maximales Sitzungslimit des Tunnels = 200
Tunnel 3, Präferenzstufe 1, 192.168.3.3, Anzahl der Zielsitzungen = 300, maximales Sitzungslimit des Tunnels = 1000
Tunnel 4, Präferenzstufe 2, 192.168.4.4, Anzahl der Zielsitzungen = 100
Wenn der erste PPP-Benutzer versucht, eine Verbindung mit der Domäne herzustellen, wählt die LAC Tunnel 1 aus, da 192.168.1.1 die niedrigste Sitzungsanzahl in der Einstellungsebene aufweist.
Wenn weitere PPP-Benutzer versuchen, eine Verbindung mit der Domäne herzustellen, verhält sich die LAC wie folgt:
Die LAC fährt mit der Auswahl von Tunnel 1 fort, bis die Anzahl der Zielsitzungen für 192.168.1.1 gleich 40 ist und damit mit der Anzahl für 192.168.2.2 in Tunnel 2 übereinstimmt.
Wenn sich der nächste Teilnehmer anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 aus, da ihre Ziele die gleiche Sitzungsanzahl haben und niedriger ist als die für Tunnel 3 (300).
Unabhängig davon, welcher Tunnel aus diesem Paar ausgewählt wird, beträgt die Sitzungsanzahl für sein Ziel jetzt 41. Der andere Tunnel wird ausgewählt, wenn sich der nächste Teilnehmer anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 40 aufweist. Dadurch erhöht sich die Anzahl der Zielsitzungen auf 41, was mit dem anderen Tunnel übereinstimmt.
Während sich die Abonnenten weiterhin anmelden, wiederholt die LAC diesen Vorgang, indem sie nach dem Zufallsprinzip zwischen Tunnel 1 und Tunnel 2 auswählt, wenn die Anzahl ihrer Sitzungen übereinstimmt, und dann den anderen Tunnel mit dem nächsten Abonnenten auswählt, bis beide die Anzahl ihrer Zielsitzungen 200 erreichen, was ihrem maximalen Tunnelsitzungslimit von 200 entspricht. Da beide Tunnel ihr maximales Sitzungslimit erreicht haben, stehen sie nicht zur Auswahl.
Während 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 (1000) erreicht.
Wenn sich der nächste Teilnehmer anmeldet, wechselt die LAC zur nächsten Einstellungsebene und wählt Tunnel 4 aus, da dies der einzige Tunnel auf dieser Ebene ist.
Während sich die 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 maximale Grenze fällt.
In Szenario 5 ist eines der Ziele gesperrt:
Tunnel 1, Einstellungsstufe 1, 192.168.1.1, Anzahl der Zielsitzungen = 100, Ziel gesperrt
Tunnel 2, Präferenzstufe 1, 192.168.2.2, Anzahl der Zielsitzungen = 200
Tunnel 3, Präferenzstufe 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 ihr Ziel die geringste Sitzungsanzahl aufweist, da sich der Tunnel im Zielsperrzustand befindet. Tunnel 1 kann erst berücksichtigt werden, wenn er den gesperrten Zustand verlassen hat. Die 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 weitere Vorgehen davon ab, wann 192.168.1.1 aus dem Sperrzustand auftaucht. Solange 192.168.1.1 gesperrt ist, trifft die LAC die Auswahl wie folgt:
Die LAC fährt mit der Auswahl von Tunnel 2 fort, bis die Sitzungsanzahl für 192.168.2.2 gleich 250 ist und damit mit der Anzahl für 192.168.3.3 in Tunnel 3 übereinstimmt.
Wenn sich der nächste Teilnehmer anmeldet, wählt die LAC nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 3 aus, da ihre Ziele die gleiche Sitzungsanzahl (250) haben.
Unabhängig davon, welcher Tunnel aus diesem Paar ausgewählt wird, beträgt die Sitzungsanzahl für sein Ziel jetzt 251. Der andere Tunnel wird ausgewählt, wenn sich der nächste Teilnehmer anmeldet, da er die niedrigere Anzahl von Zielsitzungen von 250 aufweist. Dadurch erhöht sich die Anzahl der Zielsitzungen auf 251, was mit dem anderen Tunnel übereinstimmt.
Während sich die Abonnenten weiterhin anmelden, wiederholt die LAC diesen Vorgang, indem sie nach dem Zufallsprinzip zwischen Tunnel 2 und Tunnel 3 wählt, wenn die Anzahl ihrer Sitzungen übereinstimmt, und dann den anderen Tunnel mit dem nächsten Teilnehmer auswählt.
Immer wenn 192.168.1.1 aus dem Sperrzustand auftaucht, wählt die LAC Tunnel 1 für den nächsten Teilnehmer aus, da 192.168.1.1 die niedrigste Sitzungsanzahl aufweist. Die LAC setzt dies so lange fort, 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.
Immer wenn 192.168.1.1 aus dem Sperrzustand auftaucht,
Die LAC wählt Tunnel 1 für den nächsten Teilnehmer aus, da 192.168.1.1 die niedrigste Sitzungsanzahl aufweist.
Die LAC fährt mit der Auswahl von Tunnel 1 fort, 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 im Überblick
Wenn eine L2TP-Sitzungsanforderung initiiert wird, vergleicht LNS oder LAC die Anzahl der derzeit aktiven Sitzungen mit der maximal zulässigen Anzahl von Sitzungen für das Chassis, die Tunnel, eine Tunnelgruppe, einen Client (anforderndes Hostgerät) oder eine Gruppe von Clients. Neue Sitzungsanforderungen werden abgelehnt, wenn das konfigurierte Sitzungslimit erreicht ist.
Wenn eine Sitzung angefordert wird, prüft das LNS die Sitzungsgrenzen in der folgenden Reihenfolge:
Chassis > Tunnel > Tunnelgruppe > Sitzungsbegrenzungsgruppe > Client
Auf jeder Ebene bestimmt das LNS, ob die aktuelle Sitzungsanzahl kleiner als der konfigurierte Grenzwert ist. Wenn dies der Fall ist oder wenn kein Grenzwert konfiguriert ist, ist die Prüfung bestanden und das LNS fährt mit der Überprüfung der nächsten Ebene fort. Wenn auf einer Ebene die aktuelle Sitzungsanzahl dem konfigurierten Grenzwert entspricht, lehnt das 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 als Antwort auf die eingehende Anrufanforderung (Incoming-Call Request, ICRQ) eine CDN-Nachricht (Call-Disconnect-Notify) mit einem Ergebniscode und einem Fehlercode zurückgegeben, die beide auf 4 festgelegt sind. Wenn es sich bei der abgelehnten Anforderung um einen neuen Tunnel handelt, wird der Tunnel eingerichtet, aber die Sitzung kann nicht gestartet werden, was dazu führt, dass der Tunnel unterbrochen wird, weil er keine Sitzungen hat.
Das LAC führt die gleiche Prüfung durch, jedoch nur für die Chassis- und Tunnelebenen. Die LAC lehnt Anforderungen ab, indem sie eine PPP-Beendigungsnachricht an den Client zurücksendet.
Sie können Sitzungslimits für das Chassis, alle Tunnel, eine Tunnelgruppe, 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-Begrenzung
- Szenario 2: Tunnelbegrenzung
- Szenario 3: Begrenzung der Tunnelgruppe
- Szenario 4: Gruppenlimit für Sitzungslimit
- Szenario 5: Limit für einzelne Clients
Szenario 1: Chassis-Begrenzung
In Tabelle 1 beträgt die aktuelle Anzahl von L2TP-Sitzungen 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. Neue Sitzungen sind auf keiner Ebene zulässig, bis die aktuelle Sitzungsanzahl unter 10.000 fällt.
Ebene |
Konfiguriertes Sitzungslimit |
Anzeige der aktuellen Sitzungsanzahl per |
Ergebnis der Sitzungslimitprüfung |
|---|---|---|---|
Chassis |
10,000 |
10,000 |
Fehler |
Tunnel A |
10,000 |
10,000 |
– |
Tunnel Gruppe B |
10,000 |
10,000 |
– |
Gruppe "Sitzungslimit" |
10,000 |
10,000 |
– |
Kunde |
10,000 |
10,000 |
– |
Szenario 2: Tunnelbegrenzung
In Tabelle 2 beträgt die aktuelle Anzahl der L2TP-Sitzungen 2000. Wenn eine neue Sitzung angefordert wird, ist die erste Prüfung auf Chassis-Ebene erfolgreich, da das konfigurierte Limit bis zu 10.000 Sitzungen auf dem Chassis zulässt, aber derzeit nur 2000 Sitzungen aktiv sind. Die nächste Prüfung auf Tunnelebene schlägt fehl, da die aktuelle Sitzungsanzahl mit dem konfigurierten Grenzwert von 2000 für Tunnel A übereinstimmt.
Auf den anderen Ebenen werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt.
Ebene |
Konfiguriertes Sitzungslimit |
Anzeige der aktuellen Sitzungsanzahl per |
Ergebnis der Sitzungslimitprüfung |
|---|---|---|---|
Chassis |
10,000 |
2000 |
Bestehen |
Tunnel A |
2000 |
2000 |
Fehler |
Tunnel Gruppe B |
10,000 |
2000 |
– |
Gruppe "Sitzungslimit" |
6000 |
2000 |
– |
Kunde |
6000 |
2000 |
– |
Auf Tunnel A sind keine neuen Sitzungen zulässig, bis die aktuelle Sitzungsanzahl unter 2000 fällt und die Sitzungsprüfung bestanden werden kann. In diesem Fall werden die Überprüfungen der anderen Ebenen in diesem Szenario bestanden, da die konfigurierten Grenzwerte größer sind als die 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 bestanden, solange die aktuelle Sitzungsanzahl für diesen Tunnel kleiner als 2000 ist.
Szenario 3: Begrenzung der Tunnelgruppe
In Tabelle 3 beträgt die aktuelle Anzahl der L2TP-Sitzungen 2000. Wenn eine neue Sitzung angefordert wird, ist die erste Prüfung auf Chassis-Ebene erfolgreich, da das konfigurierte Limit bis zu 10.000 Sitzungen auf dem Chassis zulässt, aber derzeit nur 2000 Sitzungen aktiv sind. Die zweite Prüfung auf Tunnelebene besteht ebenfalls aus dem gleichen Grund. Die nächste Prüfung auf Tunnelgruppenebene für Tunnelgruppe B schlägt fehl, da die aktuelle Sitzungsanzahl für Tunnelgruppe B mit dem konfigurierten Grenzwert für Tunnelgruppen von 2000 übereinstimmt.
Auf den anderen Ebenen werden keine weiteren Prüfungen durchgeführt und die Sitzungsanforderung wird abgelehnt.
Ebene |
Konfiguriertes Sitzungslimit |
Anzeige der aktuellen Sitzungsanzahl per |
Ergebnis der Sitzungslimitprüfung |
|---|---|---|---|
Chassis |
10,000 |
2000 |
Bestehen |
Tunnel A |
10,000 |
2000 |
Bestehen |
Tunnel Gruppe B |
2000 |
2000 |
Fehler |
Gruppe "Sitzungslimit" |
6000 |
2000 |
– |
Kunde |
6000 |
2000 |
– |
Für Tunnelgruppe B sind keine neuen Sitzungen zulässig, 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 Ebenen bestanden werden, da die konfigurierten Grenzwerte größer sind als die aktuelle Anzahl.
Bei Tunnelgruppen wird das Sitzungslimit pro Gruppe konfiguriert. Das heißt, Sie können keinen einzigen Grenzwert angeben, der für alle Tunnelgruppen gilt. Der Ausfall einer Tunnelgruppe hat keine Auswirkungen auf andere Tunnelgruppen. In diesem Szenario wird eine Sitzungsanforderung für eine andere Tunnelgruppe bestanden, 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 Anzahl der L2TP-Sitzungen 6000. Wenn eine neue Sitzung angefordert wird, wird die Prüfung für die Chassis-, Tunnel- und Tunnelgruppe bestanden, da das konfigurierte Limit für jede Sitzung bis zu 10.000 Sitzungen zulässt, aber derzeit nur 6000 Sitzungen aktiv sind. Die Prüfung an der session-limit-Gruppe schlägt fehl, da die aktuelle session-Anzahl für session-limit-group slg1 dem konfigurierten Limit von 6000 entspricht.
Auf der verbleibenden Ebene werden keine weiteren Prüfungen durchgeführt, und die Sitzungsanforderung wird abgelehnt.
Ebene |
Konfiguriertes Sitzungslimit |
Anzeige der aktuellen Sitzungsanzahl per |
Ergebnis der Sitzungslimitprüfung |
|---|---|---|---|
Chassis |
10,000 |
6000 |
Bestehen |
Tunnel A |
10,000 |
6000 |
Bestehen |
Tunnel Gruppe 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 Prüfung des verbleibenden Niveaus bestanden werden, da der konfigurierte Grenzwert größer ist als der aktuelle Zählerstand.
Sie können eine Sitzungsbegrenzungsgruppe 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, durch die Anzahl der aktuellen Sitzungen dieses Clients reduziert. Die neue Summe der aktuellen Sitzungen für vorhandene Clients und den neuen 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 Sitzungsanzahl unter den konfigurierten Gruppengrenzwert fällt.
Um dies weiter zu untersuchen, betrachten Sie die folgende Abfolge von Ereignissen:
Die Sitzungsbegrenzungsgruppe 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 die folgenden Clients nicht mehr als 2500 Sitzungen hinzugefügt werden:
6000 - 3500 = 2500
Dann werden 1000 Sitzungen für Client ent1-Service B angemeldet. Jetzt können für diese Clients nicht mehr als 1500 Sitzungen hinzugefügt werden:
6000 - (3500 + 1000) = 1500
Angenommen, Sie entfernen Client ent1-serviceA aus der Sitzungsbegrenzungsgruppe. Die Gruppensitzungskapazität erhöht sich auf 5000 Sitzungen:
6000 - 1000 = 5000
Zum Schluss fügen Sie der Gruppe session-limit einen neuen Client (ent1-serviceC) hinzu. Dieser neue Client hat derzeit 8000 aktive Sitzungen. In diesem Fall hat die Session-Limit-Gruppe jetzt 9000 Sitzungen:
1000 + 8000 = 9000
Es werden keine Sitzungen verworfen, obwohl das maximale Sitzungslimit für die Gruppe (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: Limit für einzelne Clients
In Tabelle 5 ist die Sitzungsprüfung für die Chassis-, Tunnel- und Tunnelgruppe erfolgreich, da deren konfigurierte Grenzwerte größer sind als die aktuelle Sitzungsanzahl. Der Client ent1-serviceA gehört nicht zu einer Session-Limit-Gruppe. Die Grenzwertüberprüfung schlägt für den Client fehl, da die aktuelle Sitzungsanzahl mit dem konfigurierten Grenzwert von 6000 übereinstimmt.
Ebene |
Konfiguriertes Sitzungslimit |
Anzeige der aktuellen Sitzungsanzahl per |
Ergebnis der Sitzungslimitprüfung |
|---|---|---|---|
Chassis |
10,000 |
6000 |
Bestehen |
Tunnel A |
10,000 |
6000 |
Bestehen |
Tunnel Gruppe B |
8000 |
6000 |
Bestehen |
Auftraggeber 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 Sitzungsüberprü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 kleiner als das konfigurierte Sitzungslimit ist.
Das Sitzungslimit, das Sie für einen einzelnen Client festlegen – einen, der nicht Teil einer Sitzungslimitgruppe ist – gilt für jede Tunnelgruppe. 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 den gleichen Quell-Hostnamen, ce-lac. LAC A und LAC B bauen über die Gateway-Adresse, die Tunnelgruppe 1 zugeordnet ist, Sitzungen mit einem LNS auf. LAC C richtet Sitzungen über ein anderes Gateway ein, das der Tunnelgruppe 2 zugeordnet ist. Da die LACs denselben Hostnamen haben, ist die Clientkonfiguration für alle drei identisch. Das Clientsitzungslimit gilt jedoch aufgrund der Tunnelgruppen anders für die LAC.
Angenommen, der Grenzwert für Clientsitzungen beträgt 100. Da sowohl LAC A als auch LAC B Sitzungen in Tunnelgruppe 1 erstellen, müssen sie sich das Clientlimit 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 Tunnelgruppe, 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 vom LAC oder LNS zugelassen werden
Sie können die maximal zulässige Anzahl von L2TP-Sitzungen für das Chassis, alle Tunnel, eine Tunnelgruppe, eine Gruppe von Clients, einen einzelnen Client oder eine einzelne Serviceschnittstelle oder aggregierte Serviceschnittstelle begrenzen. Neue Sitzungsanforderungen werden vom LNS oder LAC zurückgewiesen, wenn das konfigurierte Sitzungslimit erreicht ist. Sitzungsanforderungen werden auch abgelehnt, wenn das maximale Chassis-Limit erreicht ist, selbst wenn ein konfiguriertes Limit nicht überschritten wird. Konfigurierbare Sitzungslimits ermöglichen eine fein abgestufte Steuerung der Anzahl der Sitzungen, die ein Kunde haben kann, während er über LACs an mehreren Standorten verbunden ist.
Sie können den Grenzwert nicht höher als den standardmäßigen Maximalgrenzwert für das Chassis festlegen.
So begrenzen Sie die Anzahl der Sitzungen, die auf einem Gehäuse (LAC oder LNS) zulässig sind:
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit services l2tp] user@host# set maximum-sessions number
So begrenzen Sie die Anzahl der Sitzungen pro Tunnel für alle Tunnel (LAC oder LNS):
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit services l2tp tunnel ] user@host# set maximum-sessions number
Sie können das Limit nicht auf mehr als 65.535 Sitzungen festlegen.
So begrenzen Sie die Anzahl der Sitzungen für alle Tunnel in einer bestimmten Tunnelgruppe (LNS):
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit services l2tp tunnel-group tunnel-group-name] user@host# set maximum-sessions number
So begrenzen Sie die Anzahl der Sitzungen, die auf einer einzelnen Dienstschnittstelle zulässig sind:
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit interfaces si-slot/pic/port] user@host# set l2tp-maximum-session number
So begrenzen Sie die Anzahl der Sitzungen, die auf einer einzelnen aggregierten Dienstschnittstelle zulässig sind:
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit interfaces asinumber] user@host# set l2tp-maximum-session number
Hinweis:Die Konfiguration gilt für alle Memberschnittstellen. Der Grenzwert kann nicht für einzelne Memberschnittstellen der aggregierten Serviceschnittstelle konfiguriert werden.
So begrenzen Sie die Anzahl der Sitzungen für eine Gruppe von Clients (LNS):
So begrenzen Sie die Anzahl der Sitzungen für einen Client, der kein Mitglied einer Sitzungsbegrenzungsgruppe (LNS) ist:
Konfigurieren Sie die maximale Anzahl von Sitzungen.
[edit access profile profile-name client client-name] user@host# set maximum-sessions number
Wenn Sie das Sitzungslimit auf einer beliebigen Ebene so konfigurieren, dass es kleiner ist als die Anzahl der Sitzungen, die derzeit auf dieser Ebene vorhanden sind, hat dies keine Auswirkungen auf vorhandene Sitzungen. Das neue Limit gilt nur, wenn die Anzahl der Sitzungen unter das neue Limit fällt.
Sie können den show services l2tp summary extensive Befehl verwenden, um das konfigurierte Sitzungslimit für einen Tunnel anzuzeigen:
user@host> show services l2tp tunnel extensive
...
Max sessions: 32000, Window size: 4, Hello interval: 60
...
Der angezeigte Grenzwert für konfigurierte Sitzungen ist auf den niedrigsten der folgenden konfigurierten Sitzungswerte festgelegt:
Global (Chassis) – (LAC und LNS)
set services l2tp tunnel maximum-sessionsnumberTunnelprofil (Einzeltunnel) – (LAC und LNS)
set access tunnel-profile profile-name tunnel tunnel-idmax-sessionsnumber]RADIUS—(LAC und LNS) Wert von VSA 26–33, Tunnel-Max-Sessions
Hostprofil: (nur LNS)
set access profile profile-name client client-name l2tp maximum-sessions-per-tunnel
Die konfigurierten Werte bestimmen den Feldwert ab den folgenden Junos OS-Versionen: 19.2R3, 19.3R3, 19.4R3, 20.1R2, 20.2R2 und 20.3R1. In früheren Versionen zeigt das Feld den Hostprofilwert für das LNS an, für das LAC jedoch einen festen Wert von 512.000.
Nach einem GRES, einer vereinheitlichten ISSU oder einem Neustart des jl2tpd-Prozesses ist der Wert dieses Feldes erst dann korrekt, wenn eine neue Sitzung im Tunnel gestartet wird. Bis dahin zeigt das Feld den Wert 65.535 anstelle des konfigurierten Werts an.
Angenommen, Sie haben zwei Tunnel, Tunnel A und Tunnel B. Es findet ein GRES statt, und das Feld für jeden Tunnel zeigt 65.535 an. Wenn eine neue Sitzung in Tunnel B gestartet wird, wird der Wert für diesen Tunnel auf den konfigurierten Wert aktualisiert. Für Tunnel A zeigt das Feld weiterhin 65.535 an, bis dieser Tunnel eine neue Sitzung erhält.
Festlegen des Formats für den Tunnelnamen
Standardmäßig entspricht der Name eines Tunnels der Tunnel-Assignment-Id [82], die vom AAA-Server zurückgegeben wird. Optional können Sie die LAC so konfigurieren, dass weitere Elemente beim Aufbau eines Tunnelnamens verwendet werden, indem Sie die assignment-id-format client-server-id Anweisung auf Hierarchieebene [edit services l2tp tunnel] einfügen. Dieses Format verwendet drei Attribute: Tunnel-Client-Auth-Id [90], Tunnel-Server-Endpoint [67] und Tunnel-Assignment-Id [82]. Diese Attribute entsprechen den Werten, die im Tunnelprofil für den LAC-Namen (Quell-Gateway), die Adresse des Tunnelendpunkts (Remote-Gateway) auf dem LNS und die Tunnel-ID konfiguriert sind.
Eine Folge des client-server-id Formats ist, dass die LAC automatisch einen neuen Tunnel erstellt, wenn der AAA-Server eine andere Tunnel-Client-Auth-Id als die zuvor zurückgegebene zurückgibt.
Bevor Sie ein Downgrade auf eine Junos OS-Version durchführen, die diese Anweisung nicht unterstützt, wird empfohlen, die Konfiguration der Funktion explizit aufzuheben, indem Sie die no assignment-id-format assignment-id Anweisung auf Hierarchieebene [edit services l2tp tunnel] einfügen.
So ändern Sie die Formatierung des Tunnelnamens:
Konfigurieren Sie das Format.
[edit services l2tp tunnel] user@host# set assignment-id-format client-server-id
Konfigurieren eines Tunnelprofils für den Abonnentenzugriff
Das Tunnelprofil spezifiziert eine Reihe von Attributen zur Charakterisierung des Tunnels. Das Profil kann über eine Domänenzuordnung oder automatisch bei der Erstellung des Tunnels angewendet werden.
RADIUS-Attribute und VSAs können die Werte überschreiben, die Sie durch ein Tunnelprofil in einer Domänenzuordnung konfiguriert haben. In Ermangelung einer Domänenzuordnung kann RADIUS alle Eigenschaften eines Tunnels bereitstellen. In den Schritten des folgenden Verfahrens wird das entsprechende standardmäßige RADIUS-Attribut oder VSA aufgeführt, das Sie auf dem RADIUS-Server konfigurieren können, um das Tunnelprofil zu ändern oder zu konfigurieren.
Von RADIUS bereitgestellte Attribute sind einem Tunnel durch ein im Attribut enthaltenes Tag zugeordnet, das mit der Tunnelkennung übereinstimmt. Ein Tag von 0 gibt an, dass das Tag nicht verwendet wird. Wenn L2TP ein RADIUS-Attribut mit dem Tag 0 empfängt, kann das Attribut nicht mit der Tunnelprofilkonfiguration zusammengeführt werden, die der Abonnentendomäne entspricht, da ein Tunnelprofil kein Tunnel-Tag (Tunnelbezeichner) 0 bereitstellen kann. Es werden nur Tags im Bereich von 1 bis 31 unterstützt.
So konfigurieren Sie eine Tunneldefinition für ein Tunnelprofil:
Das folgende Beispiel zeigt eine vollständige Konfiguration für ein Tunnelprofil:
tunnel-profile marketing {
tunnel 1 {
preference 5;
remote-gateway {
address 198.51.100.4;
gateway-name work;
}
source-gateway {
address 192.0.2.10;
gateway-name local;
}
secret $ABC123;
logical-system bos-metro-5;
routing-instance rox-12-32;
medium ipv4;
type l2tp;
identification tunnel_to_work;
max-sessions 32;
nas-port-method cisco avp;
}
}
Konfigurieren der L2TP-LAC-Tunnelauswahlparameter
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 zugeordnet sind. Sie können konfigurieren, wie ein Tunnel ausgewählt wird und ob bestimmte Informationen vom LAC an das LNS gesendet werden.
So konfigurieren Sie Tunnelauswahlparameter:
Konfigurieren des LAC-Tunnelauswahl-Failovers innerhalb einer Präferenzebene
Sie können konfigurieren, wie die Auswahl des LAC-Tunnels im Falle eines Verbindungsfehlers fortgesetzt wird. Wenn der Router nicht in der Lage ist, eine Verbindung zu einem Ziel auf einer bestimmten Einstellungsebene herzustellen, versucht er standardmäßig, eine Verbindung auf der nächstniedrigeren Ebene herzustellen. Sie können angeben, dass der Router stattdessen versucht, eine Verbindung zu einem anderen Ziel auf derselben Ebene wie der fehlgeschlagene Versuch herzustellen.
Wenn alle Ziele auf einer Einstellungsebene als nicht erreichbar markiert sind, versucht der Router nicht, eine Verbindung zu einem Ziel auf dieser Ebene herzustellen. Er wird auf die nächstniedrigere Präferenzebene abgesenkt, um ein Ziel auszuwählen.
Wenn alle Ziele auf allen Einstellungsebenen als nicht erreichbar markiert sind, wählt der Router das Ziel aus, das zuerst fehlgeschlagen ist, und versucht, eine Verbindung herzustellen. Wenn die Verbindung fehlschlägt, lehnt der Router die PPP-Benutzersitzung ab, ohne zu versuchen, den Remote-Router zu kontaktieren.
Angenommen, es gibt vier Tunnel für eine Domäne: A, B, C und D. Alle Tunnel gelten als erreichbar, und die Präferenzebenen werden wie folgt zugewiesen:
A und B mit Präferenz 0
C und D bei Präferenz 1
Wenn der Router versucht, eine Verbindung mit der Domäne herzustellen, wird davon ausgegangen, dass er nach dem Zufallsprinzip Tunnel B aus der Einstellung 0 auswählt. Wenn keine Verbindung zu Tunnel B hergestellt werden kann, schließt der Router Tunnel B für fünf Minuten aus und versucht, eine Verbindung zu Tunnel A herzustellen. Wenn auch dieser Versuch fehlschlägt, fällt der Router auf Präferenz 1 zurück. Angenommen, der Router wählt Tunnel C aus. Wenn auch die Verbindung zu Tunnel C fehlschlägt, schließt der Router Tunnel C für fünf Minuten aus und versucht, eine Verbindung zu Tunnel D herzustellen.
Sie konfigurieren die Präferenzebene, die für diese Tunnelauswahlmethode verwendet wird, im Tunnelprofil oder im Attribut RADIUS Tunnel-Präferenz [83].
So aktivieren Sie das Tunnelauswahl-Failover innerhalb einer Voreinstellungsebene:
Geben Sie das Failover in den Einstellungen an.
[edit services l2tp] user@host# set failover-within-preference
Konfigurieren des gewichteten Lastenausgleichs für LAC-Tunnelsitzungen
Standardmäßig wählt die L2TP-LAC Tunnel für neue Sitzungen nach dem Zufallsprinzip innerhalb der höchsten verfügbaren Präferenzebene aus. Sie können die LAC so konfigurieren, dass Sitzungen auf der höchsten verfügbaren Präferenzebene auf Tunnel verteilt werden, indem Sie das Gewicht jedes Tunnels auswerten. Diese Methode wird als gewichteter Lastenausgleich bezeichnet. Die Gewichtung eines Tunnels ist proportional zu seinem maximalen Sitzungslimit und den maximalen Sitzungsgrenzen der anderen Tunnel auf derselben Präferenzebene. Wenn Sie das gewichtete Load Balancing konfigurieren, wählt die LAC die Tunnel weiterhin nach dem Zufallsprinzip innerhalb einer Präferenzebene aus, aber im Durchschnitt werden die Sitzungen im Verhältnis zu den Tunnelgewichtungen auf die Tunnel verteilt.
So konfigurieren Sie den gewichteten Lastenausgleich:
Geben Sie den Lastenausgleich an.
[edit services l2tp] user@host# set weighted-load-balancing
Konfigurieren von Destination-Equal Load Balancing für LAC-Tunnelsitzungen
Standardmäßig wählt die L2TP-LAC Tunnel für neue Sitzungen nach dem Zufallsprinzip innerhalb der höchsten verfügbaren Präferenzebene aus. Ab Junos OS Version 15.1 können Sie die LAC so konfigurieren, dass Sitzungen gleichmäßig auf alle Tunnel auf der höchsten verfügbaren Präferenzebene verteilt werden, indem Sie die Anzahl der Sitzungen zu den Zielen und die Anzahl der von den Tunneln übertragenen Sitzungen auswerten. Diese Verteilungsmethode wird als Destination-Equal-Load-Balancing bezeichnet. Das LAC wählt den Tunnel mit der geringsten Last nach folgenden Richtlinien aus:
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 niedrige 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 geringsten Gesamtzahl von Tunnelsitzungen aus. Wenn die Anzahl der Tunnelsitzungen für alle diese Tunnel gleich ist, wählt die LAC einen von ihnen nach dem Zufallsprinzip aus.
So konfigurieren Sie den Destination Equal Load Balancing:
Geben Sie den Lastenausgleich für das Ziel an.
[edit services l2tp] user@host# set destination-equal-load-balancing
Aktivieren der LAC für IPv6-Services
Sie können die LAC so konfigurieren, dass sie die IPv6-Adressfamilie (inet6) erstellt, wenn die Abonnenten zum LNS getunnelt werden. IPv6-Firewallfilter können dann von Services auf der LAC auf den Teilnehmerdatenverkehr angewendet werden. Standardmäßig benötigt die LAC nur family inet, um die Weiterleitung in einen IP-Tunnel zu ermöglichen. Die LAC kann IPv4-Firewallfilter auf die Sitzung anwenden. Auch wenn die Familie inet6 im dynamischen Profil enthalten ist, wird sie standardmäßig nicht erstellt, um Ressourcen zu schonen, da sie nicht benötigt wird. Folglich können keine IPv6-Firewall-Filter angewendet werden.
Gehen Sie wie folgt vor, um die Erstellung einer IPv6-Adressfamilie und die Anwendung von IPv6-Firewallfiltern zu aktivieren:
Konfigurieren Sie die Aktivierung.
[edit services l2tp] user@host# set enable-ipv6-services-for-lac
Sie können den show services l2tp summary Befehl verwenden, um anzuzeigen, ob die Anweisung aktiviert oder deaktiviert ist.
Testen von L2TP-Tunnelkonfigurationen aus der LAC
Sie können L2TP-Tunnelkonfigurationen auf der LAC und erfolgreiche Abonnentenauthentifizierung und Tunneling testen, ohne einen PPP-Benutzer und einen zugehörigen Tunnel aufzurufen.
Geben Sie den test services l2tp tunnel Befehl aus dem CLI-Betriebsmodus aus, um einen Abonnenten einem L2TP-Tunnel zuzuordnen, die L2TP-Tunnelkonfiguration zu überprüfen (sowohl lokal auf der LAC als auch auf einem Back-End-Server wie einem RADIUS-Server) und sicherzustellen, dass L2TP-Tunnel von der LAC mit dem Remote-LNS eingerichtet werden können.
Mit der LAC-Implementierung von Junos OS können Sie mehrere Tunnel konfigurieren, von denen ein Tunnel für das Tunneling eines PPP-Abonnenten ausgewählt wird. Sie können den test services l2tp tunnel Befehl verwenden, um alle möglichen Tunnelkonfigurationen zu testen, um sicherzustellen, dass jede eingerichtet werden kann. Alternativ können Sie auch nur einen bestimmten Tunnel für den Abonnenten testen.
Sie müssen einen konfigurierten Abonnentenbenutzernamen angeben, wenn Sie den Befehl absetzen. Der Test generiert ein Dummy-Kennwort (testpass) für den Abonnenten, oder Sie können das Kennwort optional angeben. Mit dem Test wird überprüft, ob der durch diesen Benutzernamen identifizierte Abonnent gemäß der Tunnelkonfiguration getunnelt werden kann. Wenn der Teilnehmer getunnelt werden kann, prüft der Test, ob der L2TP-Tunnel mit dem LNS gemäß der L2TP-Konfiguration aufgebaut werden kann.
Sie können optional eine Tunnel-ID angeben, in diesem Fall wird nur dieser Tunnel getestet. Der Tunnel muss bereits für diesen Benutzernamen konfiguriert sein. Wenn Sie diese Option weglassen, wird der Test auf den vollständigen Satz von Tunnelkonfigurationen angewendet, die für den Benutzernamen zurückgegeben werden. Die von Ihnen angegebene Tunnel-ID ist identisch mit der von Tunnel-Assignment-Id (RADIUS-Attribut 82) verwendeten und durch die identification Anweisung im Tunnelprofil angegebenen ID.
So testen Sie die Abonnentenauthentifizierung und Tunnelkonfiguration:
Geben Sie nur den Benutzernamen an.
Beispiel 1:
user@host> test services l2tp tunnel user test-user1@example.com Subscriber: test-user1@example.com, authentication failed
Der Benutzer hat die Authentifizierung mit dem generierten Kennwort nicht bestanden und wurde folglich nicht getunnelt.
Beispiel 2:
user@host> test services l2tp tunnel user user23@example.com Subscriber: user23@example.com, authentication success, l2tp tunneled Tunnel-name Tunnel-peer Logical-System Routing-Instance Status test1tunnel 192.168.2.3 default default Up test2tunnel 192.168.30.3 default default Peer unresponsive test3tunnel 192.168.50.1 default test Up
Dieser Benutzer wurde mit dem generierten Kennwort authentifiziert und erfolgreich getunnelt. Es wurde festgestellt, dass eine Reihe von Tunneln mit diesem Benutzernamen verknüpft war, und die gesamte Gruppe wurde getestet.
Geben Sie den Benutzernamen und das konfigurierte Kennwort des Benutzers an.
user@host> test services l2tp tunnel user test-user1@example.com password grZ98#jW Subscriber: test-user1@example.com, authentication success, locally terminated
Der Abonnent wurde authentifiziert. Der Benutzer wurde jedoch lokal beendet und nicht getunnelt. Dies bedeutet, dass kein Tunnel gefunden wurde, der dem Benutzer zugeordnet ist.
Geben Sie den Benutzernamen und einen bestimmten Tunnel für den Abonnenten an.
user@host> test services l2tp tunnel user rx37w@example.com tunnel-name ce-lac Subscriber: rx37w@example.com, authentication success, l2tp tunneled Tunnel-name Tunnel-peer Logical-System Routing-Instance Status ce-lac 192.168.5.10 default default Up
Der Abonnent wurde authentifiziert und getunnelt. Der angegebene Tunnel wurde für den Teilnehmer gefunden, und der Tunnel wurde eingerichtet, wodurch die Tunnelkonfiguration bestätigt wurde.
Geben Sie den Benutzernamen, das konfigurierte Kennwort des Benutzers und einen Tunnel an.
user@host> test services l2tp tunnel user fanta4-mfg-fan@example.com password dieda499 tunnel-name tunnel5 Subscriber: fanta4-mfg-fan@example.com, authentication success, l2tp tunneled
Der Abonnent wurde authentifiziert und getunnelt. Das Fehlen von Tunnelinformationen in der Ausgabe weist darauf hin, dass die angegebene Tunnelkonfiguration nicht vorhanden ist.