L2TPv2、L2TPv3、GRE、VPWS：ペイロードで選ぶ
L2TPv2、L2TPv3、GRE、MPLS VPWS を、運ぶペイロード、追加されるオーバーヘッド、実際に誰が転送を運用するかで比較します。
ほとんどのL2TP と GRE の議論は、名前が問題の異なる層にあるという同じ理由で崩れます。そのうち二つは自分のルーターで設定するカプセル化を指します。一つは誰か他の人が売るサービスを指します。エンドポイントが運ぶべきペイロードから始めれば、比較は機能の争いではなく短い結果のリストになります。
まずペイロード、次にプロトコル
実際にはペイロードは四つのうちの一つで、PPP セッション、生の Ethernet フレーム、IP パケット、あるいはプロバイダーに渡す MPLS フレームです。それぞれがアドレッシング、ブロードキャスト処理、障害検出に異なる要求を課します。このリストを間違えれば、カプセル化の調整では設計を救えません。
| Payload | Natural fit | What it needs |
|---|---|---|
| PPP session | L2TPv2 | UDP reachability, PPP negotiation on both ends |
| Ethernet frame | L2TPv3 or VPWS | Pseudowire signalling, matched MTU on both sides |
| IP packet | GRE, with IPsec alongside | Routed underlay, protocol type supported by both devices |
| MPLS frame | VPWS | Provider attachment circuits and demarcation points |
これらの行の外にあるものは、暗号化、圧縮、トラフィック整形などとして後から加えます。まず行を選んでください。
L2TPv2 と L2TPv3 は名前を共有するだけで、ほとんど他に共通点はありません
L2TPv2 は PPP セッションを IP ネットワーク越しに運ぶために存在するので、汎用的なフレーム転送というよりリモートアクセスプロトコルとして読めます。L2TPv3 はその考えを一般化し、制御接続がセッションを交渉して、各セッションは二つの IP エンドポイント間で定義されたレイヤー 2 接続を運びます。同じファミリー名でも、制御プロトコルもセッションモデルも異なります。L2TP とだけ書かれた要件は不完全で、間違ったバージョンからコピーしたテンプレートは交渉すらできません。
PPP が必要なら L2TPv2 がファミリーで唯一現実的な選択肢であり、ルーティングされたコア越しに Ethernet フレームが必要なら L2TPv3 の領域です。
転送の詳細はファイアウォールレビューで表面化する形で異なります。L2TPv3 は IP プロトコル 115 上、または UDP 内を、通常はポート 1701 で直接移動できますが、L2TPv2 は内部に PPP を抱えたまま UDP 1701 にとどまります。一方のバージョン向けに書いたポリシーが完全に正しく見えても、もう一方を落とすことがあります。
GRE はヘッダーであり、サービスではありません
GRE は任意のキーとシーケンスフィールドを伴う 四バイトのヘッダーでペイロードを包み、その結果を配送のために IP に渡します。ペイロードの意味については何も主張しないので、実装がそれらのプロトコルタイプをサポートしていれば IPv4、IPv6、Ethernet をトンネルできます。汎用と万能は同じではないので、実際のデバイスでプロトコルタイプとフラグメンテーションの挙動を確認してください。
複数のトンネルが一組のエンドポイントアドレスを共有するときに GRE が役立つのは、受信側がその値で多重分離するキーフィールドがあるからです。IPv4 上の GRE は追加オプションの前に約 24 バイトを消費し、すでに 1500 バイトのフレーム向けに用意された回線ではこれが効いてきます。GRE 単体では機密性を提供しないため、通常のパターンでは IPsec と組み合わせ、暗号の境界は IPsec に任せます。その組み合わせは機能しますが、MTU の予算は両方のヘッダーをカバーしなければなりません。
ペイロードが Ethernet のとき、GRE はトンネルを通じてマルチキャストとブロードキャストも運びますが、単純なユニキャスト IP トンネルにはできないことです。設計が GRE を選ぶ理由は、略語ではなく通常この性質です。
VPWS は購入するもので、設定するものではありません
仮想専用線サービスは、プロバイダーのネットワーク越しにポイントツーポイントのレイヤー 2 回線を提供します。あなたの接続回線はプロバイダーのエッジ装置で終端し、コアを横切る疑似回線はプロバイダーに属します。重要な問いは運用上のもので、境界がどこにあり、最初と最後のマイルを誰が所有し、プロバイダーが過大なフレームをどう扱うかです。
ここで比較が反転します。L2TPv3 と GRE は自分で端から端まで運用するものなので、自分の資格情報と自分のキャプチャでデバッグします。VPWS は引き渡しを伴う契約なので、障害はパケットキャプチャではなくチケットから始まります。どちらのモデルも完全に勝つわけではなく、失敗する場所が違い、選択は最後のマイルを所有したいかどうかにかかっています。
疑似回線のラベルスタックはプロバイダーのネットワーク内にとどまるので、目に見えるトンネルヘッダーのようには MTU の計算を変えません。
一行を選んで書き留めてください
決定を、ペイロード、カプセル化、転送の所有者という三つの部分からなる一文として記録します。次に、それを検証可能にする数字を添えます。
候補ごとに、回線上のオーバーヘッド、経路が受け入れる最大フレーム、MTU 問題を報告する最初のホップを書き留めます。両方のエンドポイントが、データシートのマーケティング用語だけでなく、選んだプロトコルタイプやセッションタイプをサポートすることを確認します。GRE キーと L2TPv3 セッション ID はその問題の互換的な解決策ではないため、来年二本目の回線が現れたときの多重化を決めておきます。その後、過大なフレームと通常のフレームを一本ずつ送れば、この組が、紙の上で良く見えた設計のほとんどを捕まえます。
トンネルを名前で比較しても、誰も決着できない議論が続くだけです。ペイロード、オーバーヘッド、所有権で比較すれば、一午後で決定が出て、後でそれを擁護する証拠も手に入ります。