Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

PPP-Abonnentenzugangsnetzwerke – Übersicht

Übersicht über dynamische Profile für PPP-Teilnehmerschnittstellen

Abonnentenverwaltung Die PPP-Unterstützung ermöglicht das Erstellen und Anhängen dynamischer Profile für PPP-Abonnentenschnittstellen. Wenn sich der PPP-Teilnehmer anmeldet, instanziiert der Router das angegebene dynamische Profil und wendet dann die im Profil definierten Attribute auf die Schnittstelle an.

Dynamische Profile werden sowohl für statische als auch für dynamische PPP-Schnittstellen verwendet. Bei statischen PPP-Schnittstellen verwenden Sie die CLI, um dynamische Profile anzuhängen, die PPP-Optionen angeben. Bei dynamischen PPP-Schnittstellen erstellt das dynamische Profil die Schnittstelle, einschließlich der PPP-Optionen.

Hinweis:

Dynamisch erstellte Schnittstellen werden nur auf PPPoE-Schnittstellen unterstützt.

Im Gegensatz zur herkömmlichen PPP-Unterstützung lässt die Teilnehmerverwaltung keine bidirektionale PPP-Authentifizierung zu – die Authentifizierung erfolgt nur durch den Router, niemals durch den Remote-Peer. Der AAA-Prozess des Routers verwaltet die Authentifizierung und Adresszuweisung für die Teilnehmerverwaltung. Wenn Sie PPP-Optionen für ein dynamisches Profil konfigurieren, können Sie entweder die CHAP- (Challenge Handshake Authentication Protocol) oder die PAP-Authentifizierung (Password Authentication Protocol) konfigurieren und die Reihenfolge steuern, in der der Router die CHAP- und PAP-Protokolle aushandelt. Darüber hinaus können Sie für die CHAP-Authentifizierung die Standardlänge der CHAP-Abfragenachricht ändern. Andere PPP-Optionen, die entweder häufig verwendet werden oder für eine herkömmliche PPP-Schnittstellenkonfiguration obligatorisch sind, werden in dynamischen Profilen für die Abonnentenverwaltung nicht unterstützt.

Verstehen, wie der Router vom Abonnenten initiierte PPP Fast Keepalive-Anforderungen verarbeitet

Bei Routern der MX-Serie mit modularen Portkonzentratoren/modularen Schnittstellenkarten (MPCs/MICs) verarbeitet und antwortet die Packet Forwarding Engine auf einem MPC/MIC LCP-Echo-Request-Pakete (Link Control Protocol), die der PPP-Teilnehmer (Client) initiiert und an den Router sendet. LCP-Echo-Request-Pakete und LCP-Echo-Reply-Pakete sind Teil des PPP-Keepalive-Mechanismus, mit dessen Hilfe festgestellt werden kann, ob eine Verbindung ordnungsgemäß funktioniert.

Bisher wurden LCP-Echo-Request-Pakete und LCP-Echo-Reply-Pakete auf einem Router der MX-Serie von der Routing-Engine verarbeitet. Der Mechanismus, mit dem LCP-Echo-Request-Pakete von der Packet Forwarding Engine statt von der Routing-Engine verarbeitet werden, wird als PPP Fast Keepalives bezeichnet.

Vorteile von PPP Fast Keepalives

  • PPP-Fast-Keepalives verkürzen die für den Keepalive-Austausch erforderliche Zeit, indem sie es der Packet Forwarding Engine ermöglichen, LCP-Echo-Request-Pakete vom PPP-Abonnenten zu empfangen und mit LCP-Echo-Reply-Paketen zu antworten, ohne die LCP-Pakete zur Verarbeitung an die Routing-Engine senden zu müssen.

  • PPP-Fast-Keepalives bieten eine erhöhte Bandbreite auf dem Router, um eine größere Anzahl von Teilnehmern mit verbesserter Leistung zu unterstützen, indem sie die Routing-Engine von der Verarbeitung der LCP-Echo-Request- und Echo-Reply-Pakete entlasten.

  • PPP-Fast-Keepalives verwenden ausgehandelte magische Zahlen, um potenzielle Datenverkehr-Loopbacks zum Router oder Netzwerkprobleme zu identifizieren. Sie können die Validierung bei Bedarf auch deaktivieren, um eine unerwünschte Beendigung der PPP-Sitzung zu verhindern, z. B. wenn die PPP-Remote-Peers beliebige Nummern anstelle der ausgehandelten Nummer verwenden.

So funktioniert die schnelle PPP-Keepalive-Verarbeitung

Auf einem Router der MX-Serie mit MPCs/MICs benötigen Sie keine spezielle Konfiguration, um die Verarbeitung von PPP-Fast-Keepalive-Anforderungen auf der Packet Forwarding Engine zu ermöglichen. Die Funktion ist standardmäßig aktiviert und kann nicht deaktiviert werden.

Die folgende Sequenz beschreibt, wie ein Router der MX-Serie LCP-Echo-Request-Pakete und LCP-Echo-Reply-Pakete in der Packet Forwarding Engine auf dem MPC/MIC verarbeitet:

  1. Die Routing-Engine benachrichtigt die Paketweiterleitungs-Engine, wenn die Übertragung von Keepalive-Anforderungen auf einer logischen PPP-Schnittstelle aktiviert ist. Die Benachrichtigung enthält die magischen Zahlen sowohl des Servers als auch des Remote-Clients.

  2. Die Packet Forwarding Engine empfängt das LCP Echo-Request-Paket, das vom PPP-Abonnenten (Client) initiiert wurde.

  3. Die Packet Forwarding Engine validiert die magische Peer-Zahl im LCP-Echo-Request-Paket und überträgt das entsprechende LCP-Echo-Reply-Paket, das die vom Router ausgehandelte magische Zahl enthält.

  4. Wenn die Packet Forwarding Engine eine Schleifenbedingung in der Verbindung erkennt, sendet sie das LCP-Echo-Request-Paket zur weiteren Verarbeitung an die Routing-Engine.

    Die Routing-Engine setzt die Verarbeitung von LCP-Echo-Request-Paketen fort, bis die Schleifenbedingung gelöscht wird.

Die Übertragung von Keepalive-Anforderungen von der Packet Forwarding Engine auf dem Router ist derzeit nicht aktiviert.

Statistikanzeige für PPP Fast Keepalive

Wenn ein Router der MX-Serie mit MPCs/MICs PPP Fast Keepalive für eine PPP-Verbindung verwendet, enthält das Keepalive statistics Feld in der Ausgabe des show interfaces pp0.logical statistics Betriebsbefehls keine Statistiken für die Anzahl der empfangenen oder gesendeten Keepalive-Pakete oder die Zeitspanne, die seit dem Empfang oder Senden des letzten Keepalive-Pakets durch den Router vergangen ist.

Auswirkung der Änderung der Weiterleitungsklassenkonfiguration

Um die standardmäßige Warteschlangenzuweisung (Weiterleitungsklasse) für ausgehenden Datenverkehr zu ändern, der von der Routing-Engine generiert wird, können Sie die forwarding-class class-name Anweisung auf Hierarchieebene [edit class-of-service host-outbound-traffic] einfügen.

Bei PPP-Fast-Keepalive-LCP-Echo-Request- und LCP-Echo-Reply-Paketen, die zwischen einem Router der MX-Serie mit MPCs/MICs und einem PPP-Client übertragen werden, wird die Änderung der Weiterleitungsklassenkonfiguration sofort sowohl für neue PPP-over-Ethernet (PPPoE)-, PPP-over-ATM (PPPoA)- und L2TP-Netzwerkserver (LNS)-Abonnentensitzungen, die nach der Konfigurationsänderung erstellt wurden, als auch für bestehende PPPoE, PPPoA und LNS-Abonnentensitzungen, die vor der Konfigurationsänderung eingerichtet wurden.

Ignorieren einer Magical-Zahlen-Diskrepanz

Wenn die Packet Forwarding Engine die magische Peer-Zahl im empfangenen LCP-Echo-Request-Paket überprüft, prüft sie, ob die magische Zahl unerwartet ist. Die empfangene Nummer sollte mit der Nummer für den Remote-Peer übereinstimmen, die während der LCP-Aushandlung vereinbart wurde. Die Remote-Peer-Nummer muss sich von der lokalen Peer-Nummer unterscheiden. Wenn sie identisch sind, wird erwartet, dass eine Loopback-Bedingung (Datenverkehr wird zum lokalen Peer zurückgeleitet) oder ein anderes Netzwerkproblem vorliegt.

Wenn bei der Validierungsprüfung festgestellt wird, dass eine Diskrepanz vorliegt, d. h., dass die empfangene Remote-Peer-Nummer von der ausgehandelten Nummer abweicht, sendet die Paketweiterleitungs-Engine die fehlgeschlagenen Echo-Reply-Pakete an die Routing-Engine. Wenn eine Echo-Antwort mit einer gültigen magischen Zahl nicht innerhalb eines bestimmten Intervalls eingeht, wertet PPP dies als Keepalive-Fehler und bricht die PPP-Sitzung ab.

Einige Kundengeräte handeln möglicherweise nicht ihre lokale magische Zahl aus und fügen stattdessen einen beliebigen Wert als magische Zahl ein, die sie an den Router in den Keepalive-Paketen senden. Diese Zahl wird als nicht übereinstimmend identifiziert und die Sitzung wird schließlich abgebrochen. Ab Junos OS Version 18.1R1 kann dieses Ergebnis vermieden werden, indem der Router so konfiguriert wird, dass keine Magic-Zahlen-Validierungsprüfung durchgeführt wird. Da die Diskrepanz nie erkannt wird, tauscht der Router weiterhin PPP-Keepalive-Pakete mit dem Remote-Peer aus. Um dieses Verhalten zu konfigurieren, fügen Sie die ignore-magic-number-mismatch Anweisung in ein L2TP-Gruppenprofil, in das dynamische Profil für dynamische PPP-Teilnehmerverbindungen, die am Router beendet sind, oder in das dynamische Profil für dynamisch getunnelte PPP-Abonnenten am LNS ein.

Siehe auch

RADIUS-bezogene Verbindungsstatusaktualisierungen für CPE-Geräte

Ab Junos OS Version 20.2R1 können Sie Nachrichten mit RADIUS-Quelle verwenden, um Informationen zu übermitteln, die das BNG transparent an ein CPE-Gerät, z. B. ein Home-Gateway, weiterleitet. Bei diesen Informationen kann es sich z. B. um die Upstream-Bandbreite oder einen anderen Parameter für die Verbindungsrate handeln, den das CPE-Gerät benötigt. Diese Funktion ist nützlich, wenn Sie die Datenverkehrsverwaltung so nah wie möglich an den Abonnenten dynamisch durchsetzen möchten.

Normalerweise können Sie das RADIUS-Standardattribut Reply-Message (18) verwenden, um diese Informationen während der PPP-Authentifizierung an das CPE-Gerät zu übermitteln. Wenn Sie dieses Attribut jedoch bereits für etwas anderes verwenden, können Sie auch die Juniper Networks Connection-Status-Message VSA (26-4874–218) verwenden. Diese VSA ist eine logische Erweiterung des Reply-Message-Attributs (18) und hat das gleiche Format und die gleiche Semantik.

PPP verwendet eine herstellerspezifische Erweiterung von LCP von Juniper Networks, um den Inhalt der Connection-Status-Message-VSA an das Peer-Home-Gateway zu senden. PPP schließt diese Informationen in die Option "Connection-Status-Message" einer LCP-Connection-Update-Request-Nachricht ein.

RADIUS kann die Connection-Status-Message VSA auf folgende Weise an authd senden:

  • In der RADIUS-Access-Accept-Meldung während der Aushandlung und Autorisierung einer PPP-Sitzung

  • In einer RADIUS-CoA-Anfrage zu einem beliebigen Zeitpunkt für eine aktive PPP-Sitzung

Sie können beide Methoden für eine bestimmte Sitzung für Geschäfts- oder Privatkunden verwenden. Die Access-Accept-Meldung enthält die anfänglichen Verbindungsparameter. Die CoA-Funktion ermöglicht es Ihnen, die Parameter für die Verbindungsrate während der gesamten Lebensdauer einer Sitzung nach Bedarf zu aktualisieren. Bei den Informationen, die in der VSA "Connection-Status-Message" enthalten sind, handelt es sich in der Regel um Datenverkehrsraten, die von der lokalen Konfiguration angewendet werden, z. B. einem dynamischen Dienstprofil oder der entsprechenden ANCP-Port-Up-Nachricht.

Hinweis:

Wenn Sie die PPP-Option nicht in das dynamische Client-Profil aufnehmen, verarbeitet PPP die lcp-connection-update Benachrichtigung von authd, führt jedoch keine Aktion aus. Wenn sich LCP auf dem Router nicht im Status "Geöffnet" befindet, führt PPP keine Aktion für den VSA aus.

In den folgenden Schritten wird beschrieben, was passiert, wenn RADIUS die VSA in einer Access-Accept-Nachricht sendet:

  1. Der authd-Prozess empfängt die Connection-Status-Message-VSA in einer Access-Accept-Nachricht vom RADIUS-Server.

  2. Der authd-Prozess sendet die Connection-Status-Message VSA an PPP (jpppd).

  3. Die PPP-NCP-Aushandlung findet zwischen dem PPP-Client des Remote-Gateways und PPP auf dem Router statt.

  4. Eine erfolgreiche Verhandlung führt zu einer Familienaktivierungsanforderung. Die PPP-Sitzung wechselt in den Status "Sitzung aktiv", wenn die Familie aktiviert wird.

  5. Wenn das dynamische Clientprofil die lcp-connection-update Option PPP enthält und LCP auf dem Router den Status "Geöffnet" aufweist, sendet PPP eine LCP Connection-Update-Request-Nachricht an das Gateway. Diese Meldung enthält die VSA-Informationen in der Option Connection-Status-Message.

    • Wenn das Gateway die LCP Connection-Update-Request unterstützt, gibt es eine LCP Connection-Update-Ack-Nachricht an den Router zurück. Das Home-Gateway-LCP muss sich beim Empfang der Anforderung im Status "Geöffnet" befinden, andernfalls wird die Anforderung verworfen.

    • Wenn das Gateway die LCP Connection-Update-Request nicht unterstützt, gibt es eine LCP Code-Reject-Nachricht an den Router zurück.

    Hinweis:

    Wenn das Gateway nicht reagiert, wiederholt der Router die Aktualisierungsanforderung. Es verwendet die PPP-Standardwerte von bis zu maximal 10 Wiederholungsversuchen mit einem Intervall von 3 Sekunden zwischen den Versuchen.
    Hinweis:

    Wenn Sie die PPP-Option nicht in das dynamische Client-Profil aufnehmen, verarbeitet PPP die lcp-connection-update Benachrichtigung von authd, führt jedoch keine Aktion aus. Wenn die Option vorhanden ist, sich LCP auf dem Router jedoch nicht im Status "Geöffnet" befindet, ergreift PPP keine Maßnahmen in Bezug auf die VSA.

In den folgenden Schritten wird beschrieben, was passiert, wenn RADIUS die VSA in einer CoA-Anforderung sendet. Dies setzt voraus, dass die NCP-Aushandlung bereits erfolgreich war und die Sitzung aktiv ist.

  1. Der authd-Prozess empfängt die Connection-Status-Message VSA in einer CoA-Anfrage vom RADIUS-Server.

  2. Der authd-Prozess sendet die Connection-Status-Message VSA an PPP (jpppd).

  3. Wenn das dynamische Clientprofil die lcp-connection-update Option PPP enthält und LCP auf dem Router den Status "Geöffnet" aufweist, sendet PPP eine LCP Connection-Update-Request-Nachricht an das Gateway. Diese Meldung enthält die VSA-Informationen in der Option Connection-Status-Message.

    • Wenn das Gateway die LCP Connection-Update-Request unterstützt, gibt es eine LCP Connection-Update-Ack-Nachricht an den Router zurück. Das Home-Gateway-LCP muss sich beim Empfang der Anforderung im Status "Geöffnet" befinden, andernfalls wird die Anforderung verworfen.

    • Wenn das Gateway die LCP Connection-Update-Request nicht unterstützt, gibt es eine LCP Code-Reject-Nachricht an den Router zurück.

    Hinweis:

    Wenn das Gateway nicht reagiert, wiederholt der Router die Aktualisierungsanforderung. Es verwendet die PPP-Standardwerte von bis zu maximal 10 Wiederholungsversuchen mit einem Intervall von 3 Sekunden zwischen den Versuchen.

Wenn das Home-Gateway keine Connection-Update-Request-Nachricht empfängt, versucht der Router, die Nachricht zu senden. Der Router wiederholt die Anforderung auch, wenn er weder eine Verbindungsaktualisierungsbestätigung noch eine LCP-Code-Ablehnung vom Gateway erhält oder wenn etwas mit der Ack-Nachricht nicht stimmt. Das standardmäßige Wiederholungsintervall beträgt 3 Sekunden. Der Router wiederholt die Nachricht bis zum Standardwert 10 Mal, bevor er beendet wird. Wenn der Router alle Wiederholungsversuche ausschöpft, ohne eine entsprechende Connection-Update-Ack-Meldung zu erhalten, protokolliert er die Meldung so, als hätte er eine PPP-Code-Reject-Meldung erhalten.

Hinweis:

RADIUS kann mehrere Instanzen des VSA "Connection-Status-Message" entweder in der Access-Accept-Nachricht oder in einer CoA-Anforderung enthalten. In diesem Fall verwendet authd nur die erste Instanz und ignoriert alle anderen.

Die Access-Accept- oder CoA-Anforderungen können neben dem Connection-Status-Message-VSA noch andere Attribute enthalten, es besteht jedoch keine gegenseitige Abhängigkeit zwischen dem VSA und anderen Attributen. Dies gilt auch dann, wenn die Nachricht die VSAs "Activate-Service" (26–65) oder "Deactivate-Service" (26–66) enthält. Das Fehlen einer Abhängigkeit bedeutet, dass selbst wenn authd die anderen Attribute nicht erfolgreich anwendet, die Verbindungsinformationen an PPP sendet, das wiederum den VSA-Inhalt an das Home-Gateway sendet.

In ähnlicher Weise wendet authd alle anderen Attribute an und gibt eine CoA-Antwort zurück, unabhängig davon, ob PPP den Inhalt der Connection-Status-Message-VSA erfolgreich an das entfernte Gateway übermittelt. Dies gilt auch dann, wenn das CoA nur die Connection-Status-Message VSA enthält. Diese Funktion ist notwendig, da nicht alle Gateways die in dieser Funktion verwendete LCP-Erweiterung akzeptieren.

Nachrichten- und Optionsformate

Abbildung 1 zeigt das Format für Connection-Update-Request- und Connection-Update-Ack-Meldungen. Die Formate sind identisch, aber Tabelle 1zeigt, dass einige Feldwerte für die beiden Nachrichten unterschiedlich sind.

Abbildung 1: Nachrichtenformat Connection-Update-Request and Connection-Update-Ack Message Format "Connection-Update-Request" und "Connection-Update-Ack"
Tabelle 1: Feldwerte für Connection-Update-Request- und Connection-Update-Ack-Nachrichten

Feld

Verbindungs-Update-Anfrage

Verbindungs-Update-Bestätigung

Code

0 für herstellerspezifisch

0 für herstellerspezifisch

Bezeichner

Kennung für herstellerspezifisches Paket

Derselbe Bezeichner wie in der Connection-Update-Request-Nachricht. Wenn dieser Wert nicht übereinstimmt, protokolliert der Router den Fehler und verwirft das Paket. Auf diese Weise kann die Anforderungsnachricht wiederholt werden, als ob das Gateway sie nicht empfangen hätte.

Länge

Anzahl der Bytes im Paket: 12 plus die Länge der Option Connection-Status-Message

Anzahl der Bytes im Connection-Update-Ack-Paket: 12

Magische Zahl

Ausgehandelter Wert für die lokale KKP-magische Zahl

Ausgehandelter Wert für die lokale KKP-magische Zahl

Organizationally Unique Identifier (OUI)

21.00.59 für Juniper Networks

21.00.59 für Juniper Networks

Art

1 für Session-Update

2 für Session-Ack. Bei jedem anderen Wert protokolliert der Router den Fehler und verwirft das Paket. Auf diese Weise kann die Anforderungsnachricht wiederholt werden, als ob das Gateway sie nicht empfangen hätte.

Werte

Verbindungsstatus-Meldungsoption im TLV-Format

Es werden keine Werte unterstützt

Sie können konfigurieren, wie die magischen PPP-Zahlen verwendet werden.

  • Wenn Sie die PPP-Option konfigurieren ignore-magic-number-mismatch , verhindern Sie, dass die magischen Zahlen validiert werden. PPP ignoriert eine Diskrepanz zwischen den magischen Zahlen in der Anforderungs- und der Ack-Nachricht. Wenn keine anderen Validierungsfehler auftreten, akzeptiert PPP die Connection-Update-Ack-Nachricht.

  • Wenn Sie die PPP-Option nicht konfigurieren ignore-magic-number-mismatch , werden die magischen Zahlen validiert. Wenn die magische Zahl in der Ack-Nachricht nicht mit der magischen Zahl des Gateways übereinstimmt, die während der LCP-Aushandlung festgelegt wurde, protokolliert der Router den Fehler und verwirft die Connection-Update-Ack-Nachricht als ungültige Antwort. Auf diese Weise kann die Anforderungsnachricht wiederholt werden, als ob das Gateway sie nicht empfangen hätte.

Weitere Informationen zu magischen Zahlen finden Sie unter Verhindern der Validierung von magischen PPP-Zahlen während des PPP-Keepalive-Austauschs .

Abbildung 2 zeigt das Format für die Optionen "Connection-Status-Message". In Tabelle 2 sind die Feldwerte aufgeführt.

Abbildung 2: Optionsformat Connection-Status-Message Option Format für Verbindungsstatus-Meldung
Tabelle 2: Feldwerte für die Option "connection-status-message"

Feld

Wert

Typ

1

Länge

Anzahl der Bytes in der Option; 2 plus die Länge der Nachricht. Die Nachrichtenlänge kann zwischen 1 und 247 Byte liegen.

Statusmeldung

Inhalt der Verbindungsstatus-Meldung VSA

Konfigurieren dynamischer Profile für PPP

Ein dynamisches Profil fungiert als Vorlage, mit der Sie eine Konfiguration erstellen, aktualisieren oder entfernen können, die Attribute für den Clientzugriff (z. B. Schnittstelle oder Protokoll) oder Service (z. B. IGMP) enthält. Mithilfe dynamischer Profile können Sie alle gemeinsamen Attribute eines Mandanten (und schließlich einer Gruppe von Kunden) konsolidieren und die Attribute gleichzeitig anwenden.

Nachdem dynamische Profile erstellt wurden, befinden sich die Profile in einer Profilbibliothek auf dem Router. Anschließend können Sie die dynamic-profile Anweisung verwenden, um Profile an Schnittstellen anzuhängen. Um einer PPP-Schnittstelle ein dynamisches Profil zuzuordnen, können Sie die dynamic-profile Anweisung auf Hierarchieebene [edit interfaces interface-name unit logical-unit-number ppp-options] einfügen:

Um die Konfiguration zu überwachen, geben Sie den show interfaces interface-name Befehl ein.

Weitere Informationen zu dynamischen Profilen finden Sie unter Übersicht über dynamische Profile im Konfigurationshandbuch für den Junos-Abonnentenzugriff.

Weitere Informationen zum Erstellen dynamischer Profile finden Sie unter Konfigurieren eines grundlegenden dynamischen Profils im Konfigurationshandbuch für den Junos-Abonnentenzugriff.

Informationen zum Zuweisen eines dynamischen Profils zu einer PPP-Schnittstelle finden Sie unter Anhängen dynamischer Profile an statische PPP-Abonnentenschnittstellen im Konfigurationshandbuch für den Abonnentenzugriff von Junos.

Weitere Informationen zur Verwendung dynamischer Profile zur Authentifizierung von PPP-Abonnenten finden Sie unter Konfigurieren der dynamischen Authentifizierung für PPP-Abonnenten.

Hinweis:

Dynamische Profile für PPP-Abonnenten werden in dieser Version nur auf PPPoE-Schnittstellen unterstützt.

Verhindern der Validierung von PPP-Magic-Nummern während PPP-Keepalive-Austauschs

Magische PPP-Nummern werden während der LCP-Aushandlung zwischen Peers ausgehandelt. Die Peers müssen unterschiedliche magische Zahlen haben. Wenn die Zahlen identisch sind, weist dies darauf hin, dass es möglicherweise ein Loopback im Datenverkehr gibt, der vom lokalen Peer gesendet wird. In diesem Fall sendet der lokale Peer eine neue Nummer an den Remotepeer. Wenn die vom Remote-Peer zurückgegebene magische Zahl von der letzten vom lokalen Peer gesendeten Nummer abweicht, gelten die Nummern als vereinbart. Andernfalls wird der Austausch von magischen Zahlen fortgesetzt, bis eine gültige (andere) Nummer empfangen wird oder der Prozess abläuft, in diesem Fall wird die Sitzung abgebrochen.

Nachdem die Nummern vereinbart wurden, fügen die Peers ihre jeweiligen magischen Zahlen hinzu, wenn sie PPP-Keepalive-Pakete (Echo-Request/Echo-Reply) austauschen. Die Packet Forwarding Engine validiert die empfangene magische Zahl für jeden Austausch. Eine Nichtübereinstimmung tritt auf, wenn die vom Remote-Peer empfangene magische PPP-Zahl nicht mit dem Wert übereinstimmt, der während der LCP-Aushandlung vereinbart wurde. Wenn bei der Validierungsprüfung festgestellt wird, dass eine Diskrepanz vorliegt, sendet die Paketweiterleitungs-Engine das fehlgeschlagene Echo-Request-Paket an die Routing-Engine. Wenn eine Echo-Antwort mit einer gültigen magischen Zahl nicht innerhalb eines bestimmten Intervalls eingeht, wertet PPP dies als Keepalive-Fehler und bricht die PPP-Sitzung ab.

Unter bestimmten Umständen ist dieses Verhalten nicht erwünscht. Einige Kundengeräte handeln ihre lokale magische Zahl nicht aus. Stattdessen fügt es einen beliebigen Wert als magische Zahl ein, die es an den Router in den Keepalive-Paketen sendet. Standardmäßig wird diese Zahl als Nichtübereinstimmung identifiziert und die Sitzung wird schließlich abgebrochen. Dieses Ergebnis kann vermieden werden, indem verhindert wird, dass die Packet Forwarding Engine die Magic-Number-Validierungsprüfung durchführt. Da die Diskrepanz nie erkannt wird, tauscht der Router weiterhin PPP-Keepalive-Pakete mit dem Remote-Peer aus.

Deaktivieren Sie die Validierungsprüfung für magische Zahlen, indem Sie die Anweisung als eine der PPP-Optionen einschließen, die ignore-magic-number-mismatch in einem dynamischen PPP-Profil, einem dynamischen L2TP-LNS-Profil oder einem L2TP-Gruppenprofil angewendet werden. 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.

Hinweis:

Da keine Überprüfung der magischen Zahlen durchgeführt wird, erkennt die Paketweiterleitungs-Engine nicht, ob der Remote-Peer die magische Zahl des lokalen Peers sendet, was auf ein Loopback oder ein anderes Netzwerkproblem hinweisen würde. Dies wird als unwahrscheinliche Situation angesehen, da die LCP-Aushandlung erfolgreich abgeschlossen wurde, was bedeutet, dass zu diesem Zeitpunkt kein Loopback vorhanden war.

So konfigurieren Sie dynamische Profile, um zu verhindern, dass die Paketweiterleitungs-Engine Diskrepanzen in magischen Zahlen erkennt:

Konfigurieren Sie die PPP-Option.

  • Für dynamische PPP-Teilnehmerverbindungen, die am Router beendet sind:

  • Für dynamisch getunnelte PPP-Abonnenten auf LNS-Inline-Service-Schnittstellen:

Mit dem show ppp interface interface-name extensive Befehl können Sie anzeigen, ob die magischen Zahlen ignoriert werden.

So konfigurieren Sie RADIUS-basierte Verbindungsstatusaktualisierungen für CPE-Geräte

Sie können RADIUS-bezogene Nachrichten verwenden, um Informationen zu übermitteln, die das BNG transparent an ein CPE-Gerät, z. B. ein Home-Gateway, weiterleitet. Bei diesen Informationen kann es sich z. B. um die Upstream-Bandbreite oder einen anderen Parameter für die Verbindungsrate handeln, den das CPE-Gerät benötigt.

Wenn Sie diese Funktion aktivieren, kann PPP auf eine Verbindungsstatusnachricht VSA (26–218) reagieren, die von authd entweder in einer RADIUS-Access-Accept-Nachricht oder einer CoA-Nachricht empfangen wird. PPP übermittelt dann den Inhalt des VSA in einer LCP Connection-Update-Request-Nachricht an den Remote-Peer. Für diese Aktion ist Folgendes erforderlich:

  • Mindestens die erste Adressfamilie wurde erfolgreich ausgehandelt und die Sitzung ist aktiv.

  • Das LCP des Routers befindet sich im Status "Geöffnet".

Andernfalls ergreift PPP keine Maßnahmen für die VSA. Wenn Sie die Option nicht aktivieren, verarbeitet PPP die lcp-connection-update Benachrichtigung von authd, führt jedoch keine Aktion aus.

Sie konfigurieren diese Funktion im dynamischen Clientprofil, das den Abonnenten zugeordnet ist, die das CPE-Gerät verwenden. In der Praxis fügen Sie dies zu zahlreichen anderen Funktionen im Kundenprofil hinzu. In diesem Beispiel wird nur die spezifische Konfiguration für dieses Feature gezeigt. Für diese Funktion müssen Sie außerdem VSA 26-218 auf Ihrem RADIUS-Server konfigurieren. Dies würde den Rahmen dieser Dokumentation sprengen.

So konfigurieren Sie die Verbindungsstatusaktualisierungen in einem dynamischen Profil für PPP-Teilnehmerschnittstellen:

  1. Bearbeiten Sie die PPP-Optionen im Kundenprofil.
  2. Aktivieren Sie die Aktualisierungen des Verbindungsstatus.

Sie können den show ppp interface extensive Befehl für die logische PPP-Schnittstelle verwenden, um zu bestimmen, ob LCP-Verbindungsaktualisierungen erfolgreich sind. Mit dem show system subscriber-management statistics ppp Befehl können Sie die relevanten Statistiken überwachen.

Anhängen dynamischer Profile an statische PPP-Teilnehmerschnittstellen

Sie können ein dynamisches Profil an eine statische PPP-Abonnentenschnittstelle anfügen. Wenn sich ein PPP-Abonnent anmeldet, wird das angegebene dynamische Profil instanziiert, und die im Profil definierten Dienste werden auf die Schnittstelle angewendet.

So fügen Sie ein dynamisches Profil an eine statische PPP-Abonnentenschnittstelle an:

  1. Geben Sie an, dass Sie PPP-Optionen konfigurieren möchten.
  2. Geben Sie das dynamische Profil an, das Sie der Schnittstelle zuordnen möchten.

Migrieren von statischen PPP-Abonnentenkonfigurationen zu dynamischen Profilen Übersicht

In diesem Thema werden verschiedene Überlegungen für die Migration bestimmter statischer, terminierter IPv4-PPP-Teilnehmerkonfigurationen zu dynamischen Konfigurationen mithilfe dynamischer Profile erörtert. Service Provider, die statische Abonnenten auf Routern mit älteren Junos OS-Versionen (vor Junos OS Version 15.1R4) verwalten, müssen ihre statischen Abonnenten auf die Verwaltung mit dynamischen Profilen auf Routern mit erweiterter Abonnentenverwaltung (Junos OS Version 15.1R4 und höhere Versionen) migrieren. Ab Junos OS Version 18.2R1 wurden mehrere Verbesserungen hinzugefügt, um den Übergang dieser statischen Service Provider-Konfigurationen zu dynamischen Profilen zu erleichtern.

Lokale Authentifizierung

Einige Anbieter mit statischen Konfigurationen verwenden möglicherweise CPE-Geräte, die keine Authentifizierungsprotokolle unterstützen, nicht einmal CHAP oder PAP. Die Anbieter können PPPoE-Dienstnamenstabellen als rudimentäre Methode verwenden, um die Abonnenten auf statischen logischen PPPoE-Schnittstellen zu authentifizieren und zu autorisieren. Wenn der ACI oder ARI des Abonnenten nicht mit einem Tabelleneintrag übereinstimmt, werden die PPP-PADI- und PADR-Pakete in der Regel verworfen. Ältere Versionen von Junos OS unterstützen keine Abonnenten, die mit keiner Authentifizierung für die Authentifizierungsmethode konfiguriert sind.

Für Abonnenten, bei denen das CPE keine Authentifizierungsprotokolle wie PAP und CHAP unterstützt, können Sie Benutzernamen und Kennwörter lokal konfigurieren. Der Router verwendet diese Werte, wenn er den RADIUS-Server zur Authentifizierung kontaktiert.

  • Um den Benutzernamen für die lokale Authentifizierung zu konfigurieren, fügen Sie die Anweisung in die PPP-Optionen für die username-include dynamische logische Schnittstelle ein. Sie können den Namen basierend auf einem oder mehreren der folgenden Attribute definieren: MAC-Adresse, Agent-Verbindungs-ID, Agent-Remote-ID und Domänenname. Standardmäßig ist ein Punkt (.) das Trennzeichen zwischen den Elementen des Namens, aber Sie können stattdessen andere Zeichen definieren.

  • Um das Kennwort für die lokale Authentifizierung zu konfigurieren, fügen Sie die Anweisung in die PPP-Optionen für die password dynamische logische Schnittstelle ein.

Sie können dasselbe dynamische Profil verwenden, um sowohl CPEs zu unterstützen, die kein Authentifizierungsprotokoll unterstützen, als auch CPEs, die ein Authentifizierungsprotokoll unterstützen.

CPE-bezogene Adresszuweisung

Bei einigen statischen Konfigurationen wird die Teilnehmeradresse nicht mithilfe von RADIUS oder einem lokalen Adresspool auf dem Router zugewiesen. Stattdessen verfügt das CPE über eine statische Adresse, die für den Teilnehmer konfiguriert ist. Während der IPCP-Aushandlung fordert das CPE den Router auf, diese Adresse dem Teilnehmer zuzuweisen.

Ab Junos OS Version 18.2R1 können Sie dem Framed-Route-Address-Attribut [8] in der Konfiguration für Ihren RADIUS-Server die Platzhalteradresse 255.255.255.255 zuweisen. Wenn RADIUS das Attribut mit diesem Wert zurückgibt, akzeptiert jpppd automatisch die vom Client in einer IPCP-Konfigurationsanforderungsnachricht bereitgestellte Adresszuweisung des Abonnenten, anstatt eine andere Adresse zuzuweisen.

Tag2 Routenattribut

In einigen Konfigurationen werden statische PPP-Teilnehmerschnittstellen in unterschiedlichen VRFs konfiguriert. Jede VRF-Konfiguration verfügt über statische Routen, die auf statische PPP-Abonnentenschnittstellen als Next-Hop-Adresse verweisen. Für diese Routen kann das Attribut tag2 konfiguriert sein. MP-BGP ist verpflichtet, bei der Ankündigung der Routen die entsprechenden lokalen Präferenzen und die entsprechende Community anzuwenden.

Ab Junos OS Version 18.2R1 können Sie Ihren RADIUS-Server so konfigurieren, dass er bei der Authentifizierung eines Abonnenten das Attribut tag2 in das Framed-Route-Attribut [22] einschließt.

Außerdem müssen Sie das dynamische Profil so konfigurieren, dass der tag2-Wert aus dem Framed-Route-Attribut abgeleitet wird. Geben Sie dazu die vordefinierte Variable $junos-framed-route-tag2 an, die bei der dynamischen Instanziierung der Zugriffsroute verwendet werden soll. Alternativ können Sie das dynamische Profil so konfigurieren, dass ein bestimmter tag2-Wert für ein bestimmtes Zugriffsroutenpräfix bereitgestellt wird.

Weitere Informationen zu vordefinierten Variablen finden Sie unter Vordefinierte Variablen von Junos OS .

Vorteile

  • Die lokale Authentifizierung ermöglicht die Authentifizierung mit lokal gespeicherten Kennwörtern und Benutzernamen für Abonnenten, wenn das CPE keine Authentifizierungsprotokolle wie PAP und CHAP unterstützt.

  • Die CPE-Adresszuweisung ermöglicht es dem Router, statisch konfigurierte Teilnehmer-IP-Adressen zu akzeptieren, die vom CPE angefordert werden, anstatt die Adresse aus einem lokalen oder externen Adresspool zuzuweisen.

  • Das Attribut tag2 ermöglicht eine detailliertere Angabe von Routen.

Konfigurieren der lokalen Authentifizierung in dynamischen Profilen für statisch beendete IPv4 PPP-Abonnenten

Einige Anbieter mit statischen Konfigurationen verwenden möglicherweise CPE-Geräte, die keine Authentifizierungsprotokolle unterstützen, nicht einmal CHAP oder PAP. Die Anbieter können PPPoE-Dienstnamenstabellen als rudimentäre Methode verwenden, um die Abonnenten auf statischen logischen PPPoE-Schnittstellen zu authentifizieren und zu autorisieren. Wenn der ACI oder ARI des Abonnenten nicht mit einem Tabelleneintrag übereinstimmt, werden die PPP-PADI- und PADR-Pakete in der Regel verworfen.

Ab Junos OS Version 18.2R1 können Sie Benutzernamen und Kennwörter lokal für Clients konfigurieren, die keine Authentifizierungsprotokolle wie PAP und CHAP unterstützen. Der Router verwendet diese Werte, wenn er den RADIUS-Server zur Authentifizierung kontaktiert. Dies hilft bei der Migration der statischen Abonnenten zur Verwendung dynamischer Profile auf einem Router, auf dem die erweiterte Abonnentenverwaltung ausgeführt wird.

So konfigurieren Sie die lokale Authentifizierung:

  1. Konfigurieren Sie den Benutzernamen mit einer oder mehreren der verfügbaren Optionen.

    1. (Optional) Geben Sie an, dass der Agent Circuit Identifier (ACI) im Benutzernamen enthalten ist. Der ACI leitet sich von PPPoE-Tags ab.

    2. (Optional) Geben Sie an, dass die Agent-Remote-ID (ARI) im Benutzernamen enthalten ist. Die ARI wird von PPPoE-Tags abgeleitet.

    3. (Optional) Geben Sie an, dass die MAC-Adresse der Client-PDU im Benutzernamen enthalten ist. Die MAC-Adresse wird aus dem PPPoE-Paket abgeleitet.

    4. (Optional) Geben Sie den Clientdomänennamen an, um den Benutzernamen zu beenden. Der Router fügt das @-Zeichen als Trennzeichen für diese Option hinzu.

    5. (Optional) Geben Sie ein Trennzeichen an, um die Komponenten zu trennen, aus denen der Benutzername besteht. Das Standardtrennzeichen ist ein Punkt (.). Der Router verwendet immer das @-Zeichen als Trennzeichen vor dem Domänennamen.

  2. Konfigurieren Sie das Kennwort für den Abonnenten.

Der Benutzername hat das folgende Format, wenn Sie alle Optionen einschließen und das Standardtrennzeichen verwenden:

Betrachten Sie z. B. die folgende Beispielkonfiguration, bei der ACI aci1002, ARI ari349 und MAC-Adresse 00:00:5e:00:53:ff lautet:

Diese Konfiguration führt zu einem lokalen Kennwort von $ABC 123$ABC123 für den folgenden eindeutigen lokalen Benutzernamen:

0000.5e00.53ff-aci1002-ari349@example.com

Konfigurieren von Tag2-Attributen in dynamischen Profilen für statisch beendete IPv4-PPP-Abonnenten

In einigen Konfigurationen verwenden PPP-Abonnenten statische Routen mit einem tag2-Attribut. Beispielsweise verwendet MP-BGP tag2, damit es bei der Ankündigung von Routen die entsprechenden lokalen Einstellungen und Communitys anwenden kann. Wenn Sie diese Abonnenten zur Verwendung dynamischer Profile auf einem Router migrieren, auf dem die erweiterte Abonnentenverwaltung ausgeführt wird, können Sie das tag2-Attribut konfigurieren, indem Sie einen bestimmten Wert für eine Route konfigurieren oder den Wert von einem RADIUS-Server ableiten. Diese Unterstützung ist erstmals in Junos OS Version 18.2R1 verfügbar.

  • So konfigurieren Sie einen bestimmten tag2-Wert für eine Route:

    • Geben Sie den Wert an.

  • So leiten Sie den tag2-Wert von einem RADIUS-Server ab:

    1. Konfigurieren Sie Ihren RADIUS-Server so, dass das Attribut tag2 in das Attribut Framed-Route [22] aufgenommen wird, wenn er einen Abonnenten authentifiziert. Konfigurationsinformationen finden Sie in der Dokumentation Ihres RADIUS-Servers. Die Konfiguration könnte in etwa wie im folgenden Beispiel aussehen:

    2. Konfigurieren Sie das dynamische Profil so, dass die vordefinierte Variable $junos-framed-route-tag2 verwendet wird, um den Wert tag2 dynamisch aus dem Attribut Framed-Route abzuleiten.

      Die vordefinierte Variable $junos-framed-route-ip-address-prefix leitet das IPv4-Adresspräfix für die Zugriffsroute ebenfalls aus dem Framed-Route-Attribut ab.

Konfigurieren der dynamischen Authentifizierung für PPP-Abonnenten

Sie können ein dynamisches Profil konfigurieren, das eine PPP-Authentifizierung enthält, mit der PPP-Clients dynamisch auf das Netzwerk zugreifen können. Sie können entweder CHAP- oder PAP-Authentifizierung angeben. Optional können Sie auch die Reihenfolge steuern, in der der Router die CHAP- und PAP-Protokolle aushandelt.

Bei dynamischen Schnittstellen unterstützt der Router nur unidirektionale Authentifizierung – der Router fungiert immer als Authentifikator. Wenn Sie die PPP-Authentifizierung in einem dynamischen Profil konfigurieren, unterstützt die CHAP-Authentifizierung die Option, mit der Sie die challenge-length minimale und maximale Länge der CHAP-Challenge-Nachricht konfigurieren können. Weder die CHAP-Authentifizierung noch die PAP-Authentifizierung unterstützen andere Konfigurationsoptionen, einschließlich der passive Anweisung.

Hinweis:

Dynamische Profile für PPP-Abonnenten werden nur auf PPPoE-Schnittstellen unterstützt.

So konfigurieren Sie die Authentifizierung in einem dynamischen Profil für PPP-Abonnentenschnittstellen:

  1. Benennen Sie das dynamische Profil.
  2. Konfigurieren Sie die Schnittstellen und die Einheit für das dynamische Profil. Verwenden Sie diese Option pp0 für den Schnittstellentyp und die vordefinierte Variable für die Einheit.
  3. Konfigurieren Sie PPP-Optionen.
  4. Geben Sie das Authentifizierungsprotokoll an, das im dynamischen Profil verwendet wird. Sie können entweder CHAP oder PAP konfigurieren. Für beide Authentifizierungsprotokolle gibt es keine zusätzlichen Optionen.
  5. (Optional) Konfigurieren Sie die minimale und maximale Länge der CHAP-Abfragenachricht.

    Weitere Informationen finden Sie unter Ändern der Länge der CHAP-Abfrage.

  6. (Optional) Konfigurieren Sie die Reihenfolge, in der der Router die CHAP- und PAP-Authentifizierungsprotokolle aushandelt.

    Weitere Informationen finden Sie unter Steuern der Aushandlungsreihenfolge von PPP-Authentifizierungsprotokollen.

  7. (Optional) Konfigurieren Sie den Router so, dass CPE während der IPCP-Aushandlung aufgefordert wird, die DNS-Adressen für dynamische PPPoE-Abonnenten auszuhandeln.

    Weitere Informationen finden Sie unter Sicherstellen der IPCP-Aushandlung für primäre und sekundäre DNS-Adressen .

Ändern der CHAP-Challenge-Länge

Sie können die standardmäßige minimale und maximale Länge der CHAP-Challenge-Nachricht (Challenge Handshake Authentication Protocol) ändern, die der Router an einen PPP-Client sendet. Die CHAP-Abfragenachricht, die Informationen enthält, die für eine bestimmte PPP-Abonnentensitzung eindeutig sind, wird als Teil des Authentifizierungsmechanismus zwischen dem Router und dem Client verwendet, um die Identität des Clients für den Zugriff auf den Router zu überprüfen.

Standardmäßig beträgt die Mindestlänge der CHAP-Abfrage 16 Byte und die maximale Länge 32 Byte. Sie können diese Standardeinstellung außer Kraft setzen, um die minimale Länge und die maximale Länge der CHAP-Abfrage im Bereich von 8 Byte bis 63 Byte zu konfigurieren.

Bewährte Methode:

Es wird empfohlen, sowohl die minimale als auch die maximale Länge der CHAP-Abfrage auf mindestens 16 Byte zu konfigurieren.

Bevor Sie beginnen:

So konfigurieren Sie die minimale und maximale Länge der CHAP-Abfragenachricht:

  1. Geben Sie an, dass Sie PPP-Optionen konfigurieren möchten.

    • Für dynamische PPP-Teilnehmerschnittstellen:

    • Für statische Schnittstellen mit PPP-Kapselung:

  2. Geben Sie an, dass Sie CHAP-Optionen konfigurieren möchten.

    • Für dynamische PPP-Teilnehmerschnittstellen:

    • Für statische Schnittstellen mit PPP-Kapselung:

  3. Geben Sie die minimale und maximale Länge der CHAP-Abfrage an.

    • Für dynamische PPP-Teilnehmerschnittstellen:

    • Für statische Schnittstellen mit PPP-Kapselung:

    Die folgende challenge-length Anweisung in einem dynamischen Profil mit dem Namen pppoe-client-profile legt beispielsweise die minimale Länge der CHAP-Abfrage auf 20 Byte und die maximale Länge auf 40 Byte fest.

Beispiel: Dynamisches Mindestprofil für PPPoE

Dieses Beispiel zeigt die Mindestkonfiguration für ein dynamisches Profil, das für statische PPPoE-Schnittstellen verwendet wird. Die Konfiguration muss die interfaces pp0 Zeilengruppe enthalten.

Überprüfen und Verwalten der PPP-Konfiguration für die Abonnentenverwaltung

Zweck

Anzeigen oder Löschen von Informationen zur PPP-Konfiguration für die Abonnentenverwaltung.

Aktion

  • So zeigen Sie Informationen zu PPP-Schnittstellen an:

  • So zeigen Sie Informationen zur PPP-Statistik an:

  • So zeigen Sie Zusammenfassungsinformationen für PPP-Sitzungen an:

  • So zeigen Sie PPP-Adresspoolinformationen an:

Zugehörige Dokumentation

Tabelle der Versionshistorie
Release
Beschreibung
20.2R1
Ab Junos OS Version 20.2R1 können Sie Nachrichten mit RADIUS-Quelle verwenden, um Informationen zu übermitteln, die das BNG transparent an ein CPE-Gerät, z. B. ein Home-Gateway, weiterleitet.
18.2R1
Ab Junos OS Version 18.2R1 wurden mehrere Verbesserungen hinzugefügt, um den Übergang dieser statischen Service Provider-Konfigurationen zu dynamischen Profilen zu erleichtern.
18.1R1
Ab Junos OS Version 18.1R1 kann dieses Ergebnis vermieden werden, indem der Router so konfiguriert wird, dass keine Magic-Zahlen-Validierungsprüfung durchgeführt wird.