Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

L2TP LNS Inline-Service-Schnittstellen

Konfigurieren eines L2TP-LNS mit Inline-Service-Schnittstellen

Die L2TP-LNS-Funktionslizenz muss installiert sein, bevor Sie mit der Konfiguration beginnen. Andernfalls wird eine Warnmeldung angezeigt, wenn die Konfiguration festgeschrieben wird.

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

  1. (Optional) Konfigurieren Sie ein Benutzergruppenprofil, das die PPP-Konfiguration für Tunnelabonnenten definiert.
  2. (Optional) Konfigurieren Sie PPP-Attribute für Abonnenten auf Inline-Dienstschnittstellen.
  3. Konfigurieren Sie die Inline-IP-Reassemblierung.

    Weitere Informationen finden Sie unter Konfigurieren der IP-Inline-Reassemblierung für L2TP.

  4. Konfigurieren Sie ein L2TP-Zugriffsprofil, das die L2TP-Parameter für jeden LNS-Client (LAC) definiert.

    Weitere Informationen finden Sie unter Konfigurieren eines L2TP-Zugriffsprofils auf dem LNS.

  5. (Optional) Konfigurieren Sie ein AAA-Zugriffsprofil, um das unter der Routing-Instanz konfigurierte Zugriffsprofil außer Kraft zu setzen.

    Weitere Informationen finden Sie unter Konfigurieren eines lokalen AAA-Zugriffsprofils auf dem LNS.

  6. Konfigurieren Sie einen Pool von Adressen, die getunnelten PPP-Abonnenten dynamisch zugewiesen werden sollen.
  7. Konfigurieren Sie die Peer-Schnittstelle so, dass der Tunnel und die serverseitige PPP-IPCP-Adresse beendet werden.

    Weitere Informationen finden Sie unter Konfigurieren der L2TP-LNS-Peer-Schnittstelle.

  8. Aktivieren von Inline-Serviceschnittstellen auf einer MPC.

    Weitere Informationen finden Sie unter Aktivieren von Inline-Service-Schnittstellen.

  9. Konfigurieren Sie eine Dienstschnittstelle.
  10. Konfigurieren Sie Optionen für jede logische Inlinedienstschnittstelle.
  11. (Optional) Konfigurieren Sie eine aggregierte Inline-Serviceschnittstelle und zustandsbehaftete 1:1-Redundanz.
  12. Konfigurieren Sie die L2TP-Tunnelgruppe.
  13. (Optional) Konfigurieren Sie ein dynamisches Profil, das logische L2TP-Schnittstellen dynamisch erstellt.
  14. (Optional) Konfigurieren Sie einen Serviceschnittstellenpool für dynamische LNS-Sitzungen.
  15. (Optional) Geben Sie an, wie oft L2TP unbestätigte Steuermeldungen erneut überträgt.
  16. (Optional) Geben Sie an, wie lange ein Tunnel im Leerlauf bleiben darf, bevor er abgerissen wird.

    Weitere Informationen finden Sie unter Festlegen des Leerlauf-Timeouts für den L2TP-Tunnel.

  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.

    Weitere Informationen finden Sie unter Festlegen der Größe des L2TP-Empfangsfensters.

  18. (Optional) Geben Sie an, wie lange der L2TP Informationen über beendete dynamische Tunnel, Sitzungen und Ziele speichert.

    Weitere Informationen finden Sie unter Festlegen des L2TP-Zerstörungs-Timeouts.

  19. (Optional) Konfigurieren Sie das Zeitlimit für die L2TP-Zielsperre.

    Weitere Informationen finden Sie unter Konfigurieren der Zeitüberschreitung für die L2TP-Zielsperre.

  20. (Optional) Konfigurieren Sie L2TP-Tunnel-Switching.

    Weitere Informationen finden Sie unter Konfigurieren von L2TP-Tunnel-Switching.

  21. (Optional) Verhindern Sie die Erstellung neuer Sitzungen, Ziele oder Tunnel für L2TP.

    Weitere Informationen finden Sie unter Konfigurieren des L2TP-Abflusses.

  22. (Optional) Konfigurieren Sie, ob das L2TP-Failover-Protokoll ausgehandelt wird oder die unbeaufsichtigte Failover-Methode für die Neusynchronisierung verwendet wird.

    Weitere Informationen finden Sie unter Konfigurieren der L2TP-Peer-Resynchronisationsmethode.

  23. (Optional) Aktivieren Sie SNMP-Statistikzähler.
  24. (Optional) Konfigurieren Sie Ablaufverfolgungsoptionen für die Fehlerbehebung bei der Konfiguration.

    Weitere Informationen zur Fehlerbehebung finden Sie unter Ablaufverfolgung von L2TP-Ereignissen.

Außerdem müssen Sie 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-Service-Schnittstelle

Sie können PPP-Attribute konfigurieren, die vom LNS auf der Inline-Service-Schnittstelle (si) auf die PPP-Abonnenten angewendet werden, die vom 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 stimmt mit der Konfiguration überein, die für beendete PPPoE-Abonnenten verwendet wird.

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-Nachrichten für den L2TP-Tunnel, der auf dem LNS endet.
  3. Konfigurieren Sie PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten beim LNS gelten.
  4. Geben Sie eine Reihe von AAA-Optionen an, die für die Authentifizierung und Autorisierung von getunnelten PPP-Abonnenten beim LNS verwendet werden, die sich über die Abonnenten- und AAA-Kontexte anmelden, die im AAA-Optionssatz angegeben sind.

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

  5. Konfigurieren Sie den Router so, dass CPE (Customer Premises Equipment) aufgefordert wird, während der IPCP-Aushandlung für getunnelte PPP-Abonnenten im LNS sowohl primäre als auch sekundäre DNS-Adressen auszuhandeln.
  6. (Optional) Deaktiviert die Validierung der magischen PPP-Zahl 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, so dass eine Nichtübereinstimmung nicht zum Abbruch der Sitzung führt.

So konfigurieren Sie die PPP-Attribute für statisch erstellte SI-Schnittstellen:

  1. Geben Sie die logische Inline-Service-Schnittstelle an.

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

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

    Hinweis:

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

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

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

Bewährte Methode:

Obwohl alle anderen Anweisungen, die untergeordnet sind – einschließlich derjenigen, die und chap pap– untergeordnet sindppp-options, unterstützt werden, werden sie in der Regel nicht für die Abonnentenverwaltung verwendet. Es wird empfohlen, diese anderen Anweisungen bei 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 dynamische Profilkonfiguration 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 Priorität bedeutet, dass keine Optionen zwischen den Profilen zusammengeführt werden. Das Gruppenprofil wird nur dann auf den Abonnenten angewendet, wenn das dynamische Profil keine PPP-Option enthält, die im Gruppenprofil verfügbar ist.

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 vom 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-Nachrichten 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 gestartet werden. Bestehende Sitzungen sind davon nicht betroffen.

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

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

  5. Konfigurieren Sie den Router so, dass das Customer Premises Equipment (CPE) aufgefordert wird, während der IPCP-Aushandlung für getunnelte PPP-Abonnenten im LNS sowohl primäre als auch sekundäre DNS-Adressen auszuhandeln.
  6. (Optional) Deaktivieren Sie die Paketweiterleitungs-Engine, um eine Validierungsprüfung auf magische PPP-Zahlen durchzuführen, die von einem Remote-Peer im LCP-Keepalive-Austausch (Echo-Request/Echo-Reply) empfangen wurden. Dadurch wird verhindert, dass PPP die Sitzung beendet, wenn die Anzahl nicht mit dem Wert übereinstimmt, der während der LCP-Aushandlung vereinbart wurde. 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 der magischen LCP-Zahlen oder auf den Austausch von Keepalives, wenn die magische Zahl des Remotepeers die erwartete ausgehandelte Zahl ist.
  7. Konfigurieren Sie, wie lange sich die PPP-Abonnentensitzung im Leerlauf befinden darf, bevor das Zeitlimit überschritten wird.
Hinweis:

Sie können PPP-Attribute auch für jede Schnittstelle einzeln 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 dynamische Profilkonfiguration 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 Priorität bedeutet, dass keine Optionen zwischen den Profilen zusammengeführt werden. Das Gruppenprofil wird nur dann auf den Abonnenten angewendet, wenn das dynamische Profil keine PPP-Option enthält, die im Gruppenprofil verfügbar ist.

Konfigurieren eines L2TP-Zugriffsprofils auf dem LNS

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

So konfigurieren Sie ein L2TP-Zugriffsprofil:

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

    Mit Ausnahme des Sonderfalls des Clients muss der Name des LAC-Clients, den Sie im Zugriffsprofil konfigurieren, mit dem Hostnamen des default LAC übereinstimmen. Im Falle eines Routers von Juniper Networks, der als LAC fungiert, wird der Hostname im LAC-Tunnelprofil mit der Gateway-gateway-name-Anweisung 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 diese Option als Client-Namen, wenn Sie einen Standard-Tunnel-Client definieren möchten. Der Standardclient ermöglicht die Authentifizierung mehrerer LACs mit denselben Secret- und L2TP-Attributen. Dieses Verhalten ist nützlich, wenn z. B. viele neue LACs zum Netzwerk hinzugefügt werden, da die LACs ohne zusätzliche LNS-Profilkonfiguration verwendet werden können.

    Nur auf Routern der MX-Serie verwenden default . Der entsprechende Clientname auf Routern der M-Serie lautet *.

  3. (Optional) Geben Sie ein lokales Zugriffsprofil an, das das globale Zugriffsprofil und das AAA-Zugriffsprofil der Tunnelgruppe außer Kraft setzt, 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 getunnelt.
  5. Konfigurieren Sie ein oder mehrere dynamische Dienstprofile, um Dienste auf alle Abonnenten in der LAC anzuwenden. Optional können Sie Parameter an die Services in derselben Anweisung ü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 in CDN-Nachrichten, die es an die LAC sendet, wenn die Anzahl der L2TP-Sitzungen den konfigurierten Maximalwert erreicht, die Ergebniscodes 4 und 5 mit dem Ergebniscode 2 überschrieben werden. Einige LACs von Drittanbietern können nur dann ein Failover auf ein anderes LNS ausführen, wenn der Ergebniscode den Wert 2 aufweist.
  8. Konfigurieren Sie das Tunnelkennwort, 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 Protocol-Clientkonfiguration verwendet haben, aus.

Konfigurieren eines lokalen AAA-Zugriffsprofils auf dem LNS

Bei einigen LNS-Tunneln kann es sinnvoll sein, das Zugriffsprofil zu überschreiben, das auf der Routing-Instanz konfiguriert ist, die den Tunnel hostet, mit einer bestimmten RADIUS-Serverkonfiguration. 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 Tunnelgruppe oder einen LAC-Client anzuwenden.

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

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 Authentifizierungskennwort.

Adresszuweisungspool für L2TP-LNS mit Inline-Services konfigurieren

Sie können Adresspools konfigurieren, die den getunnelten PPP-Abonnenten dynamisch zugewiesen werden können. Die Pools müssen für die Routinginstanz, in der der Abonnent angezeigt wird, lokal sein. 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.

Optional können Sie mehrere benannte Adressbereiche oder Teilmengen von Adressen innerhalb eines Adresszuweisungspools konfigurieren. Bei der dynamischen Adresszuweisung kann einem Mandanten 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:

Stellen Sie sicher, dass Sie die Anweisung address-assignment pools () anstelle der address pools-Anweisung (address-assignmentaddress-pool) verwenden.

Weitere Informationen zu Adresszuweisungspools finden Sie unter Übersicht über Adresszuweisungspools und Übersicht über die Konfiguration von 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 unteren und oberen Grenzen der Adressen im Bereich.

So konfigurieren Sie z. B. 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äfixangabe 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 der unteren und oberen Grenze der Präfixe im Bereich oder basierend auf der Länge der Präfixe im Bereich definieren.

So konfigurieren Sie beispielsweise einen IPv6-Adresszuweisungspool:

Konfigurieren der L2TP-LNS-Peer-Schnittstelle

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

Hinweis:

Bei 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 Tunnelendpunkt nicht unterstützt.

Aktivieren von Inline-Service-Schnittstellen

Die Inline-Dienstschnittstelle ist eine virtuelle physische Schnittstelle, die sich auf der Paketweiterleitungs-Engine befindet. Diese si Schnittstelle, die als Ankerschnittstelle bezeichnet wird, ermöglicht die Bereitstellung von L2TP-Diensten ohne ein spezielles Service-PIC. Die Inline-Service-Schnittstelle wird nur von MPCs auf Routern der MX-Serie unterstützt. Vier Inline-Service-Schnittstellen sind pro MPC-belegtem Chassis-Steckplatz 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. Auf MX80- und MX104-Routern kann si-0/0/0 für diesen Zweck nicht konfiguriert werden.

Obwohl der Bandbreitenwertebereich zwischen 1 Gbit/s und 400 Gbit/s liegt, können Sie die Bandbreite nicht in absoluten Zahlen konfigurieren, z. B. 12.345.878.000 Bbit/s. Sie müssen die in der CLI-Anweisung verfügbaren Optionen verwenden:

  • 1g

  • 10gin 10-Gbit/s-Schritten: , , , 50g40g90g20g80g30g70g60g10g100g100g

  • 100gin Schritten von 400g 100 Gbit/s: 100g, , , 300g200g400g

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

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 aktualisierten Modus mit 1,6 Tbit/s

MPC9E

400 Gbit/s

So aktivieren Sie Inline-Service-Schnittstellen:

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

Konfigurieren einer Inline-Service-Schnittstelle für L2TP-LNS

Die Inline-Service-Schnittstelle ist eine virtuelle physische Service-Schnittstelle, die sich auf der Packet Forwarding Engine befindet. Diese si Schnittstelle, die als Ankerschnittstelle bezeichnet wird, ermöglicht die Bereitstellung von L2TP-Diensten ohne ein spezielles Service-PIC. Die Inline-Service-Schnittstelle wird nur von MPCs auf Routern der MX-Serie unterstützt. Vier Inline-Service-Schnittstellen sind pro MPC-belegtem Chassis-Steckplatz 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 beansprucht 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 gestaltet werden können, auf die Anzahl der L2-Knoten oder 4096 Sitzungen beschränkt. Es gibt immer noch zusätzliche Sitzungen, aber sie sind nicht gestaltet.

So konfigurieren Sie eine Inline-Service-Schnittstelle:

  1. Greifen Sie auf die Serviceschnittstelle zu.
  2. (Optional; nur für die Strukturierung pro Sitzung) Aktivieren Sie die Inline-Dienstschnittstelle für hierarchische Scheduler, und begrenzen Sie die Anzahl der Schedulerebenen auf zwei.
  3. (Optional; nur für die Strukturierung pro Sitzung) Konfigurieren Sie die Dienstkapselung für die Inlinedienstschnittstelle.
  4. Konfigurieren Sie die IPv4-Familie auf der logischen Schnittstelle der reservierten Einheit 0.

Konfigurieren von Optionen für die logische Schnittstelle der LNS-Inline-Services

Sie müssen Merkmale für jede der logischen Inline-Services-Schnittstellendial-options 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 sie als dedicated Schnittstelle konfigurieren. Diese shared Option wird nicht unterstützt. (Unterstützung dedicated und shared Optionen für LNS bei Routern der M-Serie.) 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 Abonnent 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 Inlinedienste zu.
  2. Geben Sie einen Bezeichner für die logische Schnittstelle an.
  3. Konfigurieren Sie die logische Schnittstelle so, dass sie jeweils nur für eine Sitzung verwendet wird.
  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, um sie aus dem angegebenen Schnittstellennamen abzuleiten.

LNS 1:1 Stateful Redundancy – Übersicht

Standardmäßig geht der L2TP-Abonnentendatenverkehr verloren, 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. 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 dann erneut eine Verbindung herstellen.

Sie können unter diesen Umständen Datenverkehrsverluste vermeiden, indem Sie ein aggregiertes Inline Service Interface (asi)-Bundle so konfigurieren, dass es eine zustandsbehaftete 1:1-Redundanz bereitstellt, die auch als Hot-Standby- oder Aktiv-Backup-Redundanz bezeichnet wird. Das Bundle besteht aus einem Paar physischer si-Schnittstellen, der primären (aktiven) Member-Verbindung und der sekundären (Standby- oder Backup-) Member-Verbindung. Diese Schnittstellen müssen auf unterschiedlichen MPCs konfiguriert werden. Redundanz ist nicht erreichbar, wenn Sie die primäre und sekundäre Schnittstelle auf derselben MPC konfigurieren, da beide Mitgliedsschnittstellen ausfallen, wenn die Karte ausfällt.

Wenn sich Abonnenten anmelden und eine 1:1-Redundanz konfiguriert ist, wird die L2TP-Sitzung über eine zugrunde liegende virtuelle logische Schnittstelle (asi.0x) über die physische Schnittstelle asi0 eingerichtet. Einzelne logische Abonnentenschnittstellen werden auf der zugrunde liegenden Schnittstelle im Format asiX. erstellt.logical-unit-number Die Sitzung bleibt im Falle eines Fehlers oder eines Neustarts auf der MPC, die die primäre Member-Link-Schnittstelle hostet, aktiv. Der gesamte Datenverkehr, der für diese L2TP-Sitzung bestimmt ist, wird automatisch auf die sekundäre Member-Link-Schnittstelle des anderen MPC übertragen.

Konfiguration der zustandsbehafteten 1:1-LNS-Redundanz für aggregierte Inline-Serviceschnittstellen

Sie können ein aggregiertes ASI-Bundle (Inline Service Interface) erstellen, um zustandsbehaftete 1:1-LNS-Redundanz für Inline-Service-Ankerschnittstellen (SI) bereitzustellen. Das Paket kombiniert zwei Schnittstellen, die sich auf unterschiedlichen MPCs befinden, als primäre und sekundäre Verbindungen. LNS-Sitzungen werden anschließend über eine virtuelle logische Schnittstelle, asiX., aufgebaut.logical-unit-number Ein LNS-Sitzungsfailover 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 für die Sitzung bestimmte LNS-Datenverkehr wird automatisch auf die sekundäre Schnittstelle übertragen. Die Abonnentensitzung bleibt auf derX virtuellen asi.-Schnittstelle aktiv.logical-unit-number Es gehen keine Datenverkehrsstatistiken verloren. Wenn diese Redundanz nicht konfiguriert ist, geht der Abonnentendatenverkehr verloren, die Keepalives laufen ab, und der PPP-Client wird getrennt und muss erneut verbunden werden.

Bevor Sie beginnen, müssen Sie Folgendes tun:

Bewährte Methode:

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 Hierarchieebene [edit chassis fpc slot pic number inline-services bandwidth] konfigurierte Bandbreite muss für beide Mitgliedsverbindungen identisch sein.

  • Eine si-Schnittstelle, die als Mitglied eines aggregierten Inline-Service-Interface-Bundles konfiguriert ist, kann nicht als Mitglied einer anderen Bundle-Gruppe konfiguriert werden.

  • Eine si-Schnittstelle, die als Mitglied eines aggregierten Inline-Service-Interface-Bundles konfiguriert ist, kann nicht auch für Funktionen verwendet werden, die sich nicht auf aggregierte Services beziehen. Es kann beispielsweise nicht für die Inline-IP-Reassemblierung verwendet werden.

  • Wenn Sie eine si-Schnittstelle als Mitglied eines aggregierten Inline-Services-Bundles 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 Mitgliederschnittstellen angewendet.

So konfigurieren Sie die zustandsbehaftete 1:1-LNS-Redundanz:

  1. Geben Sie auf einer MPC den primären (aktiven) Inline-Services-Mitgliederlink im Bundle an.
  2. Konfigurieren Sie die Bandbreite, die auf dieser MPC für Tunneldatenverkehr reserviert ist, mithilfe der primären Inline-Service-Schnittstelle.
  3. Geben Sie in einer anderen MPC den sekundären (Backup) Inline-Services-Mitgliedslink im Bundle an.
    Hinweis:

    Wenn Sie die aktiven und Backup-Member-Links auf demselben MPC konfigurieren, schlägt der nachfolgende Commit der Konfiguration fehl.

  4. Konfigurieren Sie die Bandbreite, die auf dieser MPC für Tunneldatenverkehr reserviert ist, mithilfe der sekundären Inline-Service-Schnittstelle.
  5. Weisen Sie das aggregierte Inline-Service-Interface-Bundle einer L2TP-Tunnelgruppe mit einer der folgenden Methoden zu:
    • Weisen Sie ein einzelnes Bundle zu, indem Sie den Namen der aggregierten physischen Inline-Service-Schnittstelle angeben.

    • Weisen Sie der Tunnelgruppe einen oder mehrere Bundle-Pools zu.

      Hinweis:

      Ein Pool kann gemischt werden; Das heißt, sie kann sowohl aggregierte Inline-Service-Interface-Bundles als auch einzelne Inline-Service-Interfaces enthalten. Die einzelnen Schnittstellen dürfen nicht Mitglieder bestehender Bundles sein.

In der folgenden Beispielkonfiguration wird das Bundle asi0 mit Mitgliederlinks auf MPCs in Steckplatz 1 und Steckplatz 2 erstellt und dann das Bundle zugewiesen, um Redundanz für L2TP-Sitzungen in der Tunnelgruppe tg1 bereitzustellen:

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

Zweck

Zeigen Sie Informationen zu aggregierten Inline-Serviceschnittstellenpaketen, einzelnen Mitgliederlinks und Redundanzstatus an.

Aktion

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

  • So zeigen Sie detaillierte Informationen zu einem aggregierten Inline-Service-Interface-Bundle an:

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

  • So zeigen Sie den Redundanzstatus für aggregierte Inline-Service-Interface-Bundles an:

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

  • So zeigen Sie detaillierte Informationen zu allen konfigurierten Redundanzschnittstellen an:

L2TP-Sitzungslimits und Load Balancing für Serviceschnittstellen

Das LNS verteilt den Lastenausgleich der Abonnentensitzungen auf die verfügbaren Serviceschnittstellen in einem Gerätepool basierend auf der Anzahl der Sitzungen, die derzeit auf den Schnittstellen aktiv sind. Sie können eine Höchstgrenze pro Service-Interface (si) und pro aggregierter Service-Schnittstelle (asi) konfigurieren. Bei asi-Schnittstellen können Sie kein Limit für die einzelnen si-Member-Schnittstellen im Bundle konfigurieren.

Sitzungsbeschränkungen für Dienstschnittstellen

Wenn eine L2TP-Sitzungsanforderung für eine Serviceschnittstelle initiiert wird, vergleicht LNS die Anzahl der aktuell 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 (die durch den show services l2tp summary Befehl angezeigt wird) kleiner als der konfigurierte Grenzwert ist. Wenn dies der Fall ist oder wenn kein Limit konfiguriert ist, wird die Prüfung erfolgreich und die Sitzung kann eingerichtet werden. Wenn die aktuelle Sitzungsanzahl dem konfigurierten Grenzwert entspricht, lehnt das LNS die Sitzungsanforderung ab. Auf dieser Schnittstelle können keine nachfolgenden Anforderungen akzeptiert werden, bis 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, in der der Ergebniscode auf 2 und der Fehlercode auf 4 festgelegt ist.

Angenommen, in der Tunnelgruppe ist eine einzelne Dienstschnittstelle konfiguriert. Die aktuelle Anzahl von L2TP-Sitzungen beträgt 1500 mit einem konfigurierten Limit von 2000 Sitzungen. Wenn eine neue Sitzung angefordert wird, ist die Limitprüfung bestanden und die Sitzungsanforderung wird akzeptiert.

Schnittstelle

Konfiguriertes Sitzungslimit

Aktuelle Sitzungsanzahl

Ergebnis der Sitzungslimitprüfung

si-0/0/0

2000

1500

Bestehen

Die Grenzwertprüfung wird weiterhin bestanden und Sitzungsanforderungen werden akzeptiert, bis 500 Anforderungen akzeptiert wurden, sodass die aktuelle Sitzungsanzahl 2000 beträgt, was dem konfigurierten Maximum entspricht. Die Sitzungslimitprüfung schlägt für alle nachfolgenden Anforderungen fehl, und alle Anforderungen werden zurückgewiesen, bis die aktuelle Sitzungsanzahl auf der Schnittstelle unter 2000 fällt, sodass die Limitprüfung bestanden werden kann.

Schnittstelle

Konfiguriertes Sitzungslimit

Aktuelle Sitzungsanzahl

Ergebnis der Sitzungslimitprüfung

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 Tunnelgruppe ist, werden alle Sitzungsanforderungen in der Gruppe zurückgewiesen, bis das Sitzungslimit von Null erhöht wird oder der Tunnelgruppe eine weitere Dienstschnittstelle hinzugefügt wird.

Wenn eine Dienstschnittstelle in einem Dienstgerätepool den maximal konfigurierten Grenzwert erreicht hat oder der konfigurierte Grenzwert Null ist, ü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 bestanden und die Sitzung akzeptiert wird oder keine andere Schnittstelle mehr im auszuwählenden Pool verbleibt.

Session Load Balancing ü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 geringere Sitzungsanzahl als eine andere Schnittstelle im Pool aufweist und beide Schnittstellen unter ihrem maximalen Sitzungslimit liegen, werden nachfolgende Sitzungen auf die Schnittstelle mit weniger Sitzungen verteilt.

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

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

  1. Zweihundert Sitzungen verteilen sich gleichmäßig auf die beiden Serviceschnittstellen.

    • 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 es 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, die zuvor auf si-1/0/0 waren, erneut verbunden werden, werden sie gleichmäßig auf beide Dienstschnittstellen verteilt. Wenn alle 100 Sitzungen gesichert 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 auf 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 angehängten Sitzungen. Der Gerätepool verfügt wiederum über zwei Dienstschnittstellen mit jeweils einer konfigurierten Höchstgrenze von 200 Sitzungen:

  1. Zweihundert Sitzungen verteilen sich gleichmäßig auf die beiden Serviceschnittstellen.

    • 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 es 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 auf si-1/0/0 verteilt.

    1. Nach 1 neuer 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. Damit sind die Schnittstellen wieder gleich, so dass die nächste Sitzung (#103) zufällig verteilt wird. Dieses Muster wiederholt sich bis zum maximalen Limit von 200 Sitzungen für beide Schnittstellen.

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

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

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

Das Load Balancing-Verhalten ist für aggregierte Serviceschnittstellen identisch. Eine asi-Schnittstelle wird basierend auf der aktuellen Sitzungsanzahl für die asi-Schnittstelle aus einem Pool ausgewählt. Wenn dieser Zähler kleiner als der Maximalwert ist, prüft das LNS den aktuellen Sitzungszähler für die aktive si-Schnittstelle im asi-Bundle. Wenn dieser Zähler kleiner als der Maximalwert ist, kann die Sitzung auf der asi-Schnittstelle eingerichtet werden.

In einem Pool gemischter Geräte, der sowohl über Dienstschnittstellen als auch über aggregierte Dienstschnittstellen verfügt, werden Sitzungen an die Schnittstelle (asi oder si) mit der niedrigsten Sitzungsanzahl verteilt. Wenn die Sitzungsanzahl einer Schnittstelle eines der beiden Typen ihren Grenzwert erreicht, kann sie keine Sitzungen mehr akzeptieren, bis die Anzahl unter den Maximalwert fällt.

Sie können die Sitzungslimitkonfiguration verwenden, um ein Sitzungslimit für bestimmte Paketweiterleitungs-Engines zu erreichen. Angenommen, Sie möchten ein Limit von 100 Sitzungen für eine PFE0, die über zwei Dienstschnittstellen verfügt. Sie können den maximalen Grenzwert für jede Schnittstelle auf 50 oder eine beliebige andere Kombination festlegen, die zusammen 100 ergibt, um den PFE0-Grenzwert festzulegen.

Beispiel: Konfigurieren eines L2TP-LNS

Dieses Beispiel zeigt, wie Sie ein L2TP-LNS auf einem Router der MX-Serie konfigurieren können, um Tunnelendpunkte 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 die folgende Hardware und Software erforderlich:

  • Universelle 5G-Routing-Plattform der MX-Serie

  • Eine oder mehrere MPCs

  • Junos OS Version 11.4 oder höher

Über die Geräteinitialisierung hinaus ist keine spezielle Konfiguration erforderlich, bevor Sie diese Funktion konfigurieren können.

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

Tabelle 2: Namen, Reihenfolge und erforderliche Werte für VSA- und Standard-RADIUS-Attribute

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

Standard

Übersicht

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 im L2TP-Zugriffsprofil zugeordnet, das auf dem LNS konfiguriert ist. In diesem Beispiel gibt das Benutzergruppenprofil ce-l2tp-group-profile die folgenden PPP-Attribute an:

  • Ein Intervall von 30 Sekunden zwischen PPP-Keepalive-Nachrichten für L2TP-Tunnel von der Client-LAC, die auf dem LNS enden.

  • Ein 200-Sekunden-Intervall, das definiert, wie lange sich die PPP-Abonnentensitzung im Leerlauf befinden kann, bevor sie als Zeitüberschreitung betrachtet wird.

  • Sowohl PAP als auch CHAP als PPP-Authentifizierungsmethoden, die für getunnelte PPP-Abonnenten beim 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 auch zugeordnet. lac1 lac2 Beide Clients sind so konfiguriert, dass das LNS das Link Control Protocol (LCP) mit dem PPP-Client neu aushandelt, anstatt die vorab ausgehandelten LCP-Parameter zu akzeptieren, die die LACs an das 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 und lac1 für lac2. Für jede LAC wird ein anderes Kennwort konfiguriert.

Mit einem lokalen AAA-Zugriffsprofil können Sie das globale AAA-Zugriffsprofil aaa-profileaußer Kraft setzen, sodass Sie eine Authentifizierungsreihenfolge, 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 der MPC, die sich in Steckplatz 5 des Routers befindet, sind zwei Inline-Service-Schnittstellen aktiviert. Für jede Schnittstelle sind 10 Gbit/s Bandbreite für den Tunneldatenverkehr auf der der Schnittstelle zugeordneten PFE reserviert. Diese Ankerschnittstellen dienen als zugrunde liegende physische Schnittstelle. Um die Unterstützung von CoS-Warteschlangen auf den einzelnen logischen Inline-Serviceschnittstellen zu aktivieren, müssen Sie sowohl die Unterstützung für 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 die Datenverkehrslasten auf die beiden Ankerschnittstellen verteilen, wenn die Tunnelgruppe den Pool enthält.

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 Teilnehmer einen Tunnel zum LNS erhält. Für viele der Merkmale wird eine vordefinierte Variable festgelegt; Die Variablen werden dynamisch durch die entsprechenden Werte ersetzt, wenn ein Subscriber zum LNS getunnelt wird.

Die Schnittstelle, mit der der getunnelte PPP-Client eine Verbindung herstellt (), wird dynamisch in der Routinginstanz ($junos-interface-name$junos-routing-instance) erstellt, die dem Abonnenten zugewiesen ist. Zu den Routing-Optionen für Zugriffsrouten gehören die Adresse des nächsten Hops der Route (), die Metrik ($junos-framed-route-cost) und die Präferenz ().$junos-framed-route-nexthop$junos-framed-route-distance Für zugriffsinterne Routen wird eine dynamische IP-Adressvariable ($junos-subscriber-ip-address) gesetzt.

Die logischen Inline-Service-Interfaces werden durch den Namen einer konfigurierten Ankerschnittstelle () und eine logische Einheitennummer ($junos-interface-ifd-name$junos-interface-unit) definiert. Das Profil wird als Bezeichner für die logische Schnittstelle zugewiesen l2tp-encapuslation und gibt an, dass jede Schnittstelle jeweils nur für eine einzelne 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 und ein Ausgabe-Firewall-Filter $junos-input-filter $junos-output-filter an die Schnittstelle angeschlossen. Die Loopback-Variable () leitet eine IP-Adresse von einer in der Routing-Instanz konfigurierten Loopback-Schnittstelle ($junos-loopback-interfacelo) 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 das Router Advertisement Protocol ebenfalls konfiguriert ist. Diese Variable ermöglicht es AAA, die erste Adresse im Präfix zuzuweisen, die als lokale Adresse für die Schnittstelle reserviert werden soll. Die minimale Konfiguration für das Router Advertisement Protocol im dynamischen Profil gibt die Variablen and $junos-ipv6-ndra-prefix an, um dynamisch $junos-interface-name einen Präfixwert in IPv6-Neighbor Discovery-Routerankündigungen zuzuweisen.

Das dynamische Profil enthält auch die Class-of-Service-Konfiguration, die auf den Tunneldatenverkehr angewendet wird. Das Traffic-Control-Profil () enthält Variablen für die Scheduler-Map (), die Shaping-Rate (), die Gemeinkostenabrechnung (tc-profile$junos-cos-shaping-mode$junos-cos-scheduler-map$junos-cos-shaping-rate) und die Byteanpassung ).$junos-cos-byte-adjust Das dynamische Profil wendet die CoS-Konfiguration – einschließlich der Weiterleitungsklasse, des Ausgabedatenverkehrssteuerungsprofils und der Umschreibungsregeln – auf die dynamischen Serviceschnittstellen an.

Die tg-dynamic Tunnelgruppenkonfiguration gibt das Zugriffsprofilce-l2tp-profile, das lokale AAA-Profil und das dynamische Profil aaa-profiledyn-lns-profile2 an, 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 ausgleichen kann. Die lokale Gateway-Adresse entspricht der Remote-Gateway-Adresse203.0.113.2, die in der LAC konfiguriert ist. Der Name ce-lns des lokalen Gateways entspricht dem Namen des Remote-Gateways, der auf der LAC konfiguriert ist.

Hinweis:

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

Konfiguration

Verfahren

CLI-Schnellkonfiguration

Um schnell ein L2TP-LNS zu konfigurieren, kopieren Sie die folgenden Befehle, fügen Sie sie in eine Textdatei ein, entfernen Sie alle Zeilenumbrüche, und kopieren Sie dann die Befehle 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 hierzu 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 Tunnelabonnenten definiert.

    [edit access]
    user@host# edit group-profile ce-l2tp-group-profile
    [edit access group-profile ce-l2tp-group-profile]
    user@host# set ppp keepalive 30
    user@host# set ppp idle-timeout 200
    user@host# set ppp ppp-options chap
    user@host# set ppp ppp-options pap
    

  2. Konfigurieren Sie ein L2TP-Zugriffsprofil, das die L2TP-Parameter für jede Client-LAC definiert. Dazu gehören das Zuordnen eines Benutzergruppenprofils zum Client und das Angeben des Bezeichners für die logische Schnittstelle der Inline-Services, die eine L2TP-Sitzung auf dem LNS darstellt.

    Hinweis:

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

  3. Konfigurieren Sie ein AAA-Zugriffsprofil so, dass das globale Zugriffsprofil für die Reihenfolge der AAA-Authentifizierungsmethoden und Serverattribute überschrieben wird.

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

  5. Konfigurieren Sie die Peer-Schnittstelle so, dass der Tunnel und die serverseitige PPP-IPCP-Adresse (Loopback-Adresse) beendet werden.

  6. Aktivieren von Inline-Serviceschnittstellen auf einer MPC.

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

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

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

  10. Konfigurieren Sie Shapeping-, Planungs- und Umschreibungsregeln, und wenden Sie sie im dynamischen Profil auf Tunneldatenverkehr an.

  11. Konfigurieren Sie die L2TP-Tunnelgruppe so, dass dynamische LNS-Sitzungen mithilfe des Pools von Inline-Serviceschnittstellen aufgerufen werden, um den Lastenausgleich 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, indem Sie den show interfaces Befehl eingeben. Bestätigen Sie die Konfiguration des dynamischen Profils, indem Sie den show dynamic-profiles Befehl eingeben. Bestätigen Sie die Konfiguration der Tunnelgruppe, indem Sie den show services l2tp Befehl eingeben. Wenn die Ausgabe nicht die gewünschte Konfiguration anzeigt, wiederholen Sie die Konfigurationsanweisungen in diesem Beispiel, um sie zu korrigieren.

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

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

Die L2TP-Tunnelgruppe 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 an das LNS an der lokalen Gateway-Adresse verwendet wird, ein lokales Zugriffsprofil, das das globale Zugriffsprofil außer Kraft setzt, der Keepalive-Timer und ob der IP-ToS-Wert wiedergegeben wird.

Hinweis:

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

So konfigurieren Sie die LNS-Tunnelgruppe:

  1. Erstellen Sie die Tunnelgruppe.
    Hinweis:

    Sie können bis zu 256 Tunnelgruppen erstellen.

  2. Geben Sie die Serviceankerschnittstelle an, die für die L2TP-Verarbeitung auf dem LNS zuständig ist.

    Diese Dienstankerschnittstelle ist für statische LNS-Sitzungen und für dynamische LNS-Sitzungen erforderlich, bei denen der Datenverkehr nicht über einen Pool von Ankerschnittstellen verteilt wird. Die Konfiguration der Schnittstelle erfolgt auf Hierarchieebene [edit interfaces] .

  3. (Optional; nur für dynamische LNS-Sitzungen mit Lastenausgleich) Geben Sie einen Pool von Inline-Service-Ankerschnittstellen an, um den Lastenausgleich des L2TP-Datenverkehrs ü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-Service-Schnittstellen für L2TP-Tunnel definiert und instanziiert.

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

  5. Geben Sie das Zugriffsprofil an, das alle L2TP-Verbindungsanforderungen an die lokale Gatewayadresse 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 Namen des Remote-Gateways übereinstimmen, der in der LAC konfiguriert ist, andernfalls kann der Tunnel nicht erstellt werden.
  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 außer Kraft setzt, um die RADIUS-Servereinstellungen für die Tunnelgruppe 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 Dienstprofil an, das bei der Anmeldung auf die L2TP-Sitzung angewendet werden soll, zusammen mit allen Parametern, die an den Dienst übergeben werden sollen.

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

Services werden auf L2TP-Sitzungen zur Aktivierung angewendet oder später durch herstellerspezifische 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 dynamischer Serviceprofile 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 zum Anwenden von Services erforderlich sind. Durch die lokale Aktivierung dynamischer Serviceprofile können Sie dieses Problem vermeiden. Sie können auch die Aktivierung des lokalen Dienstprofils verwenden, um Standarddienste bereitzustellen, wenn RADIUS-Server ausgefallen sind.

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

Nachdem Sie ein oder mehrere dynamische Serviceprofile konfiguriert haben, die Services definieren, wenden Sie diese in der Tunnelgruppe oder in der Zugriffsprofilkonfiguration für einen LAC-Client an, indem Sie die Serviceprofilnamen 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 und die im Profil selbst konfigurierte Werte überschreiben können, z. B. eine nachgelagerte Shaping-Rate für einen CoS-Dienst.

Die lokal konfigurierte Liste der Dienste (über Dienstprofile) dient als lokale Autorisierung, die von authd während der Aktivierung der Clientsitzung angewendet wird. Diese Liste von Diensten unterliegt der gleichen Validierung und Verarbeitung wie Dienste, die von einer externen Autorität stammen, wie z. B. RADIUS. Diese Dienste werden während der Abonnentenanmeldung angezeigt.

Sie können weiterhin RADIUS-VSAs oder CoA-Anforderungen zusammen mit den Dienstprofilen verwenden. Wenn Services von einer externen Autorität als Autorisierung während der Authentifizierung oder während der Bereitstellung von Abonnentensitzungen (Aktivierung) bezogen werden, haben die Services der externen Autorität strikte Priorität vor denen in der lokalen Konfiguration. Wenn ein mit RADIUS angewendeter Dienst mit einem Dienst identisch ist wie ein Dienst, der mit einem Dienstprofil in der CLI angewendet wird, jedoch mit anderen Parametern, wird der RADIUS-Dienst mit einer neuen Sitzungs-ID angewendet und hat Vorrang vor dem früheren Dienstprofil.

Sie können Befehle zum Deaktivieren oder Reaktivieren von Diensten ausführen, die Sie zuvor für eine Tunnelgruppe oder LAC aktiviert haben.

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

So wenden Sie Dienstprofile auf alle Abonnenten in einer Tunnelgruppe an:

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

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

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

    Hinweis:

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

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

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

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

Um zu verstehen, wie lokale Dienstanwendungen funktionieren, veranschaulichen die folgenden Beispiele die verschiedenen Konfigurationsmöglichkeiten. Betrachten Sie zunächst die folgenden dynamischen Dienstprofilkonfigurationen, cos2 und fw1:

Die folgende Anweisung gilt für beide Dienste für alle Abonnenten in der Tunnelgruppe tg1. Ein Parameterwert von 31 Mbit/s wird an den CoS2-Dienst übergeben:

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

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

Jetzt ist der cos2-Dienst über die CLI für die Abonnentensitzung 27 deaktiviert.

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

Mit dem folgenden Befehl wird cos2 für die Abonnentensitzung 27 reaktiviert.

Der reaktivierte cos2-Dienst hat die neue Dienstsitzungs-ID 36.

Der reaktivierte cos2-Dienst verwendet die standardmäßige Shaping-Rate von 10 Mbit/s aus dem Dienstprofil.

Als nächstes wird eine RADIUS-CoA-Anforderung empfangen, die den 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-Dienstsitzung 36 erscheint weiterhin in der Ausgabe, wird jedoch durch die neue Dienstsitzung ersetzt, die vom CoA, 49, initiiert wurde.

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

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

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

Konfigurieren eines Pools von Inline-Service-Schnittstellen für dynamische LNS-Sitzungen

Sie können einen Pool von Inline-Dienstschnittstellen erstellen, der auch als Dienstgerätepool bezeichnet wird, um einen Lastenausgleich des L2TP-Datenverkehrs ü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-Tunnelgruppe zugewiesen. L2TP behält den Status jeder Inlinedienstschnittstelle bei und verwendet eine Round-Robin-Methode, um die Last gleichmäßig auf verfügbare Schnittstellen zu verteilen, wenn neue Sitzungsanforderungen akzeptiert werden.

Hinweis:

Load Balancing ist nur für dynamisch erstellte Abonnentenschnittstellen verfügbar.

LNS-Sitzungen, die auf einer MPC verankert sind, sind von einem MIC-Ausfall nicht betroffen, solange ein anderer Pfad zu den Peer-LACs vorhanden ist. Wenn die MPC, die die Peerschnittstelle hostet, ausfällt und es keinen Pfad zu Peer-LACs gibt, initiiert der Fehler die Beendigung und Bereinigung aller Sitzungen auf der MPC.

Wenn die MPC, die die LNS-Sitzungen selbst verankert, fehlschlägt, verschiebt 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 Wiederholungsversuch 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-Service-Schnittstellen für L2TP-Tunnel dynamisch zugewiesen werden. Sie müssen ein oder mehrere dynamische Profile definieren und jeder Tunnelgruppe ein Profil zuweisen. Das LNS unterstützt reine IPv4-, reine 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 so, dass sie dynamisch der Routinginstanz 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-Service-Schnittstellen ersetzt.
  6. Konfigurieren Sie die logischen Schnittstellen der Inlinedienste so, dass sie dynamisch instanziiert werden.
  7. Geben Sie einen Bezeichner für die logischen Schnittstellen an.
  8. Konfigurieren Sie jede logische Schnittstelle so, dass sie jeweils nur für eine Sitzung verwendet wird.
  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 wird.
    Hinweis:

    Bei dynamischen LNS-Programmen müssen Sie die Anweisung in das dynamische Profil aufnehmen, das wiederum erfordert, dass Sie die dial-options family inet Anweisung einschließen. Dies hat folgende Konsequenzen:

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

    • Wenn Sie Nur-IPv4-Schnittstellen konfigurieren, konfigurieren Sie nur family inet die Schnittstellenadresse unter family inet.

    • Wenn Sie reine IPv6-Schnittstellen konfigurieren, müssen Sie auch die Schnittstellenadresse unter family inet6konfigurierenfamily inet6. 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:

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

Tabelle der Versionshistorie
Release
Beschreibung
18.1R1
Ab Junos OS Version 18.1R1 können Sie Services auf L2TP-Sitzungen mithilfe dynamischer Serviceprofile anwenden, ohne RADIUS einzubeziehen.
16.2R1
Ab Junos OS Version 16.2 ist es nicht mehr erforderlich, explizit eine Bandbreite für L2TP-LNS-Tunneldatenverkehr mithilfe von Inline-Services anzugeben.