- ライター：渡部 満幸
- 2004年4月1日、ネットワンシステムズ入社。
応用技術、製品主管部門、製品担当業務で技術者として15年以上勤務。
主としてCisco製ローエンド～ハイエンドルータ製品の技術担当として15年の経験があります。
Cisco製だけでなくJuniper製、Nokia製ハイエンドルータの技術担当としても兼務経験があります。
現在はCisco製ロー/ミドルレンジルータ、Catalystスイッチ製品群およびVMware SD-WAN (VeloCloud)の技術担当。
目次
みなさまこんにちは。
ネットワンシステムズの渡部です。
接続手順編:VeloCloudとCiscoルータをIPSecでつないでみたに続き、後半の通信確認編をご紹介します。
前回はVeloCloud Gateway(以下、VCG)とCiscoのルータをIPSec VPNで接続するまでをご紹介しました。
今回はルーティングの設定、PingやTraceRouteを使用したLAN to LAN通信、制限事項や注意点、回避策をご紹介します。
VeloCloud Gatewayについて
本題に入る前に、VCGについて簡単に補足します。
VCGは世界各地に分散配置されたクラウドサーバです。
図1. 世界各地に存在するVCG(イメージ)
同じ国の中に複数のVCGが配置されているケースもあります。
それぞれがVeloCloudネットワークに接続され、相互に連携して通信を仲介します。
VeloCloud Edge(以下、VCE)やNon-VeloCloud Site(以下、NVS)、その他各種のクラウドサービスが接続されるVCGは、地理的な距離(近さ)やVCGそのものの負荷状態など、さまざまなメトリックによって自動的に最適なものが選択されます。
たとえば、同じ地域に設置されているVCEやNVSであっても、接続先として異なるVCGが選択されることがあります。
前回までのおさらい
接続手順編では以下の構成でVCGとNon-VeloCloud SiteをIPSec VPNで接続しました。
図2. 前回までの構成図
この段階では、Cisco-1とCisco-2は両方ともVCG-2に収容されていることを覚えておいてください。
概要
今回の通信確認編では、ルーティングの設定、ルーティングテーブルの確認方法、VCE/Cisco-1/Cisco-2に接続されているPCからのPingやTraceRouteによる通信試験と、順を追ってご紹介します。
また、接続先のVCGを変更*し、どのように変化するのかを確認します。
図3. 同じVCGに接続している場合の通信(左)と異なるVCGに接続している場合の通信(右)
上記の2パターンでそれぞれ通信を行い、その違いについて説明します。
* 通常、接続先のVCGを利用者が意図して選択したり、変更したりすることはできません。
今回は特別な操作を行って変更しています。
ルーティングの設定
VeloCloudネットワーク内のルーティング設定や状態の確認は、VeloCloud Orchestrator(以下、VCO)から行います。
VCO > Configure > Overlay Flow Control
(Monitor > Routingではないことに注意してください。)
VCOにNVSを登録する際にSite Subnetsを設定してありますので、Cisco-1とCisco-2のLAN側Subnet情報はVeloCloudネットワーク内で共有されています。
次にCisco-1のルーティングを確認します。
VCOが提供するNVS用Configテンプレートには、VeloCloudネットワークと通信するためのルーティング設定は含まれていません。
そのため192.168.101.0/24の経路が見当たりません。
VCEとCisco-2宛ての通信を確認しますので、集約した192.168.0.0/16を設定しておきましょう。
Cisco-2にも同様にStatic Routeを設定します。
これで、それぞれのPCはお互いに通信できるはずです。
パターン1: 同じVCGに接続している
前回の記事の中で、NVSがどのVCGに接続しているのかは、IPSecの接続先IPアドレスで確認できることをご紹介しました。
図4. NVS Configテンプレートの例
show crypto sessionコマンドの出力からCisco-1とCisco-2がそれぞれどのVCGに接続しているのかを確認します。
両方ともx.x.2.2、つまりVCG-2に接続しています。
それでは、VCEのPCからCisco-1とCisco-2のPCにそれぞれPing/TraceRouteを実行してみます。
PingもTraceRouteも期待どおりVCG-2を経由しています。
次にCisco-1のPCからCisco-2のPCへ向かって実行します。
VCGのIPアドレスが表示されませんが、通信はできているようです。
同じVCGに接続しているNVS同士では、VCGでの折り返しによるIPSec VPN通信が可能でした。
パターン2: 異なるVCGに接続している
それではここで特別な操作を行い、Cisco-1の接続をVCG-1(x.x.2.1)へ変更し、Cisco-2はVCG-2に接続したままにします。
この状態で同じようにVCEのPCからCisco-1とCisco-2のPCにそれぞれPing/TraceRouteを実行します。
Cisco-1へはVCG-1(x.x.2.1)、Cisco-2へはVCG-2(x.x.2.2)を経由して通信していることがわかります。
次にCisco-1のPCからCisco-2のPCへ向かって実行します。
通信できません。
この動作、実は期待されたものです。
VeloCloudでは異なるVCGに接続しているNVS間の通信をサポートしません。
(2020年08月31日現在、Version 3.4.3における情報です。)
まとめ
今回の記事では、VeloCloudネットワークとNVSをIPSec VPNで接続し、互いに通信できるかを確認しました。
ルーティングプロトコルはStatic Routeを使用しました。
これはVeloCloudネットワークとNVSの間で利用可能な方式がStatic Routeのみであるためです。
OSPFやBGPといったダイナミックルーティングプロトコルについては、現時点ではサポートしていません。
また、同じVCGに接続したNVS同士であれば通信が可能ですが、異なるVCGに接続したNVS間では通信できないこともご紹介しました。
冒頭でのご紹介のとおり、NVSの接続先VCGは必ずしも同じとは限りません。
実態としては異なるVCGに収容されることのほうが多いでしょう。
複数のNVSをVeloCloudネットワークに参加させ、なおかつNVS間通信の必要がある場合、下図のようにNVS側でVPNハブを用意するといった考慮が必要です。
図5. DMVPNなどのHubをNVSとしてVCGを接続する
おわりに
2回にわたりVeloCloudとCiscoルータとの接続方法についてご紹介しました。
だいぶプラクティカルに寄った内容でしたが、今回の内容がみなさまがVeloCloudネットワークを設計する際のお役に立てば幸いです。
免責事項
ご紹介している内容は2020年08月31日現在、VeloCloud Version 3.4.3における動作です。
今後のアップデートにより動作が変更される可能性があります。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
