Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

加入者アクセス向けL2TPの概要

加入者アクセス向けL2TPの概要

レイヤー 2 トンネリング プロトコル(L2TP)は、ポイントツーポイント プロトコル(PPP)をネットワーク上でトンネリングできるようにするクライアントサーバー プロトコルです。L2TPは、PPPなどのレイヤー2パケットをカプセル化し、ネットワークを介して送信します。アクセスデバイス上に設定されたL2TPアクセスコンセントレータ(LAC)は、リモートクライアントからパケットを受信し、リモートネットワーク上のL2TPネットワークサーバー(LNS)に転送します。LNSは、リモートクライアントからLACによってトンネリングされたPPPセッションの論理終端ポイントとして機能します。 図1 は、単純なL2TPトポロジーを示しています。

図1:典型的なL2TPトポロジー Network architecture diagram showing data flow from customer premises equipment to the internet, including access node, aggregation, PPPoE, LAC, L2TP tunnel, LNS, provider AAA servers, and internet.

L2TPは、ケーブルやxDSLなどのアクセス技術の終端を、PPPの終端およびその後のネットワークへのアクセスから分離します。この分離により、パブリックISPは、アクセス技術を競争力のある地元の交換キャリア(CLEC)にアウトソーシングすることができます。L2TPは、ISPにVPNサービスを提供する機能を提供します。民間企業は、リモートワーカーのアクセス技術への投資を削減または回避できます。

LACがリモートクライアントからパケットを受信し、レイヤー2でLNSに直接転送するPPPパススルーモードでLACとして機能するようにルーターを設定できます。LNSではPPPセッションが終了します。このLAC実装は、動的または静的論理インターフェイスを介したPPPoE(Point-to-Point Protocol over Ethernet)加入者のみをサポートします。 図2 は、L2TPパススルー接続のプロトコル層スタッキングを示しています。

図2:パススルーモードにおけるL2TP加入者のプロトコルスタッキング Diagram of L2TP network architecture showing data flow between Subscriber, LAC, and LNS with tunnel binding.
注:

MXシリーズルーターでは、LACおよびLNS機能はMPCでのみサポートされています。これらは、どのサービスPICまたはMS-DPCでもサポートされていません。L2TPのMPCサポートの詳細については、MXシリーズインターフェイスモジュールリファレンスを参照してください

特定のM Seriesルーターは、サービスPICでLNS機能をサポートしています。M SeriesルーターでのL2TP実装の詳細については、 L2TPサービス設定の概要を参照してください。

LACは、AAA認証パラメーターに基づいてトンネルを動的に作成し、IP/ユーザーデータグラムプロトコル(UDP)を介してL2TPパケットをLNSに送信します。トラフィックはL2TP sessionで移動します。トンネルは1つ以上のセッションのアグリゲーションです。また、AAAが使用するドメインマップをプロビジョニングして、LAC上のPPPoE加入者をトンネル化するか終了するかを決定できます。LNSにトンネリングされた各PPP加入者とL2TPセッションの間には、1対1のマッピングが存在します。

LNSがMXシリーズルーターの場合、MPC上のLACに面するピアインターフェイスは、トンネルエンドポイント間でIPパケットを交換するためのIPアドレスを提供します。ルーティングエンジンは、L2TPトンネルを維持します。パケット転送エンジンは、1つ以上のインラインサービス(si)インターフェイスをホストします。これらのインターフェイスは仮想物理インターフェイスのように機能し、LNS上でL2TPセッションを 固定 します。 si インターフェイスは、特別なサービスPICを必要とせずにL2TPサービスを可能にします。最後に、別のインターフェイスを使用して、インターネットとの間で加入者データを送受信します。

トンネルの特性は、設定したトンネルプロファイル、またはLACでアクセス可能なAAAサーバーからのRADIUSトンネル属性およびVSA(ベンダー固有属性)のいずれかに由来します。ドメインマップにトンネルプロファイルを含めることで、RADIUS認証が行われる前にトンネルプロファイルを適用できます。RADIUS標準属性とVSAを使用して、ドメインマップ内のトンネルプロファイルによって設定された特性の一部またはすべてを上書きできます。または、RADIUS ログインで RADIUS トンネル グループ VSA [26-64] が指定されている場合、RADIUS 自体がトンネル プロファイルを適用できます。

注:

L2TP は GRE トンネルではサポートされていません。

サービスプロバイダのAAAサーバー(LNSからアクセス可能)上の加入者プロファイルの仮想ルーターVSA [26-1]は、L2TPセッションがLNSで立ち上げられるルーティングインスタンスを決定します。このVSAが存在しない場合、AAAサーバーにはトンネルがLNSで終端するルーティングインスタンスからしかアクセスできないため、加入者セッションはトンネルと同じルーティングインスタンスで起動します。

この動作は、仮想ルーターVSAがない場合にデフォルトのルーティングインスタンスで起動するDHCPおよびトンネリングされていないPPPoE加入者の場合とは異なります。L2TP加入者の場合、加入者セッションをトンネルルーティングインスタンスとは異なるルーティングインスタンスで立ち上げたい場合、この加入者プロファイルにこのVSAを含める必要があります。

リリース 17.4R1 以降Junos OS、LNS が RADIUS サーバーに Access-Request メッセージを送信するときに、以下のRADIUS属性が含まれます。

  • トンネルタイプ (64)

  • トンネルミディアムタイプ (65)

  • トンネルクライアントエンドポイント (66)

  • トンネルサーバーエンドポイント (67)

  • 接続-トンネル接続 (68)

  • トンネル割り当てID (82)

  • トンネルクライアント認証ID(90)

  • トンネルサーバー認証ID(91)

以前のリリースでは、LNSはRADIUSサーバーに送信するアカウンティングレコードにのみこれらの属性を含めていました。Access-Requestメッセージでは、RADIUSサーバー上でLACからLNSへのセッションを関連付けるために使用できます。

LACは、特定のRADIUS VSAに基づいてセキュアなポリシーを作成し、RADIUS属性を使用してトラフィックをミラーリングする加入者を特定する、RADIUS開始のミラーリングをサポートしています。(この機能は、MXシリーズルーターに設定されたLNSではサポートされていません。)

LACとLNSは、統合型ISSUをサポートしています。アップグレードが開始されると、LACは進行中のL2TPネゴシエーションを完了しますが、アップグレードが完了するまで新しいネゴシエーションは拒否します。アップグレード中に、新しいトンネルやセッションは確立されません。加入者のログアウトはアップグレード中に記録され、アップグレード完了後に完了します。

L2TPの用語

表1に 、L2TPの基本的な用語を示します。

表1:L2TPの条件

用語

説明

AVP

属性値ペア(AVP)—整数で表される一意の属性と、属性によって識別される実際の値を含む値の組み合わせ。

電話をかける

リモート システムと LAC 間の接続(または接続の試行)。

LAC

L2TPアクセスコンセントレータ(LAC)—L2TPトンネルエンドポイントの片側として機能し、LNSのピアとなるノード。LACはLNSとリモートシステムの間に位置し、それぞれとの間でパケットを転送します。

LNS

L2TPネットワークサーバー(LNS)—L2TPトンネルエンドポイントの片側として機能し、LACのピアとなるノード。LNSは、LACによってリモートシステムからトンネリングされているPPP接続の論理終端点です。

ピア

L2TPのコンテキストでは、LAC、またはLNSのいずれかです。LACのピアはLNSであり、その逆も同様です。

プロキシ認証

LNSに代わってLACが実施するPPP事前認証。プロキシデータは、認証タイプ、認証名、および認証チャレンジなどの属性を含む認証認証データによって LNS に送信されます。LNSから認証結果が返されます。

プロキシLCP

LNSに代わってLACが実行するリンク制御プロトコル(LCP)ネゴシエーション。プロキシは、クライアントと最後にやり取りした設定属性などの属性を含む、LACからLNSに送信されます。

リモートシステム

リモートアクセスネットワークに接続されたエンドシステムまたはルーター。これは、コールの発信元または受信者です。

セッション

リモート システムと LNS の間でエンドツーエンドの PPP 接続が確立されたときに、LAC と LNS の間に作成される論理接続。

注:

確立されたL2TPセッションとそれに関連するPPP接続の間には、1対1の関係があります。

トンネル

制御接続と 0 以上の L2TP セッションで構成される LAC-LNS ペア間の接続。

L2TPの実装

L2TPは、4つのレベルで実装されます。

  • 送信元—LACとして機能するローカルルーター。

  • 宛先—LNSとして機能するリモートルーター。

  • トンネル—LACとLNS間の直接パス。

  • セッション—トンネル内のPPP接続。

ルーターが宛先、トンネル、セッションを確立したら、L2TPトラフィックを制御できます。宛先を変更すると、その宛先へのすべてのトンネルとセッションに影響します。トンネルを変更すると、そのトンネル内のすべてのセッションに影響します。例えば、宛先を閉じると、その宛先へのすべてのトンネルとセッションが閉じられます。

LACでの一連のイベント

LACとして機能するルーターは、次のように宛先、トンネル、セッションを動的に作成します。

  1. クライアントは、ルーターとのPPP接続を開始します。

  2. ルーターとクライアントは、LCP(リンク制御プロトコル)パケットを交換します。LACはLNSを代表して交渉します。これは プロキシLCPと呼ばれます。

  3. LACは、LNSに代わってクライアントを認証します。これは プロキシ認証と呼ばれます。ドメイン名またはRADIUS認証に関連するローカルデータベースのいずれかを使用して、ルーターはPPP接続を終了するかトンネル化するかを決定します。

  4. セッションをトンネル化する必要があるとルーターが判断した場合、以下を実行します。

    1. 新しい宛先を設定するか、既存の宛先を選択します。

    2. 新しいトンネルを設定するか、既存のトンネルを選択します。

      共有シークレットがトンネルプロファイルまたはRADIUS属性のTunnel-Password [69]のいずれかで構成されている場合、トンネルの設定方法に応じて、トンネルの設定方法に応じて、確立フェーズ中にトンネルの認証にシークレットが使用されます。LACは、LNSに送信されるSCCRQメッセージにチャレンジAVPを含めます。LNS は、SCCRP メッセージでチャレンジ応答 AVP を返します。LNSからの応答がLACが期待する値と一致しない場合、トンネル認証は失敗し、トンネルは確立されません。

    3. 新しいセッションを開きます。

  5. ルーターは、LCPネゴシエーションと認証の結果をLNSに転送します。

これで、クライアントとLNSの間にPPP接続が存在します。

注:

L2TPヘッダーの可変長オプションのオフセットパッドフィールドのサイズが大きすぎる場合、ルーターは受信したパケットを破棄します。ルーターは、オフセットパッドフィールドが最大16バイトのパケットを常にサポートしており、ヘッダーのその他の情報によっては、より大きなオフセットパッドフィールドをサポートする場合があります。この制限は、可能性は低いですが、L2TPパケットの過剰な廃棄の原因となる可能性があります。
注:

LACがPPPセッションを終了すると、PPP切断原因が生成され、Call-Disconnect-Notify(CDN)メッセージをLNSに送信するときにPPP切断原因コード(AVP 46)にこの情報が含まれます。コード値は0で、利用可能な情報がないグローバルエラーを示します。

LNSでのイベント順序

LNSとして機能するルーターは、次のように設定できます。

  1. LACは、ルーターがLNSとして機能するトンネルを開始します。

  2. LNSは、このLACを持つトンネルが有効であることを検証します:宛先が設定されており、ホスト名とトンネルパスワードが正しい。

  3. LNSは、LACとのトンネル設定を完了します。

  4. LACはセッションを設定し、LNSへのセッション要求を開始します。

  5. LNSは、PPPセッションを固定するために、静的インターフェイスを使用するか、動的インターフェイスを作成します。

  6. それらが有効で存在する場合、LNSはプロキシLCPとプロキシ認証データを受け入れ、PPPに渡します。

  7. PPP は、プロキシ LCP が存在する場合それを処理し、プロキシ LCP が許容可能な場合は、LCP を再ネゴシエートすることなく LNS 上の LCP をオープン状態にします。

  8. PPPは、プロキシ認証データが存在する場合それを処理し、検証のためにデータをAAAに渡します。(データが存在しない場合、PPP はピアからデータを要求します)。

    注:

    プロキシLCPが存在しない場合、または受け入れられない場合、LNSはピアとLCPをネゴシエートします。LNSでLCP再ネゴシエーションが有効になっている場合、LNSは事前にネゴシエートされたLCPパラメーターをすべて無視し、LCPパラメーターとPPPクライアントとのPPP認証の両方を再ネゴシエートします。

  9. LNSは、認証結果をピアに渡します。

L2TP制御メッセージの再送信

L2TPピアは、ピアデバイスに送信する必要がある制御メッセージのキューを維持します。ローカルピア(LACまたはLNS)は、メッセージを送信した後、リモートピアからの応答を待ちます。応答を受信しない場合、ローカルピアがメッセージを再送信します。この動作により、リモートピアがメッセージに応答する時間を増やすことができます。

再送信の動作は、以下の2つの方法で制御できます。

  • 再送信回数—未確認メッセージがローカルピアによって再送信される回数を設定できます。カウントを増やすと、リモートピアが応答する機会が増えますが、制御トラフィックの量も増加します。すでに確立されているトンネルについては、[edit services l2tp tunnel]階層レベルにretransmission-count-establishedステートメントを含めます。まだ確立されていないトンネルの場合は、retransmission-count-not-establishedステートメントを含めます。

  • 再送信間隔—ローカルピアが制御メッセージに対する最初の応答を待機する時間を設定できます。最初のタイムアウト間隔内に応答が受信されない場合、再送信タイマーは、連続する再送信の間隔を最大16秒まで2倍にします。間隔を大きくすると、リモートピアの応答時間が長くなりますが、利用できない可能性のあるピアにより多くのリソースを費やすことになります。[edit services l2tp tunnel]階層レベルにminimum-retransmission-intervalステートメントを含めます。

ローカル ピアは、次のいずれかが発生するまで制御メッセージの再送信を続行します。

  • 現在の待機期間内に応答が受信されます。

  • 再送信回数の最大に達しました。

最大カウントに達しても応答が受信されない場合、トンネルとそのすべてのセッションがクリアされます。

注:

最大間隔である16秒に達しても、再送信は停止しません。ローカルピアは、その後の再送信のたびに16秒間待機し続けます。

以下の例は、さまざまな状況での再送信動作を説明しています。

  • 例1 - 再送信カウントは3で、最小再送信間隔は1秒です。

    1. ローカルピアは、制御メッセージを送信します。

    2. ローカルピアは1秒待機しますが、応答は受信されません。

    3. ローカルピアは制御メッセージを再送信します。今回が初回再送信です。

    4. ローカルピアは2秒待ちますが、間隔が切れる前に応答を受信します。

    5. 間隔内に応答が受信されたため、再送信は停止します。

  • 例 2 - 再送信カウントは 2 で、最小再送信間隔は 8 秒です。

    1. ローカルピアは、制御メッセージを送信します。

    2. ローカルピアは8秒待ちますが、応答は受信されません。

    3. ローカルピアは制御メッセージを再送信します。今回が初回再送信です。

    4. ローカルピアは16秒待機しますが、応答は受信されません。

    5. ローカルピアは制御メッセージを再送信します。今回が2回目の再送信です。

    6. 間隔が16を超えることができないため、ローカルピアは再び16秒待ちますが、応答は受信しません。

    7. 再送信カウントの最大数である2に達したため、再送信は停止します。

    8. トンネルとそのすべてのセッションがクリアされます。

L2TP制御メッセージの再送信属性の設定

ローカルピアがメッセージを再送信する回数と、再送信までの応答待ち時間を設定することで、未確認のL2TP制御メッセージの再送信を制御できます。

L2TPピアは、ピアデバイスに送信する必要がある制御メッセージのキューを維持します。ローカルピア(LACまたはLNS)は、メッセージを送信した後、リモートピアからの応答を待ちます。最小再送信間隔内に応答が受信されない場合、ローカルピアはメッセージを再送信し、再送信間隔の2倍を待ちます。メッセージを再送信するたびに、ピアは待機時間を2倍にし、最大16秒まで待ちます。

応答を受信しない場合、ローカルピアは再送信回数が再送信回数と一致するまでメッセージを送信し続けます。この場合、再送信は停止し、トンネルとそのすべてのセッションがクリアされます。

ベストプラクティス:

これらのステートメントをサポートしていないJunos OSリリースにダウングレードする前に、[edit services l2tp tunnel]階層レベルでno retransmission-count-establishedステートメントとno retransmission-count-non-establishedステートメントを含めて、機能を明示的にアンコンフィグレーションすることをお勧めします。
ベストプラクティス:

LACとして設定されたMXシリーズルーターで統合型稼働中ソフトウェアアップグレード(統合型ISSU)が行われている間、LACはLNSからの制御メッセージに応答しません。これにより、LAC L2TPセッションがドロップされる可能性があります。この状況を回避するには、LNS の最大再送信カウントを 16 以上に設定してください。

確立されたトンネルの最大再送信カウントを設定するには:

  • カウントを設定します。

確立されていないトンネルの最大再送信カウントを設定するには:

  • カウントを設定します。

再送信の最小間隔を設定するには:

  • 間隔を設定します。

例えば、以下の設定では、確立されたトンネルの再送信カウントを最大3、最小再送信間隔を2秒に指定しています。

このサンプル設定では、LACまたはLNSから送信された各制御メッセージに以下のシーケンスが適用されます。

  1. ローカルピアは制御メッセージを送信し、リモートピアからの応答を待ちます。
  2. 最小2秒以内に応答が受信されなかった場合、ローカルピアがメッセージを再送信します。今回が初回再送信です。
  3. 4秒以内に応答を受信しない場合、ローカルピアがメッセージを再送信します。今回が2回目の再送信です。
  4. 8秒以内に応答を受信しない場合、ローカルピアがメッセージを再送信します。最大カウントに達したため、これが3回目で最後の再送信です。
  5. 16秒以内に応答を受信しない場合、トンネルとそのすべてのセッションがクリアされます。

SNMP統計収集用のトンネルおよびグローバルカウンターの有効化

デフォルトでは、L2TP統計のSNMPポーリングは無効になっています。その結果、 表2 に示すL2TPトンネルとグローバルカウンターのデフォルト値はゼロです。

表2:L2TP統計のSNMPカウンター

カウンタ名

タイプ

jnxL2tpTunnelStatsDataTxPkts

トンネル

jnxL2tpTunnelStatsDataRxPkts

トンネル

jnxL2tpTunnelStatsDataTxBytes

トンネル

jnxL2tpTunnelStatsDataRxBytes

トンネル

jnxL2tpStatsペイロードRxオクテット

グローバル

jnxL2tpStatsPayloadRxPkts

グローバル

jnxL2tpStatsペイロードTxオクテット

グローバル

jnxL2tpStatsPayloadTxPkts

グローバル

[edit services l2tp]階層レベルでenable-snmp-tunnel-statisticsステートメントを含めることで、これらの統計の収集を有効にすることができます。有効にすると、L2TPプロセスは1000セッションにわたって30秒ごとにこれらの統計情報をポーリングします。統計の潜在的な年齢は、加入者セッションの数とともに増加します。セッション数が減少すると、データはより迅速に更新されます。例えば、60,000セッションの場合、これらの統計はどれも30分を超えていきません。

ベストプラクティス:

これらのカウンターを有効にし、RADIUS の暫定アカウンティング更新を使用すると、システム負荷が増加する可能性があります。SNMP統計情報のみを使用する場合は、これらのカウンターを有効にすることをお勧めします。

SNMP の L2TP 統計収集を有効にするには:

  • 統計情報の収集を有効にします。

加入者アクセスのためのL2TPの検証と管理

目的

L2TPトンネルとセッションに関する情報を表示またはクリアします。

ベストプラクティス:

allオプションは、L2TP加入者の一括ログアウトを実行する手段として使用することを意図したものではありません。実稼働環境では、clear services l2tp destination、clear services l2tp session、またはclear services l2tp tunnelステートメントとともにallオプションを使用しないことをお勧めします。すべての加入者を一度にクリアするのではなく、インターフェイス、トンネル、または宛先エンドポイントに基づいて、より小さなグループの加入者をクリアすることを検討してください。

アクション

  • L2TPトンネル、セッション、エラー、制御パケットとデータパケットの概要を表示するには:

  • L2TP宛先を表示するには:

  • すべてのL2TP宛先をクリアするには:

  • 宛先に属するすべてのL2TPトンネル、指定されたローカルゲートウェイアドレスに属するトンネル、指定されたピアゲートウェイアドレスに属するトンネルの統計をクリアするには:

  • L2TPセッションを表示するには:

  • すべてのL2TPセッション、指定されたローカルセッションIDを持つセッション、またはIPアドレスまたは名前で指定されたローカルゲートウェイに関連付けられたセッションをクリアするには:

  • すべてのL2TPセッション、指定されたローカルセッションIDを持つセッション、またはIPアドレスまたは名前で指定されたローカルゲートウェイに関連付けられたセッションの統計をクリアするには:

  • L2TPトンネルを表示するには:

  • すべてのL2TPトンネル、指定されたローカルトンネルIDを持つトンネル、またはIPアドレスまたは名前で指定されたローカルゲートウェイに関連付けられたトンネルをクリアするには、トンネルをクリアします。

  • すべてのL2TPトンネル、指定されたローカルトンネルIDを持つトンネル、またはIPアドレスまたは名前で指定されたローカルゲートウェイに関連付けられたトンネルの統計をクリアするには、トンネルをクリアします。

関連ドキュメント