このページの内容
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)を搭載したMXシリーズルーターでは、MPC/MIC上のパケット転送エンジンが、PPP加入者(クライアント)が開始してルーターに送信するリンク制御プロトコル(LCP)エコー要求パケットを処理し、応答します。LCPエコー要求パケットとLCPエコー応答パケットは、リンクが正常に機能しているかどうかを判断するのに役立つPPPキープアライブメカニズムの一部です。
以前は、LCPエコー要求パケットとLCPエコー応答パケットは、ルーティングエンジンによってMXシリーズルーターで処理されていました。LCPエコー要求パケットがルーティングエンジンではなくパケット転送エンジンによって処理されるメカニズムは、 PPP高速キープアライブと呼ばれます。
PPP高速キープアライブのメリット
PPP高速キープアライブは、処理のためにLCPルーティングエンジンパケットを送信することなく、パケット転送エンジンがPPP加入者からLCPエコー要求パケットを受信し、LCPエコー応答パケットで応答できるようにすることで、キープアライブ交換に必要な時間を短縮します。
PPP高速キープアライブは、ルーターの帯域幅を増やし、ルーティングエンジンがLCPエコーリクエストとエコー応答パケットを処理する必要がなくなることで、パフォーマンスを向上させてより多くの加入者をサポートします。
PPPファストキープアライブは、ネゴシエートされたマジックナンバーを使用して、ルーターへの潜在的なトラフィックループバックまたはネットワークの問題を特定します。また、PPPリモートピアがネゴシエートされた番号ではなく任意の番号を使用する場合など、望ましくないPPPセッションの終了を防ぐために必要に応じて、検証を無効にすることもできます。
PPP高速キープアライブ処理の仕組み
MPC/MICを搭載したMXシリーズルーターでは、パケット転送エンジンでPPP高速キープアライブ要求を処理できるようにするために、特別な設定は必要ありません。この機能はデフォルトで有効になっており、無効にすることはできません。
次のシーケンスは、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フィールドには、送受信したキープアライブパケット数、またはルーターが最後のキープアライブパケットを受信または送信してからの経過時間の統計情報は含まれません。
転送クラス設定の変更による影響
ルーティングエンジンによって生成されるアウトバウンドトラフィックのデフォルトのキュー割り当て(フォワーディングクラス)を変更するには、[edit class-of-service host-outbound-traffic]階層レベルでforwarding-class class-nameステートメントを含めることができます。
MPC/MICを搭載したMXシリーズルーターとPPPクライアント間で送信されるPPP高速(インライン)キープアライブLCPエコー要求およびLCPエコー応答パケットの場合、転送クラス設定の変更は、設定変更後に作成された新しいPPPオーバーイーサネット(PPPoE)、PPP-over-ATM(PPPoA)、およびL2TPネットワークサーバー(LNS)加入者セッションの両方、および既存のPPPoE、PPPoA、 設定変更前に確立されたLNS加入者セッション。
マジックナンバーの不一致を無視する
パケット転送エンジンは、受信したLCPエコー要求パケットのピアマジックナンバーを検証するときに、マジックナンバーが予期しないものかどうかをチェックします。受信した番号は、LCP ネゴシエーション中に合意されたリモート ピアの番号と一致する必要があります。リモートピア番号は、ローカルピア番号と異なる必要があります。それらが同じ場合は、ループバック状態(トラフィックがローカルピアにループバックしている)またはその他のネットワーク上の問題が存在することが想定されます。
検証チェックで不一致が存在する、つまり受信したリモートピア番号がネゴシエートされた番号と異なることが判明した場合、パケット転送エンジンは失敗したエコー応答パケットをルーティングエンジンに送信します。有効なマジックナンバーを持つエコー応答が一定間隔内に受信されない場合、PPPはこれをキープアライブ障害とみなし、PPPセッションを破棄します。
一部の顧客機器は、ローカルのマジックナンバーをネゴシエートせず、代わりにキープアライブパケットのルーターに送信するマジックナンバーとして任意の値を挿入する場合があります。この番号は不一致として識別され、最終的にセッションはドロップされます。Junos OSリリース18.1R1以降、マジックナンバー検証チェックを実行しないようにルーターを設定することで、この結果を回避できます。不一致が特定されないため、ルーターはリモートピアとPPPキープアライブパケットの交換を継続します。この動作を設定するには、L2TPグループプロファイル、ルーターで終了する動的PPP加入者接続の動的プロファイル、またはLNSの動的トンネルPPP加入者の動的プロファイルに ignore-magic-number-mismatch ステートメントを含めます。
関連項目
CPEデバイスへのRADIUS送信元接続ステータスの更新
Junos OSリリース20.2R1以降、RADIUSソースメッセージを使用して、BNGがホームゲートウェイなどのCPEデバイスに透過的に転送する情報を伝達できます。たとえば、この情報は、CPEデバイスが必要とするアップストリーム帯域幅またはその他の接続レートパラメーターである可能性があります。この機能は、できるだけ加入者の近くでトラフィック管理を動的に適用したい場合に便利です。
通常、RADIUS標準属性Reply-Message(18)を使用して、PPP認証中にこの情報をCPEデバイスに伝えることができます。ただし、すでにその属性を他の用途に使用している場合は、ジュニパーネットワークスのConnection-Status-Message VSA(26-4874-218)を使用することもできます。このVSAは、Reply-Message属性(18)の論理的な拡張であり、同じフォーマットとセマンティクスを持っています。
PPPは、LCPに対するジュニパーネットワークスのベンダー固有拡張を使用して、Connection-Status-Message VSAの内容をピアホームゲートウェイに送信します。PPP は、LCP Connection-Update-Request メッセージの Connection-Status-Message オプションにこの情報を含めます。
RADIUSは、以下の方法でConnection-Status-Message VSAをauthdに送信できます。
-
PPPセッションのネゴシエーションおよび承認中のRADIUS Access-Acceptメッセージ内
-
アクティブなPPPセッションのいつでもRADIUS CoAリクエストで
これらの方法の両方を、企業または家庭の加入者向けの任意のセッションに使用できます。Access-Acceptメッセージは、初期接続パラメーターを提供します。CoA機能により、セッションのライフサイクル全体を通じて、必要に応じて接続レートパラメーターを更新できます。Connection-Status-Message VSA で伝送される情報は、通常、動的サービスプロファイルや対応する ANCP Port Up メッセージなど、ローカル設定によって適用されるトラフィックレートです。
動的クライアントプロファイルに lcp-connection-update PPPオプションが含まれていない場合、PPPはauthdからの通知を処理しますが、アクションは実行しません。ルーター上のLCPがオープン状態でない場合、PPPはVSAに対して何のアクションも実行しません。
以下の手順では、RADIUS が Access-Accept メッセージで VSA を送信した場合に何が起こるかについて説明します。
-
認証プロセスは、RADIUSサーバーからのAccess-AcceptメッセージでConnection-Status-Message VSAを受信します。
-
認証プロセスは、Connection-Status-Message VSA を PPP(jpppd)に送信します。
-
PPP NCPネゴシエーションは、リモートゲートウェイPPPクライアントとルーター上のPPPの間で行われます。
-
ネゴシエーションが成功すると、ファミリーのアクティベーション要求が行われます。ファミリーがアクティブになると、PPP セッションはセッション アップ状態に入ります。
-
動的クライアントプロファイルに
lcp-connection-updatePPPオプションが含まれており、ルーター上のLCPがOpened状態の場合、PPPはLCP Connection-Update-Requestメッセージをゲートウェイに送信します。このメッセージには、Connection-Status-Message オプション内の VSA 情報が含まれています。-
ゲートウェイがLCP Connection-Update-Requestをサポートしている場合、ゲートウェイはLCP Connection-Update-Ackメッセージをルーターに返します。ホームゲートウェイLCPは、要求を受信したときにオープン状態になっていなければならず、そうでない場合は要求を破棄します。
-
ゲートウェイがLCP Connection-Update-Requestをサポートしていない場合、LCPコード拒否メッセージをルーターに返します。
注:ゲートウェイが応答しない場合、ルーターは更新要求を再試行します。PPPのデフォルト値である最大10回の再試行を使用し、試行の間に3秒の間隔を空けて再試行できます。
注:動的クライアントプロファイルに
lcp-connection-updatePPPオプションを含めない場合、PPPはauthdからの通知を処理しますが、アクションは実行しません。オプションが存在するが、ルーター上のLCPがオープン状態ではない場合、PPPはVSAに関して何のアクションも実行しません。 -
次の手順では、RADIUS が CoA リクエストで VSA を送信した場合に何が起こるかについて説明します。これは、NCPネゴシエーションがすでに成功しており、セッションがアクティブであることを前提としています。
-
認証プロセスは、RADIUSサーバーからのCoAリクエストでConnection-Status-Message VSAを受信します。
-
認証プロセスは、Connection-Status-Message VSA を PPP(jpppd)に送信します。
-
動的クライアントプロファイルに
lcp-connection-updatePPPオプションが含まれており、ルーター上のLCPがOpened状態の場合、PPPはLCP Connection-Update-Requestメッセージをゲートウェイに送信します。このメッセージには、Connection-Status-Message オプション内の VSA 情報が含まれています。-
ゲートウェイがLCP Connection-Update-Requestをサポートしている場合、ゲートウェイはLCP Connection-Update-Ackメッセージをルーターに返します。ホームゲートウェイLCPは、要求を受信したときにオープン状態になっていなければならず、そうでない場合は要求を破棄します。
-
ゲートウェイがLCP Connection-Update-Requestをサポートしていない場合、LCPコード拒否メッセージをルーターに返します。
注:ゲートウェイが応答しない場合、ルーターは更新要求を再試行します。PPPのデフォルト値である最大10回の再試行を使用し、試行の間に3秒の間隔を空けて再試行できます。
-
ホームゲートウェイがConnection-Update-Requestメッセージを受信できない場合、ルーターはメッセージの送信を再試行します。また、ゲートウェイからConnection-Update-AckまたはLCPコード拒否を受信しない場合、またはAckメッセージに問題がある場合も、ルーターはリクエストを再試行します。デフォルトの再試行間隔は 3 秒です。ルーターは、終了する前にデフォルトで最大10回メッセージを再試行します。適切なConnection-Update-Ackメッセージを受信せずにルーターがすべての再試行を使い果たした場合、PPP Code-Rejectメッセージを受信したかのようにメッセージをログに記録します。
RADIUS では、Access-Accept メッセージまたは CoA リクエストのいずれかに、Connection-Status-Message VSA の複数のインスタンスを含めることができます。この場合、authd は最初のインスタンスのみを使用し、その他のインスタンスは無視します。
Access-AcceptまたはCoA要求には、Connection-Status-Message VSA以外の属性が含まれている場合がありますが、VSAと他の属性の間には相互依存関係はありません。これは、メッセージにActivate-Service(26-65)またはDeactivate-Service(26-66)VSAが含まれている場合でも同様です。依存関係がないため、authdが他の属性を正常に適用できなくても、接続情報をPPPに送信し、PPPがVSAコンテンツをホームゲートウェイに送信します。
同様に、authd は、PPP が Connection-Status-Message VSA の内容をリモートゲートウェイに正常に伝達したかどうかに関係なく、他の属性を適用し、CoA 応答を返します。これは、CoAにConnection-Status-Message VSAのみが含まれている場合でも同様です。すべてのゲートウェイがこの機能で使用されるLCP拡張を受け入れるわけではないため、この機能が必要です。
メッセージとオプションのフォーマット
図 1 は、Connection-Update-Request メッセージと Connection-Update-Ack メッセージの形式を示しています。形式は同じですが、表 1に、2 つのメッセージで一部のフィールド値が異なることを示します。
| フィールド |
接続更新リクエスト |
接続更新Ack |
|---|---|---|
| コード |
ベンダー固有の場合は0 |
ベンダー固有の場合は0 |
| 識別子 |
ベンダー固有パケットの識別子 |
Connection-Update-Requestメッセージと同じ識別子。この値が一致しない場合、ルーターはエラーを記録し、パケットを破棄します。これにより、ゲートウェイが受信していないかのように、リクエストメッセージを再試行できます。 |
| 長さ |
パケット内のバイト数:12にConnection-Status-Messageオプションの長さを加えたもの |
Connection-Update-Ack パケットのバイト数:12 |
| マジックナンバー |
ローカルPPPマジックナンバーの交渉された値 |
ローカルPPPマジックナンバーの交渉された値 |
| 組織固有識別子(OUI) |
00-21-59 ジュニパーネットワークス |
00-21-59 ジュニパーネットワークス |
| 種類 |
セッション更新の1 |
session-ack の場合は 2。その他の値の場合、ルーターはエラーを記録し、パケットを破棄します。これにより、ゲートウェイが受信していないかのように、リクエストメッセージを再試行できます。 |
| 価値 |
TLV形式のConnection-Status-Messageオプション |
サポートされている値はありません |
PPPマジックナンバーの使用方法を設定できます。
-
ignore-magic-number-mismatchPPPオプションを設定すると、マジックナンバーが検証されなくなります。PPP は、リクエスト内のマジックナンバーと Ack メッセージの不一致を無視します。他に検証エラーがない場合、PPPはConnection-Update-Ackメッセージを受け入れます。 -
PPPオプション
ignore-magic-number-mismatch設定しない場合、マジックナンバーは検証されます。Ack メッセージのマジックナンバーが LCP ネゴシエーション中に確立されたゲートウェイのマジックナンバーと一致しない場合、ルーターはエラーを記録し、Connection-Update-Ack メッセージを無効な応答として破棄します。これにより、ゲートウェイが受信していないかのように、リクエストメッセージを再試行できます。
マジックナンバーの詳細については、「 PPPキープアライブ交換中にPPPマジックナンバーの検証を防止 する」を参照してください。
図 2 は、Connection-Status-Message オプションの形式を示しています。表2にフィールド値を示します。
| フィールド |
値 |
|---|---|
| タイプ |
1 |
| 長さ |
オプションのバイト数。2にメッセージの長さを加えた値です。メッセージの長さは1バイトから247バイトまで可能です。 |
| ステータスメッセージ |
connection-status-message 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キープアライブ(Echo-Request/Echo-Reply)パケットを交換する際に、それぞれのマジックナンバーを含めます。パケット転送エンジンは、交換ごとに受信したマジックナンバーを検証します。リモートピアから受信した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によって受信されたConnection-Status-Message VSA(26〜218)に対して動作することができます。次に、PPP は LCP Connection-Update-Request メッセージ内の VSA の内容をリモート ピアに伝達します。このアクションには、以下が満たされている必要があります。
少なくとも最初のアドレスファミリーは正常にネゴシエートされ、セッションはアクティブです。
ルーターLCPはオープン状態です。
それ以外の場合、PPPはVSAに対して何のアクションも実行しません。 lcp-connection-update オプションを有効にしない場合、PPPはauthdからの通知を処理しますが、アクションは実行しません。
この機能は、CPEデバイスを使用している加入者に関連付けられた動的クライアントプロファイルで設定します。実際には、クライアントプロファイルの他の多くの機能にこれを追加しています。この例では、この機能の具体的な設定のみを示しています。この機能を使用するには、RADIUSサーバーでVSA 26-218を設定する必要もあります。これは、このドキュメントの範囲外です。
PPP 加入者インターフェイスの動的プロファイルで接続ステータスの更新を設定するには:
PPP 論理インターフェイスの show ppp interface extensive コマンドを使用して、LCP 接続の更新が成功しているかどうかを判断できます。 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 リリースでは、認証方法に 認証なし が設定された加入者には対応していません。
CPEがPAPやCHAPなどの認証プロトコルをサポートしていない加入者の場合、ユーザー名とパスワードをローカルで設定できます。ルーターは、認証のために RADIUS サーバーに接続するときにこれらの値を使用します。
ローカル認証のユーザー名を設定するには、動的論理インターフェイスのPPPオプションに
username-includeステートメントを含めます。MACアドレス、エージェント回線ID、エージェントリモートID、ドメイン名の1つ以上の属性に基づいて名前を定義できます。デフォルトでは、ピリオド(.)は名前の要素間の区切り文字ですが、代わりに他の文字を定義することもできます。ローカル認証のパスワードを設定するには、動的論理インターフェイスのPPPオプションに
passwordステートメントを含めます。
同じ動的プロファイルを使用して、認証プロトコルをサポートしないCPEとサポートするCPEの両方をサポートできます。
CPE送信元アドレス割り当て
一部の静的構成では、ルーターの RADIUS またはローカル アドレス プールを使用して加入者アドレスが割り当てられません。代わりに、CPEには加入者用に設定された静的アドレスがあります。IPCP ネゴシエーション中、CPE はそのアドレスを加入者に割り当てるようにルーターに要求します。
Junos OSリリース18.2R1以降、RADIUSサーバーの設定でFramed-Route-Address属性[8]にワイルドカードアドレス255.255.255.255を割り当てることができます。RADIUS がその値を持つ属性を返すと、jpppd は別のアドレスを割り当てるのではなく、IPCP 設定リクエストメッセージでクライアントから提供された加入者 IP アドレスの割り当てを自動的に受け入れます。
Tag2ルート属性
一部の設定では、静的PPP加入者インターフェイスが異なるVRFに設定されています。各VRF設定には、ネクストホップアドレスとして静的なPPP加入者インターフェイスを指す静的ルートがあります。これらのルートには、tag2属性が設定されている場合があります。MP-BGPは、ルートをアドバタイズする際に、適切なローカルプリファレンスとコミュニティを適用する必要があります。
Junos OSリリース18.2R1以降、加入者を認証する際に、Framed-Route属性[22]にtag2属性を含めるようにRADIUSサーバーを設定できます。
また、Framed-Route属性から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: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加入者の動的プロファイルでのTag2属性の設定
一部の設定では、PPP加入者はtag2属性を持つスタティックルートを使用します。例えば、MP-BGPはタグ2を使用して、ルートをアドバタイズする際に適切なローカルプリファレンスとコミュニティを適用できるようにします。拡張加入者管理を実行しているルーターで動的プロファイルを使用するようにこれらの加入者を移行する場合、ルートに特定の値を設定するか、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値を導き出すには:
RADIUSサーバーが加入者を認証する際に、Framed-Route属性[22]にtag2属性を含めるように設定します。設定情報については、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)チャレンジメッセージのデフォルトの最小長と最大長を変更できます。特定のPPP加入者セッションに固有の情報を含むCHAPチャレンジメッセージは、ルーターとクライアント間の認証メカニズムの一部として使用され、ルーターにアクセスするためのクライアントの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";
}
}
}
}
加入者管理のためのPPP設定の検証と管理
変更履歴テーブル
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。