令和6年（2024年）ネスペ午後Ⅰ　問Ⅱ　解答解説

  1. 設問１
    1. （１）ア：カスタマー　イ：再配布　ウ：DMZ　エ：eBGP　オ：プライベート　カ：ポリシーベース
  2. 設問２
    1. （１）a: 10.3.0.0/16　b:64500 64500
  3. 設問３
    1. （２）タイプ：Type５　機器：ルータ３
  4. 設問４
    1. （１）IPsecトンネル確立のためのIPアドレス、IPsecトンネル確立のための鍵情報
    2. （２）IPsecトンネルに障害があった場合の検出を高速にする
  5. さらに深いVersion………………………………
    1. p.9 支店が追加されたら、どのような変更があるの？ｰｰｰｰｰｰｰｰｰｰｰｰｰｰ
    2. p.9 現行構成における課題と、SD-WAN導入による改善点
    3. Q.どうやってSD-WANはゼロタッチプロビジョニングを実現しているの？
    4. Q.従来のZTPとSD-WANのZTPの違いは？
    5. Q.ってか、、そもそもWANって何？
    6. Q.SD-WANのインターネット通信に対するアプローチはどういう感じ？
    7. Q.もし回線が1つしかなかったらSD-WANを導入する意味なくね？
    8. Q.では、回線1本でもSD-WANを入れるメリットとは何か？
    9. p.9 MPLSとは?———————
    10. p.9 MPLSとMPLS VPNの違いは？
    11. Q.MPLS VPNのフローは？———————–
    12. 2. データプレーン（実際の通信フロー）
    13. LDPのメカニズム＆フロー
      1. ステップ1：アンダーレイIGP（OSPF/IS-IS）の確立
      2. ステップ2：LDPによるトランスポートラベル（外側）の配布
      3. ステップ3：PEルータでのVRF・RD・RTの設定
      4. ステップ4：CE ➔ PE 間の経路学習
      5. ステップ5：PE1でのVPNラベル（内側）自動採番とMP-BGP広告
    14. ▼外側ラベルの配布メカニズム＆フロー
    15. ▼内側ラベルの配布メカニズム＆フロー
    16. Q.なんでRDタグが必要なの？
    17. Q.もしRDがないと？
    18. Q.CEルータとPEルータはどうやってつながっているの？
    19. Q.再配布のループ防止方法は？——————
      1. 手法1：ルートタグ（Route Tag）を使う方法【推奨・最もスマート】
      2. 手法2：ディストリビューションリスト（Prefix-list）を使う方法
    20. p.12 SD-WANコントローラとエッジルータのmTLS通信とは?——————
    21. Q.OMPってなに?————————
    22. Q.なんでわざわざOMPを使うの？
    23. Ｑ．OMPで配布する情報とそれ以外で配布する情報の違いは？
    24. Q.SD-WANにおけるIPsec構築フロー
    25. Q.なぜ DMVPN では IKE をやめられなかったのか？
    26. Q.なぜ SD-WAN では IKE を捨てられたのか？
    27. p.12 なぜSD-WANはVRFが必要なの？
    28. Q.もし、VRFを使わないと何が起きるの？
      1. 制御プレーンとデータプレーンのループ（矛盾）が生まれる
    29. Q.なぜ普通のルーター（従来のIPsec）はVRFを使わずにループしないのか？
    30. Q.SD-WANにおけるBFDとは？——-

設問１

（１）ア：カスタマー　イ：再配布　ウ：DMZ　エ：eBGP　オ：プライベート　カ：ポリシーベース

ア：カスタマー/イ：再配布/エ：eBGP/オ：プライベート
　この空欄に関しては知識問題であるため説明は割愛

ウ：DMZ　

問題の雰囲気的に「インターネット・OSPF・配布」という単語から、つい「デフォルトルート」と回答してしまうかもしれない。しかし、その単語をいれると「デフォルトルートのサブネットを～」と書いてあり、文章として成立しなくなってしまう。デフォルトルートは特定のサブネットではないから！
文脈として可能性が最も高いのは「インターネットアクセス、特定のサブネット、HTTP/HTTPS」という単語からプロキシサーバが配置されているDMZという回答になる。

Q.DMZではなく、プロキシサーバ単体で広告すれば？
DMZのプレフィックスよりもプロキシサーバ単体でよくね？
A.大抵の場合、DMZには複数の機器が収容されている。そのため、それらを一つずつ広告するとエントリー消費が無駄になる。なので、DMZのプレフィックスでまとめて広告している。

Q.プロキシサーバまで行くのはPACファイルで登録すればいいのでは？
PACファイルなどでPC内にデフォルトルートでプロキシサーバの場所を埋め込んじゃえば、プロキシサーバに関する広告は不要では？
A.PACファイルはプロキシのIPはわかるが、経路まではわからない。広告をすることで経路が明確になる。以下、フローで確認しよう。
▼PCからプロキシまでのフロー
① PCがPACファイル参照（宛先: プロキシIP）
② 最寄りのL3SWへ送信
③ L3SWはOSPFで学んだ「DMZサブネット宛て」の経路に従いルータへ
④ ルータからMPLS VPN（BGP）を渡ってデータセンターのPE1/ルータ1へ
⑤ 本社のL3SW1 ➔ FW ➔ DMZ内のプロキシサーバーに到着！
このように、宛先に届かすには経路広告の情報が必要となる。

カ：ポリシーベースルーティング
　ポリシーベースルーティングとはルーティングプロトコルによって導きだされたSPFではなく、定義したポリシー（条件）ごとにルーティング経路や優先度を変更させること。逆を言えば、最適経路以外でも、余裕で使われるということ。

設問２

（１）a: 10.3.0.0/16　b:64500 64500

PrefixAS PATH
as-override 設定無しa:10.3.0.0/1664500 65500
as-override 設定有りa:10.3.0.0/16b:64500 64500

a:10.3.0.0/16
これに関しては、支店Vの経路情報が届いているので、表２より支店Vのプレフィックスである10.3.0.0/16を書けばよい。

b:64500 64500
　as-overrideを使うと、AS-PATHが上書きされる。G社のASは65500だとわかるので、64500がL社のAS番号であるとわかる。つまり、65500を64500で上書きするだけなので、64500 64500となる。
＊ちなみにAS-PATHは右側が発信源で、左にどんどん追加していく。なので、「50000 60000 70000」というようなAS-PAHTがあったら、70000が最も遠く50000が最も自分の近くにあるASであると判断できる。

設問３

（２）タイプ：Type５　機器：ルータ３

まずは背景を整理しよう。
　背景：
　　・データセンターからのDMZに関する広告がBGPを経由して流れてくる
　　・で、その広告がOSPFに入るときにどのタイプになるか
　　・また、そのOSPF広告を流したのはだれか？
ということから答えを導いていこう。

まず、BGPからOSPFに経路が入るということは外部経路なのでType５であることが分かる。で、かつ、外部経路をOSPFに変換する機器はどこか？と考えると、BGPとOSPFの両方のプロトコルが稼働しているのはルータであることが分かる。で、問題では支店V社にフォーカスしているので、支店V社におけるルータはルータ３なので答えはルータ３となる。

設問４

（１）IPsecトンネル確立のためのIPアドレス、IPsecトンネル確立のための鍵情報

では、まずはSD-WANとかは置いといてIPsecに必要な情報を整理していこう！
▼IPsecに必要な情報
・相手のIPアドレス
・認証用の鍵情報
・暗号化方法
・認証方法
・ハッシュ方法
・Diffie-Hellmanのグループ番号
・ライフタイム

ShellScript
crypto isakmp key パスワード address 相手のIPアドレス #相手のIPアドレス＆認証用の鍵情報
crypto isakmp policy ポリシー番号
 encryption aes #暗号化方法
 authentication pre-share #認証方法
 hash sha256 #ハッシュ方法
 group 14 #Diffie-Hellmanのグループ番号
 lifetime 3600 #ライフタイム

以上の情報の中で、相手が変わっても変化がない情報は「暗号化方法・認証方法・ハッシュ方法・Diffie-Hellmanのグループ番号・ライフタイム」である。逆に相手に応じてかける必要がある情報は「相手のIPアドレス・認証用の鍵情報」である。
言い換えると、前者の相手が変わっても変化がない情報はSD-WANコントローラーがポリシーとして一括配布できる情報である。一方、後者はSD-WANルータ毎に配らなければならない情報である。

上記の前提を念頭に置いたうえで、問題文を確認すると「SD-WAN装置ごとの～と、IPsecトンネルを構築するための情報」と書かれているので、SD-WAN装置毎に送らなければならない情報は相手のIPアドレス・認証用の鍵情報である。

（２）IPsecトンネルに障害があった場合の検出を高速にする

BFDとはBidirectional Forwarding Detection（双方向転送検出）の略。通信経路（トンネルや物理リンク）の障害をミリ秒単位で超高速に検知する軽量プロトコル。
そのため、BFDを使うことで、IPsecトンネルに障害があった場合の検出を高速にすることができる。

また、障害検知だけでなく、以下のように👇より細かな情報も取得できる。
レイテンシー（遅延）： パケットの往復にかかる時間
パケットロス（欠損率）： 通信がどれくらい途切れているか
ジッター（パケブレ）： 遅延の揺らぎ・ばらつき

さらに深いVersion………………………………

p.9 支店が追加されたら、どのような変更があるの？ｰｰｰｰｰｰｰｰｰｰｰｰｰｰ

Q.視点を追加すると変更作業が起きると書かれている。が、実際にはどのような変更作業があるのか？

A.結論から言うと、現行構成（MPLS VPN＋BGP/OSPF）のまま支店を増やす場合、「新規支店以外の既存拠点（データセンターや本社など）」でのルータ設定変更作業はほぼ発生しない。
新規拠点側ではルータのコンソールに接続し、IPアドレス、eBGP設定、OSPF再配布、ルートフィルタなどを1台ずつ手動でコマンド設定（CLI）する必要がある。しかし、新拠点のサブネット情報は、BGPとOSPFの再配布によって自動的にデータセンターや本社、他支店へ伝播する。そのため、既存ルータの設定をわざわざいじる必要はない。

p.9 現行構成における課題と、SD-WAN導入による改善点

項目現行構成（MPLS VPN）SD-WAN導入後
現地作業専門技術者が現地へ行き、ルータにコマンドを打ち込んで設定現地作業員は箱を開けてLAN/WANケーブルを挿すだけ（ゼロタッチプロビジョニング / ZTP）
設定の管理拠点ごとにルータのコンソールに入って個別に設定・管理クラウド上のSD-WANコントローラーで全拠点を一元管理
回線の追加MPLS回線の開通を待つ必要があり、導入に時間がかかる安価な一般インターネット回線を引き、IPsecトンネルを全自動で網の目（メッシュ）状に張り巡らせることが可能

Q.どうやってSD-WANはゼロタッチプロビジョニングを実現しているの？

A.コントローラからポリシーを配布してもらっている。では、フローを見ながらSD-WANにおけるゼロタッチプロビジョニングを確認していこう！

▼SD-WAN 起動〜設定完了までの詳細フロー
1：出荷および事前準備（ベンダーX社・クライアントA社）

  • 機器の出荷と登録（X社）： X社はSD-WANルータを工場から発送する際、そのルータの個体識別情報（シリアル番号やMACアドレス等）と「A社」の顧客情報を紐づけて、自社の「中央集権型ZTPリダイレクトサーバー」のデータベースに登録する。
  • 初期ハードコーディング（X社）： ルータのファームウェアには、無条件で「X社の中央集権型ZTPリダイレクトサーバー（例: ztp.vendor-x.com）」へアクセスする宛先情報が最初から組み込まれている。
  • 事前にコントローラーでのポリシー定義（A社）： A社のネットワーク管理者は、クラウド上の「A社専用SD-WANコントローラー」の管理画面にて、新規追加するルータのシリアル番号を指定し、適用させたいネットワーク設定（IPアドレス、BGP/OSPF、IPsecトンネル、VPNポリシーなど）を作成しておく。

2：現地設置および自動リダイレクト（現地・ZTPサーバー）

  • 現地設置と電源投入（現地）： 現地作業員（専門知識不要）がルータを箱から取り出し、LAN/WANケーブルを挿して電源を入れる。
  • 中央サーバーへのアクセス（ルータ ➔ X社ZTP）： ルータは起動後、ハードコードされた宛先（ztp.vendor-x.com）へ自動で通信を行い、「私のシリアル番号は SN12345 です。私の接続先コントローラーを教えてください」とリクエストを送信する。
  • 契約情報の照合と案内（X社ZTP ➔ ルータ）： X社ZTPサーバーは、受信したシリアル番号 SN12345 をデータベースと照合し、「この機器はA社所有」であることを特定する。特定後、ルータに対して「A社専用コントローラーのFQDN/IPアドレス（例: controller.a-company.com）」を応答（リダイレクト案内）する。

3：認証および設定ファイルの適用（ルータ ➔ A社コントローラー）

  • 専用コントローラーへの接続（ルータ ➔ A社コントローラー）： ルータは案内された「A社専用コントローラー」へアクセスし、証明書等を用いて安全な暗号化通信（TLSトンネル）を確立する。
  • 設定データ（構成定義）の配布（A社コントローラー ➔ ルータ）： A社コントローラーは、接続してきたルータのシリアル番号を認証し、あらかじめ準備しておいた設定データ（JSON、XML、YANGモデル形式など）をTLSトンネル経由で流し込む。
  • 設定の自動反映（ルータ内部）： ルータ内のOS（エージェント）が受け取った設定データを解析し、ルーティングテーブルの構築、IPsecトンネルの確立、OSPF/BGPプロセスの起動などを自動で実行・適用する。

4：開通・運用開始

  • オーバーレイ網の確立と開通： 設定完了後、他の拠点のSD-WANルータとの間で自動的にIPsecトンネルが立ち上がり、オーバーレイネットワークの通信がスタートする。

Q.従来のZTPとSD-WANのZTPの違いは？

正直、従来環境でもZTPはできていた。従来の普通のルータ（制御と転送が一体化している機器）でも、DHCP Option 66/67やTFTP/FTPサーバーを使って「電源を入れたら自動で設定ファイルをダウンロードして適用する」というZTP（自動構築）の仕組みは存在していた。しかし、それはあくまでも静的なコマンド投入である。
一方、SD-WANはコマンドではなく、ポリシーをZTPで配布している。そして、そのポリシーを解釈して実際に動作に落とし込むのはSD-WANルータ自体の仕事。つまり、動的な設定を投入することができるようになったということが従来とSD-WANでは違う。

比較項目従来型ルータのZTP（制御・転送が一体）SD-WANのZTP（制御・転送が分離）
機器の役割1台ごとに自立した「脳（制御）」を持つ機器は「体（転送）」のみ。脳はクラウド（コントローラー）
流し込むデータ完成された個別の静的コンフィグ（CLIコマンドの塊）ポリシー情報や識別情報などの動的なパラメータ（JSON/XML等）
接続後の運用設定適用後は単体動作。変更時は再度個別に設定を書き換えるコントローラーと常に繋がり、集中制御・リアルタイム変更を受け続ける
メッシュ接続全拠点とVPNを張る場合、事前またはZTPで巨大な設定を書き込む必要ありコントローラーが仲介し、全拠点間のIPsecトンネルを動的・自動生成する

Q.ってか、、そもそもWANって何？

A.「自社の敷地や所有設備を出た外側の領域全体」をWAN（Wide Area Network）という。

区分範囲と所有権具体例
LAN自社・自組織が所有・管理する敷地内のネットワークオフィスのLANケーブル、社内Wi-Fi、フロアスイッチ、自社ビル内のネットワーク
WAN敷地外に出て、電気通信事業者（キャリア）の設備を借りて接続する広域ネットワークMPLS VPN、広域イーサネット、インターネット、IP-VPN

Q.SD-WANのインターネット通信に対するアプローチはどういう感じ？

SD-WANルータは基本的にSD-WANコントローラの制御に従う。これは当たり前だが、SD-WANコントローラ配下の拠点間だから成立する。しかし、インターネット接続（Google、Yahhoo、一般Webサーバ）の場合は、それらのサーバはSD-WANコントローラ配下にはない。なので、通常の拠点間通信とは異なるアプローチによって経路が選択される。

▼拠点間通信とインターネット通信の違い

SD-WANコントローラー配下の拠点間通信（自社拠点 ⇔ 自社拠点）

  • アプローチ: 「双方向の協調制御」
  • 送信側と受信側の両方にSD-WANルータ（CE機器）が存在。
  • お互いに制御パケット（BFDなど）を送り合うことで、遅延・パケットロス・ジッターを双方向でリアルタイム測定し、コントローラーが定めたポリシーに従って最適なトンネル（IPsec）へパケットを動的に流す。

インターネット通信（自社拠点 ➔ 一般Webサーバ / SaaSなど）

  • アプローチ: 「片側（送信側ルータのみ）での単独制御」
  • 相手（Google、Yahoo!、Microsoft 365など）は自社のSD-WANコントローラーの制御配下にはない。
  • そのため、送信側のSD-WANルータが単独でアプリケーションを識別（DPI）したり、片道のレスポンス速度を測定したりして、「自社の出口回線（MPLS経由か、一般インターネット回線へのローカルブレイクアウトか）」をポリシーに基づいて判断・選択する。

▼取得できる情報の違い

比較項目拠点間通信（双方にSD-WANルータあり）インターネット通信（相手は一般Web等）
取得できる情報① リアルタイム片道/往復遅延（ミリ秒）
② 精密なパケットロス率（%）
③ ジッター（遅延の揺らぎ・MS）
④ 対向ルータのCPU/帯域負荷状況		① リンクの物理UP/DOWN状態
② 自社出口でのHTTP/DNS応答時間
③ 自社側回線の利用率（帯域使用率）
④ アプリの種類（DPI識別：Teams, YouTube等）
情報の取得方法双方で専用の制御用プローブパケット（BFDなど）を高頻度（例：100ms周期）で直接打ち合う。相手がプローブに応答しないため、自ルータを通過する通常のデータ通信のレスポンスを観測する。
情報の正確性極めて高い（双方向の完璧な数値）
「行きは良いが帰りの回線が混んでいる」といった片道障害も正確に検知。		限定的（片側・推定）
相手サーバーや途中のインターネット網内の混雑か、自社の回線品質劣化かの切り分けが困難。

Q.もし回線が1つしかなかったらSD-WANを導入する意味なくね？

Q1.そもそもSD-WANの目的はポリシーによって動的な経路制御をすることである。しかし、そもそもの回線が１つしかなかったら、動的に経路制御しようと思っても結局１つしか道がないんだからポリシーによる動的制御しても意味なくね？
Q2.また、ZTPに至っても、自社で初期の設定コマンドなどのコンフィグを自社サーバなどに配置して、起動時にそれを取得するようにハードコーディングしておけば、それによって一元的なポリシー割り当ても可能になるのでは？
ということから、回線が１つであればSD-WANを導入する意味ってなくね？

A.では、疑問を一つずつ答えていこう！
A1.「回線が1本なら動的ルーティング（経路切替）の意味がない」 ⇒ 【100% 正解】 逃げ道の回線がない以上、どれだけリアルタイムに遅延やパケットロスを検知しても、その回線を通すしかない。

A2.「ZTP（ゼロタッチ）や一括設定投入だけなら、SD-WANじゃなくてもできる」 ⇒ 【100% 正解】 従来のルータでもDHCP/TFTPやAnsible等の構成管理ツール、独自ZTPサーバーを使えば初期設定の一括配布は可能。

Q.では、回線1本でもSD-WANを入れるメリットとは何か？

「回線が1本」という条件であっても、SD-WAN（クラウドコントローラーによる一元管理）を導入するメリットは主に3つある。

① 「ZTPそのもの」ではなく「開通後の継続的な集中管理（Day 2 Operation）」
　従来のZTP（TFTP等）は「最初の設定を入れる時（Day 1）」だけの仕組み。 開通後に「セキュリティポリシーを変更したい」「新しい通信を許可したい」となった場合、従来方式では全拠点のルータに個別ログイン（CLI）して設定変更を打ち込む必要がある。 SD-WANであれば、コントローラーのUI上でポリシーを1回変更するだけで、全国100拠点のルータへ一瞬で変更が波及・同期される。

② 「アプリの可視化」と「優先度制御（QoS）」
　回線が1本しかないからこそ、帯域の奪い合いが発生する。

  • 状況： 1本しかない回線で、誰かが巨大なファイルをダウンロードして帯域を圧迫した。
  • SD-WANの動作： アプリケーション識別（DPI）機能により、「Web会議（Teams等）」のパケットを最優先し、「ファイルダウンロードや動画視聴」の帯域を動的に制限（QoS）する。 経路変更はできなくても、「1本の回線の中でどのアプリを優先して通すか」という帯域制御（シェーピング）が強力に働く。

③ セキュリティ連携（SASE / SSE への発展性）
　現在、1回線（インターネットVPN）の拠点でSD-WANを入れる最大の理由はクラウドプロキシ（ZscalerやPalo Alto Prisma Access等）との自動連携。

  • ローカルブレイクアウトの簡略化： クラウド型セキュリティ（SASE）へ通信を飛ばすための暗号化トンネルの設定や、IPアドレス変更への自動追従をコントローラーがすべて自動で行ってくれる。

p.9 MPLSとは?———————

MPLS（Multi-Protocol Label Switching）とはIPヘッダの宛先IPアドレスを見る代わりに、パケットに付与した短い『ラベル』を見て超高速に転送（スイッチング）する技術。
しかし、現在のルータではMPLSと同等レベルの転送処理が可能になってきているので、高速転送というメリットは薄くなってきている。

p.9 MPLSとMPLS VPNの違いは？

比較項目普通のMPLSMPLS VPN
主な目的パケットの高速転送・特定経路への迂回複数企業の通信を絶対に混ざらないように完全分離（仮想化）
付与するラベルの数1つ（シングルラベル）2つ（ダブルラベル / 2重ラベル）
VRFの有無なし（テーブルは1つ）あり（企業ごとに独立したルーティングテーブルを作成）

Q.MPLS VPNのフローは？———————–

G社の本社CEから支店CEへ「10.1.0.0/24（本社）」の経路を教える流れを見ていこう！

ShellScript
[本社CE] ➔(eBGP/OSPF)➔ [PE-1] ➔=== (MP-BGP) ===➔ [PE-2] ➔(eBGP/OSPF)➔ [支店CE]

1. コントロールプレーン（経路広告のフロー）
①アンダーレイ構築：
　PE-1、P（中継）、PE-2 間でOSPF/IS-ISとLDPを動かし、事業者網内の全ルータが「PE-1やPE-2のループバックIP」へ届く状態（トランスポートラベル）を作る。
②CE ➔ PE-1（経路の受領）：
　本社CEがPE-1の「G社用VRF」へ 10.1.0.0/24 を広告。
③PE-1 での加工（VPNv4化）：
　PE-1は受け取った 10.1.0.0/24 に以下を付与する。
　　・RDをくっつけて「一意なVPNv4アドレス（例: 65000:1:10.1.0.0/24）」に変換。
　　・RT（エクスポートタグ）を付与。
　　・G社用VRF宛てであることを示す「VPNラベル（内側ラベル）」を自動採番。

④PE-1 ➔ PE-2（MP-BGPで広告）： PE-1は対向のPE-2へ、MP-BGPを使って上記の情報を一括送信。

⑤PE-2 での取り込み： PE-2は届いたRTタグを見て「G社用VRF」に合致することを確認。RDを外して元の 10.1.0.0/24 に戻し、G社用VRFのルーティングテーブルへ登録。

⑥PE-2 ➔ 支店CE： 支店CEへ 10.1.0.0/24 を広告。

2. データプレーン（実際の通信フロー）

支店CEから本社（10.1.0.0/24）へパケットを送る際の流れです。

  1. 支店CE ➔ PE-2： 普通のIPパケット（宛先: 10.1.0.1）をPE-2のG社用VRF宛てに送信。
  2. PE-2 での2重ラベル付与：
    • 内側（VPNラベル）： MP-BGPでPE-1から教えてもらった「G社VRF識別用ラベル」を貼る。
    • 外側（トランスポートラベル）： LDPで知った「PE-1（目的地）まで運ぶためのラベル」を貼る。
  3. Pルータ（中継）： 外側ラベルだけを見て、ラベルを付け替えながらPE-1へ超高速転送（内側ラベルやIPヘッダは見ない）。
  4. PE-1 到着：
    • 外側ラベルが剥がれ（※直前のPルータで剥がれるPHP機能が一般的）、PE-1には「内側ラベル＋IPパケット」が届く。
    • PE-1は内側ラベルを見て「これはG社VRF行きだ」と判断し、ラベルを剥がしてG社VRFのルーティングテーブルを参照。
  5. PE-1 ➔ 本社CE： 生のIPパケットとして本社CEへ渡す。

LDPのメカニズム＆フロー

OSPFで経路ができた後、LDP（Label Distribution Protocol）がどうやってラベルのバケツリレー表を作り上げるのか、そのメカニズムをステップ順に解説します。

▼前提コンポーネント
　CE1（本社） / CE2（支店）： 顧客（G社）のルータ
　PE1 / PE2： 事業者（L社）のエッジルータ（VRFを設定）
　P： 事業者（L社）のコア中継ルータ（VRFは存在しない）

ステップ1：アンダーレイIGP（OSPF/IS-IS）の確立

　・事業者内のルータ（PE1, P, PE2）間でOSPFまたはIS-ISを起動。
　・これにより、事業者網内の全ルータが「互いのIPアドレス（Loopback等）」に届く状態を作る。

ステップ2：LDPによるトランスポートラベル（外側）の配布

　・LDP（Label Distribution Protocol）が起動し、IGPで学習した宛先（特にPEのLoopback IP）に対してラベルを割り当てる。
　・動作： 下流（PE2）から上流（PE1）に向かって、「PE2宛てのパケットはラベルXで送ってくれ」とバケツリレー式にラベル情報（外側ラベル）を伝播し、全ルータにLFIB（ラベル転送表）を構築する。（このプロセスのわかりやすい具体例はこちら）

ステップ3：PEルータでのVRF・RD・RTの設定

　・PE1およびPE2に顧客（G社）用の仮想ルータ（VRF）を作成する。
　・RD（Route Distinguisher）： 他社とIPが重複しても一意に識別できるよう、IPプレフレフィックスの先頭に付与する（例：65000:1 + 10.1.0.0/24 ➔ 65000:1:10.1.0.0/24 というVPNv4アドレスを生成）。
　・RT（Route Target）： どのVRFに経路を取り込むかを制御するタグ（Export/Importルール）を設定する。

ステップ4：CE ➔ PE 間の経路学習

　・CE1（顧客G社本社）が自身の持つ経路（10.1.0.0/24）をPE1へ広告する（eBGPやOSPF等を使用）。
　・PE1は届いた経路を「G社用VRF」のルーティングテーブルに登録する。

ステップ5：PE1でのVPNラベル（内側）自動採番とMP-BGP広告

　・PE1は、顧客G社VRF宛てを引き込むためのVPNラベル（内側ラベル、例: 1001）を内部で自動生成する。
　・PE1はPE2に対して、MP-BGP（iBGP）を使って以下の情報をセットで広告します。
　　・VPNv4アドレス： 65000:1:10.1.0.0/24
　　・ネクストホップ： PE1のIPアドレス
　　・内側ラベル： 1001
　　・RTタグ： Export RT（例: 65000:100）
　　・内側ラベルのわかりやすいプロセスはこちら

ステップ6：PE2でのRT照合とVRFへの取り込み

  • PE2はMP-BGPで受信した経路のRTタグ（65000:100）を確認します。
  • 自身のVRFに設定されたImport RTと一致したため、RDを取り除いて普通のIPv4（10.1.0.0/24）に戻し、G社用VRFテーブルへ登録します。
  • PE2はG社VRFからCE2（支店）へこの経路を広告します。

▼外側ラベルの配布メカニズム＆フロー

直感的に理解できるように、ルータを1列に並べた超シンプルな具体例で解説していこう！
＊ルータが4台一直線に並んでいる場合

ShellScript
目的は、PE1からゴールである「PE2（IP: 2.2.2.2）」へパケットを届けること。
[PE1] ─── [P1] ─── [P2] ─── [PE2]

▼LDPのバケツリレー（ラベルの通知フロー）
LDPはゴールのPE2から始まって、下流から上流へ向かってメッセージを送っていく。

① PE2 ➔ P2 への通知
　・PE2の主張： 「P2さん、僕（2.2.2.2）宛ての荷物を持ってくるときは、ラベル10を貼って渡してね！」
　・P2の処理： P2はメモする。
　　[メモ：PE2（2.2.2.2）に行くなら ➔ ラベル10を貼ってPE2へ投げる]

② P2 ➔ P1 への通知
　ここが疑問のコア！P2は「ラベル10」をそのままP1に教えるのではなく、P2自身が新しい番号（ラベル20）を勝手に決めてP1に伝える。
　・P2の主張： 「P1さん、PE2（2.2.2.2）宛ての荷物があるなら、僕にはラベル20を貼って渡してね！」
　・P1の処理： P1はメモする。
　　[メモ：入力ラベル20が来たら ➔ ラベル10に付け替えてP2へ投げる]

ShellScript
[PE1] ーーーーーーーーーーー [P1] ーーーーーーーーーーー [P2] ーーーーーーーーーーー [PE2]
      ←2.2.2.2はラベル30　　　　　←2.2.2.2はラベル20　　　　←2.2.2.2はラベル10

③ P1 ➔ PE1 への通知
　P1も同じように、自分専用の新しい番号（ラベル30）を決めてPE1に伝える。
　・P1の主張： 「PE1さん、PE2（2.2.2.2）宛ての荷物は、僕にはラベル30を貼って渡してね！」　
　・PE1の処理： PE1はメモする。
　　[メモ：PE2（2.2.2.2）行きパケット ➔ ラベル30を貼ってP1へ投げる]

▼実際のデータ（パケット）が流れる
全ルータが「隣のルータから指定されたラベル」に貼り替えながら投げるので、パケットは無事に届きくようになる。

  1. PE1： PE2行きのパケットに、P1から頼まれた「ラベル30」を貼ってP1に投げる。
    ＊入り口部分のPEルータでは、IPアドレスも確認する。そして、「あ、このIPアドレス宛はこのラベルだなと」判断してラベルを付与。以降のPルータはラベルのみで転送する。
  2. P1： 「30」が届いたので、P2から頼まれた「ラベル20」に貼り替えてP2に投げる。
  3. P2： 「20」が届いたので、PE2から頼まれた「ラベル10」に貼り替えてPE2に投げる。
  4. PE2： 「10」が届いたので、自分宛てだと分かって受領する。

👆ステップ２の解説に戻る

▼内側ラベルの配布メカニズム＆フロー

出口側であるPE1（本社側）が顧客網（CE1）から経路を学習し、入口側であるPE2（支店側）へ内側ラベルを配るまでの流れを見ていこう。

ShellScript
[CE1] ーーーーーー [PE1] ーーーーーー [P1] ーーーーーー [P2] ーーーーーー [PE2]

1.PE1：CE1からIPv4経路を学習:
　VRF内での処理。
　・PE1は、接続されているCE1（顧客本社）から普通のIPv4経路（例: 10.1.0.0/24）を学習し、顧客A用のVRF-Aに登録する。
　・検証: PE1の show ip route vrf VRF-A で 10.1.0.0/24 が見えれば成功。

2.PE1：VPNv4アドレスへの変換と内側ラベルの採番:
　・MP-BGPでの処理。
　・PE1は、この経路を対向のPE2へ通知するために次のように加工。

  1. RDの付与: IPv4経路の頭にRDを結合し、VPNv4アドレスに変換する（65001:100 : 10.1.0.0/24）。
  2. 内側ラベルの採番: このVRF-A宛て専用の内側ラベル（例: 1001）を自前で1つ割り当てる。
  3. RT（Export RT）の付与: 判定用のRTタグ（例: 65001:10）を付与する。

　・検証: PE1のBGPテーブル（show bgp vpnv4 unicast all）で、VPNv4経路にラベル 1001 が紐付いていれば成功。

3.PE1 ➔ PE2：MP-BGP UPDATEメッセージの送信:
　・PE間（iBGP）通信。
　・PE1は、MP-BGP（iBGP）を使ってPE2へアップデートメッセージを直接送信する。
　・途中のPルータはこの通信を単なるIPパケット（あるいはBGPパケット）として透過するだけで、中身は見ない。

  • 送信される内容:
    • Destination (NLRI): 65001:100 : 10.1.0.0/24（VPNv4アドレス）
    • VPN Label: 1001（内側ラベル）
    • Route Target: 65001:10（Export RT）
    • BGP Next-Hop: 192.168.1.1（PE1のLoopback IPアドレス）

4.PE2：RT判定とVRFへの取り込み:
　Import処理。
　・メッセージを受け取ったPE2は、付与されているRT（65001:10）を確認する。
　・PE2の「VRF-A」に設定された Import RT と一致するか判定。
　・一致した場合、RDを取り除いて元のIPv4経路（10.1.0.0/24）に戻し、PE2の「VRF-A」のルーティングテーブルに登録します。
　・このとき、ネクストホップ 192.168.1.1（PE1）へ向かうための内側ラベルとして 1001 を内部テーブル（LFIB）に記憶します。
　・検証: PE2の show ip route vrf VRF-A に 10.1.0.0/24 が登録され、ネクストホップがPE1のIPになっていれば完了。

▼実際のパケットが転送される
＊支店（CE2）から本社（CE1: 10.1.0.1）宛てにパケットが送信されたときのラベル挙動。

ShellScript
[CE2] ──(生のIP)──> [PE2 (入口)] ──(2重ラベル)──> [Pルータ網] ──(内側のみ)──> [PE1 (出口)] ──(生のIP)──> [CE1]
  1. PE2（入口ルータ）でのルックアップ:
    CE2から送られてきた生のIPパケット（宛先: 10.1.0.1）を「VRF-A」で検索。
  2. 2重ラベルの着せ替え（Push）:
    • 内側ラベル (1001): MP-BGPでPE1から教わった「VRF-A識別用ラベル 1001」を貼る。
    • 外側ラベル (30): LDPで隣のPルータから教わった「PE1（192.168.1.1）へ運ぶ用のトランスポートラベル 30」を上から重ねて貼る。
  3. 網内（Pルータ）の転送:
    Pルータ群は外側ラベル（30）だけを見てバケツリレー（Swap）を行います。内側ラベル 1001 は隠されたままで無視される。
  4. PE1（出口ルータ）でのカプセル解除（Pop）:
    • 外側ラベルが剥がされた状態でPE1に届く（※PHP機能により直前のPルータで外側が剥がされている場合もある）。
    • PE1は残った内側ラベル 1001 だけを見て、「あ！これはVRF-A向けの荷物だ！」と一瞬で判断する。
    • 内側ラベル 1001 を剥がし、生のIPパケットに戻してCE1（本社）へ送信する。

step5に戻る👆

Q.なんでRDタグが必要なの？

Q.RTタグがあるなら、RDっていらなくね？だって、複数の会社で同一のプレフィックスを使っていても、RTで分ければ、問題なくね？
A.RDが必要になる理由はPEルータ内のBGPプロセス内で経路を識別するため。参考書に乗っているRDの説明を聞くと「コアネットワーク内で経路を一意に識別するため」と書かれてミスリーディングをされることがある。そもそも、RDの内容をコアルータは見ないので、これは完全なミスリーディングとなる。
実際は、PEルータ内のBGPプロセスにおいて、同じプレフィックスがあると属性などから最適な経路のみが登録されることになって、それ以外が破棄されてしまうから。

Q.もしRDがないと？

・パターン１：
　PEルータが複数の会社から同一プレフィックスを広告するときに、BGPプロセス内で「あ、これ同一プレフィックスだから１番いい経路だけ広告して他は破棄しよ」となってしまい、広告されなくなる。

・パターン２：
　PEルータが複数の同一プレフィックスから経路を受信しても、その中から最も良い経路のみがテーブルに登録される。たとえ、RTで別々のVRFに登録してね！と明示してあったとしても、それを確認する前にBGPプロセスで最良経路が選択されて、最良経路のみのVRFに登録される。ほかのVRFには登録されなくなる。

Q.CEルータとPEルータはどうやってつながっているの？

CEルータとPEルータはどのようにつながっているのか？専用線のようなものを施設しているのか。それとも、なにか別の接続方法でつながっているのか。それを紐解いていこう！
A.「顧客ビルから通信事業者の設備（PEルータ）まで物理的なアクセス回線（光ファイバーなど）を直接引き込んで接続する」のが一般的。
インターネット経由で自宅のルータからVPNを張る（IPsec VPN等）のとは異なり、MPLS VPNは「暗号化を使わない代わりに、物理・論理的にインターネットから完全に孤立させた閉域網を使う。拠点（CE）からPEルータまでの間に「何が存在し、どう繋がっているのか」を以下で詳細を記す。

▼MPLS VPNにおけるCEとPEのフロー

ShellScript
[顧客ビル]                                 [通信事業者（L社）の拠点]
┌───────┐      ┌────────┐                  ┌────────┐      ┌────────┐
│  CE   │ ───> │ ONU /  │ ═══════════════> │ L2/L3  │ ───> │   PE   │
│ルータ │ (LAN)│ ONU(ONU)│   アクセス回線   │ 網装置 │ (LAN)│ルータ  │
└───────┘      └────────┘  (光ファイバー)   └────────┘      └────────┘
                           └───────────────┘
                              ↑ 中間にNTTなどの
                                ダークファイバや
                                網内スイッチが存在

物理的なアクセス回線（光ファイバーやONU）の仕組み自体は、個人宅の光回線（フレッツ光など）と全く同じ。
特別な「MPLS専用の魔法の光ファイバー」が地中に埋まっているわけではない。違いは物理回線ではなく、「集約局（基地局/収容局）でどの網へ振り分けるか（スイッチング）」という論理的な出口（VLANやポート）の話。

Q.再配布のループ防止方法は？——————

本文中では「ループ防止のため経路フィルターを設定」としか書かれていないため具体的なイメージがわかない。なので、ここでは再配布時に発生するループを防ぐ方法を具体的に見ていこう！

手法1：ルートタグ（Route Tag）を使う方法【推奨・最もスマート】

再配布するときに経路へ「目印（数字のタグ）」を貼り付け、そのタグが付いた経路が入ってきたら再配布を拒否する手法。
仕組み：
　・OSPFからBGPへ渡すとき：「タグ 100」 を貼って再配布する
　・BGPからOSPFへ渡すとき：「タグ 100」が付いている経路は再配布をブロックする。
Cisco IOSでの設定コマンド例👇

ShellScript
#① タグを定義するルール（Route-map）を作成
route-map OSPF-TO-BGP permit 10
 set tag 100      #再配布する経路に「100」のタグを貼り付ける

route-map BGP-TO-OSPF deny 10
 match tag 100    #「100」のタグが付いた経路は拒否（再配布しない）
route-map BGP-TO-OSPF permit 20
                  #その他の経路は許可

#② BGPプロセス側で再配布を設定
router bgp 65001
 redistribute ospf 1 route-map OSPF-TO-BGP  #タグ100を貼ってBGPへ入れる

#③ OSPFプロセス側で再配布を設定
router ospf 1
 redistribute bgp 64512 subnets route-map BGP-TO-OSPF  #タグ100付きを拒否してOSPFへ入れる

手法2：ディストリビューションリスト（Prefix-list）を使う方法

自拠点のIPプレフィックスを明示的に指定してフィルタリングする手法。
　仕組み：
　　「自社のIPアドレス範囲（例: 10.0.0.0/8）はBGPからOSPFへ絶対に再配布しない」というフィルターを直書きする。
　デメリット：
　　拠点やネットワークが増えるたびにルータのリストを手動で更新する必要がある（タグ方式の方が自動化できるため実務では好まれる）。

ShellScript
#プレフィックスリストの場合
ip prefix-list prefix_リスト seq 10 deny 10.0.0.0/16
ip prefix-list prefix_リスト seq 20 permit 0.0.0.0/0 le 32

#ACLの場合
access-list ACL名 deny 10.0.0.0 0.0.255.255
access-list ACL名 permit any

router ospf プロセス番号
 distribute-list prefix prefix_リスト名 in #プレフィックスリストの場合
 distribute-list ACL名 in #ACLの場合
 area 1 filter-list prefix prefix_リスト in #エリア1に入ってくるSAを制限
 
*filter-listはprefix-listしか対応していない。
また、BGPのfilter-listはas-pathリストにしか対応していない。

p.12 SD-WANコントローラとエッジルータのmTLS通信とは?——————

mTLS通信とは、Mutual TLS（相互TLS認証）の略でクライアントとサーバーの「双方が」お互いにデジタル証明書を提示し合い、「お前は誰だ？」「お前こそ誰だ？」と互いの身元を確認する通信方式のこと。一般的なWebアクセスではクライアント側が証明書を提供しない、いわば片方向のTLSであることが多い。しかし、クライアント側も証明しなければならないときは、双方向のTLS、つまりmTLSが必要となる。

Q.証明書はだれが？いつ？発行してくれるの？
誰が発行したかをわかっていないと、事前にどのルートCAの証明書をインストールしておくかわからない
A.SD-WAN機器の製造ベンダー（Cisco等）が運営する認証局（ベンダー独自CA）が、工場出荷時（製造工程）に機器固有のクライアント証明書を発行する。 機器側には、このクライアント証明書および秘密鍵、そして検証用のベンダーのルートCA証明書が、TPM等の耐タンパー性を持つ暗号チップ内（ハードウェア領域）にあらかじめプリインストール（組み込み）される。

Q.OMPってなに?————————

Q.SD-WANを勉強していると必ずと言っていいほど、OMPが出てくる。何かの情報を運ぶんだろうなぁという解釈はあるが、いまいちわかっていない。。。なので、ここですっきりしていこう！

A.OMPとはOverlay Management Protocolの略でCisco SD-WAN（旧Viptela）独自で動作するコントロールプレーン用プロトコル。コントローラーとSD-WANルーター間で、オーバーレイ網の構築に必要な各種情報を一括してやり取りする「司令塔通信の言葉」。
一言で言うと、OMPは「拠点同士が直接IPsecトンネルを張るための仲介役（ルーティング＆鍵情報・IP情報の動的交換プロトコル）」。

mTLSでコントロールプレーンが確立された後、コントローラーとルータの間でこの「OMP」という独自ルーティングプロトコルが動き出す。具体的には、以下の3つの情報をOMPでやり取りしている。

１. 相手のIPアドレスや暗号鍵の交換（TLOC情報）
　・ルータAは「自分の今のWAN側IP」や「IPsec用公開鍵」を、OMPに乗せてコントローラーへ送る（収集）。
　・コントローラーは、「対向ルータBのWAN側IP」や「対向ルータBの公開鍵」をOMPに乗せてルータAに配る（配布）。
　・これによって、ルータAとルータBが手動設定なしで直接IPsecトンネルを全自動で張れるようになる。

2. 各拠点配下のLANのルーティング情報（OMP Routes）
　・「拠点Aの配下には 192.168.10.0/24 があるよ」「拠点Bの配下には 192.168.20.0/24 があるよ」というLAN側のルート情報をOMPでコントローラーへ送る。
　・コントローラーがこれを全拠点のルータへ配ることで、各拠点ルータのルーティングテーブルに自動的に相手拠点のルートが追加される。

3. サービスやセキュリティポリシー情報（Service Routes / Policies）
　・「ファイアウォールはデータセンターを通せ」「Teams通信は各拠点から直出し（ブレイクアウト）しろ」といった動的な経路変更指示をOMPで配る。

Q.なんでわざわざOMPを使うの？

OMPを使わずにHTTPやmGRE/NHRPなどの既存の技術を使っても実現できそうなのに、なんでわざわざ、面倒くさそうなOMPを導入しているの？決められたフォーマットを使えばまとめて情報を送れるから？でもそれも、JSONとか使えばHTTPでもフォーマット作ってまとめて送れるよね？あと、HTTPはステートレスっていうけど、セッションの保持時間を長くすればたとえNAT環境とかでもコントローラからの通信を受け取れるよね？

A.既存技術（HTTPやmGRE/NHRP）では、数千台規模の大規模企業網の制御、多重回線の集約、複雑なポリシー制御に耐えられないから。

▼OMPとHTTPの違い
OMPはルーティングプロトコルそのもの。つまり受け取ったポリシーからスムーズにルーティングに落とし込むことができる。一方HTTPはただデータを運ぶだけなので、受け取った後に再度、プログラムを稼働させてからでなければルーティングに落とし込むことができない。いわば無駄なオーバーヘッドが生まれてしまうということ。なので、OMPを使うべき。

Ｑ．OMPで配布する情報とそれ以外で配布する情報の違いは？

パラメータの種類具体例配布元・プロトコルなぜそこから渡されるのか？
共通ポリシー（静的）AES-256、SHA-256、DHグループ14、IKE/IPsecライフタイムSD-WAN Manager
(HTTPS / NETCONF)		全拠点共通のセキュリティ基準（テンプレート）なので、初期設定（ZTP直後）として配れば十分だから。
接続識別情報（動的）WAN側IPアドレス、UDPポート番号、TLOCカラーSD-WAN Controller
(OMP)		プロバイダのIP変動やマルチ回線（フレッツ、5G等）のポート番号など、常に変わり得る値だから。
暗号化鍵データ（動的）IPsecの鍵（SPI、AES encryption keyなど）SD-WAN Controller
(OMP)		定期的に鍵を自動更新（Re-key）するため、リアルタイム同期が必要だから。

要は、拠点に依存しない設定であればZTP直後に配布する。逆に拠点依存の設定はOMPで動的に配布するという棲み分けがある。

Q.SD-WANにおけるIPsec構築フロー

  1. 初期生成（ローカル）：各エッジルーターは起動時、内部でDH鍵ペア（秘密鍵 a, 公開鍵 A）を生成する。
    • 公開鍵 A の計算式: A＝ ga mod p (g と p は共通ポリシーで固定指定された値）
  2. OMPによる集約と配布（制御プレーン）：ルーターは自身の「WAN側IP」「UDPポート」「公開鍵 A」などをセット（TLOC Route）にして、OMPでコントローラーへ送信。コントローラーはこれを全拠点へ一括配布する。
  3. 共通鍵の自動導出（ローカル）：拠点1は、OMPで届いた「拠点2の公開鍵 B」と「自分の秘密鍵 a」を掛け合わせ、共通鍵 K を計算する。
    • 拠点1の計算: Ba mod p = (gb)a mod p = gab mod p
    • 拠点2の計算: Ab mod p = (ga)b mod p = gab mod p
      双方の手元で交渉なしに全く同じ共通鍵 K が完成する。
  4. 事前確立とデータ通信（データプレーン）：通信が発生する前にバックグラウンドでIPsecトンネルを開通。実際のデータ通信時には、導き出した共通鍵 K（AES）で高速に暗号化・復号を行う。

以上のようなフローになる。また、上記より、SD-WANではIKEが不要であることが分かる。

Q.なぜ DMVPN では IKE をやめられなかったのか？

  1. 理論的には可能だった
    NHRP を拡張して「IPアドレス」と一緒に「各拠点ルータの公開鍵」もハブから配れば、理論上は IKE を排除できる。
  2. ハードウェアと役割の限界（現実の壁）
    当時のハブは単なる 1 台の物理ルーターであり、パケット転送処理でスペックがカツカツ。全拠点の鍵の最新状態や Re-key（更新）までハブで一元管理すると莫大なメモリ領域、CPUが必要で処理が破綻するため、「鍵交渉や認証（IKE）は拠点同士で直接やってくれ」 という設計（割り切り）にせざるを得ない。

Q.なぜ SD-WAN では IKE を捨てられたのか？

  1. 制御（Control）と転送（Data）の分離
    パケット転送を行わない「制御専用」のコントローラー（vSmart等）を分離独立させた。
  2. クラウド・サーバのハイスペック化
    クラウド上の強力な CPU/メモリ を背景に、中央コントローラーが「全拠点の認証」「暗号ルールの統一」「安全なパイプ（mTLS/OMP）での鍵配布」をすべて一括処理できるようになった。
  3. 結果
    IKE がやってくれていた泥臭い事前交渉をすべてコントローラーが完了させておいてくれるため、エッジルーター同士は IKE 交渉をスキップしていきなり IPsec トンネルを開通できるようになった。

p.12 なぜSD-WANはVRFが必要なの？

Q.「MPLS-VPNのPEルータみたいに複数の企業と接続するためにVRFでルーティングを分ける」という理由ならVRFの必要性にうなずける。しかし、SD-WANの場合は１つの会社の拠点間で運用されているので、ルーティングが混ざっても問題ないのではないか？それなのになぜVRFを使うの？

A.SD-WANにおけるVRFは「ルーター内部で『アンダーレイ（制御用通信）』と『オーバーレイ（社内データ通信）』を分けるためのセキュリティ壁として利用されている。

VRF（RI）の名称割り振られる役割どんな通信が流れるか？
トランスポートVRF
（コントロールプレーン）		アンダーレイ
（WAN回線そのもの）		コントローラー（vSmart/vManage）とのmTLS/OMP通信、拠点間のIPsecトンネル自体の通信（WAN側IP）
サービスVRF
（データプレーン）		オーバーレイ
（社内ネットワーク）		社員が使うパソコン、社内サーバー、業務データ（プライベートIP：192.168.x.xなど）

ループの構成を簡単にすると👇
①わからない宛先があった、0.0.0.0は本社IPsecだな！よし、IPsecに入れよう！
②よし、カプセル化できたからインターネット経由で流そう！インターネットのルーティングはわからないから0.0.0.0のデフォルトルートで流そう！
③ん？デフォルトルートはIPsecに入れるの？
というように、ループが発生する。
なので、そもそも、１つのデフォルトルートを参照し続けるのではなく、ルーティングテーブルを２つ持って、それぞれのデフォルトルートを持てば解決するよねっていう単純な話だったのである。

Q.もし、VRFを使わないと何が起きるの？

SD-WANでVRFが使われるのは制御プレーンとデータプレーンを分けるためという理解はできたが、もし、分けなかったら具体的に何が起きるのかがいまいちイメージできない。なので、それをはっきりさせていこう！

制御プレーンとデータプレーンのループ（矛盾）が生まれる

ルーティングテーブルが1つ（単一のVRF）しかない場合、「トンネルを作るための外側のパケット」と「トンネルを通すための内側のパケット」の宛先判断が混ざり、ルーティングの無限ループ（再帰的ルーティングループ）が発生する。具体的には、センタートラフィック集約で、わからないルートはすべて本社のIPsecに流すとい設定をした場合に発生する。ローカルブレイクアウトではこれは起きない。
▼具体的な発生メカニズムとフロー
前提：
　拠点Aの物理WAN IP： 203.0.113.1（アンダーレイ）
　拠点Bの物理WAN IP： 198.51.100.2（アンダーレイ）
　IPsecトンネル（データプレーン）： 拠点Aと拠点Bの間に張り、デフォルトルート（0.0.0.0/0）または他拠点宛の経路をトンネル向けに向ける。

①.拠点AのPCから通信が発生:
　拠点Aの社内PCが、拠点B宛にデータ（例: 10.2.0.5）を送信
②.IPsecトンネルへルーティング:
　拠点Aのエッジルーターはルーティングテーブルを参照
　「10.2.0.0/24 宛は IPsecトンネル（ipsec0） に送る」というルールに従い、パケットをトンネルに送る
③.暗号化と外側ヘッダー（ESP）の付与:
　ルーターは元のパケットを暗号化し、対向の物理WAN IP（拠点B: 198.51.100.2）へ届けるため、新しいIPヘッダー（送信元: 203.0.113.1 / 宛先: 198.51.100.2）を包み込むように付与（カプセル化）する。
④.【障害発生】外側パケットの再ルーティング:
　カプセル化した「新しいパケット（宛先: 198.51.100.2）」を実際にWANポートから物理送信するため、ルーターはもう一度同じルーティングテーブルを参照する。
　ここで、OMPや動的ルーティングにより「0.0.0.0/0（全通信）は IPsecトンネル（ipsec0） に送る」という集約ルートや過剰な経路が入っていると、ルーターはこう判断する。
「198.51.100.2 宛のパケットも、IPsecトンネル（ipsec0）の中に送らなきゃ！」
⑤.無限ループ（カプセル化の再帰）:
　「暗号化パケット」をさらにIPsecトンネルに送り込むため、ルーターはもう一度暗号化し、さらに外側に新しいIPヘッダーを付与。
以上👆より、要は、
①わからない宛先があった、0.0.0.0は本社IPsecだな！よし、IPsecに入れよう！
②よし、カプセル化できたからインターネット経由で流そう！インターネットのルーティングはわからないから0.0.0.0のデフォルトルートで流そう！
③ん？デフォルトルートはIPsecに入れるの？
というように、ループが発生する。

結果として「カプセル化されたパケットを、さらにカプセル化してトンネルに投げる」という処理がメモリやCPUの限界まで無限に繰り返され（またはTTL切れで廃棄され）、通信が完全に破綻する。
しかし、これはあくまでもデフォルトルート（0.0.0.0/0）をIPsecにすべて流すようなセンタートラフィック集約を意図した場合である。ローカルブレイクアウトであれば、パケットがカプセル化（IPsec化）されないため、「暗号化された外側パケットがもう一度トンネルに吸い込まれる」という現象自体が起こり得ない。

Q.なぜ普通のルーター（従来のIPsec）はVRFを使わずにループしないのか？

ループのメカニズムを確認すると、SD-WANに限った話ではないように感じる。しかし、旧来のIPsecルータはVRFをデフォルトで必要としない。でもループは起きない。ではなぜか？？

A.普通のルーター（CiscoのIOSなど）で「全通信（0.0.0.0/0）をIPsecトンネルに投げる」設定をした場合、ルーター内部では特殊な処理（ローカル配送の例外処理）が働いている。

ShellScript
【従来のルーター内部の例外処理】
1. PCから通信が来る ➔ ルーティングテーブルを見て「0.0.0.0/0 宛てだから Tunnel0（IPsec）へ投げる」
2. ルーターが暗号化して「対向物理IP（200.200.200.200）」を外側に貼り付ける。
3. ★ここがポイント！★
   従来のIPsec（GRE/VTIなど）機能は、「自分自身が生成した暗号化後の物理パケット（宛先: 200.200.200.200）」を、もう一度ルーティングテーブルに通すのではなく、物理WANポート（Ge0/0）へ直接吐き出す特殊なマーク（ソケットバインド）を内部で自動的に行う。

従来のルーターは「暗号化したパケットは例外的にループ判定から外して物理WANに出す」というOS内部の泥臭いハードコード（内部実装）によって、単一VRFでもギリギリでループを防いでいた。

Q.SD-WANにおけるBFDとは？——-

Q.どの区間でBFDが実施されるの？
A.BFDが実施されるのは拠点間。コントローラとの通信はOMPのKeepAliveを使う。

Q.なんで拠点間はBFDを使うの？
A.コントローラとの通信はリアルタイム性がそれほど求められないため、OMPのKeepAliveで十分。一方、拠点間の通信は実際のデータパケットが流れるため、より障害に敏感にならなければならないから。なので、ミリ秒単位で障害を検知できるBFDを使う

Q.IPsecのKeepAlive機能じゃダメなの？
A.IPsecにも障害を検知するための機能がある。それがDPD（DeadPeerDetection）である。しかし、それはBFDに比べ、検知が遅く品質も判断できないという粗い精度なので、より高性能なBFDを使っている。

比較項目DPD (Dead Peer Detection)BFD (Bidirectional Forwarding Detection)
主な目的相手機器の生存確認（切れていればクリーンアップ）リンクの超高速障害検知＆回線品質の測定
検知速度遅い（数秒 〜 30秒程度）超爆速（数十 〜 数百ミリ秒）
得られる情報「生きてる」か「死んでる」かのみ生死 ＋ 遅延、パケットロス、ジッター（品質）
パケットサイズやや大きい（IKE制御用ヘッダー等を含む）極小（約 24〜52 バイト程度の軽量固定長）
送受信の頻度数秒〜数分に1回（またはトラフィック停止時のみ）1秒間に数回〜十数回（ミリ秒単位）
帯域・負荷の合計合計パケット数は極小（ミリ秒単位ではないため）送信数は多いが、パケットが小さく専用処理のため負荷は無視できるレベル
処理エンジンコントロールプレーン（CPU処理）データプレーン（ASIC/ハードウェア高速処理）
サイレント障害の検知不可能（パケロス50%でも生きていれば正常判定）可能（パケロスや遅延を測定して劣化を検知）


タイトルとURLをコピーしました