Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

PPP Subscriber Access Networks – Übersicht

Dynamische Profile für PPP-Anwenderschnittstellen – Übersicht

Anwenderverwaltung Die PPP-Unterstützung ermöglicht es Ihnen, dynamische Profile für PPP-Anwender-Schnittstellen zu erstellen und anzuhängen. Wenn sich der PPP-Anwender 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. Für statische 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 ist bei der Anwender-Verwaltung keine bidirektionale PPP-Authentifizierung möglich – die Authentifizierung wird nur vom Router durchgeführt, niemals vom Remote-Peer. Der AAA-Prozess des Routers verwaltet die Authentifizierung und Adresszuweisung für die Verwaltung von Anwendern. 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 Sie können 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 das Anwender-Management nicht unterstützt.

verstehen, wie der Router vom Abonnenten initiierte PPP-Fast-Keepalive-Anfragen verarbeitet

Bei Routern der MX-Serie mit Modular Port Concentrators/Modular Interface Cards (MPCs/MICs) verarbeitet und beantwortet die Packet Forwarding Engine auf einem MPC/MIC Echo-Request-Pakete des Link Control Protocol (LCP), die der PPP-Anwender (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 reduzieren die für den Keepalive-Austausch erforderliche Zeit, indem sie es der Packet Forwarding Engine ermöglichen, LCP-Echo-Request-Pakete vom PPP-Anwender 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 die Routing-Engine von der Verarbeitung der LCP-Echo-Request- und Echo-Reply-Pakete entlastet wird.

  • PPP-Fast-Keepalives verwenden ausgehandelte magische Zahlen, um potenzielle Datenverkehrs-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 Zahlen anstelle der ausgehandelten Anzahl verwenden.

So funktioniert die schnelle Keepalive-Verarbeitung von PPP

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

In der folgenden Sequenz wird beschrieben, 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 Packet Forwarding Engine, wenn die Übertragung von Keepalive-Anforderungen auf einer logischen PPP-Schnittstelle aktiviert ist. Die Benachrichtigung enthält die magischen Zahlen des Servers und des Remote-Clients.

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

  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 verarbeitet weiterhin LCP-Echo-Request-Pakete, bis die Schleifenbedingung gelöscht ist.

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 Betriebsbefehls show interfaces pp0.logical statistics keine Statistiken über die Anzahl der empfangenen oder gesendeten Keepalive-Pakete oder die Zeitspanne, seit der Router das letzte Keepalive-Paket empfangen oder gesendet hat.

Auswirkung einer Ä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] einschließen.

Für PPP Fast (Inline) Keepalive LCP Echo-Request- und LCP Echo-Reply-Pakete, 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 Network Server (LNS)-Anwender-Sessions, die nach der Konfigurationsänderung erstellt werden, als auch für bestehende PPPoE-, PPPoA-, und LNS-Anwender-Sitzungen, die vor der Konfigurationsänderung eingerichtet wurden.

Ignorieren einer nicht übereinstimmenden magischen Zahl

Wenn die Packet Forwarding Engine die magische Zahl des Peers im empfangenen LCP-Echo-Request-Paket validiert, prüft sie, ob die magische Zahl unerwartet ist. Die erhaltene 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 (der Datenverkehr wird in einer Schleife zum lokalen Peer zurückgeleitet) oder ein anderes Netzwerkproblem vorliegt.

Wenn die Validierungsprüfung feststellt, dass eine Diskrepanz vorliegt, d. h. die empfangene Remote-Peer-Nummer von der ausgehandelten Nummer abweicht, sendet die Packet Forwarding Engine die fehlgeschlagenen Echo-Reply-Pakete an die Routing-Engine. Wenn innerhalb eines bestimmten Intervalls keine Echo-Antwort mit einer gültigen magischen Nummer empfangen wird, betrachtet PPP dies als Keepalive-Fehler und bricht die PPP-Sitzung ab.

Einige Kundengeräte handeln möglicherweise nicht mit ihrer lokalen magischen 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 Diskrepanz 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 er keine Validierungsprüfung für magische Zahlen durchführt. 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-Anwender-Verbindungen, die am Router beendet werden, oder in das dynamische Profil für dynamische getunnelte PPP-Abonnenten am LNS ein.

Siehe auch

RADIUS-gestützte Aktualisierungen des Verbindungsstatus für CPE-Geräte

Ab Junos OS Version 20.2R1 können Sie Nachrichten aus RADIUS-Quellen verwenden, um Informationen zu übermitteln, die die BNG transparent an ein CPE-Gerät weiterleitet, z. B. ein Home-Gateway. Bei diesen Informationen kann es sich beispielsweise um die Upstream-Bandbreite oder einen anderen Parameter der 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 erzwingen 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 fügt 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-Nachricht während der Aushandlung und Autorisierung einer PPP-Sitzung

  • In einer RADIUS CoA-Anfrage für eine aktive PPP-Sitzung jederzeit

Sie können diese beiden Methoden für jede Sitzung für Geschäfts- oder Privatkunden verwenden. Die Access-Accept-Nachricht stellt die anfänglichen Verbindungsparameter bereit. Die CoA-Funktion ermöglicht es Ihnen, die Parameter der Verbindungsrate während der gesamten Lebensdauer einer Sitzung nach Bedarf zu aktualisieren. Bei den in der Connection-Status-Message-VSA enthaltenen Informationen handelt es sich in der Regel um Datenverkehrsraten, die durch eine lokale Konfiguration angewendet werden, z. B. ein dynamisches Serviceprofil oder die entsprechende ANCP-Port-Up-Nachricht.

Hinweis:

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

In den folgenden Schritten wird beschrieben, was geschieht, wenn RADIUS den 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 (jppppd).

  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 einem Antrag auf Familienaktivierung. Die PPP-Sitzung wechselt in den Status "Sitzung aktiv", wenn die Familie aktiviert ist.

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

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

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

    Hinweis:

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

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

In den folgenden Schritten wird beschrieben, was passiert, wenn RADIUS den VSA in einer CoA-Anforderung sendet. Dabei wird davon ausgegangen, dass die NCP-Verhandlung 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 (jppppd).

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

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

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

    Hinweis:

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

Wenn das Home-Gateway keine Connection-Update-Request-Nachricht empfängt, versucht der Router erneut, die Nachricht zu senden. Der Router wiederholt die Anforderung auch, wenn er weder einen Connection-Update-Ack noch einen LCP-Code-Reject vom Gateway erhält oder wenn etwas mit der Ack-Nachricht nicht stimmt. Das Standardintervall für Wiederholungen 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 Nachricht so, als hätte er eine PPP-Code-Reject-Nachricht 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, aber es besteht keine 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 authd auch dann die Verbindungsinformationen an PPP sendet, selbst wenn es die anderen Attribute nicht erfolgreich anwendet, das wiederum den VSA-Inhalt an das Home-Gateway sendet.

Ebenso wendet authd alle anderen Attribute an und gibt eine CoA-Antwort zurück, unabhängig davon, ob PPP den Inhalt des Connection-Status-Message-VSA erfolgreich an das Remote-Gateway übermittelt. Dies gilt auch dann, wenn das CoA nur die Connection-Status-Message-VSA enthält. Diese Funktion ist erforderlich, 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: Connection-Update-Request- und Connection-Update-Ack-Nachrichtenformate Diagram of TLV encoded data structure with fields Code, Identifier, Length, Magic Number, OUI, Kind, and Values, showing bit positions.
Tabelle 1: Feldwerte für Connection-Update-Request- und Connection-Update-Ack-Nachrichten

Feld

Verbindungs-Update-Anfrage

Verbindungs-Update-Ack

Kodex

0 für anbieterspezifische

0 für anbieterspezifische

Kennung

Kennung für anbieterspezifisches Paket

Derselbe Bezeichner wie in der Connection-Update-Request-Nachricht. Wenn dieser Wert nicht übereinstimmt, protokolliert der Router den Fehler und verwirft das Paket. Dadurch 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

Organisatorisch eindeutiger Identifikator (OUI)

21.00.59 für Juniper Networks

21.00.59 für Juniper Networks

Sehr freundlich

1 für Session-Update

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

Werte

Option Connection-Status-Message 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 Anforderung und den Ack-Nachrichten. Wenn keine anderen Validierungsfehler vorliegen, akzeptiert PPP die Connection-Update-Ack-Nachricht.

  • Wenn Sie die PPP-Option nicht konfigurieren ignore-magic-number-mismatch , durchlaufen die magischen Zahlen eine Validierung. 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-Meldung als ungültige Antwort. Dadurch 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 PPP Magic Numbers während PPP Keepalive Exchanges .

Abbildung 2 zeigt das Format für die Optionen für Connection-Status-Message. Tabelle 2 listet die Feldwerte auf.

Abbildung 2: Connection-Status-Message-Optionsformat Diagram of MIDI message structure showing Type and Length fields in the first byte and Status Message field in the second and third bytes.
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 Verbindungsstatusmeldung VSA

Konfigurieren Sie dynamische 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 Client-Zugriff (z. B. Schnittstelle oder Protokoll) oder Service (z. B. IGMP) enthält. Mithilfe von dynamischen Profilen können Sie alle allgemeinen Attribute eines Mandanten (und eventuell einer Gruppe von Mandanten) konsolidieren und 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] einbinden:

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 Subscriber Access.

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

Informationen zum Zuweisen eines dynamischen Profils zu einer PPP-Schnittstelle finden Sie unter Dynamische Profile an statische PPP-Anwenderschnittstellen anhängen im Konfigurationshandbuch für den Junos-Anwenderzugriff.

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

Hinweis:

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

Verhinderung der Validierung von PPP Magic Numbers während des PPP-Keepalive-Austauschs

Die magischen PPP-Zahlen werden während der LCP-Aushandlung zwischen Peers ausgehandelt. Die Peers müssen unterschiedliche magische Zahlen haben. Wenn die Zahlen identisch sind, deutet 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 Remote-Peer. Wenn die vom Remote-Peer zurückgegebene magische Zahl von der zuletzt vom lokalen Peer gesendeten Nummer abweicht, werden die Zahlen vereinbart. Andernfalls wird der Austausch von magischen Zahlen fortgesetzt, bis eine gültige (andere) Zahl empfangen wird oder der Prozess eine Zeitüberschreitung aufweist, in diesem Fall wird die Sitzung abgebrochen.

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

Unter bestimmten Umständen ist dieses Verhalten nicht wünschenswert. Einige Kundengeräte handeln nicht mit ihrer lokalen magischen Zahl 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 Diskrepanz identifiziert und die Sitzung wird schließlich gelöscht. 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 ignore-magic-number-mismatch Anweisung als eine der PPP-Optionen in ein dynamisches PPP-Profil, ein dynamisches L2TP-LNS-Profil oder ein L2TP-Gruppenprofil aufnehmen. Die Konfiguration dieser Anweisung hat keine Auswirkungen auf die Aushandlung magischer LCP-Nummern oder auf den Austausch von Keepalives, wenn die magische Remote-Peer-Nummer die erwartete ausgehandelte Nummer ist.

Hinweis:

Da keine Magic Number-Validierung durchgeführt wird, erkennt die Packet Forwarding Engine nicht, ob der Remote-Peer die Magic Number des lokalen Peers sendet, was auf ein Loopback oder ein anderes Netzwerkproblem hinweisen würde. Dies wird als unwahrscheinlich 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 Packet Forwarding Engine Übereinstimmungen in magischen Zahlen erkennt:

Konfigurieren Sie die PPP-Option.

  • Für dynamische PPP-Anwender-Verbindungen, die am Router beendet werden:

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

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

Konfigurieren von RADIUS-bezogenen Verbindungsstatusaktualisierungen für CPE-Geräte

Sie können Nachrichten aus RADIUS-Quellen verwenden, um Informationen zu übermitteln, die die BNG transparent an ein CPE-Gerät weiterleitet, z. B. an ein Home-Gateway. Bei diesen Informationen kann es sich beispielsweise um die Upstream-Bandbreite oder einen anderen Parameter der 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 muss Folgendes zutreffen:

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

  • Der Router-LCP befindet sich im Zustand Geöffnet.

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

Sie konfigurieren diese Funktion im dynamischen Clientprofil, das 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 auch VSA 26-218 auf Ihrem RADIUS-Server konfigurieren. Dies würde den Rahmen dieser Dokumentation sprengen.

So konfigurieren Sie die Aktualisierungen des Verbindungsstatus in einem dynamischen Profil für PPP-Anwenderschnittstellen:

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

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

Dynamische Profile an statische PPP-Anwenderschnittstellen anhängen

Sie können ein dynamisches Profil an eine statische PPP-Schnittstelle für Anwender anhängen. Wenn sich ein PPP-Anwender anmeldet, wird das angegebene dynamische Profil instanziiert und die im Profil definierten Services werden auf die Schnittstelle angewendet.

So fügen Sie ein dynamisches Profil an eine statische PPP-Anwender-Schnittstelle 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.

Migration statischer PPP-Anwenderkonfigurationen in dynamische Profile – Übersicht

In diesem Thema werden mehrere Überlegungen zum Migrieren bestimmter statischer, terminierter IPv4 PPP-Anwenderkonfigurationen zu dynamischen Konfigurationen mit dynamischen Profilen erläutert. 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 Router mit erweiterter Anwender-Verwaltung (Junos OS Version 15.1R4 und höher) migrieren, um sie mit dynamischen Profilen zu verwalten. 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-Dienstnamentabellen als rudimentäre Methode verwenden, um die Abonnenten auf statischen logischen PPPoE-Schnittstellen zu authentifizieren und zu autorisieren. Wenn die ACI oder ARI des Anwenders nicht mit einem Tabelleneintrag übereinstimmen, werden die PPP-PADI- und PADR-Pakete in der Regel verworfen. Ältere Junos OS-Versionen unterstützen keine Abonnenten, die ohne Authentifizierung für die Authentifizierungs-Methode konfiguriert sind.

Für Abonnenten, für die 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, schließen Sie die username-include Anweisung in die PPP-Optionen für die 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, schließen Sie die password Anweisung in die PPP-Optionen für die 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 dies tun.

CPE-gestützte Adresszuweisung

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

Ab Junos OS Version 18.2R1 können Sie dem Attribut "Framed-Route-Address" [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 IP-Adresszuweisung des Anwenders, die vom Client in einer IPCP-Konfigurationsanforderungsnachricht bereitgestellt wird, anstatt eine andere Adresse zuzuweisen.

Tag2 Routen-Attribut

In einigen Konfigurationen sind statische PPP-Anwender-Schnittstellen in verschiedenen VRFs konfiguriert. Jede VRF-Konfiguration verfügt über statische Routen, die als Next-Hop-Adresse auf statische PPP-Anwender-Schnittstellen verweisen. Für diese Routen ist möglicherweise das Attribut tag2 konfiguriert. es ist von MP-BGP verpflichtet, die entsprechende lokale Präferenz und Gemeinde anzuwenden, wenn es die Routen bewirbt.

Ab Junos OS Version 18.2R1 können Sie Ihren RADIUS-Server so konfigurieren, dass das Attribut tag2 in das Attribut Framed-Route [22] aufgenommen wird, wenn er einen Anwender authentifiziert.

Sie müssen auch das dynamische Profil so konfigurieren, dass der tag2-Wert vom Framed-Route-Attribut abgeleitet wird. Geben Sie dazu die vordefinierte Variable $junos-framed-route-tag2 an, die verwendet werden soll, wenn die Zugriffsroute dynamisch instanziiert wird. 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-basierte Adresszuweisung ermöglicht es dem Router, statisch konfigurierte IP-Adressen von Anwendern zu akzeptieren, die vom CPE angefordert werden, anstatt die Adresse aus einem lokalen oder extern bezogenen Adresspool zuzuweisen.

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

Konfiguration 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-Dienstnamentabellen als rudimentäre Methode verwenden, um die Abonnenten auf statischen logischen PPPoE-Schnittstellen zu authentifizieren und zu autorisieren. Wenn der ACI oder ARI des Anwenders 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 mit erweiterter Anwender-Verwaltung.

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 wird von PPPoE-Tags abgeleitet.

    2. (Optional) Geben Sie an, dass die Remote-ID (ARI) des Agenten 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 Anwender.

Der Benutzername nimmt das folgende Format an, wenn Sie alle Optionen angeben und das Standardtrennzeichen verwenden:

Betrachten Sie beispielsweise die folgende Beispielkonfiguration, in der die ACI aci1002, die ARI ari349 und die 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. MP-BGP verwendet beispielsweise tag2, damit es die entsprechende lokale Präferenz und Community anwenden kann, wenn Routen angekündigt werden. Wenn Sie diese Abonnenten zur Verwendung dynamischer Profile auf einem Router mit erweiterter Anwenderverwaltung migrieren, können Sie das Attribut tag2 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 Anwender 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 tag2-Wert dynamisch aus dem Framed-Route-Attribut 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.

Konfiguration der dynamischen Authentifizierung für PPP-Abonnenten

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

Bei dynamischen Schnittstellen unterstützt der Router nur die unidirektionale Authentifizierung – der Router fungiert immer als Authentifikator. Wenn Sie die PPP-Authentifizierung in einem dynamischen Profil konfigurieren, unterstützt die CHAP-Authentifizierung die challenge-length Option, mit der Sie die minimale und maximale Länge der CHAP-Abfragenachricht 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-Anwenderschnittstellen:

  1. Nennen Sie das dynamische Profil.
  2. Konfigurieren Sie die Schnittstellen und die Einheit für das dynamische Profil. Verwenden Sie pp0 für den Schnittstellentyp und die vordefinierte Variable für die Einheit.
  3. Konfigurieren Sie PPP-Optionen.
  4. Geben Sie das im dynamischen Profil verwendete Authentifizierungsprotokoll an. 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-Challenge-Nachricht.

    Siehe Ändern der CHAP-Herausforderungslänge.

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

    Siehe Aushandlungsreihenfolge von PPP-Authentifizierungsprotokollen steuern.

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

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

Ändern der CHAP-Herausforderungslänge

Sie können die standardmäßige Mindestlänge und maximale Länge der CHAP-Abfragenachricht (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-Anwender-Sitzung 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-Herausforderung 16 Byte und die maximale Länge 32 Byte. Sie können diese Standardeinstellung überschreiben, um die Mindestlänge und maximale Länge der CHAP-Herausforderung im Bereich von 8 Byte bis 63 Byte zu konfigurieren.

Optimale Vorgehensweise:

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

Bevor Sie beginnen:

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

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

    • Für dynamische PPP-Anwender-Schnittstellen:

    • Für statische Schnittstellen mit PPP-Verkapselung:

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

    • Für dynamische PPP-Anwender-Schnittstellen:

    • Für statische Schnittstellen mit PPP-Verkapselung:

  3. Geben Sie die Mindestlänge und die maximale Länge der CHAP-Herausforderung an.

    • Für dynamische PPP-Anwender-Schnittstellen:

    • Für statische Schnittstellen mit PPP-Verkapselung:

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

Beispiel: Dynamisches PPPoE-Profil

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

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

Zweck

Zeigen Sie Informationen zur PPP-Konfiguration für die Anwender-Verwaltung an oder löschen Sie sie.

Aktion

  • So zeigen Sie Informationen zu PPP-Schnittstellen an:

  • So zeigen Sie KKP-Statistikinformationen an:

  • So zeigen Sie die Zusammenfassung der PPP-Sitzung an:

  • So zeigen Sie PPP-Adresspoolinformationen an:

Zugehörige Dokumentation

Tabellarischer Änderungsverlauf

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

Veröffentlichung
Beschreibung
20.2R1
Ab Junos OS Version 20.2R1 können Sie Nachrichten aus RADIUS-Quellen verwenden, um Informationen zu übermitteln, die die BNG transparent an ein CPE-Gerät weiterleitet, z. B. ein Home-Gateway.
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 er keine Validierungsprüfung für magische Zahlen durchführt.