1. 目的
本書の目的は、オンプレミスまたは自社データセンター上の NFV 基盤で提供している NF サービスを、パブリッククラウドへ持ち込む際の技術的成立性を整理することである。
対象とする NF は、Linux 汎用 VM ではなく、Cisco などの仮想アプライアンスである。現行環境では、これらの仮想アプライアンスが IPsec 終端、BGP による経路交換、およびユーザー通信の中継点として動作している。
本書では、論点を混在させないために、まず アンダーレイ を固定し、その上で オーバーレイ を扱う。特に、パブリッククラウド側の L3 制約をどこまでアンダーレイに閉じ込められるかを中心に整理する。
本書の結論は次である。
- Direct Connect 配下で、仮想マシンの private IP を外側終端として扱う構成は成立する。AWS の Private VIF は VPC の private IP 到達性を提供し、EC2 上の self-managed VPN appliance に対して Direct Connect 経由で IPsec を張る構成も AWS が案内している。
- その上に形成される IPsec トンネル内の L3 は、パブリッククラウドのルーティング制御とは分離して設計可能である。
- ただし、実運用の成立条件は、製品サポート、BGP / VIF 制約、経路数上限、MTU / MSS、性能要件の再定義を満たすことにある。
2. 対象構成
2.1 現行構成の要点
現行環境は、自社データセンター内の NFV 基盤上で NF を提供している。基盤は KVM 系で構成され、CPU ピニングや SR-IOV を前提とした NFV 向け最適化が入っている。NF は Linux 汎用 VM ではなく、Cisco などの仮想アプライアンスである。
ユーザー企業には通信キャリア提供回線が収容されており、ユーザー側ルーターと NF の間で IPsec を確立し、その IPsec トンネル上で BGP により経路交換を行っている。バックボーン側も BGP 主体であり、ユーザー通信は NF を経由してインターネットへ到達する。
2.2 パブリッククラウド移行時の主語
本構成において、パブリッククラウドと直接接続する主体はユーザー企業ではない。Direct Connect を契約・収容する主体は 通信キャリア であり、ユーザー企業はその回線利用者である。
したがって、主語は次のように固定する。
- Direct Connect 契約主体：通信キャリア
- 回線提供主体：通信キャリア
- 回線利用者：ユーザー企業
- クラウド側収容点：仮想マシン上の仮想アプライアンス
- クラウド側外側 IP：仮想マシンの private IP
3. アンダーレイ
3.1 アンダーレイの定義
本書における アンダーレイ とは、仮想アプライアンスが IPsec を終端するまでの外側到達性を指す。すなわち、次の経路である。
ユーザー側ルーター → 通信キャリア回線 → 通信キャリア網 → Direct Connect → クラウド VPC → 仮想マシン private IP
ここで重要なのは、クラウド側到達先が public IP ではなく、仮想マシンの private IP である点である。アンダーレイの本質は、通信キャリア網と Direct Connect を用いて、クラウド内の private 到達性を成立させることにある。AWS の Private VIF は VPC に対する private IP 到達用として定義されている。
3.2 Direct Connect 上の経路交換
この段階で扱う BGP は、まだ IPsec トンネル内の BGP ではない。これは Direct Connect 上のアンダーレイ BGP である。
ここで必要なのは、片方向の到達性ではなく、往復の到達性である。したがって、Direct Connect 上で交換すべき経路は次の 2 方向に分かれる。
3.2.1 クラウド側 → 通信キャリア側
クラウド側から通信キャリア側へは、VPC 側の private reachability を広告する。目的は、通信キャリア網側から仮想マシンの private IP へ到達できるようにすることである。Private VIF は、VGW または Direct Connect Gateway 経由で VPC 側の private reachability を提供する。
3.2.2 通信キャリア側 → クラウド側
通信キャリア側からクラウド側へは、通信キャリア側のグローバル IP レンジ を広告する。目的は、クラウド側から通信キャリア側グローバル IP 宛通信を返送できるようにすることである。AWS の Direct Connect では、Private VIF における on-premises 側プレフィクスとして private だけでなく public も扱える。
3.2.3 アンダーレイとして成立していること
この時点で成立しているのは、次の 2 点である。
- 通信キャリア網側から仮想マシン private IP へ到達できる
- クラウド側から通信キャリア側グローバル IP へ返送できる
これが、本構成におけるアンダーレイの往復条件である。
3.3 通信キャリア網側の前提
通信キャリア側グローバル IP レンジをクラウド側へ広告して戻り経路を成立させるためには、当該プレフィクスが 通信キャリア網内で閉域経路として収容・返送可能であること が前提となる。
したがって、本構成は、通信キャリア網側で次が成立していることを前提とする。
- 当該グローバルプレフィクスが通信キャリア網内で保持されること
- そのプレフィクスがインターネット側へ逃げず、通信キャリア網 / Direct Connect 側で処理されること
- 必要に応じて VRF 等により論理分離されていること
つまり、通信キャリア側グローバル IP を Direct Connect 経由で扱えるルーティング設計 が成立していることが前提条件である。
3.4 仮想マシン private IP の扱い
クラウド側の外側終端として使用するのは、仮想マシンの private IP である。この private IP は、OS 内で静的設定するものではなく、クラウド基盤側で仮想 NIC に対して固定し、OS は DHCP でその値を受ける という扱いになる。
したがって、本構成で本質となるのは次である。
- OS 内で static 設定を書くことではない
- 仮想 NIC にどの private IP を持たせるかをクラウド基盤側で固定設計すること
このため、外側アドレス設計の主体は OS 設定ではなく、クラウド基盤側の仮想 NIC / IP 管理 である。EC2 の primary private IP は起動時に明示指定でき、VPC 内では DHCP により配布される。
3.5 NIC 数の扱い
アンダーレイ成立性の観点では、1 NIC でも 2 NIC でもよい。必要なのは、通信キャリア網から到達可能な private IP を、仮想アプライアンスの外側アドレスとして持たせることである。
したがって、NIC 数はこの段階では本質ではない。2 NIC 以上が意味を持つのは、たとえば次のような場合である。
- 管理面とサービス面を分離したい場合
- 製品要件として複数 NIC を前提とする場合
- 面分離を設計上要求する場合
結論として、NIC 数は アンダーレイ成立性の制約ではなく、設計および製品要件の問題 である。
4. オーバーレイ
4.1 オーバーレイの定義
本書における オーバーレイ とは、アンダーレイ上に構成された IPsec トンネル、およびその内側で動作する L3 を指す。
この段階で、IPsec を終端する主体は仮想マシン上の Linux 一般ではなく、仮想マシン上で動作する仮想アプライアンス である。仮想マシンはその実行基盤であり、外側アドレスとして使うのが仮想マシンの private IP である。
したがって、構造は次のように整理できる。
通信キャリア網 / Direct Connect / クラウド VPC / 仮想マシン private IP / その仮想マシン上の仮想アプライアンス
AWS は、Direct Connect private VIF 上で self-managed な EC2 上の VPN appliance に対して IPsec を張る構成を案内している。
4.2 IPsec の成立条件
仮想アプライアンスは、自身が動作する仮想マシンの private IP を外側アドレスとして使用し、ユーザー側のグローバル IP を持つルーターとの間で IPsec を張る。
ここで重要なのは、IPsec の外側アドレスは両端が同じ種別である必要はなく、相互到達性があればよい という点である。したがって、次の組み合わせでも問題はない。
- クラウド側：private IP
- ユーザー側：global IP
4.3 IKE Peer ID の設計
ただし、IP レベルの相互到達性だけでは不十分である。本構成では、クラウド側外側アドレスが private IP、ユーザー側外側アドレスが global IP となるため、IKE ネゴシエーションでは Peer ID の整合性 が別途問題になる。
そのため、Local ID / Remote ID は暗黙値に依存せず、FQDN または明示 ID で設計する前提 とすべきである。すなわち、本構成では次を前提条件に含める。
- Local ID / Remote ID を明示指定すること
- デフォルトの interface address 依存挙動に期待しないこと
- 仮想アプライアンス側、ユーザー側ルーター側の双方で Peer ID 設計を合わせること
4.4 トンネル内 L3 の自由度
アンダーレイが成立し、その上で IPsec トンネルが形成されると、トンネル内の L3 はクラウド側のルーティング制御とは別層 になる。
クラウド側が直接関与するのは、あくまで 仮想マシン private IP までの到達性 である。その先、すなわち IPsec トンネルの内側でどのプレフィクスを流し、どのように BGP を張り、どうルーティングするかは、仮想アプライアンス同士の制御 に委ねられる。
したがって、現行環境で行っている次の要素は、クラウド側 L3 制約とは分離して扱える。
- トンネル上での BGP 経路交換
- ユーザー側プレフィクスの収容
- サービス経路のルーティング設計
これが、本構成の技術的核心である。
5. FHRP の扱い
FHRP は本書の主題ではない。ただし、設計上の補足として位置づけは明示しておく必要がある。
FHRP は一般に、L2 セグメント、マルチキャスト、仮想 IP / 仮想 MAC 共有 を前提とする。通常のパブリッククラウドでは、利用者がオンプレミスと同じ意味で L2 を自由に扱うことはできないため、FHRP をそのまま適用することはできない。
したがって、冗長化に関しては次の方針を採る。
- FHRP 方式そのものを要件にしない
- 必要なのは、冗長時の到達性維持と切替後の経路整合性である
- 実現方式は、パブリッククラウド側ネットワーク設計で別方式として実装する
6. 実務上の確認事項
本構成は、概念整理としては成立する。ただし、実務設計では以下の項目を確認対象とする必要がある。
6.1 仮想アプライアンスの製品サポート
対象の仮想アプライアンスが、パブリッククラウド上で本構成を正式にサポートするかを確認する必要がある。特に確認対象となるのは次である。
- 仮想マシン private IP を外側アドレスとして使う構成
- 当該構成における IPsec 対応可否
- 複数 NIC 構成の要求有無
- 対応インスタンスタイプ
- 暗号性能、経路数、セッション数
6.2 Source / Destination Check
本構成では、仮想アプライアンスは IPsec の終端点 であり、ルーティングは IPsec トンネル インターフェイス上の経路 に閉じることを前提とする。この場合、ENI 上を流れるのは EC2 自身宛 / 自身発の外側パケットであり、VPC / ENI 上で他者宛の平文パケットを forward しない。したがって、本構成に限れば Source / Destination Check の無効化は必須ではない。
一方で、仮想アプライアンスが単なる IPsec 終端点に留まらず、復号後トラフィックを VPC 内の別経路へルーティング、NAT、Firewall 等として中継する場合には、クラウド基盤側の送信元 / 宛先チェック無効化 が必要となる。つまり、必要性の判定基準は 中継 NF であること自体 ではなく、ENI 上で他者宛パケットを forward するかどうか である。AWS は NAT や routing、firewall 用途では source / destination check の無効化を必要としている。
6.3 MTU / MSS 設計
Direct Connect、クラウドファブリック、および IPsec カプセル化オーバーヘッドを跨ぐため、MTU および TCP MSS の設計は必須 である。
少なくとも、次は設計・検証対象へ含める必要がある。
- 実効 MTU の確認
- TCP MSS の調整
- PMTUD 依存可否
- フラグメンテーション時の挙動
- 長時間通信および大容量転送時の実測
6.4 経路数設計
Direct Connect 上の BGP で持ち込むプレフィクス数、およびトンネル内で扱う経路数は、クラウド側制限および仮想アプライアンス側制限の両面から確認する必要がある。
特に、次を分けて扱うべきである。
- アンダーレイで交換する経路数
- オーバーレイ内で交換する経路数
- 製品として保証される経路収容数
- 実際の障害時再収束時間
AWS の Direct Connect では、Private VIF / Transit VIF における on-premises 側から AWS 側への広告上限は、IPv4 / IPv6 それぞれ 100 経路であり、超過すると BGP セッションは idle / DOWN になる。Public VIF は 1,000 経路である。VPC route table 側にも別の上限があるため、戻り経路設計を含めた全体の経路数を早期に確認する必要がある。
6.5 Direct Connect の BGP / 接続形態制約
Direct Connect 上の BGP 設計では、AWS 側仕様に起因する制約を前提条件として明示する必要がある。
第一に、AWS は BFD と Graceful Restart の同時使用を非推奨 としている。そのため、アンダーレイの障害検知と経路維持のどちらを優先するかを設計段階で固定する必要がある。実務上は、アンダーレイ障害の早期検知を優先して BFD を採用する設計が自然である。
第二に、AWS 側の BFD minimum interval は 300 ms、minimum multiplier は 3 である。したがって、理論上の最短障害検知時間は 900 ms であり、これより短い切替を前提要件にはできない。さらに、実際の再収束時間は、BFD 検知後の BGP 状態遷移、経路再選択、転送面反映を含むため、900 ms より長くなる前提で扱う必要がある。
第三に、通信キャリア側の提供形態が Hosted Connection の場合、1 接続あたり作成可能な VIF は 1 つのみ であり、この制約は増加できない。したがって、管理系とサービス系を VIF 分離する設計や、複数の論理系を 1 Hosted Connection 上に収容する設計は、事前に提供形態を確認しなければ成立性を判断できない。Dedicated Connection と Hosted Connection は、この点で設計自由度が大きく異なる。
6.6 性能要件に関するクラウド側制約
パブリッククラウド上の NF は、オンプレミス NFV 基盤と同一の性能前提では扱えない。
Direct Connect は、インターネット経由より一貫した接続特性と、より予測可能な latency / throughput を提供するが、利用者がクラウド内部ファブリックに対してオンプレミス同等の QoS 優先制御や帯域保証を行えるわけではない。したがって、クラウド内部はベストエフォート前提で評価する必要がある。
また、EC2 のネットワーク帯域はインスタンスタイプによって baseline / burst 仕様 を持つ。したがって、NF の常時高負荷運用では、”up to” 表記のピーク帯域ではなく、sustained throughput を個別に確認しなければならない。
さらに、Dedicated Host や Dedicated Instance はコンピュート資源の占有を意味するが、データセンター内ネットワーク経路全体の専有を意味しない。よって、オンプレミス同等の確定的な帯域保証、マイクロバースト抑制、厳密なジッタ制御を前提要件には置かず、クラウド仕様に依存するベストエフォート型スループット設計へ要件を再定義する必要がある。
7. 結論
本書で整理した内容を要約すると、次のようになる。
パブリッククラウド上の NFV アンダーレイは、通信キャリア契約の Direct Connect を用いて、通信キャリア網からクラウド上の仮想マシン private IP へ到達性を作る構造 として成立する。その仮想マシン private IP を外側アドレスとして、仮想アプライアンスが IPsec を終端することで、その上にオーバーレイを形成できる。さらに、IPsec トンネル内の L3 はクラウド側ルーティング制御とは分離されるため、トンネル内では仮想アプライアンス同士で自由にルーティング設計できる。
したがって、パブリッククラウドへ NFV 型 NF を持ち込む際に最初に整理すべきなのは、冗長化方式やトンネル内経路ではなく、次の 4 点である。
- 誰が Direct Connect の主体か
- クラウド側到達先は何か
- Direct Connect 上で何を経路交換するか
- 仮想マシン private IP をどのように外側終端として扱うか
これらを先に固定すれば、その後のオーバーレイ設計は比較的明確になる。逆に、ここを曖昧にしたままトンネル内設計へ進むと、論点が崩れやすい。
以上より、Direct Connect 配下の仮想マシン private IP を外側終端とする構成は技術的に成立し、パブリッククラウド上でも仮想アプライアンス型 NF によるオーバーレイ制御は実現可能である。ただし、実運用の成立条件は、製品サポート、BGP / VIF 制約、経路数上限、MTU / MSS、Source / Destination Check の適用条件整理、性能要件の再定義を満たすことにある。
