このページの目次
PPP加入者アクセスネットワークの概要
PPP 加入者インターフェイスの動的プロファイルの概要
加入者管理 PPP サポートにより、PPP 加入者インターフェイスの動的プロファイルを作成して接続できます。PPP加入者がログインすると、ルーターは指定された動的プロファイルをインスタンス化し、プロファイルで定義された属性をインターフェイスに適用します。
動的プロファイルは、静的および動的 PPP インターフェイスの両方に使用されます。静的PPPインターフェイスの場合、CLIを使用して、PPPオプションを指定する動的プロファイルをアタッチします。動的 PPP インターフェイスの場合、動的プロファイルは、PPP オプションを含むインターフェイスを作成します。
動的に作成されたインターフェイスは、PPPoE インターフェイスでのみサポートされます。
従来の PPP サポートとは異なり、加入者管理では双方向 PPP 認証は許可されません。認証はルーターによってのみ実行され、リモート ピアでは実行されません。ルーターのAAAプロセスは、加入者管理のための認証とアドレス割り当てを管理します。動的プロファイルの PPP オプションを設定する場合、チャレンジ ハンドシェイク認証プロトコル(CHAP)またはパスワード認証プロトコル(PAP)認証のいずれかを設定し、ルーターが CHAP および PAP プロトコルをネゴシエートする順序を制御できます。また、CHAP 認証では、CHAP チャレンジ メッセージの既定の長さを変更できます。従来の PPP インターフェイス設定で一般的に使用されている、または必須であるその他の PPP オプションは、加入者管理動的プロファイルではサポートされていません。
ルーターが加入者開始 PPP 高速キープアライブ要求を処理する方法の理解
MPC/MIC(Modular Port Concentrator/Modular Interface Card)を搭載した MX シリーズ ルーターでは、MPC/MIC 上のパケット転送エンジンが、PPP 加入者(クライアント)が開始してルーターに送信する LCP(リンク制御プロトコル)エコー要求パケットを処理し、応答します。LCPエコー要求パケットとLCPエコー応答パケットは、リンクが正常に機能しているかどうかを判断するのに役立つPPPキープアライブメカニズムの一部です。
以前は、LCPエコー要求パケットとLCPエコー応答パケットは、ルーティングエンジンによってMXシリーズルーターで処理されていました。LCPエコー要求パケットがルーティングエンジンではなくパケット転送エンジンによって処理されるメカニズムは、 PPP高速キープアライブと呼ばれます。
PPP高速キープアライブの利点
PPP高速キープアライブは、パケット転送エンジンがPPP加入者からLCPエコー要求パケットを受信し、LCPエコー応答パケットで応答できるようにすることで、キープアライブ交換に必要な時間を短縮します。LCPパケットをルーティングエンジンに送信して処理する必要はありません。
PPP高速キープアライブは、ルータの帯域幅を拡大し、ルーティングエンジンがLCPエコー要求およびエコー応答パケットを処理する必要をなくすことで、パフォーマンスを向上させて、より多くの加入者をサポートします。
PPP高速キープアライブは、ネゴシエートされたマジックナンバーを使用して、ルーターへの潜在的なトラフィックループバックまたはネットワークの問題を特定します。また、PPPリモートピアがネゴシエートされた番号ではなく任意の番号を使用している場合など、望ましくないPPPセッションの終了を防ぐために必要に応じて検証を無効にすることもできます。
PPP 高速キープアライブ処理の仕組み
パケット転送エンジンでPPP高速キープアライブ要求を処理できるようにするために、MPC/MICを搭載したMXシリーズルーターで特別な設定を行う必要はありません。この機能はデフォルトで有効になっており、無効にすることはできません。
次のシーケンスは、MX シリーズ ルーターが MPC/MIC のパケット転送エンジンで LCP エコー要求パケットと LCP エコー応答パケットを処理する方法を示しています。
ルーティング エンジンは、PPP 論理インターフェイスでキープアライブ要求の送信が有効になっている場合に、パケット転送エンジンに通知します。通知には、サーバーとリモートクライアントの両方のマジックナンバーが含まれます。
パケット転送エンジンは、PPP加入者(クライアント)によって開始されたLCPエコー要求パケットを受信します。
パケット転送エンジンは、LCPエコーリクエストパケット内のピアマジックナンバーを検証し、ルーターによってネゴシエートされたマジックナンバーを含む対応するLCPエコー応答パケットを送信します。
パケット転送エンジンがリンク内のループ状態を検出すると、LCPエコー要求パケットをルーティングエンジンに送信してさらに処理します。
ルーティング エンジンは、ループ状態が解除されるまで LCP エコー要求パケットの処理を続けます。
ルーター上のパケット転送エンジンからのキープアライブ要求の送信は、現在有効ではありません。
PPP 高速キープアライブの統計情報表示
MPC/MICを搭載したMXシリーズルーターがPPPリンクにPPP高速キープアライブを使用している場合、 操作コマンドの出力show interfaces pp0.logical statistics
のフィールドには、受信または送信したキープアライブパケットの数や、Keepalive statistics
ルーターが最後のキープアライブパケットを送受信してからの時間の統計情報は含まれません。
転送クラス設定の変更による影響
ルーティング エンジンが生成するアウトバウンド トラフィックのデフォルトのキュー割り当て(転送クラス)を変更するには、 階層レベルでステート forwarding-class class-name
メント [edit class-of-service host-outbound-traffic]
を含めます。
MPC/MICを搭載したMXシリーズルーターとPPPクライアントの間で送信されるPPP高速(インライン)キープアライブLCPエコーリクエストおよびLCPエコー応答パケットの場合、転送クラス設定の変更は、設定変更後に作成された新しいPPP-over-Ethernet(PPPoE)、PPP-over-ATM(PPPoA)、およびL2TPネットワークサーバー(LNS)加入者セッションの両方に対して、および既存のPPPoE、PPPoAに対して直ちに有効になります。 および LNS 加入者セッションの設定変更前に確立されたセッション。
マジックナンバーの不一致の無視
パケット転送エンジンは、受信したLCPエコー要求パケットのピアマジックナンバーを検証するときに、マジックナンバーが予期しないものかどうかをチェックします。受信した番号は、LCP ネゴシエーション中に合意されたリモート ピアの番号と一致する必要があります。リモート・ピア番号はローカル・ピア番号と異なっていなければなりません。同じ場合は、ループバック状態(トラフィックがローカルピアにループバックしている)またはその他のネットワークの問題が存在することが想定されます。
検証チェックで不一致が存在する、つまり受信したリモートピア番号がネゴシエートされた番号と異なると判断された場合、パケット転送エンジンは失敗したエコー応答パケットをルーティングエンジンに送信します。有効なマジックナンバーを持つエコー応答が一定の間隔内に受信されない場合、PPP はこれをキープアライブ障害とみなし、PPP セッションを破棄します。
一部の顧客機器は、ローカルマジックナンバーをネゴシエートせず、代わりにキープアライブパケットでルーターに送信するマジックナンバーとして任意の値を挿入する場合があります。この番号は不一致として識別され、最終的にセッションはドロップされます。Junos OS Release 18.1R1以降では、マジックナンバー検証チェックを実行しないようにルーターを設定することで、この結果を回避できます。不一致が特定されないため、ルーターはリモートピアとPPPキープアライブパケットを交換し続けます。この動作を設定するには、L2TPグループプロファイル、ルーターで終了した動的PPP加入者接続の動的プロファイル、またはLNSの動的トンネリングPPP加入者の動的プロファイルに ステートメントを含め ignore-magic-number-mismatch
ます。
関連項目
CPEデバイスに対するRADIUSソースの接続ステータスの更新
Junos OSリリース20.2R1以降、RADIUS 送信元メッセージを使用して、BNG がホーム ゲートウェイなどの CPE デバイスに透過的に転送する情報を伝達できます。たとえば、この情報はアップストリーム帯域幅や、CPE デバイスが必要とするその他の接続速度パラメータなどです。この機能は、できるだけ加入者の近くでトラフィック管理を動的に適用したい場合に有効です。
通常、PPP認証中にRADIUS標準属性の応答メッセージ(18)を使用して、この情報をCPEデバイスに伝達できます。ただし、すでにその属性を別の用途に使用している場合は、ジュニパーネットワークスのConnection-Status-Message VSA(26-4874–218)を使用することもできます。このVSAは、返信メッセージ属性(18)の論理拡張であり、同じ形式とセマンティクスを持ちます。
PPPは、LCPに対するジュニパーネットワークスのベンダー固有の拡張機能を使用して、接続ステータスメッセージVSAの内容をピアホームゲートウェイに送信します。PPP は、LCP 接続更新要求メッセージの接続ステータス メッセージ オプションにこの情報を組み込みます。
RADIUS は、以下の方法で接続ステータスメッセージ VSA を authd に送信できます。
PPP セッションのネゴシエーションおよび許可中の RADIUS Access-Accept メッセージ内
アクティブなPPPセッションに対するRADIUS CoA要求において、いつでも
これらの方法の両方を、企業または家庭のサブスクライバーの特定のセッションに使用できます。Access-Accept メッセージは、初期接続パラメーターを提供します。CoA機能により、セッションのライフサイクルを通じて、必要に応じて接続速度パラメータを更新できます。接続ステータスメッセージVSAで伝送される情報は、通常、動的サービスプロファイルや対応するANCPポートアップメッセージなどのローカル設定によって適用されるトラフィックレートです。
動的クライアント・プロファイルに PPP オプションを含め lcp-connection-update
ない場合、PPP は authd からの通知を処理しますが、アクションは実行しません。ルータのLCPがオープン状態でない場合、PPPはVSAに対して何も処理を行いません。
次の手順では、RADIUS が Access-Accept メッセージで VSA を送信するとどうなるかを説明します。
認証プロセスは、RADIUSサーバーからのAccess-Acceptメッセージで接続ステータスメッセージVSAを受信します。
認証プロセスは、接続ステータスメッセージ VSA を PPP (jpppd) に送信します。
PPP NCPネゴシエーションは、リモートゲートウェイPPPクライアントとルーター上のPPPの間で行われます。
ネゴシエーションが成功すると、ファミリーアクティベーションリクエストが発生します。PPP セッションは、ファミリーがアクティブになるとセッション アップ状態になります。
動的クライアント プロファイルに PPP オプションが含まれ
lcp-connection-update
ていて、ルータの LCP がオープン状態の場合、PPP はゲートウェイに LCP 接続更新要求メッセージを送信します。このメッセージには、接続ステータスメッセージオプション内のVSA情報が含まれます。ゲートウェイが LCP 接続更新要求をサポートしている場合、ゲートウェイは LCP 接続更新-Ack メッセージをルーターに返します。ホーム ゲートウェイ LCP は、要求の受信時に Opened 状態である必要があり、それ以外の場合は要求を破棄します。
ゲートウェイが LCP 接続更新要求をサポートしていない場合、ゲートウェイは LCP コード拒否メッセージをルーターに返します。
メモ:ゲートウェイが応答しない場合、ルーターは更新要求を再試行します。PPP のデフォルト値である最大 10 回の再試行と、試行の間には 3 秒の間隔があります。
メモ:動的クライアント・プロファイルに PPP オプションを含め
lcp-connection-update
ない場合、PPP は authd からの通知を処理しますが、アクションは実行しません。オプションが存在していても、ルーター上のLCPがオープン状態でない場合、PPPはVSAに関するアクションを行いません。
次の手順では、RADIUS が CoA リクエストで VSA を送信するとどうなるかを説明します。これは、NCP ネゴシエーションがすでに成功し、セッションがアクティブであることを前提としています。
認証プロセスは、RADIUSサーバーからのCoAリクエストで接続ステータスメッセージVSAを受信します。
認証プロセスは、接続ステータスメッセージ VSA を PPP (jpppd) に送信します。
動的クライアント プロファイルに PPP オプションが含まれ
lcp-connection-update
ていて、ルータの LCP がオープン状態の場合、PPP はゲートウェイに LCP 接続更新要求メッセージを送信します。このメッセージには、接続ステータスメッセージオプション内のVSA情報が含まれます。ゲートウェイが LCP 接続更新要求をサポートしている場合、ゲートウェイは LCP 接続更新-Ack メッセージをルーターに返します。ホーム ゲートウェイ LCP は、要求の受信時に Opened 状態である必要があり、それ以外の場合は要求を破棄します。
ゲートウェイが LCP 接続更新要求をサポートしていない場合、ゲートウェイは LCP コード拒否メッセージをルーターに返します。
メモ:ゲートウェイが応答しない場合、ルーターは更新要求を再試行します。PPP のデフォルト値である最大 10 回の再試行と、試行の間には 3 秒の間隔があります。
ホームゲートウェイが接続更新要求メッセージの受信に失敗した場合、ルーターはメッセージの送信を再試行します。ルーターは、ゲートウェイから接続更新-Ack または LCP コード拒否を受信しない場合、または Ack メッセージに問題がある場合にも、要求を再試行します。既定の再試行間隔は 3 秒です。ルーターは、メッセージが終了する前に、デフォルトまで 10 回再試行します。ルーターが適切な Connection-Update-Ack メッセージを受け取らずにすべての再試行回数を使い果たした場合、ルーターは PPP コード拒否メッセージを受信したかのようにメッセージを記録します。
RADIUSは、Access-AcceptメッセージまたはCoAリクエストのいずれかに、接続ステータスメッセージVSAの複数のインスタンスを含めることができます。これが発生した場合、authd は最初のインスタンスのみを使用し、他のインスタンスを無視します。
Access-AcceptまたはCoAリクエストには、接続ステータスメッセージVSA以外の属性が含まれている場合がありますが、VSAと他の属性の間に相互依存関係はありません。これは、メッセージにサービスアクティブ化(26–65)または非アクティブ化サービス(26–66)VSAが含まれている場合にも当てはまります。依存関係がないということは、authd が他の属性をうまく適用しなくても、 PPP は接続情報を PPP に送信し、PPP は VSA の内容をホームゲートウェイに送信します。
同様に、authdは、PPPが接続ステータスメッセージVSAの内容をリモートゲートウェイに正常に通信したかどうかに関係なく、他の属性を適用し、CoA応答を返します。これは、CoAに接続ステータスメッセージVSAのみが含まれている場合にも当てはまります。すべてのゲートウェイがこの機能で使用される LCP 拡張機能を受け入れるわけではないため、この機能が必要です。
メッセージとオプションの形式
図 1 は、接続更新要求メッセージと接続更新確認メッセージの形式を示しています。形式は同じですが、 表 1は、2 つのメッセージで一部のフィールド値が異なっていることを示しています。
フィールド |
接続更新要求 |
Connection-Update-Ack |
---|---|---|
コード |
0 (ベンダー固有) |
0 (ベンダー固有) |
識別子 |
ベンダー固有パケットの識別子 |
接続更新要求メッセージと同じ識別子。この値が一致しない場合、ルーターはエラーをログに記録し、パケットを破棄します。これにより、ゲートウェイが要求メッセージを受信しなかった場合と同様に、要求メッセージを再試行できます。 |
長さ |
パケット内のバイト数:12に接続ステータスメッセージオプションの長さを加えたもの |
接続更新-Ack パケットのバイト数:12 |
マジックナンバー |
ローカル PPP マジックナンバーのネゴシエートされた値 |
ローカル PPP マジックナンバーのネゴシエートされた値 |
組織固有識別子(OUI) |
00-21-59(ジュニパーネットワークス向け) |
00-21-59(ジュニパーネットワークス向け) |
種類 |
セッション更新の場合は 1 |
セッション確認の場合は 2。その他の値の場合、ルーターはエラーをログに記録し、はパケットを破棄します。これにより、ゲートウェイが要求メッセージを受信しなかった場合と同様に、要求メッセージを再試行できます。 |
値 |
TLV 形式の接続ステータス メッセージ オプション |
サポートされている値はありません |
PPP マジックナンバーの使用方法を設定できます。
PPP オプションを設定する
ignore-magic-number-mismatch
と、マジックナンバーの検証が妨げられます。PPPは、リクエストメッセージとAckメッセージのマジックナンバーの不一致を無視します。他の検証エラーがなければ、PPP は Connection-Update-Ack メッセージを受け入れます。PPP オプションを設定し
ignore-magic-number-mismatch
ない場合、マジックナンバーは検証を受けます。Ack メッセージのマジック ナンバーが LCP ネゴシエーション中に確立されたゲートウェイのマジック ナンバーと一致しない場合、ルーターはエラーをログに記録し、Connection-Update-Ack メッセージを無効な応答として破棄します。これにより、ゲートウェイが要求メッセージを受信しなかった場合と同様に、要求メッセージを再試行できます。
マジックナンバーの詳細については、 PPP キープアライブ交換中のPPPマジックナンバー検証の防止 を参照してください。
図 2 は、接続状況メッセージのオプションの形式を示しています。 表 2 に、フィールド値を示します。
フィールド |
値 |
---|---|
型 |
1 |
長さ |
オプション内のバイト数。2 にメッセージの長さを加えた値。メッセージの長さは 1 から 247 バイトです。 |
ステータスメッセージ |
接続ステータスメッセージ VSA の内容 |
PPPの動的プロファイルを設定する
動的プロファイルは、クライアント アクセス(インターフェイス、プロトコルなど)やサービス(IGMP など)の属性が含まれる設定の作成、更新、または削除を実行できるテンプレートとして機能します。動的プロファイルを使用すると、クライアント(最終的にクライアントのグループ)の共通の属性をすべて統合し、属性を同時に適用できます。
動的プロファイルを作成すると、ルーターのプロファイル ライブラリに保存されます。次に、 dynamic-profile
ステートメントを使用してインターフェイスにプロファイルをアタッチできます。PPPインターフェイスに動的プロファイルを割り当てるには、 階層レベルで ステートメント[edit interfaces interface-name unit logical-unit-number ppp-options]
を含めることができますdynamic-profile
。
[edit interfaces interface-name unit logical-unit-number ppp-options] dynamic-profile profile-name;
設定を監視するには、 コマンドを発行します show interfaces interface-name
。
動的プロファイルの詳細については、 Junos 加入者アクセス設定ガイドの 動的プロファイルの概要を参照してください。
動的プロファイルの作成については、 Junos加入者アクセス設定ガイドの 基本的な動的プロファイルの設定を参照してください。
PPPインターフェイスへの動的プロファイルの割り当てについては、 Junos 加入者アクセス設定ガイドの 静的PPP加入者インターフェイスへの動的プロファイルのアタッチを参照してください。
PPP加入者認証のための動的プロファイルの使用については、 PPP加入者向けの動的認証の設定を参照してください。
PPP 加入者の動的プロファイルは、このリリースの PPPoE インターフェイスでのみサポートされています。
PPP キープアライブ交換中の PPP マジックナンバー検証の防止
PPP マジック ナンバーは、LCP ネゴシエーション中にピア間でネゴシエートされます。ピアは異なるマジックナンバーを持っている必要があります。数字が同じ場合は、ローカル ピアから送信されたトラフィックにループバックが発生している可能性があることを示します。この場合、ローカルピアはリモートピアに新しい番号を送信します。リモートピアから返されたマジックナンバーが、ローカルピアから送信された最新の番号と異なる場合、その番号は合意されます。それ以外の場合、マジックナンバーの交換は、有効な(異なる)番号を受信するか、プロセスがタイムアウトするまで続行され、タイムアウトするとセッションはドロップされます。
番号が合意された後、ピアは PPP キープアライブ(エコー要求/エコー応答)パケットを交換するときに、それぞれのマジック ナンバーを含めます。パケット転送エンジンは、受信したマジックナンバーを各交換ごとに検証します。不一致は、リモート ピアから受信した PPP マジックナンバーが、LCP ネゴシエーション中に合意された値と一致しない場合に発生します。検証チェックで不一致があると判断された場合、パケット転送エンジンは失敗したエコーリクエストパケットをルーティングエンジンに送信します。有効なマジックナンバーを持つエコー応答が一定の間隔内に受信されない場合、PPP はこれをキープアライブ障害とみなし、PPP セッションを破棄します。
状況によっては、この動作は望ましくありません。一部のお客様の機器は、ローカルマジックナンバーをネゴシエートしません。代わりに、キープアライブパケットでルーターに送信するマジックナンバーとして任意の値を挿入します。デフォルトでは、この数は不一致として識別され、最終的にセッションはドロップされます。この結果は、パケット転送エンジンがマジックナンバー検証チェックを実行しないようにすることで回避できます。不一致が特定されないため、ルーターはリモートピアとPPPキープアライブパケットを交換し続けます。
動的PPPプロファイル、L2TP LNS動的プロファイル、またはL2TPグループプロファイルに適用されるPPPオプションの1つとしてステートメントを含めて ignore-magic-number-mismatch
、マジックナンバー検証チェックを無効にします。このステートメントを設定しても、LCPマジックナンバーネゴシエーションや、リモートピアマジックナンバーが予期されたネゴシエート番号である場合のキープアライブの交換には影響しません。
マジックナンバーの検証は行われないため、パケット転送エンジンは、ループバックまたはその他のネットワークの問題を示す、リモートピアがローカルピアのマジックナンバーを送信したかどうかを検出しません。LCP ネゴシエーションは正常に完了し、その時点ではループバックが存在していなかったため、これはありそうもない状況と考えられます。
パケット転送エンジンがマジックナンバーの不一致を検出しないように動的プロファイルを設定するには:
PPP オプションを設定します。
ルーターで終端される動的 PPP 加入者接続の場合:
[edit dynamic-profiles profile-name interfaces pp0 unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
LNS インラインサービスインタフェース上の動的トンネリング PPP 加入者の場合:
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit “$junos-interface-unit” ppp-options] user@host# set ignore-magic-number-mismatch
コマンドを使用して、マジックナンバーが無視されるかどうかを確認できます show ppp interface interface-name extensive
。
CPEデバイスへのRADIUSソースの接続ステータスの更新を構成する方法
RADIUS 発信元のメッセージを使用して、BNG がホーム ゲートウェイなどの CPE デバイスに透過的に転送する情報を伝えることができます。たとえば、この情報はアップストリーム帯域幅や、CPE デバイスが必要とするその他の接続速度パラメータなどです。
この機能を有効にすると、PPPは、RADIUS Access-AcceptメッセージまたはCoAメッセージのいずれかでauthdが受信した接続ステータスメッセージVSA(26-218)に対して動作できます。その後、PPPはVSAの内容をLCP接続更新リクエストメッセージでリモートピアに伝えます。このアクションを実行するには、次の条件を満たしている必要があります。
少なくとも最初のアドレスファミリーは正常にネゴシエートされ、セッションはアクティブです。
ルーター LCP はオープン状態です。
それ以外の場合、PPPはVSAに対して何のアクションも行いません。このオプションを有効にしない場合 lcp-connection-update
、PPP は authd からの通知を処理しますが、アクションは実行しません。
この機能は、CPE デバイスを使用する加入者に関連付けられた動的クライアント プロファイルで設定します。実際には、これをクライアントプロファイルの他の多くの機能に追加しています。この例では、この機能の特定の設定のみを示しています。また、この機能を使用するには、RADIUS サーバーで VSA 26-218 を設定する必要があります。これは、このドキュメントの範囲外です。
PPP加入者インターフェイスの動的プロファイルで接続ステータスの更新を設定するには、次の手順に従います。
PPP 論理インターフェイスに コマンドを使用して、LCP 接続の更新が成功したかどうかを判断できます show ppp interface extensive
。コマンドを使用して、関連する統計を show system subscriber-management statistics ppp
監視できます。
静的PPP加入者インターフェイスへの動的プロファイルのアタッチ
静的 PPP 加入者インターフェイスにダイナミック プロファイルをアタッチできます。PPP加入者がログインすると、指定された動的プロファイルがインスタンス化され、プロファイルで定義されたサービスがインタフェースに適用されます。
静的PPP加入者インターフェイスに動的プロファイルをアタッチするには、次の手順に従います。
静的 PPP 加入者設定の動的プロファイルへの移行の概要
このトピックでは、特定の静的で終了した IPv4 PPP 加入者設定を動的プロファイルを使用して動的構成に移行する際のいくつかの考慮事項について説明します。レガシーJunos OSリリース(Junos OSリリース15.1R4より前)のルーターで静的加入者を管理するサービスプロバイダは、拡張加入者管理を実行しているルーター(Junos OSリリース15.1R4以降のリリース)で静的加入者を動的プロファイルで管理されるように移行する必要があります。Junos OS リリース 18.2R1 以降、これらの静的サービス プロバイダーの設定を動的プロファイルに移行しやすくするために、いくつかの機能強化が追加されました。
ローカル認証
静的構成の一部のプロバイダーは、CHAP や PAP でさえも、認証プロトコルをサポートしていない CPE デバイスを使用する場合があります。プロバイダーは、静的 PPPoE 論理インターフェイス上の加入者を認証および許可するための基本的な方法として、PPPoE サービス名テーブルを使用する場合があります。サブスクライバの ACI または ARI がテーブル エントリに一致しない場合、PPP PADI および PADR パケットは通常ドロップされます。レガシーJunos OSリリースでは、認証方法に no-authentication が設定された加入者はサポートされません。
CPE が PAP や CHAP などの認証プロトコルをサポートしていない加入者の場合、ユーザ名とパスワードをローカルで設定できます。ルーターは、認証のためにRADIUSサーバーに接続するときに、これらの値を使用します。
ローカル認証用のユーザー名を設定するには、動的論理インターフェイスの PPP オプションに ステートメントを含め
username-include
ます。この名前は、MACアドレス、エージェント回線ID、エージェントリモートID、ドメイン名の1つ以上の属性に基づいて定義できます。既定では、ピリオド (.) は名前の要素間の区切り記号ですが、代わりに他の文字を定義することもできます。ローカル認証用のパスワードを設定するには、動的論理インターフェイスの PPP オプションに ステートメントを使用します
password
。
同じ動的プロファイルを使用して、認証プロトコルをサポートしない CPE とサポートする CPE の両方をサポートできます。
CPEから発信されたアドレスの割り当て
一部の静的構成では、RADIUS またはルーターのローカル アドレス プールを使用して加入者アドレスが割り当てられません。代わりに、CPE にはサブスクライバ用に設定された静的アドレスがあります。IPCPネゴシエーション中に、CPEはルーターにそのアドレスを加入者に割り当てるように要求します。
Junos OS Release 18.2R1以降、RADIUSサーバーの設定で、Framed-Route-Address属性[8]に255.255.255.255のワイルドカードアドレスを割り当てることができるようになりました。RADIUS がその値を持つ属性を返すと、 jppd は、別のアドレスを割り当てるのではなく、 IPCP configure-request メッセージでクライアントが提供する加入者 IP アドレス割り当てを自動的に受け入れます。
Tag2ルート属性
一部の設定では、静的 PPP 加入者インターフェイスが異なる VRF で設定されます。各 VRF 設定には、スタティック PPP 加入者インターフェイスをネクストホップ アドレスとしてポイントするスタティック ルートがあります。これらのルートには、tag2 属性が設定されている場合があります。MP-BGP がルートをアドバタイズする際に、適切なローカル プリファレンスとコミュニティを適用する必要があります。
Junos OSリリース18.2R1以降、RADIUSサーバーが加入者を認証するときに、フレームルート属性[22]にtag2属性を含めるように設定できます。
また、フレームルート属性からtag2値を取得するように動的プロファイルを設定する必要があります。そのためには、アクセスルートを動的にインスタンス化する際に使用する$junos-framed-route-tag2の定義済み変数を指定します。または、動的プロファイルを設定して、特定のアクセスルートプレフィックスに特定のtag2値を提供することもできます。
定義済み変数の詳細については、 Junos OS定義済み変数 を参照してください。
利点
ローカル認証では、CPE が PAP や CHAP などの認証プロトコルをサポートしていない場合に、加入者のパスワードとユーザ名をローカルに保存した認証が可能になります。
CPEから送信されたアドレスの割り当てにより、ルーターは、ローカルまたは外部から送信されたアドレスプールからアドレスを割り当てるのではなく、CPEによって要求された静的に設定された加入者IPアドレスを受け入れることができます。
tag2 属性を使用すると、ルートをより詳細に指定できます。
静的終端 IPv4 PPP 加入者の動的プロファイルでのローカル認証の設定
静的構成の一部のプロバイダーは、CHAP や PAP でさえも、認証プロトコルをサポートしていない CPE デバイスを使用する場合があります。プロバイダーは、静的 PPPoE 論理インターフェイス上の加入者を認証および許可するための基本的な方法として、PPPoE サービス名テーブルを使用する場合があります。加入者の ACI または ARI がテーブル エントリと一致しない場合、PPP PADI および PADR パケットは通常ドロップされます。
Junos OS リリース 18.2R1 以降、PAP や CHAP などの認証プロトコルをサポートしないクライアントに対して、ローカルでユーザー名とパスワードを設定できます。ルーターは、認証のためにRADIUSサーバーに接続するときに、これらの値を使用します。これは、拡張加入者管理を実行しているルーターで動的プロファイルを使用するための静的加入者の移行を支援します。
ローカル認証を構成するには:
すべてのオプションを含め、デフォルトの区切り文字を使用する場合、ユーザー名は次の形式になります。
mac-address.circuit-id.remote-id@domain-name
たとえば、ACI が aci1002、ARI が ari349、MAC アドレスが 00:00:5e:00:53:ff である次の設定例を考えてみます。
[edit dynamic-profiles profile-name interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" ppp-options local-authentication] user@host# set username-include circuit-id user@host# set username-include remote-id user@host# set username-include mac-address user@host# set username-include domain-name example.com user@host# set username-include delimiter - user@host# set password $ABC123$ABC123
この設定により、次の一意のローカルユーザ名のローカルパスワードは$ABC 123$ABC123になります。
0000.5e00.53ff-aci1002-ari349@example.com
静的終端 IPv4 PPP 加入者の動的プロファイルにおけるタグ 2 属性の設定
一部の設定では、PPP加入者はtag2属性を持つスタティックルートを使用します。例えば、MP-BGP は、ルートをアドバタイズするときに、tag2 を使用して適切なローカルプリファレンスとコミュニティを適用できるようにします。拡張加入者管理を実行しているルーターで動的プロファイルを使用するようにこれらの加入者を移行する場合、ルートに特定の値を設定するか、RADIUSサーバーから値を導き出すことで、tag2属性を設定できます。このサポートは、Junos OSリリース18.2R1で初めて利用可能になりました。
ルートに特定の tag2 値を設定するには:
値を指定します。
[edit dynamic-profiles profile-name routing-options access route prefix] user@host# set tag2 route-tag2
RADIUS サーバーから tag2 値を取得するには、以下を行います。
加入者を認証する際に、フレームルート属性 [22] に tag2 属性を含めるように RADIUS サーバーを設定します。設定情報については、RADIUS サーバーのマニュアルを参照してください。設定は次の例のようになります。
user@sub.example.com User-Password := "$ABC123" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Route += "198.51.100.0/24 203.0.113.27 tag 5 distance 10 tag2 3"
$junos-framed-route-tag2定義済み変数を使用して、Framed-Route属性からtag2値を動的に導出するように動的プロファイルを設定します。
[edit dynamic-profiles profile-name routing-options access route "$junos-framed-route-ip-address-prefix] user@host# set tag2 $junos-framed-route-tag2
$junos-framed-route-ip-address-prefix定義済み変数は、同様にFramed-Route属性からアクセスルートのIPv4アドレスプレフィックスを導き出します。
PPP 加入者向けの動的認証の設定
PPP クライアントがネットワークに動的にアクセスできるようにする PPP 認証を含む動的プロファイルを設定できます。CHAP 認証または PAP 認証のいずれかを指定できます。オプションで、ルーターが CHAP および PAP プロトコルをネゴシエートする順序を制御することもできます。
動的インターフェイスの場合、ルーターは単方向認証のみをサポートし、ルーターは常に認証として機能します。動的プロファイルでPPP認証を設定する場合、CHAP認証ではこのオプション challenge-length
がサポートされ、CHAPチャレンジ・メッセージの最小長と最大長を構成できます。CHAP 認証も PAP 認証も、 ステートメントを含む passive
他の構成オプションをサポートしていません。
PPP 加入者の動的プロファイルは、PPPoE インターフェイスでのみサポートされます。
PPP加入者インターフェイスの動的プロファイルで認証を設定するには、次の手順に従います。
CHAPチャレンジの長さの変更
ルーターが PPP クライアントに送信するチャレンジ ハンドシェイク認証プロトコル(CHAP)チャレンジ メッセージのデフォルトの最小長と最大長を変更できます。CHAP チャレンジ メッセージは、特定の PPP 加入者セッションに固有の情報を含み、ルーターとクライアント間の認証メカニズムの一部として使用され、ルーターにアクセスするクライアントの ID を確認します。
デフォルトでは、CHAP チャレンジの最小長は 16 バイトで、最大長は 32 バイトです。このデフォルトを上書きして、CHAP チャレンジの最小長と最大長を 8 バイトから 63 バイトの範囲で構成できます。
CHAP チャレンジの最小長と最大長の両方を少なくとも 16 バイトに構成することをお勧めします。
始める前に:
インターフェイスのCHAPプロトコルを設定します。
動的 PPP 加入者インターフェイスについては、 PPP 加入者向けの動的認証の設定を参照してください。
PPPカプセル化された静的インターフェイスについては、 PPPチャレンジハンドシェイク認証プロトコルの設定を参照してください。
CHAPチャレンジ・メッセージの最小長と最大長を構成するには:
例:最小 PPPoE 動的プロファイル
この例では、静的 PPPoE インターフェイスに使用される動的プロファイルの最小設定を示します。構成には スタンザを含める interfaces pp0
必要があります。
dynamic-profiles { ppp-profile-1 { interfaces { pp0 { unit "$junos-interface-unit"; } } } }