Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

L2TP LNS Inline-Serviceschnittstellen

Konfiguration eines L2TP-LNS mit Inline-Serviceschnittstellen

Die L2TP LNS-Featurelizenz muss installiert werden, bevor Sie mit der Konfiguration beginnen. Andernfalls wird eine Warnmeldung angezeigt, wenn ein Commit für die Konfiguration ausgeführt wird.

So konfigurieren Sie ein L2TP-LNS mit Inline-Serviceschnittstellen:

  1. (Optional) Konfigurieren Sie ein Benutzergruppenprofil, das die PPP-Konfiguration für Tunnel-Abonnenten definiert.
  2. (Optional) Konfigurieren Sie PPP-Attribute für Abonnenten auf Inline-Serviceschnittstellen.
  3. Konfigurieren Sie die Inline-IP-Reassemblierung.
  4. Konfigurieren Sie ein L2TP-Zugriffsprofil, das die L2TP-Parameter für jeden LNS-Client (LAC) definiert.
  5. (Optional) Konfigurieren Sie ein AAA-Zugriffsprofil, um das unter der Routing-Instance konfigurierte Zugriffsprofil zu überschreiben.
  6. Konfigurieren Sie einen Adresspool, der getunnelten PPP-Abonnenten dynamisch zugewiesen werden soll.
  7. Konfigurieren Sie die Peer-Schnittstelle zum Beenden des Tunnels und der serverseitigen PPP-IPCP-Adresse.
  8. Aktivieren Sie Inline-Serviceschnittstellen auf einer MPC.
  9. Konfigurieren Sie eine Dienstschnittstelle.
  10. Konfigurieren Sie Optionen für jede logische Inline-Serviceschnittstelle.
  11. (Optional) Konfigurieren Sie eine aggregierte Inline-Serviceschnittstelle und zustandsbehaftete 1:1-Redundanz.
  12. Konfigurieren Sie die L2TP-Tunnel-Gruppe.
  13. (Optional) Konfigurieren Sie ein dynamisches Profil, das logische L2TP-Schnittstellen dynamisch erstellt.
  14. (Optional) Konfigurieren Sie einen Service-Schnittstellen-Pool für dynamische LNS-Sitzungen.
  15. (Optional) Legen Sie fest, wie oft L2TP unbestätigte Steuernachrichten erneut überträgt.
  16. (Optional) Geben Sie an, wie lange ein Tunnel ungenutzt bleiben kann, bevor er abgerissen wird.
  17. (Optional) Geben Sie die Größe des L2TP-Empfangsfensters für den L2TP-Tunnel an. Die Größe des Empfangsfensters gibt die Anzahl der Pakete an, die ein Peer senden kann, bevor er auf eine Bestätigung vom Router wartet.
  18. (Optional) Geben Sie an, wie lange das L2TP Informationen über beendete dynamische Tunnel, Sitzungen und Ziele aufbewahrt.
  19. (Optional) Konfigurieren Sie die Zeitüberschreitung für die L2TP-Zielsperre.
  20. (Optional) Konfigurieren Sie L2TP-Tunnel-Switching.
  21. (Optional) Verhindern Sie die Erstellung neuer Sitzungen, Ziele oder Tunnel für L2TP.
  22. (Optional) Konfigurieren Sie, ob das L2TP-Failover-Protokoll ausgehandelt wird oder die Silent-Failover-Methode für die Neusynchronisierung verwendet wird.
  23. (Optional) Aktivieren Sie SNMP-Statistikzähler.
  24. (Optional) Konfigurieren Sie Ablaufverfolgungsoptionen für die Fehlerbehebung der Konfiguration.

Sie müssen auch CoS für LNS-Sitzungen konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von dynamischem CoS für einen L2TP LNS-Inline-Service.

Anwenden von PPP-Attributen auf L2TP LNS-Abonnenten pro Inline-Serviceschnittstelle

Sie können PPP-Attribute konfigurieren, die vom LNS auf der Inline-Service-Schnittstelle (si) auf die PPP-Abonnenten angewendet werden, die von der LAC getunnelt werden. Da Sie die Attribute pro Schnittstelle und nicht mit einem Benutzergruppenprofil konfigurieren, können die Attribute für Abonnenten mit einer feineren Granularität variiert werden. Diese Konfiguration entspricht der Konfiguration für beendete PPPoE-Abonnenten.

So konfigurieren Sie die PPP-Attribute für dynamisch erstellte si-Schnittstellen:

  1. Geben Sie die vordefinierte dynamische Schnittstelle und die logischen Schnittstellenvariablen im dynamischen Profil an.
  2. Konfigurieren Sie das Intervall zwischen PPP-Keepalive-Meldungen für den L2TP-Tunnel, der auf dem LNS endet.
  3. Konfigurieren Sie PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten im LNS gelten.
  4. Geben Sie eine Reihe von AAA-Optionen an, die für die Authentifizierung und Autorisierung von getunnelten PPP-Abonnenten am LNS verwendet werden, die sich über die im AAA-Optionssatz angegebenen Anwender- und AAA-Kontexte anmelden.

    Der Optionssatz wird mit der aaa-options aaa-options-name Anweisung auf Hierarchieebene [edit access] konfiguriert.

  5. Konfigurieren Sie den Router so, dass er CPE (Customer Premises Equipment) auffordert, während der IPCP-Aushandlung für getunnelte PPP-Abonnenten am LNS sowohl primäre als auch sekundäre DNS-Adressen auszuhandeln.
  6. (Optional) Deaktivieren Sie die Validierung der PPP Magic Number während der LCP-Aushandlung und im LCP-Keepalive-Austausch (Echo-Request/Echo-Reply). Verhindert den Vergleich der empfangenen magischen Zahl mit der intern generierten magischen Zahl, sodass eine Abweichung nicht zum Abbruch der Sitzung führt.

So konfigurieren Sie die PPP-Attribute für statisch erzeugte si-Schnittstellen:

  1. Geben Sie die logische Inline-Serviceschnittstelle an.

  2. Konfigurieren Sie das Intervall zwischen PPP-Keepalive-Meldungen für den L2TP-Tunnel, der auf dem LNS endet.

  3. Konfigurieren Sie die Anzahl der Keepalive-Pakete, die ein Ziel nicht empfangen darf, bevor das Netzwerk eine Verbindung trennt.

    Hinweis:

    Die Option wird in der Regel nicht für die keepalives up-count Verwaltung von Anwendern verwendet.

  4. Konfigurieren Sie PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten im LNS gelten.

  5. Konfigurieren Sie den Router so, dass er CPE (Customer Premises Equipment) auffordert, während der IPCP-Aushandlung für getunnelte PPP-Abonnenten am LNS sowohl primäre als auch sekundäre DNS-Adressen auszuhandeln.

Optimale Vorgehensweise:

Obwohl alle anderen Anweisungen, die untergeordnet sind – ppp-optionseinschließlich derjenigen, die und untergeordnet chap papsind – unterstützt werden, werden sie in der Regel nicht für die Verwaltung von Anwendern verwendet. Es wird empfohlen, diese anderen Anweisungen auf ihren Standardwerten zu belassen.

Hinweis:

Sie können PPP-Attribute auch mit einem Benutzergruppenprofil konfigurieren, das die Attribute auf alle Abonnenten mit diesem Profil auf einem LAC-Client anwendet. Weitere Informationen finden Sie unter Anwenden von PPP-Attributen auf L2TP LNS-Abonnenten mit einem Benutzergruppenprofil . Wenn Sie die PPP-Attribute für L2TP LNS-Abonnenten sowohl auf der si-Schnittstelle als auch in Benutzergruppenprofilen konfigurieren, hat die Konfiguration der Inline-Serviceschnittstelle Vorrang vor der Konfiguration des Benutzergruppenprofils.

Hinweis:

Wenn PPP-Optionen sowohl in einem Gruppenprofil als auch in einem dynamischen Profil konfiguriert sind, hat die Konfiguration des dynamischen Profils vollständigen Vorrang vor dem Gruppenprofil, wenn das dynamische Profil eine oder mehrere der PPP-Optionen enthält, die im Gruppenprofil konfiguriert werden können. Vollständige Rangfolge bedeutet, dass es keine Zusammenführung von Optionen zwischen den Profilen gibt. Das Gruppenprofil wird nur dann auf den Anwender angewendet, wenn das dynamische Profil keine im Gruppenprofil verfügbare PPP-Option enthält.

Anwenden von PPP-Attributen auf L2TP LNS-Abonnenten mit einem Benutzergruppenprofil

Sie können ein Benutzergruppenprofil konfigurieren, das es dem LNS ermöglicht, PPP-Attribute auf die PPP-Abonnenten anzuwenden, die von der LAC getunnelt werden. Das Benutzergruppenprofil ist Clients (LACs) im L2TP-Zugriffsprofil zugeordnet. Folglich haben alle Abonnenten, die von einem bestimmten Client verwaltet werden, die gleichen PPP-Attribute.

So konfigurieren Sie ein Benutzergruppenprofil:

  1. Erstellen Sie das Profil.
  2. Konfigurieren Sie das Intervall zwischen PPP-Keepalive-Meldungen für den L2TP-Tunnel, der auf dem LNS endet.
    Hinweis:

    Änderungen am Keepalive-Intervall in einem Benutzergruppenprofil wirken sich nur auf neue L2TP-Sitzungen aus, die nach der Änderung aktiviert werden. Bestehende Sitzungen sind davon nicht betroffen.

  3. Konfigurieren Sie PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten im LNS gelten.
  4. Geben Sie eine Reihe von AAA-Optionen an, die für die Authentifizierung und Autorisierung von getunnelten PPP-Abonnenten am LNS verwendet werden, die sich über die im AAA-Optionssatz angegebenen Anwender- und AAA-Kontexte anmelden.

    Der Optionssatz wird mit der aaa-options aaa-options-name Anweisung auf Hierarchieebene [edit access] konfiguriert.

  5. Konfigurieren Sie den Router so, dass er CPE (Customer Premises Equipment) auffordert, während der IPCP-Aushandlung für getunnelte PPP-Abonnenten am LNS sowohl primäre als auch sekundäre DNS-Adressen auszuhandeln.
  6. (Optional) Deaktivieren Sie die Packet Forwarding Engine Durchführung einer Validierungsprüfung für PPP Magic Numbers, die von einem Remote-Peer in LCP-Keepalive-Austauschen (Echo-Request/Echo-Reply) empfangen wurden. Dies verhindert, dass PPP die Sitzung beendet, wenn die Anzahl nicht mit dem während der LCP-Aushandlung vereinbarten Wert übereinstimmt. Diese Funktion ist nützlich, wenn die entfernten PPP-Peers beliebige magische Zahlen in die Keepalive-Pakete aufnehmen. Die Konfiguration dieser Anweisung hat keine Auswirkungen auf die Aushandlung magischer LCP-Nummern oder auf den Austausch von Keepalives, wenn die magische Remote-Peer-Nummer die erwartete ausgehandelte Nummer ist.
  7. Konfigurieren Sie, wie lange die PPP-Anwender-Sitzung inaktiv sein kann, bevor eine Zeitüberschreitung als Zeitüberschreitung gilt.
Hinweis:

Sie können PPP-Attribute auch für einzelne Schnittstellen konfigurieren. Weitere Informationen finden Sie unter Anwenden von PPP-Attributen auf L2TP LNS-Abonnenten pro Inline-Service-Schnittstelle . Wenn Sie die PPP-Attribute für L2TP LNS-Abonnenten sowohl auf der si-Schnittstelle als auch in Benutzergruppenprofilen konfigurieren, hat die Konfiguration der Inline-Serviceschnittstelle Vorrang vor der Konfiguration des Benutzergruppenprofils.

Hinweis:

Wenn PPP-Optionen sowohl in einem Gruppenprofil als auch in einem dynamischen Profil konfiguriert sind, hat die Konfiguration des dynamischen Profils vollständigen Vorrang vor dem Gruppenprofil, wenn das dynamische Profil eine oder mehrere der PPP-Optionen enthält, die im Gruppenprofil konfiguriert werden können. Vollständige Rangfolge bedeutet, dass es keine Zusammenführung von Optionen zwischen den Profilen gibt. Das Gruppenprofil wird nur dann auf den Anwender angewendet, wenn das dynamische Profil keine im Gruppenprofil verfügbare PPP-Option enthält.

Konfigurieren eines L2TP-Zugriffsprofils auf dem LNS

Zugriffsprofile definieren, wie Layer 2 Tunneling Protocol (L2TP)-Verbindungen und Sitzungsanfragen validiert werden. Innerhalb jedes L2TP-Zugriffsprofils konfigurieren Sie einen oder mehrere Clients (LACs). Die Client-Merkmale werden verwendet, um LACs mit übereinstimmenden Kennwörtern zu authentifizieren und Attribute des Client-Tunnels und der Sitzung festzulegen. Sie können mehrere Zugriffsprofile und mehrere Clients in jedem Profil konfigurieren.

So konfigurieren Sie ein L2TP-Zugriffsprofil:

  1. Erstellen Sie das Zugriffsprofil.
  2. Konfigurieren Sie Merkmale für einen oder mehrere Clients (LACs).
    Hinweis:

    Mit Ausnahme des Sonderfalls default des Clients muss der LAC-Clientname, den Sie im Zugriffsprofil konfigurieren, mit dem Hostnamen der LAC übereinstimmen. Wenn ein Juniper Networks-Router als LAC fungiert, wird der Hostname im LAC-Tunnel-Profil mit der Anweisung gateway gateway-name auf Hierarchieebene [edit access tunnel-profile profile-name tunnel tunnel-id source-gateway] konfiguriert. Alternativ kann der Clientname von RADIUS im Attribut Tunnel-Client-Auth-Id [90] zurückgegeben werden.

    Hinweis:

    Verwenden default Sie als Clientname, wenn Sie einen Standard-Tunnel-Client definieren möchten. Der Standardclient ermöglicht die Authentifizierung mehrerer LACs mit denselben geheimen und L2TP-Attributen. Dieses Verhalten ist nützlich, wenn dem Netzwerk z. B. viele neue LACs hinzugefügt werden, da die LACs ohne zusätzliche LNS-Profilkonfiguration verwendet werden können.

    Nur auf Routern der MX-Serie verwendendefault. Der entsprechende Clientname auf Routern der M Series lautet .*

  3. (Optional) Geben Sie ein lokales Zugriffsprofil an, das das globale Zugriffsprofil und das AAA-Zugriffsprofil der Tunnel-Gruppe überschreibt, um die RADIUS-Servereinstellungen für den Client zu konfigurieren.
  4. Konfigurieren Sie das LNS so, dass das Link Control Protocol (LCP) mit dem PPP-Client neu ausgehandelt wird. vom Client aus getunnelt wird.
  5. Konfigurieren Sie ein oder mehrere dynamische Dienstprofile, um Services auf alle Abonnenten in der LAC anzuwenden. Sie können optional Parameter in derselben Anweisung an die Services übergeben.
  6. Konfigurieren Sie die maximale Anzahl von Sitzungen, die in einem Tunnel vom Client (LAC) zulässig sind.
  7. Konfigurieren Sie das LNS so, dass die Ergebniscodes 4 und 5 mit dem Ergebniscode 2 in CDN-Nachrichten überschrieben werden, die es an die LAC sendet, wenn die Anzahl der L2TP-Sitzungen den konfigurierten Maximalwert erreicht. Bei einigen LACs von Drittanbietern kann kein Failover auf ein anderes LNS ausgeführt werden, es sei denn, der Ergebniscode hat den Wert 2.
  8. Konfigurieren Sie das Tunnel-Kennwort, das zur Authentifizierung des Clients (LAC) verwendet wird.
  9. (Optional) Ordnen Sie ein Gruppenprofil mit PPP-Attributen zu, das für die PPP-Sitzungen angewendet werden soll, die von diesem LAC-Client getunnelt werden.
    Hinweis:

    Wenn user-group-profile geändert oder gelöscht wird, fallen die vorhandenen LNS-Abonnenten, die diese Layer-2-Tunneling-Protokoll-Client-Konfiguration verwendet haben, aus.

Konfiguration eines lokalen AAA-Zugriffsprofils auf dem LNS

Bei einigen LNS-Tunneln möchten Sie möglicherweise das Zugriffsprofil überschreiben, das in der Routing-Instanz konfiguriert ist, die den Tunnel mit einer bestimmten RADIUS-Serverkonfiguration hostet. Dazu können Sie ein lokales Zugriffsprofil konfigurieren. Anschließend können Sie die aaa-access-profile Anweisung verwenden, um das lokale Zugriffsprofil auf eine Tunnel-Gruppe oder einen LAC-Client anzuwenden.

Ein lokales Zugriffsprofil, das auf einen Client angewendet wird, überschreibt ein lokales Zugriffsprofil, das auf eine Tunnel-Gruppe angewendet wird, wodurch wiederum das Zugriffsprofil für die Routing-Instanz überschrieben wird.

So konfigurieren Sie ein lokales AAA-Zugriffsprofil:

  1. Erstellen Sie das Zugriffsprofil.
  2. Konfigurieren Sie die Reihenfolge der AAA-Authentifizierungsmethoden.
  3. Konfigurieren Sie die RADIUS-Serverattribute, z. B. das Kennwort für die Authentifizierung.

Konfiguration eines Adresszuweisungspools für L2TP LNS mit Inline-Services

Sie können Adresspools konfigurieren, die den getunnelten PPP-Abonnenten dynamisch zugewiesen werden können. Die Pools müssen sich lokal in der Routing-Instanz befinden, in der der Anwender hochkommt. Die konfigurierten Pools werden in den Attributen RADIUS Framed-Pool und Framed-IPv6-Pool bereitgestellt. Pools sind optional, wenn Framed-IP-Address von RADIUS gesendet wird.

Um einen Adresszuweisungspool zu konfigurieren, müssen Sie den Namen des Pools angeben und die Adressen für den Pool konfigurieren.

Sie können optional mehrere benannte Bereiche oder Teilmengen von Adressen innerhalb eines Adresszuweisungspools konfigurieren. Bei der dynamischen Adresszuweisung kann einem Client eine Adresse aus einem bestimmten benannten Bereich zugewiesen werden. Um einen benannten Bereich zu erstellen, geben Sie einen Namen für den Bereich an und definieren den Adressbereich.

Hinweis:

Achten Sie darauf, die Anweisung address-assignment pools (address-assignment) anstelle der Anweisung address pools (address-pool) zu verwenden.

Weitere Informationen zu Adresszuweisungspools finden Sie unter Übersicht über Adresszuweisungspools und Konfigurationsübersicht für Adresszuweisungspools.

So konfigurieren Sie einen IPv4-Adresszuweisungspool für L2TP LNS:

  1. Konfigurieren Sie den Namen des Pools und geben Sie die IPv4-Familie an.
  2. Konfigurieren Sie die Netzwerkadresse und die Präfixlänge der Adressen im Pool.
  3. Konfigurieren Sie den Namen des Bereichs sowie die untere und obere Grenze der Adressen im Bereich.

So konfigurieren Sie beispielsweise einen IPv4-Adresszuweisungspool:

So konfigurieren Sie einen IPv6-Adresszuweisungspool für L2TP LNS:

  1. Konfigurieren Sie den Namen des Pools und geben Sie die IPv6-Familie an.

  2. Konfigurieren Sie das IPv6-Netzwerkpräfix für den Adresspool. Die Präfixspezifikation ist erforderlich, wenn Sie einen IPv6-Adresszuweisungspool konfigurieren.

  3. Konfigurieren Sie den Namen des Bereichs und definieren Sie den Bereich. Sie können den Bereich basierend auf den unteren und oberen Grenzen der Präfixe im Bereich oder basierend auf der Länge der Präfixe im Bereich definieren.

So konfigurieren Sie beispielsweise einen IPv6-Adresszuweisungspool:

Konfiguration der L2TP LNS-Peer-Schnittstelle

Die Peer-Schnittstelle verbindet das LNS mit der Cloud zu den LACs, sodass IP-Pakete zwischen den Tunnel-Endpunkten ausgetauscht werden können. MPLS und aggregiertes Ethernet können auch verwendet werden, um die LACs zu erreichen.

Hinweis:

Auf Routern der MX-Serie müssen Sie die Peer-Schnittstelle auf einem MPC konfigurieren.

So konfigurieren Sie die LNS-Peer-Schnittstelle:

  1. Geben Sie den Schnittstellennamen an.
  2. Aktivieren Sie VLANs.
  3. Geben Sie die logische Schnittstelle an, binden Sie eine VLAN-Tag-ID an die Schnittstelle und konfigurieren Sie die Adressfamilie und die IP-Adresse für die logische Schnittstelle.
    Hinweis:

    Die IPv6-Adressfamilie wird als Tunnel-Endgerät nicht unterstützt.

Aktivieren von Inline-Serviceschnittstellen

Die Inline-Serviceschnittstelle ist eine virtuelle physische Schnittstelle, die sich auf der Packet Forwarding Engine befindet. Diese si Schnittstelle, die als Ankerschnittstelle bezeichnet wird, ermöglicht es, L2TP-Dienste ohne ein spezielles Service-PIC bereitzustellen. Die Inline-Serviceschnittstelle wird nur von MPCs auf Routern der MX-Serie unterstützt. Vier Inline-Serviceschnittstellen sind pro MPC-belegtem Gehäusesteckplatz konfigurierbar.

Hinweis:

Auf MX80- und MX104-Routern können Sie nur vier physische Inline-Service-Schnittstellen als Ankerschnittstellen für L2TP-LNS-Sitzungen konfigurieren: si-1/0/0, si-1/1/0, si-1/2/0 und si-1/3/0. Sie können si-0/0/0 für diesen Zweck nicht auf MX80- und MX104-Routern konfigurieren.

Obwohl der Bereich der Bandbreitenwerte 1 Gbit/s bis 400 Gbit/s beträgt, können Sie die Bandbreite nicht in absoluten Zahlen wie 12.345.878.000 Bit/s konfigurieren. Sie müssen die in der CLI-Anweisung verfügbaren Optionen verwenden:

  • 1g

  • 10gin 100g Schritten von 10 Gbit/s: 10g, 20g, 30g, 40g, 50g, 60g70g, , 80g, , 90g, ,100g

  • 100g in 400g Schritten von 100 Gbit/s: 100g, 200g, 300g, 400g

Die maximal verfügbare Bandbreite variiert je nach MPC, wie in Tabelle 1 dargestellt. Eine Systemprotokollmeldung wird generiert, wenn Sie eine höhere Bandbreite als die auf der MPC unterstützte Bandbreite konfigurieren.

Tabelle 1: Maximale Bandbreite für Inline-Services pro MPC

MPC

Maximal unterstützte Bandbreite

MPC2E NG, MPC2E NG Q,

80 Gbit/s

MPC3E NG, MPC3E NG Q

130 Gbit/s

100GE und 40GE MPC3 und MICs

40 Gbit/s

MPC4E

130 Gbit/s

MPC5E

130 Gbit/s

MPC6E

130 Gbit/s

MPC7E

240 Gbit/s

MPC8E

240 Gbit/s

400 Gbit/s im 1,6 Tbit/s Upgrade-Modus

MPC9E

400 Gbit/s

So aktivieren Sie Inline-Serviceschnittstellen:

  1. Greifen Sie auf einen MPC-belegten Steckplatz und den PIC zu, in dem die Schnittstelle aktiviert werden soll.
  2. Aktivieren Sie die Schnittstelle und geben Sie optional die Bandbreite an, die auf jeder Packet Forwarding Engine für den Tunnel-Datenverkehr mit Inline-Services reserviert ist. Ab Junos OS Version 16.2 müssen Sie nicht explizit eine Bandbreite für L2TP LNS-Tunnel-Datenverkehr über Inline-Services angeben. Wenn Sie keine Bandbreite angeben, ist die maximale Bandbreite, die im PIC unterstützt wird, automatisch für die Inline-Services verfügbar. Inline-Dienste können bis zu diesem Maximalwert nutzen. In früheren Versionen müssen Sie eine Bandbreite angeben, wenn Sie Inlinedienste mit der inline-services Anweisung aktivieren.

Konfiguration einer Inline-Serviceschnittstelle für L2TP LNS

Die Inline-Serviceschnittstelle ist eine virtuelle physische Serviceschnittstelle, die sich auf der Packet Forwarding Engine befindet. Diese si Schnittstelle, die als Ankerschnittstelle bezeichnet wird, ermöglicht es, L2TP-Dienste ohne ein spezielles Service-PIC bereitzustellen. Die Inline-Serviceschnittstelle wird nur von MPCs auf Routern der MX-Serie unterstützt. Vier Inline-Serviceschnittstellen sind pro MPC-belegtem Gehäusesteckplatz konfigurierbar.

Sie können die Anzahl der Sitzungen maximieren, die in einer Serviceschnittstelle gestaltet werden können, indem Sie die maximale Anzahl von Hierarchieebenen auf zwei festlegen. In diesem Fall verbraucht jede LNS-Sitzung einen L3-Knoten in der Scheduler-Hierarchie für das Shaping.

Wenn Sie die Anzahl der Ebenen nicht angeben (zwei sind die einzige Option), ist die Anzahl der LNS-Sitzungen, die auf der Serviceschnittstelle geformt werden können, auf die Anzahl der L2-Knoten oder 4096 Sitzungen beschränkt. Es kommen noch zusätzliche Sitzungen, aber sie sind nicht ausgestaltet.

So konfigurieren Sie eine Inline-Serviceschnittstelle:

  1. Greifen Sie auf die Serviceschnittstelle zu.
  2. (Optional; nur für Pro-Session-Shaping) Aktivieren Sie die Inline-Serviceschnittstelle für hierarchische Scheduler, und begrenzen Sie die Anzahl der Scheduler-Ebenen auf zwei.
  3. (Optional; nur für Sitzungsformung) Konfigurieren Sie die Servicekapselung für die Inline-Serviceschnittstelle.
  4. Konfigurieren Sie die IPv4-Familie auf der logischen Schnittstelle der reservierten Einheit 0.

Optionen für die logische Schnittstelle für LNS Inline Services konfigurieren

Sie müssen Merkmaledial-options für jede der logischen Inline-Service-Schnittstellen angeben, die Sie für das LNS konfigurieren. LNS auf Routern der MX-Serie unterstützt nur eine Sitzung pro logischer Schnittstelle, daher müssen Sie es als dedicated Schnittstelle konfigurieren; diese shared Option wird nicht unterstützt. (Unterstützung dedicated und shared Optionen für LNS auf Routern der M Series.) Außerdem konfigurieren Sie einen identifizierenden Namen für die logische Schnittstelle, der mit dem Namen übereinstimmt, den Sie im Zugriffsprofil angeben.

Sie müssen die inet Adressfamilie für jede statische logische Schnittstelle oder im dynamischen Profil für dynamische LNS-Schnittstellen angeben. Obwohl die CLI entweder inet oder inet6 für statische logische Schnittstellen akzeptiert, kann sich der Anwender nur dann erfolgreich anmelden, wenn die Adressfamilie inet konfiguriert ist.

Hinweis:

Informationen zur Konfiguration dynamischer Schnittstellen finden Sie unter Konfigurieren eines dynamischen Profils für dynamische LNS-Sitzungen.

So konfigurieren Sie die statischen logischen Schnittstellenoptionen:

  1. Greifen Sie auf die logische Schnittstelle der Inline-Services zu.
  2. Geben Sie einen Bezeichner für die logische Schnittstelle an.
  3. Konfigurieren Sie die logische Schnittstelle so, dass jeweils nur eine Sitzung verwendet werden soll.
  4. Konfigurieren Sie die Adressfamilie für jede logische Schnittstelle und aktivieren Sie die lokale Adresse auf dem LNS, die die lokale Terminierung für den L2TP-Tunnel bereitstellt, die vom angegebenen Schnittstellennamen abgeleitet werden soll.

Übersicht über zustandsbehaftete LNS-1:1-Redundanz

Wenn eine Inline-Service-Ankerschnittstelle (si) ausfällt, z. B. wenn die Karte, auf der die Schnittstelle gehostet wird, ausfällt oder neu gestartet wird, geht standardmäßig der L2TP-Datenverkehr der Anwender verloren. Wenn der PPP-Keepalive-Timer für den Tunnel anschließend abläuft, fällt die Steuerungsebene aus und der PPP-Client wird getrennt. Folglich muss der Client die Verbindung wiederherstellen.

Unter diesen Umständen können Sie Datenverkehrsverluste vermeiden, indem Sie ein ASI-Paket (Aggregated Inline Service Interface) so konfigurieren, dass es zustandsbehaftete 1:1-Redundanz bietet, die auch als Hot-Standby- oder Active-Backup-Redundanz bezeichnet wird. Das Bündel besteht aus einem Paar physischer Si-Schnittstellen, dem primären (aktiven) Mitgliedslink und dem sekundären (Standby- oder Backup) member-Link. Diese Schnittstellen müssen auf verschiedenen MPCs konfiguriert werden; Redundanz ist nicht erreichbar, wenn Sie die primäre und sekundäre Schnittstelle auf demselben MPC konfigurieren, da beide Mitgliedsschnittstellen ausfallen, wenn die Karte ausfällt.

Wenn sich Anwender anmelden und eine 1:1-Redundanz konfiguriert ist, wird die L2TP-Sitzung über eine zugrunde liegende virtuelle logische Schnittstelle (asi.0x) über die physische AS0-Schnittstelle eingerichtet. Individuelle logische Schnittstellen des Anwenders werden auf der zugrunde liegenden Schnittstelle im Format asiX erstelltlogical-unit-number. Die Sitzung bleibt im Falle eines Fehlers oder eines Neustarts auf dem MPC aktiv, der die primäre Member Link-Schnittstelle hostet. Der gesamte Datenverkehr, der für diese L2TP-Sitzung bestimmt ist, wird automatisch an die sekundäre Verbindungsschnittstelle des anderen MPC weitergeleitet.

Konfiguration der zustandsbehafteten 1:1-LNS-Redundanz auf aggregierten Inline-Serviceschnittstellen

Sie können ein aggregiertes Inline-Service-Interface-Bundle (asi) erstellen, um eine zustandsbehaftete 1:1-LNS-Redundanz für Inline-Service-Ankerschnittstellen (SI) bereitzustellen. Das Bundle paart zwei Schnittstellen, die sich auf verschiedenen MPCs befinden, als primäre und sekundäre Verbindungen. LNS-Sitzungen werden anschließend über eine virtuelle logische Schnittstelle aufgebaut, asiX.logical-unit-number. Das LNS-Sitzungs-Failover tritt auf, wenn entweder die primäre Ankerschnittstelle ausfällt oder die Karte mit dem request chassis fpc restart Befehl neu gestartet wird. In diesem Fall wird die sekundäre Verbindung – auf einer anderen MPC – aktiv, und der gesamte LNS-Datenverkehr, der für die Sitzung bestimmt ist, wird automatisch an die sekundäre Schnittstelle weitergeleitet. Die Sitzung des Anwenders bleibt auf der virtuellen Schnittstelle asiX.logical-unit-number aktiv. Es gehen keine Verkehrsstatistiken verloren. Wenn diese Redundanz nicht konfiguriert ist, geht der Datenverkehr des Anwenders verloren, die Keepalives laufen ab, und der PPP-Client wird getrennt und muss die Verbindung wiederherstellen.

Bevor Sie beginnen, müssen Sie Folgendes tun:

Optimale Vorgehensweise:

Befolgen Sie diese Richtlinien:

  • Sie müssen für jedes Bundle konfigurieren unit 0 family inet , andernfalls kann die Sitzung nicht gestartet werden.

  • Die primäre (aktive) und die sekundäre (Backup-) Schnittstelle müssen sich auf unterschiedlichen MPCs befinden.

  • Die auf der [edit chassis fpc slot pic number inline-services bandwidth] Hierarchieebene konfigurierte Bandbreite muss für beide Mitgliedsverbindungen gleich sein.

  • Eine SI-Schnittstelle, die als Mitglied eines aggregierten Inline-Service-Schnittstellenpakets konfiguriert ist, kann nicht als Mitglied einer anderen Paketgruppe konfiguriert werden.

  • Eine si-Schnittstelle, die als Mitglied eines aggregierten Inline-Service-Schnittstellenpakets konfiguriert ist, kann nicht auch für Funktionen verwendet werden, die nicht mit aggregierten Services verbunden sind. es kann beispielsweise nicht für die Inline-IP-Reassemblierung verwendet werden.

  • Wenn Sie eine SI-Schnittstelle als Mitglied eines aggregierten Inline-Services-Pakets konfigurieren, können Sie diese SI-Schnittstelle nicht mehr unabhängig konfigurieren. Sie können nur das übergeordnete Bundle konfigurieren. Die Konfiguration des Bundles wird sofort auf alle Mitgliedsschnittstellen angewendet.

So konfigurieren Sie die zustandsabhängige 1:1-LNS-Redundanz:

  1. Geben Sie auf einer MPC den primären (aktiven) Link für Inline-Service-Member im Paket an.
  2. Konfigurieren Sie die Bandbreite, die auf dieser MPC für den Tunnel-Datenverkehr reserviert ist, indem Sie die primäre Inline-Serviceschnittstelle verwenden.
  3. Geben Sie auf einer anderen MPC den sekundären (Backup-)Inline-Services-Member-Link im Bundle an.
    Hinweis:

    Wenn Sie die aktiven und Backup-Komponentenverbindungen auf derselben MPC konfigurieren, schlägt die nachfolgende Übertragung der Konfiguration fehl.

  4. Konfigurieren Sie die auf dieser MPC für den Tunnel-Datenverkehr reservierte Bandbreite mithilfe der sekundären Inline-Serviceschnittstelle.
  5. Weisen Sie das aggregierte Inline-Service-Schnittstellenpaket einer L2TP-Tunnel-Gruppe mit einer der folgenden Methoden zu:
    • Weisen Sie ein einzelnes Bundle zu, indem Sie den Namen der aggregierten physischen Inline-Serviceschnittstelle angeben.

    • Weisen Sie der Tunnel-Gruppe einen oder mehrere Pools von Paketen zu.

      Hinweis:

      Ein Pool kann gemischt werden; Das heißt, sie kann sowohl aggregierte Inline-Serviceschnittstellenbündel als auch einzelne Inline-Serviceschnittstellen umfassen. Die einzelnen Schnittstellen dürfen nicht Mitglieder bestehender Bundles sein.

Die folgende Beispielkonfiguration erstellt das Bundle asi0 mit Member-Links auf MPCs in Slot 1 und Slot 2 und weist dann das Bundle zu, um Redundanz für L2TP-Sitzungen in der Tunnel-Gruppe TG1 bereitzustellen:

Überprüfung der 1:1-Redundanz der aggregierten Inline-Serviceschnittstelle von LNS

Zweck

Zeigen Sie Informationen über aggregierte Inline-Serviceschnittstellenpakete, einzelne Mitgliederverbindungen und den Redundanzstatus an.

Aktion

  • So zeigen Sie zusammenfassende Informationen zu einem aggregierten Inline-Service-Schnittstellen-Bundle an:

  • So zeigen Sie detaillierte Informationen zu einem aggregierten Inline-Serviceschnittstellenpaket an:

  • So zeigen Sie Informationen zu einer einzelnen Mitgliedsschnittstelle in einem aggregierten Inline-Serviceschnittstellenpaket an:

  • So zeigen Sie den Redundanz-Status für aggregierte Inline-Serviceschnittstellen-Bundles an:

    Diese Beispielausgabe zeigt, dass sowohl aggregierte Ethernet- als auch aggregierte Inline-Serviceschnittstellen für Redundanz konfiguriert sind. So zeigen Sie nur eines der aggregierten Inline-Serviceschnittstellenpakete an:

  • So zeigen Sie detaillierte Informationen zu allen konfigurierten Redundanz-Schnittstellen an:

L2TP-Sitzungslimits und Lastausgleich für Serviceschnittstellen

Das LNS gleicht Anwender-Sitzungen über die verfügbaren Serviceschnittstellen in einem Gerätepool basierend auf der Anzahl der derzeit auf den Schnittstellen aktiven Sitzungen aus. Sie können eine Höchstgrenze pro Serviceschnittstelle (si) und pro aggregierter Serviceschnittstelle (asi) konfigurieren. Bei asi-Schnittstellen können Sie kein Limit für die einzelnen SI-Member-Schnittstellen im Bundle konfigurieren.

Sitzungsbeschränkungen für Serviceschnittstellen

Wenn eine L2TP-Sitzungsanforderung für eine Serviceschnittstelle initiiert wird, vergleicht das LNS die Anzahl der derzeit aktiven Sitzungen auf dieser Schnittstelle mit der maximalen Anzahl von Sitzungen, die für die einzelne Serviceschnittstelle oder die aggregierte Serviceschnittstelle zulässig sind. Das LNS bestimmt, ob die aktuelle Sitzungsanzahl (vom show services l2tp summary Befehl angezeigt) kleiner als der konfigurierte Grenzwert ist. Wenn dies der Fall ist oder wenn kein Limit konfiguriert ist, ist die Prüfung erfolgreich und die Sitzung kann eingerichtet werden. Wenn die aktuelle Sitzungsanzahl dem konfigurierten Grenzwert entspricht, lehnt LNS die Sitzungsanforderung ab. Nachfolgende Anforderungen können auf dieser Schnittstelle erst akzeptiert werden, wenn die Anzahl der aktiven Anforderungen unter das konfigurierte Maximum fällt. Wenn eine Sitzungsanforderung für eine SI- oder ASI-Schnittstelle abgelehnt wird, gibt das LNS eine CDN-Nachricht zurück, deren Ergebniscode auf 2 und der Fehlercode auf 4 gesetzt ist.

Nehmen wir zum Beispiel an, dass eine einzelne Serviceschnittstelle in der Tunnel-Gruppe konfiguriert ist. Die aktuelle L2TP-Sitzungsanzahl beträgt 1500, mit einem konfigurierten Limit von 2000 Sitzungen. Wenn eine neue Sitzung angefordert wird, ist die Grenzwertprüfung erfolgreich und die Sitzungsanforderung wird akzeptiert.

Schnittstelle

Konfiguriertes Sitzungslimit

Anzahl der aktuellen Sitzungen

Ergebnis der Überprüfung des Sitzungslimits

SI-0/0/0

2000

1500

Bestehen

Die Grenzwertprüfung wird fortgesetzt und Sitzungsanforderungen werden akzeptiert, bis 500 Anforderungen akzeptiert wurden, sodass die aktuelle Sitzung 2000 zählt, was dem konfigurierten Maximum entspricht. Die Sitzungsbegrenzungsprüfung schlägt für alle nachfolgenden Anforderungen fehl, und alle Anforderungen werden abgelehnt, bis die aktuelle Sitzungsanzahl auf der Schnittstelle unter 2000 fällt, sodass die Grenzwertprüfung bestanden werden kann.

Schnittstelle

Konfiguriertes Sitzungslimit

Anzahl der aktuellen Sitzungen

Ergebnis der Überprüfung des Sitzungslimits

SI-0/0/0

2000

2000

Fehler

Wenn das Sitzungslimit für eine Schnittstelle auf Null gesetzt ist, können keine Sitzungsanforderungen akzeptiert werden. Wenn dies die einzige Schnittstelle in der Tunnel-Gruppe ist, werden alle Sitzungsanforderungen in der Gruppe abgelehnt, bis das Sitzungslimit von Null erhöht wird oder eine weitere Serviceschnittstelle zur Tunnel-Gruppe hinzugefügt wird.

Wenn eine Serviceschnittstelle in einem Servicegerätepool den maximalen konfigurierten Grenzwert erreicht hat oder einen konfigurierten Grenzwert von Null hat, überspringt das LNS diese Schnittstelle, wenn eine Sitzungsanforderung gestellt wird, und wählt eine andere Schnittstelle im Pool aus, um das Sitzungslimit zu überprüfen. Dies wird so lange fortgesetzt, bis eine Schnittstelle passiert und die Sitzung akzeptiert wird oder keine andere Schnittstelle mehr im Pool zur Auswahl ist.

Sitzungslastausgleich über Serviceschnittstellen hinweg

Das Verhalten für die Verteilung der Sitzungslast in einem Dienstgerätepool wurde in Junos OS Version 16.2 geändert. Wenn eine Dienstschnittstelle eine niedrigere Sitzungsanzahl als eine andere Schnittstelle im Pool aufweist und beide Schnittstellen unter ihrem maximalen Sitzungslimit liegen, werden nachfolgende Sitzungen an die Schnittstelle mit weniger Sitzungen verteilt.

In früheren Versionen wurden Sitzungen unabhängig von der Anzahl der Sitzungen streng nach dem Round-Robin-Prinzip verteilt. Das alte Verhalten kann zu einer ungleichmäßigen Sitzungsverteilung führen, wenn die Packet Forwarding Engine neu gestartet wird oder eine Serviceschnittstelle ausfällt und wieder hochfährt.

Betrachten Sie beispielsweise das folgende Szenario mit dem alten Roundrobin-Verteilungsverhalten für einen Pool mit zwei Dienstschnittstellen:

  1. Zweihundert Sitzungen werden gleichmäßig auf die beiden Serviceschnittstellen verteilt.

    • si-0/0/0 hat 100 Sitzungen.

    • SI-1/0/0 hat 100 Sitzungen.

  2. Die si-1/0/0-Schnittstelle wird neu gestartet. Wenn er zurückkommt, sind die Sitzungen zunächst nur auf si-0/0/0 verfügbar.

    • si-0/0/0 hat 100 Sitzungen.

    • si-1/0/0 hat 0 Sitzungen.

  3. Wenn die Sitzungen zuvor auf si-1/0/0 wieder verbunden werden, werden sie gleichmäßig auf beide Serviceschnittstellen verteilt. Wenn alle 100 Sitzungen wieder verfügbar sind, ist die Verteilung erheblich unausgewogen.

    • SI-0/0/0 hat 150 Sitzungen.

    • SI-1/0/0 hat 50 Sitzungen.

  4. Nach 100 neuen Sitzungen erreicht si-0/0/0 sein maximales Limit. Nachfolgende Sitzungen werden nur an si-1/0/0 akzeptiert.

    • si-0/0/0 hat 200 Sitzungen.

    • SI-1/0/0 hat 100 Sitzungen.

  5. Nach 100 weiteren Sitzungen erreicht si-1/0/0 sein maximales Limit. Es können keine weiteren Sitzungen akzeptiert werden, bis die Anzahl der Sitzungen für eine der Schnittstellen unter 200 fällt.

    • si-0/0/0 hat 200 Sitzungen.

    • SI-1/0/0 hat 200 Sitzungen.

Betrachten Sie nun das gleiche Szenario mit dem aktuellen Lastverteilungsverhalten basierend auf der Anzahl der angeschlossenen Sitzungen. Der Gerätepool verfügt wieder über zwei Serviceschnittstellen mit jeweils einem konfigurierten maximalen Limit von 200 Sitzungen:

  1. Zweihundert Sitzungen werden gleichmäßig auf die beiden Serviceschnittstellen verteilt.

    • si-0/0/0 hat 100 Sitzungen.

    • SI-1/0/0 hat 100 Sitzungen.

  2. Die si-1/0/0-Schnittstelle wird neu gestartet. Wenn sie wieder hochgefahren wird, sind die Sitzungen zunächst nur auf si-0/0/0 verfügbar.

    • si-0/0/0 hat 100 Sitzungen.

    • si-1/0/0 hat 0 Sitzungen.

  3. Wenn die Sitzungen, die zuvor auf si-1/0/0 waren, wieder verbunden werden, werden sie entsprechend der Sitzungslast auf jeder Schnittstelle verteilt. Da beide Schnittstellen unter ihrem maximalen Grenzwert liegen und si-1/0/0 weniger Sitzungen als si-0/0/0 hat, werden Sitzungen zunächst nur an si-1/0/0 verteilt.

    1. Nach 1 neuen Sitzung:

      • si-0/0/0 hat 100 Sitzungen.

      • SI-1/0/0 hat 1 Sitzung.

    2. Nach 10 neuen Sitzungen:

      • si-0/0/0 hat 100 Sitzungen.

      • SI-1/0/0 hat 10 Sitzungen.

    3. Nach 100 neuen Sitzungen:

      • si-0/0/0 hat 100 Sitzungen.

      • SI-1/0/0 hat 100 Sitzungen.

  4. Da beide Schnittstellen jetzt die gleiche Sitzungsanzahl haben, wird die nächste Sitzung (#101) zufällig auf die beiden Schnittstellen verteilt. Die nächste Sitzung danach (#102) geht an die Schnittstelle mit der niedrigeren Sitzungsanzahl. Das macht die Schnittstellen wieder gleich, so dass die nächste Sitzung (#103) zufällig verteilt ist. Dieses Muster wiederholt sich bis zum maximalen Grenzwert von 200 Sitzungen für beide Schnittstellen.

    • si-0/0/0 hat 200 Sitzungen.

    • SI-1/0/0 hat 200 Sitzungen.

    Auf beiden Schnittstellen können keine weiteren Sitzungen akzeptiert werden, bis die Anzahl der Sitzungen auf einer der Schnittstellen unter 200 fällt.

Das Verhalten des Load Balancing ist für aggregierte Serviceschnittstellen identisch. Eine ASI-Schnittstelle wird aus einem Pool basierend auf der aktuellen Sitzungsanzahl für die ASI-Schnittstelle ausgewählt. Wenn diese Anzahl kleiner als das Maximum ist, prüft das LNS die Anzahl der aktuellen Sitzungen für die aktive SI-Schnittstelle im ASI-Paket. Wenn diese Anzahl kleiner als das Maximum ist, kann die Sitzung auf der asi-Schnittstelle eingerichtet werden.

In einem gemischten Gerätepool, der sowohl Dienstschnittstellen als auch aggregierte Dienstschnittstellen umfasst, werden Sitzungen an die Schnittstelle (entweder asi oder si) verteilt, die die niedrigste Sitzungsanzahl aufweist. Wenn die Sitzungsanzahl einer Schnittstelle eines der beiden Typs ihren Grenzwert erreicht, kann sie keine Sitzungen mehr akzeptieren, bis die Anzahl unter das Maximum fällt.

Sie können die Konfiguration des Sitzungslimits verwenden, um ein Sitzungslimit für bestimmte Packet Forwarding Engines zu erreichen. Angenommen, Sie möchten ein Limit von 100 Sitzungen auf einer PFE0 mit zwei Serviceschnittstellen. Sie können das maximale Limit für jede Schnittstelle auf 50 oder eine andere Kombination festlegen, die zusammen 100 ergibt, um das PFE0-Limit festzulegen.

Beispiel: L2TP-LNS konfigurieren

Dieses Beispiel zeigt, wie Sie ein L2TP-LNS auf einem Router der MX-Serie konfigurieren können, um Tunnel-Endpunkte für eine L2TP-LAC in Ihrem Netzwerk bereitzustellen. Diese Konfiguration umfasst ein dynamisches Profil für Dual-Stack-Abonnenten.

Anforderungen

Für dieses L2TP LNS-Beispiel ist folgende Hard- und Software erforderlich:

  • Universelle Routing-Plattform der MX-Serie 5G

  • Ein oder mehrere MPCs

  • Junos OS Version 11.4 oder höher

Bevor Sie diese Funktion konfigurieren können, ist keine spezielle Konfiguration erforderlich, die über die Geräteinitialisierung hinausgeht.

Damit dieses Beispiel funktioniert, müssen Sie bestimmte standardmäßige RADIUS-Attribute und Juniper Networks VSAs in der Attributrückgabeliste auf dem AAA-Server konfigurieren, der dem LNS zugeordnet ist. Tabelle 2 listet die Attribute mit der erforderlichen Reihenfolge, Einstellung und den Werten auf. Es wird empfohlen, das aktuellste Juniper Networks RADIUS Wörterbuch zu verwenden, das im Feld Downloads auf der Seite Junos OS Subscriber Management unter https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/subscriber-access/index.html verfügbar ist.

Tabelle 2: VSA- und Standard-RADIUS-Attributnamen, Reihenfolge und erforderliche Werte, z. B.

VSA-Name [Nummer]

Bestellung

Wert

CoS-Parameter-Typ [26–108]

1

T01 Multiplay

CoS-Parameter-Typ [26–108]

2

T02 10m

CoS-Parameter-Typ [26–108]

3

T08 -36

CoS-Parameter-Typ [26–108]

4

T07 Zellen-Modus

Framed-IPv6-Pool [100]

0

jnpr_ipv6_pool

Gerahmter Pool [88]

0

jnpr_pool

Name der Ausgangsrichtlinie [26-11]

0

Klassifizieren

Name der Eingangsrichtlinie [26-10]

0

Klassifizieren

Virtueller Router [26-1]

0

Standardeinstellung

Überblick

Das LNS verwendet Benutzergruppenprofile, um PPP-Attribute auf die PPP-Abonnenten anzuwenden, die von der LAC getunnelt werden. LACs im Netzwerk sind Clients des LNS. Die Clients sind Benutzergruppenprofilen in dem auf dem LNS konfigurierten L2TP-Zugriffsprofil zugeordnet. In diesem Beispiel gibt das Benutzergruppenprofil ce-l2tp-group-profile die folgenden PPP-Attribute an:

  • Ein 30-Sekunden-Intervall zwischen PPP-Keepalive-Meldungen für L2TP-Tunnel von der Client-LAC bis zum LNS.

  • Ein Intervall von 200 Sekunden, das definiert, wie lange die PPP-Anwender-Sitzung im Leerlauf sein kann, bevor sie als Zeitüberschreitung gilt.

  • Sowohl PAP als auch CHAP als PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten im LNS gelten.

Das L2TP-Zugriffsprofil ce-l2tp-profile definiert eine Reihe von L2TP-Parametern für jede Client-LAC. In diesem Beispiel ist das Benutzergruppenprofil ce-l2tp-group-profile sowohl Clients als lac2auch zugeordnet. lac1 Beide Clients sind so konfiguriert, dass der LNS das Link Control Protocol (LCP) mit dem PPP-Client neu aushandelt, anstatt die vorab ausgehandelten LCP-Parameter zu akzeptieren, die die LACs an den LNS übergeben. Die LCP-Neuverhandlung führt auch dazu, dass die Authentifizierung vom LNS neu ausgehandelt wird. Die Authentifizierungsmethode wird im Benutzergruppenprofil angegeben. Die maximal zulässige Anzahl von Sitzungen pro Tunnel ist auf 1000 für lac1 und auf 4000 für lac2festgelegt. Für jede LAC ist ein anderes Kennwort konfiguriert.

Mit einem lokalen AAA-Zugriffsprofil aaa-profilekönnen Sie das globale AAA-Zugriffsprofil außer Kraft setzen, sodass Sie einen Authentifizierungs-Auftrag, einen RADIUS-Server, den Sie für L2TP verwenden möchten, und ein Kennwort für den Server angeben können.

In diesem Beispiel definiert ein Adresspool einen Bereich von IP-Adressen, die das LNS den getunnelten PPP-Sitzungen zuweist. In diesem Beispiel werden Bereiche von IPv4- und IPv6-Adressen definiert.

Auf dem MPC in Steckplatz 5 des Routers sind zwei Inline-Serviceschnittstellen aktiviert. Für jede Schnittstelle sind 10 Gbit/s Bandbreite für den Tunnel-Datenverkehr auf der zugehörigen PFE der Schnittstelle reserviert. Diese Ankerschnittstellen dienen als zugrunde liegende physische Schnittstelle. Um die Unterstützung für CoS-Warteschlangen auf den einzelnen logischen Inline-Serviceschnittstellen zu aktivieren, müssen Sie sowohl die Servicekapselung (generic-services) als auch die Unterstützung für die hierarchische Planung auf den Ankern konfigurieren. Die IPv4-Adressfamilie ist für beide Ankerschnittstellen konfiguriert. Beide Ankerschnittstellen werden im lns_p1 Dienstgerätepool angegeben. Das LNS kann Datenverkehrslasten über die beiden Ankerschnittstellen ausgleichen, wenn die Tunnel-Gruppe den Pool umfasst.

In diesem Beispiel wird das dynamische Profil dyn-lns-profile2 verwendet, um Merkmale der L2TP-Sitzungen anzugeben, die dynamisch erstellt oder zugewiesen werden, wenn ein Anwender zum LNS getunnelt wird. Für viele der Merkmale wird eine vordefinierte Variable festgelegt; Die Variablen werden dynamisch durch die entsprechenden Werte ersetzt, wenn ein Anwender zum LNS getunnelt wird.

Die Schnittstelle, mit der der getunnelte PPP-Client eine Verbindung herstellt ($junos-interface-name), wird dynamisch in der Routing-Instanz ($junos-routing-instance) erstellt, die dem Anwender zugewiesen ist. Routing-Optionen für Zugriffsrouten umfassen die Next-Hop-Adresse ($junos-framed-route-nexthop), Metrik ($junos-framed-route-cost) und Präferenzen ($junos-framed-route-distance). Für zugriffsinterne Routen wird eine dynamische IP-Adressvariable ($junos-subscriber-ip-address) gesetzt.

Die logischen Inline-Serviceschnittstellen werden durch den Namen einer konfigurierten Ankerschnittstelle ($junos-interface-ifd-name) und eine logische Einheitennummer ($junos-interface-unit) definiert. Das Profil wird l2tp-encapuslation als Bezeichner für die logische Schnittstelle zugewiesen und gibt an, dass jede Schnittstelle jeweils nur für eine Sitzung verwendet werden kann.

Die IPv4-Adresse wird auf einen Wert festgelegt, der vom AAA-Server zurückgegeben wird. Für IPv4-Datenverkehr sind ein Eingabe-Firewall-Filter $junos-input-filter und ein Ausgabe-Firewall-Filter $junos-output-filter an die Schnittstelle angeschlossen. Die Loopback-Variable ($junos-loopback-interface) leitet eine IP-Adresse von einer in der Routing-Instanz konfigurierten Loopback-Schnittstelle (lo) ab und verwendet sie in der IPCP-Aushandlung als PPP-Serveradresse. Da es sich um eine Dual-Stack-Konfiguration handelt, wird auch die IPv6-Adressfamilie mit den von der $junos-ipv6-address Variablen bereitgestellten Adressen festgelegt.

Die $junos-ipv6-address Variable wird verwendet, weil auch das Router Advertisement Protocol konfiguriert ist. Diese Variable ermöglicht es AAA, die erste Adresse im Präfix, die als lokale Adresse für die Schnittstelle reserviert werden soll, zuzuweisen. Die Minimalkonfiguration für das Router-Ankündigungsprotokoll im dynamischen Profil gibt die und-Variablen $junos-ipv6-ndra-prefix an, um einen $junos-interface-name Präfixwert in IPv6-Neighbor-Discovery-Router-Ankündigungen dynamisch zuzuweisen.

Das dynamische Profil enthält auch die Class-of-Service-Konfiguration, die auf den Tunnel-Datenverkehr angewendet wird. Das Datenverkehrssteuerungsprofil (tc-profile) enthält Variablen für die Scheduler-Zuordnung ($junos-cos-scheduler-map), die Shaping-Rate ($junos-cos-shaping-rate), die Overhead-Abrechnung ($junos-cos-shaping-mode) und die Byte-Anpassung $junos-cos-byte-adjust). Das dynamische Profil wendet die CoS-Konfiguration – einschließlich der Weiterleitungsklasse, des Ausgabe-Datenverkehrssteuerungsprofils und der Rewrite-Regeln – auf die dynamischen Serviceschnittstellen an.

Die tg-dynamic Konfiguration der Tunnel-Gruppe spezifiziert das Zugriffsprofil ce-l2tp-profile, das lokale AAA-Profil aaa-profileund das dynamische Profil dyn-lns-profile2 , die zum dynamischen Erstellen von LNS-Sitzungen und zum Definieren der Merkmale der Sitzungen verwendet werden. Der lns_p1 Servicegerätepool ordnet der Gruppe einen Pool von Serviceschnittstellen zu, damit LNS den Datenverkehr über die Schnittstellen hinweg ausgleichen kann. Die lokale Gateway-Adresse 203.0.113.2 entspricht der Remote-Gateway-Adresse, die in der LAC konfiguriert ist. Der Name ce-lns des lokalen Gateways entspricht dem Namen des Remotegateways, der in der LAC konfiguriert ist.

Hinweis:

In diesem Beispiel werden nicht alle möglichen Konfigurationsoptionen angezeigt.

Konfiguration

Vorgehensweise

CLI-Schnellkonfiguration

Um ein L2TP-LNS schnell zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, kopieren Sie die Befehle dann und fügen Sie sie in die CLI ein.

Schritt-für-Schritt-Anleitung

Im folgenden Beispiel müssen Sie durch verschiedene Ebenen in der Konfigurationshierarchie navigieren. Anweisungen dazu finden Sie unter Verwenden des CLI-Editors im Konfigurationsmodus.

So konfigurieren Sie ein L2TP-LNS mit Inline-Serviceschnittstellen:

  1. Konfigurieren Sie ein Benutzergruppenprofil, das die PPP-Konfiguration für Tunnel-Abonnenten definiert.

  2. Konfigurieren Sie ein L2TP-Zugriffsprofil, das die L2TP-Parameter für jede Client-LAC definiert. Dazu gehört die Zuordnung eines Benutzergruppenprofils zum Client und die Angabe der Kennung für die logische Schnittstelle der Inline-Services, die eine L2TP-Sitzung im LNS darstellt.

    Hinweis:

    Wenn user-group-profile geändert oder gelöscht wird, fallen die vorhandenen LNS-Abonnenten, die diese Layer-2-Tunneling-Protokoll-Client-Konfiguration verwendet haben, aus.

  3. Konfigurieren Sie ein AAA-Zugriffsprofil, um das globale Zugriffsprofil für die Reihenfolge der AAA-Authentifizierungsmethoden und Serverattribute zu überschreiben.

  4. Konfigurieren Sie IPv4- und IPv6-Adresszuweisungspools, um Adressen für die Clients (LACs) zuzuweisen.

  5. Konfigurieren Sie die Peer-Schnittstelle zum Beenden des Tunnels und die serverseitige PPP-IPCP-Adresse (Loopback-Adresse).

  6. Aktivieren Sie Inline-Serviceschnittstellen auf einer MPC.

  7. Konfigurieren Sie die Ankerdienstschnittstellen mit Servicekapselung, hierarchischer Planung und der Adressfamilie.

  8. Konfigurieren Sie einen Pool von Serviceschnittstellen für dynamische LNS-Sitzungen.

  9. Konfigurieren Sie ein dynamisches Profil, das dynamische logische L2TP-Schnittstellen für Dual-Stack-Abonnenten erstellt.

  10. Konfigurieren Sie Shaping-, Scheduling- und Rewrite-Regeln und wenden Sie sie im dynamischen Profil auf den Datenverkehr im Tunnel an.

  11. Konfigurieren Sie die L2TP-Tunnel-Gruppe so, dass dynamische LNS-Sitzungen mithilfe des Pools von Inline-Serviceschnittstellen aufgerufen werden, um Load-Balancing zu ermöglichen.

Ergebnisse

Bestätigen Sie im Konfigurationsmodus die Konfiguration des Zugriffsprofils, des Gruppenprofils, des AAA-Profils und der Adresszuweisungspools, indem Sie den show access Befehl eingeben. Bestätigen Sie die Konfiguration der Inline-Dienste, indem Sie den show chassis Befehl eingeben. Bestätigen Sie die Schnittstellenkonfiguration durch Eingabe des show interfaces Befehls. Bestätigen Sie die Konfiguration des dynamischen Profils durch Eingabe des show dynamic-profiles Befehls. Bestätigen Sie die Konfiguration der Tunnel-Gruppe, indem Sie den show services l2tp Befehl eingeben. Wenn die Ausgabe nicht die beabsichtigte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

Wenn Sie mit der Konfiguration des Geräts fertig sind, rufen Sie den Konfigurationsmodus auf commit .

Konfigurieren einer L2TP-Tunnelgruppe für LNS-Sitzungen mit Inline-Serviceschnittstellen

Die L2TP-Tunnel-Gruppe gibt Attribute an, die für L2TP-Tunnel und -Sitzungen von einer Gruppe von LAC-Clients gelten. Zu diesen Attributen gehören das Zugriffsprofil, das zur Validierung von L2TP-Verbindungsanforderungen verwendet wird, die an das LNS an der lokalen Gateway-Adresse gesendet werden, ein lokales Zugriffsprofil, das das globale Zugriffsprofil überschreibt, der Keepalive-Timer und ob der IP-ToS-Wert widergespiegelt wird.

Hinweis:

Wenn Sie eine Tunnel-Gruppe löschen, werden alle L2TP-Sitzungen in dieser Tunnel-Gruppe beendet. Wenn Sie den Wert der local-gateway-addressAnweisungen , service-device-pooloder service-interface ändern, werden alle L2TP-Sitzungen beendet, die diese Einstellungen verwenden. Wenn Sie andere Anweisungen auf Hierarchieebene [edit services l2tp tunnel-group name] ändern oder löschen, verwenden neue Tunnel, die Sie einrichten, die aktualisierten Werte, aber vorhandene Tunnel und Sitzungen sind nicht betroffen.

So konfigurieren Sie die LNS-Tunnel-Gruppe:

  1. Erstellen Sie die Tunnel-Gruppe.
    Hinweis:

    Sie können bis zu 256 Tunnel-Gruppen erstellen.

  2. Geben Sie die Service-Ankerschnittstelle an, die für die L2TP-Verarbeitung im LNS verantwortlich ist.

    Diese Service-Ankerschnittstelle ist für statische LNS-Sitzungen und für dynamische LNS-Sitzungen erforderlich, die den Datenverkehr nicht über einen Pool von Ankerschnittstellen ausgleichen. Die Schnittstelle wird auf Hierarchieebene [edit interfaces] konfiguriert.

  3. (Optional; nur für dynamische LNS-Sitzungen mit Lastausgleich) Geben Sie einen Pool von Inline-Serviceankerschnittstellen an, um das Lastenausgleich von L2TP-Datenverkehr über die Schnittstellen hinweg zu ermöglichen.

    Der Pool wird auf Hierarchieebene [edit services service-device-pools] definiert.

  4. (Nur für dynamische LNS-Sitzungen) Geben Sie den Namen des dynamischen Profils an, das Inline-Serviceschnittstellen für L2TP-Tunnel definiert und instanziiert

    Das Profil wird auf Hierarchieebene [edit dynamic-profiles] definiert.

  5. Geben Sie das Zugriffsprofil an, das alle L2TP-Verbindungsanfragen an die lokale Gateway-Adresse validiert.
  6. Konfigurieren Sie die lokale Gateway-Adresse auf dem LNS; entspricht der IP-Adresse, die von LACs zur Identifizierung des LNS verwendet wird.
  7. (Optional) Konfigurieren Sie den Namen des lokalen Gateways auf dem LNS, der in der SCCRP-Nachricht an die LAC zurückgegeben wird. Der Name muss mit dem in der LAC konfigurierten Namen des Remote-Gateways übereinstimmen, da sonst der Tunnel nicht erstellt werden kann.
  8. (Optional) Konfigurieren Sie das Intervall, in dem das LNS Hello-Nachrichten sendet, wenn es keine Nachrichten von der LAC empfangen hat.
  9. (Optional) Geben Sie ein lokales Zugriffsprofil an, das das globale Zugriffsprofil überschreibt, um die RADIUS-Servereinstellungen für die Tunnel-Gruppe zu konfigurieren.

    Dieses lokale Profil wird auf Hierarchieebene [edit access profile] konfiguriert.

  10. (Optional) Konfigurieren Sie das LNS so, dass es den IP-ToS-Wert vom inneren IP-Header zum äußeren IP-Header widerspiegelt (gilt für CoS-Konfigurationen).
  11. (Optional) Geben Sie ein dynamisches Serviceprofil an, das bei der Anmeldung auf die L2TP-Sitzung angewendet werden soll, sowie alle Parameter, die an den Service übergeben werden sollen.

Anwenden von Services auf eine L2TP-Sitzung ohne Verwendung von RADIUS

Services werden auf L2TP-Sitzungen zur Aktivierung angewendet oder später durch anbieterspezifische Attribute (VSAs) vom RADIUS-Server oder in RADIUS-CoA-Anforderungen (Change of Authorization) geändert. Ab Junos OS Version 18.1R1 können Sie Services auf L2TP-Sitzungen mithilfe von dynamischen Serviceprofilen anwenden, ohne RADIUS einzubeziehen. In Umgebungen mit mehreren Anbietern verwenden Kunden möglicherweise nur Standard-RADIUS-Attribute, um die Verwaltung zu vereinfachen, indem die Verwendung von VSAs von mehreren Anbietern vermieden wird. Dies erschwert jedoch die Anwendung von Services auf L2TP-Sitzungen, da VSAs in der Regel Services anwenden müssen. Mit der Aktivierung des lokalen dynamischen Serviceprofils können Sie dieses Problem vermeiden. Sie können auch die lokale Serviceprofilaktivierung verwenden, um Standarddienste bereitzustellen, wenn RADIUS-Server ausgefallen sind.

Sie können Services auf alle Teilnehmer in einer Tunnel-Gruppe oder auf alle Teilnehmer anwenden, die eine bestimmte LAC verwenden. Sie können maximal 12 Services pro Tunnel-Gruppe oder LAC-Hostname konfigurieren.

Nachdem Sie ein oder mehrere dynamische Serviceprofile konfiguriert haben, die Services definieren, wenden Sie diese in der Tunnel-Gruppe oder in der Zugriffsprofilkonfiguration für einen LAC-Client an, indem Sie die Namen der Serviceprofile angeben. Sie können mehr als ein zu aktivierendes Profil auflisten, getrennt durch ein kaufmännisches Und-Zeichen (&). Sie können auch Parameter angeben, die vom Dienstprofil verwendet werden sollen, die im Profil selbst konfigurierte Werte überschreiben können, z. B. eine Downstream-Shaping-Rate für einen CoS-Dienst.

Die lokal konfigurierte Liste der Services (über Serviceprofile) dient als lokale Autorisierung, die von authd während der Aktivierung der Client-Sitzung angewendet wird. Diese Liste von Services unterliegt der gleichen Validierung und Verarbeitung wie Services, die von einer externen Stelle wie RADIUS stammen. Diese Dienste werden während der Anmeldung des Anwenders angezeigt.

Sie können weiterhin RADIUS VSAs oder CoA-Anforderungen zusammen mit den Dienstprofilen verwenden. Wenn Services von einer externen Stelle als Autorisierung während der Authentifizierung oder während der Sitzungsbereitstellung (Aktivierung) des Anwenders bezogen werden, haben die Services der externen Instanz strikten Vorrang vor denen in der lokalen Konfiguration. Wenn ein mit RADIUS angewendeter Service mit einem Service identisch ist, der mit einem Serviceprofil in der CLI angewendet wird, jedoch mit anderen Parametern, wird der RADIUS-Service mit einer neuen Sitzungs-ID angewendet und hat Vorrang vor dem früheren Serviceprofil.

Sie können Befehle ausgeben, um jeden Service zu deaktivieren oder zu reaktivieren, den Sie zuvor für eine Tunnel-Gruppe oder LAC aktiviert haben.

Definieren Sie die dynamischen Serviceprofile, die Sie später auf eine Tunnel-Gruppe oder LAC anwenden möchten.

So wenden Sie Serviceprofile auf alle Abonnenten in einer Tunnel-Gruppe an:

  • Geben Sie ein oder mehrere Serviceprofile und alle Parameter an, die an die Services übergeben werden sollen.

So wenden Sie Serviceprofile auf alle Abonnenten für eine bestimmte LAC an:

  • Geben Sie ein oder mehrere Serviceprofile und alle Parameter an, die an die Services übergeben werden sollen.

    Hinweis:

    Wenn Dienstprofile für einen LAC-Client und für eine Tunnel-Gruppe konfiguriert sind, die diesen Client verwendet, wird nur das LAC-Client-Serviceprofil angewendet. Es überschreibt die Konfiguration der Tunnel-Gruppe. In der folgenden Konfiguration verwendet die Tunnel-Gruppe tg-LAC-3 beispielsweise den LAC-Client LAC-3, sodass die LAC3-Konfiguration die Konfiguration der Tunnel-Gruppe überschreibt. Folglich wird für Teilnehmer in der Tunnel-Gruppe nur der cos-A3-Dienst aktiviert und nicht Cos2 und fw1. Die für den Dienst übergebene Shaping-Rate beträgt 24 Mbit/s.

Sie können jeden Dienst, der auf eine Anwendersitzung angewendet wird, deaktivieren, indem Sie den folgenden Befehl eingeben:

Sie können jeden Dienst, der auf eine Anwendersitzung angewendet wird, reaktivieren, indem Sie den folgenden Befehl ausführen:

Um die Dienstsitzungen für alle aktuellen Anwender Sitzungen anzuzeigen, verwenden Sie den show subscribers extensive Befehl oder show network-access aaa subscribers session-id id-number detail .

Um die Funktionsweise der lokalen Dienstanwendung zu verstehen, veranschaulichen die folgenden Beispiele die verschiedenen Konfigurationsmöglichkeiten. Betrachten Sie zunächst die folgenden dynamischen Serviceprofilkonfigurationen, cos2 und fw1:

Die folgende Anweisung gilt für beide Dienste für alle Teilnehmer in der Tunnel-Gruppe tg1; Ein Parameterwert von 31 Mbit/s wird an den Cos2-Dienst übergeben:

Im cos2-Serviceprofil wird die Shaping-Rate durch eine benutzerdefinierte Variable mit einem Standardwert von 10 m oder 1 Mbit/s bereitgestellt. Nachdem die L2TP-Sitzung beendet ist, werden cos2 und fw1 mit den Servicesitzungs-IDs 34 bzw. 35 aktiviert.

Der an cos2 übergebene Parameter wird als Wert für $shaping-rate verwendet. Folglich wird die Shaping-Rate für den Dienst vom Standardwert von 10 Mbit/s auf 31 Mbit/s angepasst, wie in der folgenden Befehlsausgabe gezeigt. Obwohl die Ausgabe angibt, dass es sich bei der Anpassungsanwendung um RADIUS CoA handelt, ist die Anpassung eine Folge des an das Serviceprofil übergebenen Parameters. Dieser Vorgang verwendet denselben internen Rahmen wie ein CoA und wird als solcher gemeldet.

Jetzt ist der cos2-Dienst in der CLI für die Anwender-Sitzung 27 deaktiviert.

Die folgende Ausgabe zeigt, dass cos2 verschwunden ist, sodass nur noch fw1 als aktiver Dienst übrig bleibt.

Der folgende Befehl reaktiviert cos2 für die Anwendersitzung 27.

Der reaktivierte cos2-Dienst hat eine neue Dienstsitzungs-ID von 36.

Der reaktivierte cos2-Dienst verwendet die Standard-Shaping-Rate von 10 Mbit/s aus dem Dienstprofil.

Als nächstes geht eine RADIUS CoA-Anfrage ein, die die Activate-Service VSA (26-65) enthält. Der VSA spezifiziert und aktiviert den Dienst und gibt eine Änderung der Shaping-Rate von cos2 von den standardmäßigen 10 Mbit/s auf 12 Mbit/s an. Die cos2-Servicesitzung 36 erscheint weiterhin in der Ausgabe, wird aber durch die neue Servicesitzung ersetzt, die vom CoA 49 initiiert wurde.

Wenn ein Service sowohl von der CLI-Konfiguration als auch von einem RADIUS-VSA (26-65) angewendet wird, jedoch mit unterschiedlichen Parametern, überschreibt die RADIUS-Konfiguration die CLI-Konfiguration. Im folgenden Beispiel wendet die CLI-Konfiguration das cos2-Dienstprofil mit einem Wert von 31 Mbit/s für die Shaping-Rate an.

Die Aktivierung des RADIUS Access-Accept-Nachrichtendiensts VSA (26-65) wendet cos2 mit einem Wert von 21 Mbit/s für die Shaping-Rate an.

Die CLI-Konfiguration aktiviert die Servicesitzung 22 mit einer Shaping-Rate von 31 Mbit/s. Der RADIUS VSA aktiviert die Servicesitzung 23 mit einer Shaping-Rate von 21 Mbit/s.

Pool von Inline-Service-Schnittstellen für dynamische LNS-Sitzungen konfigurieren

Sie können einen Pool von Inline-Serviceschnittstellen erstellen, der auch als Servicegerätepool bezeichnet wird, um das Load Balancing von L2TP-Datenverkehr über die Schnittstellen hinweg zu ermöglichen. Der Pool wird für dynamische LNS-Konfigurationen unterstützt, in denen er eine Reihe logischer Schnittstellen bereitstellt, die dynamisch erstellt und L2TP-Sitzungen auf dem LNS zugewiesen werden können. Der Pool ist einer LNS-Tunnel-Gruppe zugeordnet. L2TP behält den Status jeder Inline-Serviceschnittstelle bei und verwendet eine Round-Robin-Methode, um die Last gleichmäßig auf die verfügbaren Schnittstellen zu verteilen, wenn neue Sitzungsanforderungen akzeptiert werden.

Hinweis:

Load Balancing ist nur für dynamisch erstellte Anwender-Schnittstellen verfügbar.

LNS-Sitzungen, die auf einem MPC verankert sind, sind von einem MIC-Ausfall nicht betroffen, solange ein anderer Pfad zu den Peer-LACs existiert. Wenn der MPC, der die Peer-Schnittstelle hostet, ausfällt und es keinen Pfad zu Peer-LACs gibt, löst der Fehler die Beendigung und Bereinigung aller Sitzungen auf dem MPC aus.

Wenn der MPC, der die LNS-Sitzungen verankert, selbst ausfällt, verlagert die Routing-Engine die Sitzungen nicht in einen anderen Steckplatz, und alle Sitzungen werden sofort beendet. Neue Sitzungen können auf einer anderen verfügbaren Schnittstelle angezeigt werden, wenn der Client einen erneuten Versuch unternimmt.

So konfigurieren Sie den Dienstgerätepool:

  1. Erstellen Sie den Pool.
  2. Geben Sie die Inlinedienstschnittstellen an, aus denen der Pool besteht.

Konfigurieren eines dynamischen Profils für dynamische LNS-Sitzungen

Sie können L2TP so konfigurieren, dass Inline-Serviceschnittstellen für L2TP-Tunnel dynamisch zugewiesen werden. Sie müssen ein oder mehrere dynamische Profile definieren und jeder Tunnel-Gruppe ein Profil zuweisen. Das LNS unterstützt IPv4-, Nur-IPv6- und Dual-Stack-IPv4/IPv6-Sitzungen.

So konfigurieren Sie das dynamische L2TP-Profil:

  1. Erstellen Sie das dynamische Profil.
  2. Konfigurieren Sie die Schnittstelle, die der Routing-Instanz dynamisch zugewiesen wird, die von den getunnelten PPP-Clients verwendet wird.
  3. Konfigurieren Sie die Routing-Optionen für Zugriffsrouten in der Routing-Instanz.
  4. Konfigurieren Sie die Routing-Optionen für zugriffsinterne Routen in der Routing-Instanz.
  5. Definieren Sie die Schnittstellen, die vom dynamischen Profil verwendet werden. Die Variable wird dynamisch durch eine der konfigurierten Inline-Serviceschnittstellen ersetzt.
  6. Konfigurieren Sie die logischen Schnittstellen der Inlineservices für die dynamische Instanziierung.
  7. Geben Sie einen Bezeichner für die logischen Schnittstellen an.
  8. Konfigurieren Sie jede logische Schnittstelle so, dass jeweils nur eine Sitzung verwendet werden kann.
  9. Konfigurieren Sie die Adressfamilie für die logischen Schnittstellen und aktivieren Sie die lokale Adresse auf dem LNS, die die lokale Terminierung für den L2TP-Tunnel bereitstellt, die vom angegebenen Schnittstellennamen abgeleitet werden soll.
    Hinweis:

    Dynamische LNS-Sitzungen erfordern, dass Sie die dial-options Anweisung in das dynamische Profil aufnehmen, was wiederum erfordert, dass Sie die family inet Anweisung einbeziehen. Dies hat folgende Konsequenzen:

    • Sie müssen immer konfigurieren family inet , unabhängig davon, ob Sie Nur-IPv4-, Nur-IPv6- oder Dual-Stack-Schnittstellen im Profil konfigurieren.

    • Wenn Sie reine IPv4-Schnittstellen konfigurieren, konfigurieren Sie nur family inet die Schnittstellenadresse, und Sie müssen die Schnittstellenadresse unter family inetkonfigurieren.

    • Wenn Sie reine IPv6-Schnittstellen konfigurieren, müssen Sie auch family inet6 die Schnittstellenadresse unter family inet6konfigurieren. Sie konfigurieren die Adresse nicht unter family inet.

    • Wenn Sie Dual-Stack-IPv4/IPv6-Schnittstellen konfigurieren, konfigurieren Sie sowohl als family inet6 auch family inet eine Schnittstellenadresse unter jeder Familie.

    Für reine IPv4-Schnittstellen:

    Für reine IPv6-Schnittstellen:

    Für Dual-Stack-IPv4/IPv6-Schnittstellen:

    Hinweis:

    Wenn das Router Advertisement Protocol konfiguriert ist, konfigurieren Sie eine nummerierte Adresse anstelle einer nicht nummerierten Adresse für die lokale IPv6-Adresse:

    Informationen zur Verwendung von Variablen für die reine IPv6- und Dual-Stack-Adressierung in dynamischen Profilen finden Sie im Benutzerhandbuch für Breitband-Anwendersitzungen .

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Veröffentlichung
Beschreibung
18.1R1
Ab Junos OS Version 18.1R1 können Sie Services auf L2TP-Sitzungen mithilfe von dynamischen Serviceprofilen anwenden, ohne RADIUS einzubeziehen.
16.2R1
Ab Junos OS Version 16.2 müssen Sie nicht explizit eine Bandbreite für L2TP LNS-Tunnel-Datenverkehr über Inline-Services angeben.