L2TP für den Abonnentenzugriff – Übersicht

Das Layer 2 Tunneling Protocol (L2TP) ist ein Client-Server-Protokoll, mit dem das Point-to-Point Protocol (PPP) über ein Netzwerk getunnelt werden kann. L2TP kapselt Layer-2-Pakete, wie z. B. PPP, für die Übertragung über ein Netzwerk. Ein L2TP-Zugriffskonzentrator (LAC), der auf einem Zugriffsgerät konfiguriert ist, empfängt Pakete von einem Remote-Client und leitet sie an einen L2TP-Netzwerkserver (LNS) in einem Remote-Netzwerk weiter. Das LNS fungiert als logischer Endpunkt der PPP-Sitzung, die von der LAC vom Remote-Client getunnelt wird. Abbildung 1 zeigt eine einfache L2TP-Topologie.

L2TP trennt die Terminierung von Zugangstechnologien, wie z. B. Kabel oder xDSL, von der Terminierung von PPP und dem anschließenden Zugriff auf ein Netzwerk. Diese Trennung ermöglicht es öffentlichen ISPs, ihre Zugangstechnologien an wettbewerbsfähige Local Exchange Carrier (CLECs) auszulagern. L2TP bietet ISPs die Möglichkeit, VPN-Dienste bereitzustellen. Private Unternehmen können Investitionen in Zugangstechnologien für Telearbeiter reduzieren oder vermeiden.

Sie können Ihren Router so konfigurieren, dass er als LAC im PPP-Passthrough-Modus fungiert, in dem die LAC Pakete von einem Remote-Client empfängt und sie dann auf Layer 2 direkt an das LNS weiterleitet. Die PPP-Sitzung wird auf dem LNS beendet. Diese LAC-Implementierung unterstützt nur PPPoE-Abonnenten (Point-to-Point Protocol over Ethernet) über dynamische oder statische logische Schnittstellen. Abbildung 2 zeigt das Stacking der Protokollschicht für eine L2TP-Passthrough-Verbindung.

Hinweis:

Auf Routern der MX-Serie werden die LAC- und LNS-Funktionen nur auf MPCs unterstützt. Sie werden von den Diensten PIC oder MS-DPC nicht unterstützt. Ausführliche Informationen zur MPC-Unterstützung für L2TP finden Sie in der Referenz zu Schnittstellenmodulen der MX-Serie

Bestimmte Router der M-Serie unterstützen LNS-Funktionen auf Service-PICs. Weitere Informationen zur L2TP-Implementierung auf Routern der M-Serie finden Sie unter Konfigurationsübersicht für L2TP-Services.

Der LAC erstellt dynamisch Tunnel auf der Grundlage von AAA-Authentifizierungsparametern und überträgt L2TP-Pakete über das IP/User Datagram Protocol (UDP) an das LNS. Der Datenverkehr fließt in einem L2TP session; ein Tunnel ist eine Aggregation von einer oder mehreren Sitzungen. Sie können auch eine Domänenzuordnung bereitstellen, die von AAA verwendet wird, um zu bestimmen, ob der PPPoE-Abonnent auf der LAC getunnelt oder beendet werden soll. Es besteht eine Eins-zu-Eins-Zuordnung zwischen jedem PPP-Abonnenten, der zum LNS getunnelt wird, und einer L2TP-Sitzung.

Wenn es sich bei dem LNS um einen Router der MX-Serie handelt, stellt eine LAC-seitige Peer-Schnittstelle auf einem MPC eine IP-Adresse für den Austausch von IP-Paketen zwischen den Tunnelendpunkten bereit. Die Routing-Engine verwaltet die L2TP-Tunnel. Die Packet Forwarding Engine hostet eine oder mehrere Inline-Services-Schnittstellen (si). Diese Schnittstellen funktionieren wie eine virtuelle physische Schnittstelle und verankern die L2TP-Sitzungen im LNS. Die si Schnittstelle ermöglicht L2TP-Services, ohne dass ein spezielles Services PIC erforderlich ist. Schließlich wird eine weitere Schnittstelle verwendet, um die Teilnehmerdaten zum und vom Internet zu übertragen.

Die Eigenschaften des Tunnels können entweder von einem Tunnelprofil stammen, das Sie konfigurieren, oder von RADIUS-Tunnelattributen und herstellerspezifischen Attributen (VSAs) vom AAA-Server, auf den über die LAC zugegriffen werden kann. Sie können ein Tunnelprofil in eine Domänenzuordnung einschließen, wodurch das Tunnelprofil angewendet wird, bevor die RADIUS-Authentifizierung stattfindet. Sie können RADIUS-Standardattribute und VSAs verwenden, um einige oder alle vom Tunnelprofil konfigurierten Merkmale in einer Domänenzuordnung zu überschreiben. Alternativ kann RADIUS selbst ein Tunnelprofil anwenden, wenn im RADIUS-Login die RADIUS Tunnel-Group VSA [26-64] angegeben ist.

Hinweis:

L2TP wird über GRE-Tunnel nicht unterstützt.

Der Virtual-Router VSA [26-1] im Teilnehmerprofil auf dem AAA-Server des Service Providers (auf den vom LNS aus zugegriffen werden kann) bestimmt die Routing-Instanz, in der die L2TP-Sitzung auf dem LNS aufgerufen wird. Wenn diese VSA nicht vorhanden ist, wird die Abonnentensitzung in derselben Routinginstanz wie der Tunnel ausgeführt, da auf den AAA-Server nur von der Routinginstanz aus zugegriffen werden kann, in der der Tunnel auf dem LNS endet.

Dieses Verhalten unterscheidet sich von dem für DHCP- und nicht getunnelte PPPoE-Abonnenten, die in der Standard-Routinginstanz ohne den virtuellen Router VSA auftreten. Für L2TP-Abonnenten müssen Sie diese VSA in das Abonnentenprofil aufnehmen, wenn die Abonnentensitzung in einer anderen Routinginstanz als die Tunnelroutinginstanz ausgeführt werden soll.

Ab Junos OS Version 17.4R1 enthält das LNS die folgenden RADIUS-Attribute, wenn es eine Access-Request-Nachricht an den RADIUS-Server sendet:

• Tunnel-Typ (64)

• Tunnel-Medium-Typ (65)

• Tunnel-Client-Endpunkt (66)

• Tunnel-Server-Endpunkt (67)

• Acct-Tunnel-Verbindung (68)

• Tunnel-Zuweisungs-ID (82)

• Tunnel-Client-Authentifizierungs-ID (90)

• tunnel-server-auth-id (91)

In früheren Versionen enthält das LNS diese Attribute nur in den Abrechnungsdatensätzen, die es an den RADIUS-Server sendet. In den Access-Request-Nachrichten können sie verwendet werden, um auf dem RADIUS-Server die Sitzung von der LAC zum LNS zu korrelieren.

Die LAC unterstützt die von RADIUS initiierte Spiegelung, bei der sichere Richtlinien auf der Grundlage bestimmter RADIUS-VSAs erstellt werden, und verwendet RADIUS-Attribute, um einen Abonnenten zu identifizieren, dessen Datenverkehr gespiegelt werden soll. (Diese Funktion wird für LNS, das auf einem Router der MX-Serie konfiguriert ist, nicht unterstützt.)

Die LAC und die LNS unterstützen die einheitliche ISSU. Wenn ein Upgrade eingeleitet wird, schließt die LAC alle laufenden L2TP-Verhandlungen ab, lehnt jedoch alle neuen Verhandlungen ab, bis das Upgrade abgeschlossen ist. Während des Upgrades werden keine neuen Tunnel oder Sitzungen eingerichtet. Abonnentenabmeldungen werden während des Upgrades aufgezeichnet und nach Abschluss des Upgrades abgeschlossen.

Tabelle 1 beschreibt die Grundbegriffe für L2TP.

Tabelle 1: L2TP-Begriffe

Begriff	Beschreibung
AVP	Attributwertpaar (AVP): Kombination aus einem eindeutigen Attribut, das durch eine ganze Zahl dargestellt wird, und einem Wert, der den tatsächlichen Wert enthält, der durch das Attribut identifiziert wird.
Aufrufen	Eine Verbindung (oder versuchte Verbindung) zwischen einem Remote-System und dem LAC.
LAC	L2TP Access Concentrator (LAC): Ein Knoten, der als eine Seite eines L2TP-Tunnelendpunkts fungiert und ein Peer zum LNS ist. Die LAC befindet sich zwischen einem LNS und einem Remote-System und leitet Pakete zu und von beiden weiter.
LNS	L2TP-Netzwerkserver (LNS): Ein Knoten, der als eine Seite eines L2TP-Tunnelendpunkts fungiert und ein Peer zum LAC ist. Das LNS ist der logische Endpunkt einer PPP-Verbindung, die vom LAC vom Remote-System getunnelt wird.
Peer	Im L2TP-Kontext entweder die LAC oder LNS. Der Peer des LAC ist ein LNS und umgekehrt.
Proxy-Authentifizierung	PPP-Vorauthentifizierung, die von der LAC im Auftrag des LNS durchgeführt wird. Die Proxy-Daten werden von der LAC an das LNS gesendet und enthalten Attribute wie Authentifizierungstyp, Authentifizierungsname und Authentifizierungsabfrage. Das LNS antwortet mit den Authentifizierungsergebnissen.
Proxy-LCP	LCP-Aushandlung (Link Control Protocol), die von der LAC im Auftrag des LNS durchgeführt wird. Der Proxy wird von der LAC an das LNS gesendet, das Attribute enthält, wie z. B. die letzten Konfigurationsattribute, die vom Client gesendet und empfangen wurden.
Entferntes System	Ein Endsystem oder ein Router, der mit einem RAS-Netzwerk verbunden ist, das entweder der Initiator oder der Empfänger eines Anrufs ist.
Sitzung	Eine logische Verbindung, die zwischen dem LAC und dem LNS hergestellt wird, wenn eine End-to-End-PPP-Verbindung zwischen einem Remote-System und dem LNS hergestellt wird. Hinweis: Es besteht eine Eins-zu-Eins-Beziehung zwischen etablierten L2TP-Sitzungen und den zugehörigen PPP-Verbindungen.
Tunnel	Eine Verbindung zwischen dem LAC-LNS-Paar, die aus einer Steuerverbindung und 0 oder mehr L2TP-Sitzungen besteht.

Die Implementierung von L2TP erfolgt auf vier Ebenen:

• Quelle: Der lokale Router, der als LAC fungiert.

• Ziel: Der Remote-Router, der als LNS fungiert.

• Tunnel: Ein direkter Pfad zwischen dem LAC und dem LNS.

• Sitzung: Eine PPP-Verbindung in einem Tunnel.

Wenn der Router Ziele, Tunnel und Sitzungen eingerichtet hat, können Sie den L2TP-Datenverkehr steuern. Das Vornehmen einer Änderung an einem Ziel wirkt sich auf alle Tunnel und Sitzungen zu diesem Ziel aus. Eine Änderung an einem Tunnel wirkt sich auf alle Sitzungen in diesem Tunnel aus. Wenn Sie beispielsweise ein Ziel schließen, werden alle Tunnel und Sitzungen zu diesem Ziel geschlossen.

• Ablauf der Ereignisse auf der LAC
• Ablauf der Ereignisse auf dem LNS

L2TP-Peers unterhalten eine Warteschlange von Steuernachrichten, die an das Peer-Gerät gesendet werden müssen. Nachdem der lokale Peer (LAC oder LNS) eine Nachricht gesendet hat, wartet er auf eine Antwort vom Remote-Peer. Wenn keine Antwort empfangen wird, überträgt der lokale Peer die Nachricht erneut. Dieses Verhalten gibt dem Remotepeer mehr Zeit, auf die Nachricht zu antworten.

Sie haben zwei Möglichkeiten, das Verhalten der erneuten Übertragung zu steuern:

• Anzahl der erneuten Übertragungen: Sie können konfigurieren, wie oft eine nicht bestätigte Nachricht vom lokalen Peer erneut übertragen wird. Durch Erhöhen der Anzahl erhalten Sie mehr Reaktionsmöglichkeiten für den Remotepeer, erhöhen aber auch die Menge des Steuerungsdatenverkehrs. Fügen Sie bei eingerichteten Tunneln die retransmission-count-established Anweisung auf Hierarchieebene [edit services l2tp tunnel] ein. Fügen Sie für Tunnel, die noch nicht eingerichtet wurden, die retransmission-count-not-established Anweisung hinzu.

• Erneutes Übertragungsintervall: Sie können konfigurieren, wie lange der lokale Peer auf die erste Antwort auf eine Steuernachricht wartet. Wenn eine Antwort nicht innerhalb des ersten Timeoutintervalls empfangen wird, verdoppelt der Timer für die erneute Übertragung das Intervall zwischen jeder nachfolgenden erneuten Übertragung auf maximal 16 Sekunden. Durch Erhöhen des Intervalls hat der Remotepeer mehr Zeit zum Antworten, wendet aber auch mehr Ressourcen für einen potenziell nicht verfügbaren Peer auf. Fügen Sie die minimum-retransmission-interval Anweisung auf Hierarchieebene [edit services l2tp tunnel] ein.

Der lokale Peer setzt die erneute Übertragung der Steuernachricht fort, bis einer der folgenden Fälle eintritt:

• Innerhalb der aktuellen Wartezeit geht eine Antwort ein.

• Die maximale Anzahl von Wiederholungen ist erreicht.

Wenn die maximale Anzahl erreicht ist und keine Antwort empfangen wurde, werden der Tunnel und alle seine Sitzungen gelöscht.

Hinweis:

Das Erreichen des maximalen Intervalls von 16 Sekunden stoppt die erneute Übertragung nicht. Der lokale Peer wartet nach jeder weiteren Neuübertragung noch 16 Sekunden.

Die folgenden Beispiele beschreiben das erneute Übertragungsverhalten unter verschiedenen Umständen:

• Beispiel 1: Die Anzahl der erneuten Übertragungen beträgt drei und das minimale Intervall für die erneute Übertragung beträgt 1 Sekunde.

  1. Der lokale Peer sendet eine Steuernachricht.

  2. Der lokale Peer wartet 1 Sekunde, erhält aber keine Antwort.

  3. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die erste Wiederholung.

  4. Der lokale Peer wartet 2 Sekunden, erhält jedoch eine Antwort, bevor das Intervall abläuft.

  5. Die erneute Übertragung wird beendet, da innerhalb des Intervalls eine Antwort empfangen wird.

• Beispiel 2: Die Anzahl der erneuten Übertragungen beträgt zwei und das minimale Intervall für die erneute Übertragung beträgt 8 Sekunden.

  1. Der lokale Peer sendet eine Steuernachricht.

  2. Der lokale Peer wartet 8 Sekunden, erhält aber keine Antwort.

  3. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die erste Wiederholung.

  4. Der lokale Peer wartet 16 Sekunden, erhält aber keine Antwort.

  5. Der lokale Peer überträgt die Steuernachricht erneut. Dies ist die zweite erneute Übertragung.

  6. Der lokale Peer wartet erneut 16 Sekunden, da das Intervall nicht über 16 Sekunden ansteigen kann, erhält aber keine Antwort.

  7. Die erneute Übertragung wird beendet, weil die maximale Anzahl von zwei erneuten Übertragungen erreicht wurde.

  8. Der Tunnel und alle seine Sitzungen werden gelöscht.

• Zweck
• Aktion