今日のWANが抱える問題点

一般的に異なる地点間を結ぶネットワークはWide Area Network(WAN)と呼ばれます。例えば企業の拠点間や学校のキャンパス間を結ぶネットワークはWANということになります。当初WANは専用線やフレームリレーで構築されるのが一般的でしたが、それらは徐々にMPLS VPNや広域イーサーネットサービスなどに置き換えれらていきました。

従来のWANが抱える課題

当初はさほど大きな問題はなかったWANですが、ネットワークがビジネス上不可欠なツールとなり、拠点数が数千〜数万になることも珍しくなくなってくると、拠点開設にかかる時間がビジネスが求める俊敏性に応えられなくなってきました。また、世の中のグローバル化に伴い、拠点は国内だけはなく海外にも展開されるようになり、回線費用や回線品質などが問題になってきました。広帯域を必要とするアプリケーション(ビデオなど)を使うニーズも増えてきましたが、狭帯域な従来のWANでそれを実行するのは非現実的でした。

クラウドとSaaSがネットワークを変える?

そこに追い打ちをかけたがのが近年のパブリッククラウドやSaaSの台頭です。これらのサービスは全てインターネット上にあるわけですが、WANからインターネットへ抜ける道は通常データセンタなど一箇所に限られることが多いため、パブリッククラウドやSaaS向きのトラフィックでデータセンタのインターネット回線が輻輳してしまったり、プロキシーの性能が足らずアプリケーションが思ったように動作しない、などといった問題が顕在化してきました。Office 365の使用は爆発的に伸びています。今後もこのようなクラウドベースのアプリケーションがどんどんと出てくると考えられます。

SD-WANはクラウド時代のWAN

これらの課題を解決するために生まれてきたのがSD-WAN(Softwre Defined WAN)という技術です。回線コストの削減と広帯域化を図るために、従来のMPLS回線に加えインターネットを活用します。ただし、信頼性保証のないインターネットだけでは今日のビジネス要件に応えることはできないので、複数ある回線の品質をモニターしながらSLAを満たす回線のみを使えるような機能が提供されています。また、ゼロタッチプロビジョニングと呼ばれる機能を持ち、簡単に拠点のネットワークを立ち上げることができます。特定のアプリケーションのトラフィックだけ拠点から直接インターネットに抜けるようにして、高価なMPLS回線の使用を抑え、クラウドやSaaSアプリケーションに最適化されたネットワークを提供することができるので、まさに「クラウド時代のWAN」ということができるでしょう。

本Blogでは、SD-WAN分野リーディングカンパニーで、SD-WANの市場を牽引してきたViptelaのソリューションに関する情報を提供していきたいと思います。

Viptelaユーザー事例:ACADIA Healthcare

ACADIA Healthcare(以下ACADIA)は行動問題医療を専門とする医療機関で、2016年にFortuneで「最も早いスピードで成長している企業100」にも選出されています。米国、英国、プエルトリコなどに600近い施設と約17,000の病床を持ち、この分野では最大級の医療機関です。

彼らが直面していた問題は、従来使っていたWAN回線はかなり信頼性が低く(特に地方拠点)たびたびダウンタイムが発生していたことでした。サーバがオンプレミス側にあるうちはWANに障害があっても業務に大きな支障は発生しませんでしたが、近年業務アプリケーションがクラウド化さるようになってくるに伴い、WANの障害によって業務に大きな支障が生じるようになってきました。特に音声アプリケーションがクラウド化され、WANの障害で電話による受付業務が止まってしまい、ビジネスの機会損失になってしまうのが大きな悩みでした。

ACADIAは、このような問題にはSD-WANが有効であると考え、SD-WANの検討を始めました。3ヶ月ほどSD-WAN製品選定を行い、最終的にはViptelaを選択しました。Viptelaを選択した理由は、最もネットワーク機能がしっかりしており「ネットワーク屋が作ったネットワーク製品」と感じられた、というのも大きかったようです。

まずは10拠点ほどでPOCを行い、その結果も良好だったのでその後展開を進め、2016年秋の時点で50箇所ほどデプロイを完了、最終的には100拠点ほどにViptelaを展開する予定だそうです。従来はMPLS回線を使っていましたが、そこにブロードバンド回線とLTEを加え、非常に可用性の高いネットワークにすると共に、Application Aware Routing機能を使って、医療用アプリケーションに対してSLAを保証するようにしているのも特徴的な使い方と言えるでしょう。

将来的にはセグメンテーションの機能を活用したり、より積極的にクラウド化を進めて行くことを考えているとのことです。

ACADIAの方が2016年秋のONUGでプレゼンテーションをしていますので、興味がある方はこちらのビデオをご覧ください。

SD-WANでマルチキャスト

ViptelaのSD-WANに特徴的な機能の一つにマルチキャストのサポートがあります。アンダーレイネットワーク側にマルチキャストのサポートは必要ありません。オーバーレイネットワーク側でマルチキャストネットワークを作ることができます。以下、Viptelaのマルチキャスト機能について見てみましょう。

スケーラブルなマルチキャスト

ViptelaのSD-WANはPIM-SMをサポートしています。マルチキャストの送信者側、受信者側共に特別な要件はなく、普通にマルチキャストをする場合となんら変わりません。一方、オーバーレイ側では少々工夫がされています。

Multicast Support by Viptela
オーバーレイでマルチキャストをサポート

サービス(LAN)側から来るIGMPまたはPIMのjoinは、OMPプロトコルを使ってvSmartコントローラに送られるようになっています。

また、パケットのレプリケーションは上流のルータ(マルチキャストのソースを持つvEdge)が行うのではなく、「レプリケータ」と呼ばれる別のvEdgeルータが行うようになっています。通常、データセンタ側に置かれるvEdgeをレプリケータに設定します(性能や帯域に余裕があることが多いため)。このようにレプリケータを設けることで、拠点側のvEdgeの処理負荷軽減や帯域の削減が可能になります。レプリケータは複数設定することができ、マルチキャストのグループアドレス、ソースのvEdgeなどによって分散するようになっており、その際に各はレプリケータの負荷も考慮してレプリケータへの振り分けが行われるようになっています。このようにレプリケータを設けることで、単純にソースのvEdgeでレプリケーションするよりもスケールするマルチキャストネットワークを構築することができます。

セキュアなマルチキャストオーバーレイ

マルチキャストのトラフィックもユニキャストの時と同様に全てIPsecで暗号化されて送られます。「SD-WANのスケーラビリティ」で述べたように、vEdgeは自分宛に送るパケットを暗号化する際に使って欲しい暗号化鍵を自分で生成し、vSmartでそれを配布するようになっています。しかし、マルチキャストでこれをやろうとすると、レプリケータは送信先のvEdgeの数だけIPsecの暗号化処理をしなければなりません。暗号化処理はハードウェアで行われるとはいうものの、下流にvEdgeが100台あったら100回別々の鍵で暗号化をしなければいけませんのでかなり大変です。そこで、マルチキャストトラフィックを暗号化する際は、送信先のvEdgeが生成した鍵ではなく、送信元が生成した鍵を使うようになっています。このようにすればレプリケータは下流のvEdgeの数だけ別々に暗号化する必要は無くなります。レプリケータからパケットを受け取ったvEdgeは送信元のvEdgeが生成した鍵を使って復号化を行えば良いわけです。

ViptelaのSD-WANでは、上記のようなさまざま工夫によってスケールするマルチキャストネットワークを構築することができるようになっています。Viptelaユーザの中には、実際にこのマルチキャスト機能を使ってWAN上でビデオ配信を行なっているお客様がおられます。

vEdgeのQoS機能

どのようなSD-WANソリューションであっても、通常拠点側(エッジ)に設置する機器(CPE; Customer Premise Equipment)があります。Viptelaソリューションの場合はvEdgeがCPEになります。基本的にこれらのCPEは「ルータ」ですので、ルータとしての基本機能を備えている必要があります。ルーティングプロトコルサポートの重要性については「SD-WANへのスムースなマイグレーション」で述べましたが、QoS(Quality of Service)機能もSD-WANのCPEがサポートしていなければならない基本的機能要件の一つです。アプリケーションの重要度によってWANの回線を使い分ける、というのが最も典型的なSD-WANのユースケースだと思いますが、そもそも重要度の高いアプケーションのQoSを担保できなかったら回線を使い分けてもあまり意味がないでしょう。

一口に「QoSサポート」といっても非常に幅広いので、SD-WANソリューションを選択する際には具体的にどのようなQoS機能をサポートしているのかを注意深く見極める必要があります。vEdgeが持つQoS機能は以下のようなものがあります。

  • キューイング
  • シェーピング
  • ポリシング
  • リマーキング

キューイング

パケットの分類(Classification)はACL(src/dst IPアドレス or プレフィックス、src/dstポート番号、DSCP、パケット長、TCPフラグ、PLP (Packet Loss Priority) を使用できます。またDPIによるアプリケーション分類を使うこともできます。

vEdgeはEgressインターフェース毎に8個のキュー(Q0〜Q7)を持っています。このうちQ0はLLQ(Low Latency Queue)です。LLQは他のキューよりも高い優先度を持つものの、指定された以上の割合でスケジュールされることはありません。これにより単純なPQ(Priority Queueing)時に見られるような他のキューの飢餓状態(Starvation)が起こりません。したがって、音声などのトラフィックに向いています。残りのQ1〜Q7は通常のWRR(Weighted Round Robin)なキューです。

Queueing
キューイング処理

また、キューが輻輳した際の挙動についてはテールドロップをするかRED(Random Early Detection)をするかを指定できます。REDはキューへのたまり具合に応じて(たとえキューが満杯になっていなくても)パケットを確率的に落とす方法です。REDを使うことによりテールドロップ時に見られる「TCPのグローバル同期問題」を避けることができます。

シェーピング

シェーピングは単純にEgressのインターフェースに上限のレート(Kbps)を設定します。指定したレートを超えるパケットはキューイングされます。

ポリーシング

いわゆるシングルレート、2カラーなポリサーです。レート(bps)とバーストサイズ(bytes)を設定します。

ポリサーはIngress、Egressのインターフェースのどちらにでも設定することができます。また、ACLを使ってパケットに対して選択的にポリーシングをかけることもできます。

Policiing
ポリーシング処理

なお、指定したポリサーに違反するトラフィックに対するアクションとして “drop” もしくは “remark” を指定することができます。remarkを指定すると違反パケットはドロップはされませんが、PLPが “high” であるとマークされ、それを元にキューイングをしたりDSCPのリマーキングをすることができます。

リマーキング

ACLやDPIで特定されたトラフィックによって指定されるトラフィッククラスとPLP毎に、書き換えるDSCPの値を指定することができます。このリライトルールはインターフェースに対して適用されます。

Viptelaユーザー事例:Agilent Technologies

Agilent Technologies(以下、アジレント)は、1999年にヒューレットパッカードからスピンオフされた会社で、食品、環境、医薬品、分析機器、化学、エネルギーなど幅広い分野でビジネスを行なっています。現在、社員数約12,000人、30数ヶ国に約120の拠点を展開しています。

アジレントが2016年春のONUG (Open Networking User Group) で発表したビデオがこちらでご覧頂けます。従来WANの課題と、SD-WAN評価のプロセス、SD-WANを導入することによって得られたメリットと発見について非常に説得力ある話をしてくれていますので、是非一度ご覧いただければと思います。以下は、その要約です。


アジレントは、高価で低速なMPLS回線、バックアップ(休眠)回線による非効率、WANのクラウド対応など、多くの課題を抱えていました。また、企業買収によるネットワークの統合に長い時間がかかるのにも頭を悩ませていました。

彼らはこれらの課題をSD-WANで解決できると考えました。そしてくつかの要件をまとめました。

  • コントローラを持ち、オーケストレーションと自動化ができること
  • 基本的なモニタリングができること
  • ダイナミックルーティングをサポートすること
  • ハードウェアは小さなものから大きなものまでラインナップがあること
  • 電源が冗長化されていること
  • 冗長構成が組めること
  • GRE/IPsecトンネルとzScalerとの連携
  • DSCP値でトラフィックをコントロールできること
  • アジレントと似たようなスコープとスケールで最低2つのリファレンスカスタマーがあること

上記の要件について、SD-WANを標榜する会社20数社からヒアリングを行い、最終的に3つのベンダーに絞り込みました。そして、3社に彼らのネットワークを模擬したテスト環境と200ページを超える詳細なドキュメントを渡して、各ベンダーにSD-WANの実装とテストをさせました。各ベンダーにはテスト期間として1週間が与えられましたが、Viptelaはわずか3日で構築を完了させ、テスト結果も非常に良好だったため、彼らはViptelaを採用することに決めました。

その後、プロダクション環境でのパイロット運転を移りました。そこでまずわかったのは大きなコスト削減効果でした。Mbpsあたりのコストで見た場合、80%〜90%のコスト削減効果がありました。また、ネットワークの可用性も向上しました。

Viptelaの持つアプリケーションの可視化機能により新しい発見もありました。彼らのトラフィックの約60%がインターネット宛のトラフィック(OneDrive、Dropbox、FLEXNET、など)だったのです。これらのトラフィックをインターネットに直接ローカルExitさせることで、これらのアプリケーションが高価なMPLS回線を使わないように最適化することができました。

Viptelaのテンプレートベースの設定は監査にも役に立ちました。従来は100台のルータの設定が正しいかどうかをそれぞれ個別に確認する必要がありましたが、テンプレートを使った設定をしていればテンプレートの正当性だけ確認すれば良いので、大幅な工数削減が可能になりました。また、企業買収やビジネスパートナーとの連携にViptelaのセグメンテーション機能が非常に有用であるということもわかりました。

そして、何よりも驚いたのはインターネットの回線の品質が思ったよりはるかに良かったことでした。Viptelaを使うとWAN回線の品質(遅延、パケットロス率、ジッター)をモニターできますが、ほとんどの場合でMPLSよりもインターネット回線の方が品質が良いという結果が得られたのです。

彼らは社内、社外とのコミュニケーションのために非常に積極的にVoIPを使っていたので、インターネットベースのVPNに移行した際の音声の品質について懸念をしていましたが、実際にSD-WANを導入してみると音声の品質も以前より高くなりました。SD-WANを入れる前と後でNetScoutを使って音声の品質を計測しましたが、MOS値は良くなり、パケットロス率も大幅に改善しました。

今後の予定としては、vEdge Cloud(ソフトウェア版vEdge)の導入を考えていきたい、とのことでした。

Viptelaユーザー事例:GAP

アパレル大手のGAPは非常に初期からのViptelaのお客様の一つで、2016年12月現在で、1,200を超える拠点でViptelaによるSD-WANを運用されてています。

導入時には毎日25以上の拠点を立ち上げていたそうで、3ヶ月あまりで1,200あまりの全拠点の開設を行なったそうです。このような迅速な展開が可能だったのはViptelaのSD-WANによるゼロタッチプロビジョニングのおかげです。既存の技術で構築していたら、はおそらく1年以上はかかったでしょう(時間がかかればコストもかかりますので大きなコスト削減になります)。

また、GAPはViptelaの持つ「セグメンテーション機能」を非常に積極的に使われていることも特徴的な点です。GAPはショッピングモールなどに多数の店舗を出店されており、さまざまな目的でネットワークを必要としていました。通常の社内システムを使うためのネットワーク、クレッジトカード情報を扱うためのPCI-DSSに準拠したネットワークだけでなく、ゲストWi-Fiやキオスク端末、IP電話などのためのネットワーク、さらにモール内で盗難防止用に設置してるビデオカメラ映像を見るためのネットワーク、などです。これらのネットワークはそれぞれセキュリティ的な要件や最適なトポロジーが異なります。例えば社内システムやクレジットカー情報を扱うネットワークはハブ&スポークなトポロジーにしてデータセンターにトラフィックを集約してIDS/IPS、ファイアウォールを経由させたいでしょう。一方、ゲストWi-Fiはデータセンターに集約するのは望ましくありません。ローカルからインターネットにExitさせたいはずです。その際、zScalerなどと連携をさる必要もあるかもしれません。また、IP電話やビデオ映像のトラフィックをデータセンターに集約するのも非効率です。サイト間で直接通信をさせた方が効率が良いですし、そもそも音声やビデオに対してIDS/IPSやファイアウォールができることはほとんどありませんので、センターに集約してもあまり意味がありません(既存のネットワークで音声やビデオのトラフィックがデータセンターのファイアウォールを通過しているとしたら、それはファイアウォールの性能を無駄遣いしているに過ぎません)。

Viptelaのセグメンテーションの機能を使うと、このようにセキュリティ要件やトポロジー要件が異なるネットワークを一つのWANの上に簡単に作り出すことができます。セグメントごとにトポロジー(フルメッシュ、ハブ&スポーク)を自由に構成できますし、サービスチェイニング機能でファイアウォールを通過させるトラフィックをセグメントごとにフレキシブルに設定することも可能です。

セグメンテーション機能がなかった場合に、上記のような複数の要件の異なるネットワークをWAN上に構築するのは大変なことです。それぞれのネットワークごとにキャリアのVPNサービスを個別に契約する(当然相当のコストがかかります)か、自分でVLANやVRFの設定などをする(設定は複雑ですしスケールさせるのも困難です)ことになりますが、いずれの場合でもネットワークの「面(スライス)」は作れても、面ごとにトポロジーの自由にコントロールをするのは難しいと言えるでしょう。

Segmentaton Challengesi
SD-WANを使わないセグメンテーション。いずれにしても困難が伴う。

Viptelaのセグメンテーション機能を使うと、要件の異なったネットワークをWAN上に構築でき、それを簡単にグローバルに展開できます。GAPがViptelaを採用した大きな動機の一つになったのはこのセグメンテーションの機能であったようです。

Segmentation by Viptela
Viptelaのセグメンテーション。物理ネットワークに依存いない。

セグメンテーションの件も含め、なぜGAPがSD-WANを採用したのか、そしてSD-WAN化する事で得られたメリットについて、INTEROPで彼らが発表した内容がここにありますので、興味がある方はぜひ目を通してみてください。

SD-WANへのスムースなマイグレーション

SD-WANを導入するにあたり、全く新規にネットワークを構築すること(いわゆる「グリーンフィールド」な案件)は稀だと思います。したがって既存のWAN環境に段階的にSD-WANを適用して行く必要があります。まずは数拠点でパイロット的な適用を行い、順次適用を拡大して行くわけですが、それがスムースに行えるかどうかは実はとても重要な要件です。機能の多少の多い少ないよりも、むしろこの既存環境からのスムースなマイグレーションができるかどうかのほうがSD-WANを採用する上で重要な判断材料と言ってもいいかもしれません。

ステップ1: LAN側でインテグレーション

ViptelaのSD-WANソリューションはこのマイグレーションがスムースにできるように設計されています。既存ネットワークとのインテグレーションに際し最も非破壊的なやり方は、既存のネットワーク(例えばMPLS環境)には全く手を加えず、それと並列に別の回線(例えばインターネット)をWAN回線に使用したvEdgeによるネットワークを作り、LAN側で二つのネットワークを統合する方法です。

既存ネットワークと並列に展開し、LAN側でインテグレーション
既存ネットワークと並列に展開し、LAN側でインテグレーション

このような構成を取れば、ある意味MPLSとインターネットによるハイブリッドなWAN環境を作ることができます。このような構成が可能なのは、vEdgeが既存のLAN環境で使われているルーティングプロトコル(典型的にはOSPFですが、BGPの場合もあるかもしれません)をフルにサポートしているからです。ルーティングプロトコルを使ってLAN側でインテグレーションするわけです。

ステップ2: ハイブリッドなネットワークを構成

一旦上記のような構成が取れれば、既存ネットワークに若干の設定変更(具体的にはvEdgeからMPLSのCEルータに足を伸ばしてやる)をすることで、今度はvEdgeがインターネットに加えてMPLS回線を使ったWANを使うことができるようになります。この構成ができれば、今までご紹介してきたさまざまなユースケース(アプリケーション種別によるWAN回線の使い分け、アプリケーションのSLAに応じたルーティング、など)をすべて利用することができます。

MPLS CEに足を伸ばして、ハイブリッドなネットワークを構成
MPLS CEに足を伸ばして、ハイブリッドなネットワークを構成

ステップ3: 既存CEルータを巻き取り

最終的にはMPLSのCEルータもvEdgeで巻き取って、全てvEdgeで構成をできればベストです。vEdgeはWAN側においてもBGPやOSPFを喋ることができますので、既存CEルータを置き換えるのに十分な機能を持っています。

既存CEルータをvEdgeで巻き取る
既存CEルータをvEdgeで巻き取る

いきなりこの最終形に持っていければ理想的ではありますが、実際には上記のように徐々に適用の対象を広めていき、最終的に全てをSD-WAN化するのがより現実的でしょう。

LAN側、WAN側両方においてvEdgeのルーティング機能は非常に充実しています。ルーティング機能はSD-WANに固有の話ではないので見落としがちですが、SD-WANへの移行設計をする際に非常に重要な要素になりますので注意するようにしましょう。

いずれにせよ移行期間中には既存ネットワークとの共存が必要になります。具体的にどのような構成を取れば良いのかについては次回に解説をしたいと思います。

Cloud Express:SaaS、クラウド環境をSD-WANで快適に

ViptelaのSD-WANソリューションは単にSD-WANを提供するだけにとどまりません。Viptelaが目指しているのは「クラウド/SaaSに最適化されたWANを提供する」ことです。「リージョナル/ローカルExit」もクラウド/SaaSに最適化されたネットワークを作るための一つの有効な方法であることは前回ご紹介しました。今回ご紹介する “Cloud Express” という機能は、単純なリージョナル/ローカルExitよりもさらにインテリジェントにSaaS/クラウドに最適化されたネットワークを提供することのできる機能で、Viptelaソリューションが持つ非常にユニークな機能の一つです。

課題はSaaS、クラウドへのラストマイル

「ユースケース:アプリケーション対応ルーティング」の回で説明した通り、vEdge間で張られているIPsecトンネルの中にBFDのパケットを流して、各トンネルの品質(遅延、ジッター、パケットロス率)を常に監視しています。フルメッシュなネットワークであればすべてのvEdgeの間でこれらを測定して各トンネルの品質を把握していますので、vEdgeのネットワーク内に関してはどのvEdge(例えばローカル、リージョナル、DC、など)Exitするのが最適であるのかを判断することができます。しかし、出口のvEdgeからSaaSサービスまでのネットワークの品質は分かりませんので、本当にどの出口からExitするのがいいのか判断をすることはできません。一般的にはローカルからExitする方が良好なパフォーマンスが得られる場合が多いと考えられますが、場合によってはDCから抜けた方が良い場合もあるかもしれないわけです。

Cloud ExpressでSaaS、クラウドをより快適に!

Cloud Expressはエンド〜エンドでSaaSアプリケーションの品質を監視します。具体的には、出口となるvEdgeからSaaSアプリケーションまでの遅延などをHTTP pingなどにより監視をして、vEdge内のネットワークの遅延と合計します。これによりSaaSアプリケーションにとって本当にどのExitポイントが最適なのかを判断し、それに基づいたポリシーを自動的に適用することにより、SaaSアプリケーションに最適なネットワークパフォーマンスを提供します。Cloud Expressは、まずはOffice 365、SharPoint、Salesforce.com、Dropbox、Box、WebExなど代表的なSaaSアプリケーションに対応します。

CloudXpress
Cloud ExpressはSaaS、クラウドアプリケーションに最適なパスを提供

Cloud Expressは2016年12月末リリース予定の16.3というソフトウェアリリースから利用可能になります。まだリリース前なので、具体的な画面などはソフトウェアがリリースされてから再度ご紹介をしようと思います。

Viptela SD-WANのオンプレ展開

Viptelaのコントローラコンポーネント(vBond, vSmart, vManage)は通常Viptelaが運用管理しているクラウド(これは現状AWS上にあります)にデプロイして利用するのが一般的です。コントローラのインフラストラクチャの運用管理をViptelaに任せることができるので、サービスを素早く立ち上げることができます。しかし、何かしらの理由でこれらのコントローラコンポーネントを自社設備(オンプレ)に立てたい、または、サービスプロバイダーなどが自前のパブリッククラウド上にデプロイして使いたい、という場合もあるかと思います。Viptelaのソリューションはオンプレ環境でもまったく問題なく利用をすることができます。

コントローラコンポーネントを動作させるハイパーバイザとしては、現在VMware ESXi及びKVMがサポートされており、それぞれOVA形式、QCOW2形式のイメージがが提供されています。2016年末にはこれらに加え、Hyper-V用のサポートが加わる予定です。

これらのコントローラコンポーネントはvEdgeからIP的な到達性さえあれば、パブリッククラウド、プライベートクラウド、オンプレ、どこにデプロイしても構いません。コントローラをオンプレにデプロイした際でも、Viptelaソリューションの持つすべての機能を利用することができます。このようにオンプレ環境にコントローラを置くことができますので、インターネット接続のない環境(完全クローズドなネットワーク環境)でもViptela SD-WANソリューションを使うことができます。

オンプレ環境でコントローラを立てる際には、vBond、vSmart、vManageで以下のようなスペックを満たす仮想マシン環境を用意する必要があります。

  • vBond
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 8 GB 1 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 2 4 GB 8 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 2 4 GB 8 GB 5 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 4 8 GB 8 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vSmart
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 16 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 4 8 GB 16 GB 5 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 4 16 GB 16 GB 7 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 8 16 GB 16 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vManage
サイト数 vCPUs RAM OS用ボリューム DB用ボリューム 帯域 vNICS
1-250 16 32 GB 16 GB 500 GB, 1500 IOPS 25 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
251-1000 32 64 GB 16 GB 1TB, 3072 IOPS 100 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
1001- 32 64 GB 16 GB 1TB, 3072 IOPS GB 150 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)

SD-WANのスケーラビリティ

ViptelaのSD-WANはIPsecによるオーバーレイネットワークです。今回はこのオーバーレイネットワークのスケーラビリティについて少し考えてみたいと思います。

オーバーレイネットワークの進化の方向性

オーバーレイ技術の歴史を振り返ると、その技術の進化の方向性としては、私は3つほどあるのではないかと思っています。

オーバーレイネットワークの進化の方向性
オーバーレイネットワークの進化の方向性

一つはカプセル化技術の進化です。古くはGREから、そしてその後もさまざまなカプセル化技術(IP in IP、MPLS、L2TP、VXLANなど)が生まれてきました。オーバーレイの二つ目の進化の軸はシグナリングです。こちらも過去さまざまな方式が生まれましたが、歴史的に振り返ってみると、勝者はBGP(あるいはその拡張)ということになるのではないかと思います。MPLS/BGP VPNの成功や最近のEVPNなどがそれを証明しているように思います。3つ目の進化の軸はスケーラビリティです。今回はここに注目してみたいと思います。

なぜフルメッシュが困難なのか?

一般的に大規模なフルメッシュのオーバーレイネットワークを構築するのは大変困難です。大きく分けると2つ理由あります。一つは設定(プロビジョニング)の困難さです。初期設定時に多くの工数がかかるものもちろんですが、むしろ大変なのはサイトを追加する時です。フルメッシュを維持するためには、対向の全てのノードにも再設定をしなければいけません。初期構築時は仮に頑張れても、運用に入った後に全てのノードの再設定をしなければいけないのは大きな苦痛を伴います。もう一つの困難さはステート維持です。使用するオーバーレイ技術が何かしらのステートを持つ場合、nノードからなるフルメッシュなネットワークでは、全体としてn^2のオーダー(O(n^2))のステートを維持管理していかなければいけません。IPsecの鍵もこのようなステートの一種です。IPsecのフルメッシュネットワークが難しいのは上記の二つの理由に依るところが大きいと言えます。

サイト追加時のプロビジョニングの苦痛を解決する策としては、過去にも提案がありました。例えばRFC6224です。提案者の名前から通称「Kompella方式」とも呼ばれる方法です。

Kompella方式
Kompella方式

この方式のポイントは「オーバー・プロビジョニング」をする、という点にあります。この方式では、例えばFrame RelayのネットワークであればDLCIをあらかじめ余計に割り当てておき、サイトが追加になった際にローカルの設定変更だけで残りのリモートサイトには変更が必要ないように工夫されています。

また、CoSine CommunicationsのIPSXは仮想ルータをIPsecで結んでオーバレイネットワーク(VPN)を作ることができました。

CoSine IPSX
CoSine IPSX

CoSineのInVisonというNMSには自由にハブ&スポークやフルメッシュのIPsecを構成する機能がありましたので、ある意味プロビジョニング上の問題は解決することができていたとも言えます。2000年当時、1仮想ルータで1000のIPsecトンネルを終端することができた(ハブ&スポーク)を構成することができた)のはかなり頑張っていたのではないかと思いますが、では1000個の仮想ルータでフルメッシュのIPsecトンネルを作れたかというと、それは全くもって不可能な話でした。

IPsecをスケールさせるのが難しい理由

IPsecをスケールさせるのが難しいのには二つの理由があります。IPsecの鍵交換プロトコルであるIKEで使われる処理(Diffie Hellmanの鍵交換)が非常に重たい処理であるという点。Diffie Hellmanの鍵交換がどれくらい重いのか、少し考えて見ましょう。

https://www.cryptopp.com/benchmarks.html を見ると様々な暗号化アルゴリズムのベンチマーク結果が出ています。この中からAES-CBC-256bitとDiffie Hellmanの鍵交換の結果を以下に掲載します。

Diffie Hellman鍵交換とAESによる暗号化処理の比較
Diffie Hellman鍵交換とAESによる暗号化処理の比較

AESなどの暗号化アルゴリズムの性能はスループット(MiB/s)で測るのに対し、Diffie Hellmanの鍵交換は1オペレーションの実行時間(msec/operation)で測りますので単純に比較はできませんが、仮に1500バイトのデータをAES-CBC-256bitで暗号化するのを1オペレーションとみなしてそれにかかる時間を計算して見ると上記のようになります。Diffie Hellmanの鍵交換はAES-CBC-256bitに比べると二桁ほど重い処理であることがわかります。このようにDiffie Hellmanの鍵交換処理は非常に重たい処理なのです。

IPsecのフルメッシュネットワークが難しいもう一つの理由が、IKEによって作られる鍵が “pair-wise” である、という点です。鍵がpair-wiseであるというのは、相手が異なれば異なる鍵を使う、すなわちペアごとに異なる鍵が存在するということです。nノードのフルメッシュのネットワークの場合にはO(n^2)の個の鍵が存在することになります。暗号鍵があるということは、必ず鍵の更新(Rekey)をしなければいけないということを意味します。どんな暗号化システムでも、同じ鍵を使い続けていけば暗号強度は必ず低下してくるからです。上記のように重たい処理であるDiffie Hellmanの鍵交換を全体としてO(n^2)回やらなければいけないのでとても大変です。O(n^2)問題を甘く見てはいけません。例えば1,000ノードのフルメッシュを構成するとおよそ500,000のペアが存在することになります。仮にIKEのPhase 1のRekey時間を24時間としましょう。24時間はたった86,400秒しかありません。この間に500,000回の鍵交換をしなければいけないわけですから、毎秒5〜6回のペースで鍵交換をし続けなければいけないことになります。3,000ノードのフルメッシュなら毎秒50回以上になります。

このように非常に重たい処理のIKEですが、IPsecにとって本当に必須のものなのでしょうか? 実際、多くの場合IPsecを使う際にはIKEが使われます。しかし、IPsecにとってIKEが唯一無二の鍵交換プロトコルというわけではありません。実は、IPsecにはKINKやPhoturisといった別の鍵交換プロトコルもあります。極端な話、手動で鍵を設定することもできるわけです(もちろん鍵の更新をしなければセキュアとは言い難いですが・・)。つまりIPsecにとってIKEは必須ではないのです。

IKEはセキュアなチャネルがないところにセキュアなチャネルを開設するプロトコルです。従ってすでにセキュアなチャネルがあれば、必ずしもIKEを使う必要はないという点に注意してください。「Viptelaのアーキテクチャー」の回で、コントローラとvEdgeの間のコントロールチャネルはTLSもしくはDTLSが使われているというご説明をしました。すでにそこにセキュアなチャネルがあるわけですから、それを使えば良いのです!

Viptelaによるスケーラブルなオーバーレイネットワーク

ViptelaのコントローラであるvSmartはBGPをベースに拡張をされたOMP (Overlay Management Protocol)というプロトコルを使って経路の配布を行っており、OMPはTLS/DTLSによるセキュアなチャネルの上で動いています。vSmartはBGPのルートリフレクタと同様の役割を果たしていて、経路情報をすべてのvEdgeに配布するようになっています。実はこのOMPは、経路だけではなくIPsecで使う鍵の配布も行えるように拡張をされているのです。このためOMPでの鍵交換は非常にシンプルなものになっています。

統合されたルーティングとセキュリティ
統合されたルーティングとセキュリティ

vEdgeは自分宛に送るパケットの暗号化に使う鍵を自らランダムに生成し、それをvSmartに送ります。すると、vSmartは他のすべてのvEdgeにその鍵を配布してくれます。これだけで鍵を更新することができるわけです。

各vEdgeがやらなければいけないのはランダムな鍵を自ら生成するだけです。これは非常に軽い処理ですので、例えば極端に短い時間(例えば30秒)で鍵更新をするということも可能です。IPsec/IKEのフルメッシュネットワークで30秒で鍵更新をするのはほぼ不可能だと思いますが、Viptelaではそれが可能です。Viptelaのアーキテクチャでは鍵の更新は経路のアップデートとほぼ同程度の処理です。BGPの環境で30秒に一度程度の経路アップデートをさばくのはさほど大変なことではないのはみなさん肌でご理解いただいていると思います。ViptelaのIPecの鍵更新は経路の更新と本質的に同じ処理ですので、BGPと同様のスケーラビリティをIPsecについても実現できる、と考えていただければいいかと思います。

また、鍵はvEdge毎に1つしかないことも注目すべき点です。したがって鍵はpair-wiseにはならず、IKEの時のような鍵の個数をO(n^2)からO(n)に大幅に減らすことができるのでスケーラビリティを確保することができます。

今日の多くのSD-WANソリューションは、IPsecによるオーバーレイネットワークを使ったものが多いです。SD-WANソリューションには通常何かしらのコントローラがありますので、プロビジョニングに関する問題は多くの場合解決されていると考えて良いと思います。しかし、維持しなければいけないステートの問題、特にIPsecの鍵交換のスケーラビリティに関して未解決のものが多いです。ViptelaのSD-WANソリューションのオーバーレイネットワークは、IKEを使わず鍵もpair-wiseに作らないので、他のIPsec/IKEベースのオーバーレイネットワークに比べると遥かにスケールする仕組みになっています。

Viptelaのオーバーレイネットワーク
Viptelaのオーバーレイネットワーク

実際に、ViptelaのSD-WANを使っているお客様の中には3,000拠点のIPsecフルメッシュなネットワークを実現されているされているお客様がおられます。そのお客様の利用事例についてはまた日を改めてご紹介をしたいと思います。