はじめに

普段、Ciscoの物理NW機器やAWSのDirect Connectなどを触っています。
ネットワークエンジニアとして、日々の設計や検証業務の中で「もっと自由に試せる環境があれば...」と感じたことはありませんか？
ネットワークの検証環境を用意するにはこんなハードルがあると思います。

本番環境と同様の物理ネットワーク機器を複数用意するのはコストが高すぎる
本番環境で様々なベンダーのネットワーク機器を使用しているため、検証用に本番機器と同一のネットワークOSを用意するのが大変
仮想環境を用意しようにも、ネットワークの仮想環境に関する情報はインターネット上に少ない

本記事では、これらの課題を解消するためにAWSで簡単にネットワーク検証環境を構築する方法を紹介したいと思います。

なぜAWSなのか

本記事では、ネットワーク検証環境をネットワークOSのAMIを利用したEC2で構築します。
ではなぜAWSで構築するのか、他のツールとの比較も交えながらメリットを説明していきたいと思います。

ネットワークの仮想環境構築ツールや検証ツールは、ざっと調べただけでも以下が挙げられます。

Cisco Packet Tracer
Cisco Modeling Labs
GNS3
ESXi
ContainerLab
EVE-NG

これらのツールは様々な長所がある反面、マルチベンダーなネットワーク検証環境を素早く用意するにはいくつかの弱点があります。

例えば、

Cisco Packet TracerやCisco Modeling LabsはCisco以外の製品には非対応である
GNS3やContainerLabは無料で本番環境の機器により近いOSを利用できるが、OSを自分で集めてくる必要がある、複雑なネットワークトポロジを再現するにはPCにRAMを大量に搭載する必要がある
ESXiはハイスペックな物理サーバが必要になり、初期コストがかかる
などが挙げられます。

AWSは、反対にこれらのツールの弱点を克服し、

マルチベンダーのネットワークOSのAMIを様々なバージョンでAWS MarketPlaceから入手可能なので、個人でマシンイメージを収集・作成する必要がない
EC2を起動するだけなので、マシンイメージを動かす環境の構築までが早い
ハイスペックなローカル環境を用意する必要がない

というメリットがあります。

以上のようにAWS上で構築することで、本番環境と同様のネットワークOSを利用した検証環境を素早く用意することができます。

AWSを利用したネットワーク検証環境構築手順

それでは、実際にAWSを利用したネットワーク検証環境の構築手順について説明していきます。
全体的な手順は以下のとおりです。

EC2インスタンスを配置するVPC・サブネット・ENIを作成する
AWS MarketPlaceで利用したいOSのAMIを入手する
各サブネットにEC2インスタンスを作成する
インスタンスに接続し、ネットワーク機器設定のConfigを流し込む

各手順の詳細についてみていきます。

EC2インスタンスを配置するVPC・サブネット・ENIを作成する

はじめに、EC2インスタンスとENIを配置するVPCとサブネットを作成していきます。
検証環境のネットワークで同じセグメントとなるインタフェースが同じサブネットになるように、異なるセグメントのインタフェースは異なるサブネットになるように、適切な数のサブネットを作成するのがおすすめです。

例として、以下の図のように3台のルータを直列に並べる場合を考えます。
Router-AのGi2とRouter-BのGi1が直接接続され、またRouter-BのGi2とRouter-CのGi1が直接接続されています。

この場合は以下の図のように、Router-AとなるEC2のENIとRouter-BとなるEC2のENIが同じサブネットに、Router-BのENIとRouter-CのENIが同じサブネットに所属できるように作成するのがいいでしょう。

サブネットの大きさはネットワークセグメントの大きさに揃えるのがいいですが、以下の2点に注意する必要があります。

各サブネットで先頭のIPアドレス3つと末尾のIPアドレスはAWS側で予約されているため利用不可
また、サブネット内にEC2インスタンスを配置する場合は、利用可能なIPアドレスがさらに少なくなる

とはいえ、ルータ間でピアを張るだけであればIPアドレスを2つしか必要ないのに対して、サブネットは/28以上の大きさで作成する必要があるので、基本的には/28でサブネットを作成するのが良さそうです。

最後にENIを作成します。ENIを作成する際は、VPC・サブネット・IPアドレスを指定します。
IPアドレスは実際にネットワーク機器のインタフェースで利用するアドレスを指定します。
複数のENIを作成することになるので、分かりやすい名前をつけるのがいいでしょう。

AWS MarketPlaceで利用したいOSのAMIを入手する

VPCとサブネットを作成できたら次に、検証したいネットワークOSを入手します。
ネットワークOSのAMIを入手するためにAWS MarketPlaceへ行きます。「製品を検出」のリンクから、入手可能な製品のリストを見ることができます。

今回はCiscoのCatalyst8000Vを例に見ていきたいと思います。
Catalyst8000Vで検索し、Cisco Catalyst 8000V SD-WAN & Routerを選択します。

Catalyst8000VはBYOLとPAYGの2種類がありますが、国内ではBYOLのみが利用可能です。BYOLを利用した場合、AWS利用料にライセンス費用は含まれませんが、個人でライセンスを用意する必要があります。(60日間のFree Tierがあるので試すことは可能です)

この画面では製品の概要や料金、バージョンなどを確認することができます。
View purchase optionsを押下して契約画面に進み、契約後にAMIを配置する設定画面に進みます。画面右側には価格の情報が掲載されています。BYOLなのでソフトウェア利用料は含まれませんが、EC2インスタンスの利用料が発生します。大きめのインスタンスがを利用することになるので、最低限の時間だけ起動するなど注意が必要です。

設定画面では、ネットワークOSのバージョンと配置するリージョンを選択することができます。

各サブネットにEC2インスタンスを作成する

AMIを契約したら、各サブネットにEC2インスタンスを作成します。
AWS MarketPlaceの画面からEC2インスタンスの作成画面に遷移することができますし、直接EC2インスタンス作成の画面でAMIを選択することも可能です。

EC2インスタンスを作成する際、インスタンスもサブネット内のIPアドレスを1つ消費することに留意が必要です。
インスタンスのIPアドレスは、「高度なネットワーク設定」のネットワークインターフェース1のプライマリIPに記入することで指定可能です。

また、「ネットワークインターフェースを追加」を押下することで、インスタンスにアタッチするENIを追加することができます。「新しいインタフェース」で作成済みのENIを選択します。この時、ネットワークOS上のGigabitEthernetと順番が連動しているので、EC2のネットワークインタフェース2にはGigabitEthernet2用のENIを、ネットワークインタフェース3にはGigabitEthernet3用のENIをという風にアタッチしていきます。

インスタンスに接続し、ネットワーク機器設定のConfigを流し込む

最後にインスタンスへ接続し、ネットワーク機器設定のConfigを流し込んでいきます。
ネットワークOSの場合は、Systems Mangerのエージェントをインストールできないため、インスタンスへ直接Session Managerで接続することができません。そのため、ローカルからインスタンスへ直接SSHするか、Session Managerで接続可能な踏み台インスタンスからSSHする必要があります。
また、パスワードでのログインを設定するまでは、SSH接続でEC2作成時に取得したキーペアを利用する必要があります。

AWSで構築する際に注意事項・Tips

ネットワーク初期設定の自動化

EC2ではインスタンス作成時に、Uesr Dataを記入することでスクリプトを自動実行することができます。
例えばSSHの初期設定や、すでに作成時みのConfigがある場合はUser Dataに記載してからインスタンスを立ち上げることで設定を簡素化できます。
私の場合は以下の記事を参考に、SSHの初期設定をUser Dataに記載しました。

GigabitEthernet1について

インスタンスに接続してネットワーク機器のConfigを確認すると、既にインタフェースが一つあることを確認できます。
上記の例で紹介したCatalyst8000Vの場合、GigabitEthernet1が最初から存在しています。
このインタフェースはEC2インスタンス自体のIPアドレスと対応しており、IPアドレスを指定せずにインスタンスを立ち上げた場合は、DHCPの設定がされています。また、NATの設定もされています。

interface GigabitEthernet1
 ip address dhcp
 ip nat outside
 negotiation auto
 ipv6 address dhcp
 ipv6 enable
 ipv6 nd autoconfig default-route

ネットワークの検証をする上で、初期インタフェースを利用しても問題はないです。
しかし、既にNATの設定がされており、また仮想ルータのグローバルのルーティングテーブルと紐づけられています。
そのため、グローバルのルートテーブルと論理的に分離されたネットワーク環境を用意する場合は、初期インタフェースは利用せずにENIをアタッチすることでインタフェースを必要な数だけ増やし、またVRFを作成して増設したインタフェースと紐づける必要があります。

Static RouteのNextHopについて

仮想ルータでStatic Routeを設定する際、NextHopの指定方法には注意が必要です。
同じサブネット内のIPアドレスは仮想ルータからconnectedで見えていますが、
異なるサブネットや異なるVPCのIPアドレスはルーティングプロトコルを利用して学習しない限り、仮想ルータのルーティングテーブルには載りません。
そのため、異なるサブネットや異なるVPCのIPアドレスに向けてStatic Routeを設定する場合、NextHopにインタフェースを指定しても正しくルーティングすることができません。

異なるサブネット、異なるVPCに向けてStatic Routeを設定する場合は、各サブネットのセグメントの先頭のIPアドレスをNextHopとして指定する必要があります。
これは、先頭のIPアドレスはVPCルータ用のIPアドレスとしてAWS側で予約されており、このアドレスをNextHopとしてStatic Routeを切ることで、サブネットに紐づけられたルートテーブルを参照して、別サブネットや別VPCへルーティングされるようになるためです。

例として、以下の画像のように仮想ルータにて192.168.0.20向けのStatic Routeを設定する場合を考えます。
仮想ルータは、GigabitEthernet2のENIがある192.168.0.0/28のサブネット内のIPアドレスはconnectedとしてルーティングすることができます。
しかし、192.168.0.16/28は仮想ルータからは見えません。そのため、Static Routeを設定する際にNextHopをGigabitEthernet2にするのでは疎通できず、NextHopを192.168.0.1に指定する必要があります。

セキュリティグループの設定について

検証環境が構築できたらEnd-to-Endで疎通確認を実施することが多いと思いますが、初回では疎通できない場合が多々あります。自分の場合は、その原因のほとんどがセキュリティグループの設定漏れでした。
AWS上でネットワーク環境を構築する場合、以下の2つの通信を考慮する必要があります。

実際に通信したい経路の送信元IPアドレスと宛先IPアドレスが各セキュリティグループのインバウンド・アウトバウンドで許可されているか
DRPを利用する場合、ピアを張る部分でDRPの通信が許可されているか

特に2点目は考慮が漏れていたことが多かったです。セキュリティグループのインバウンドで自身のセキュリティグループを指定し、全てのENIに同一のセキュリティグループをアタッチすると設定考慮漏れによる疎通NGが減るのでおすすめです。

例として、以下の図のように仮想ルータ間でBGPを利用する場合を考えます。
この場合、各ENIのセキュリティグループで共通して、インバウンドルールで172.16.0.0/24を、アウトバウンドルールで10.0.0.0/24を許可する必要があります。
さらに仮想ルータAのGigabitEthernet3と仮想ルータGigabitEthernet2のENIにアタッチするセキュリティグループでは、BGPの通信を許可するために179番ポートで相手のIPアドレスをお互いに許可する必要があります。

End-to-Endの通信に関する許可設定は全ENIで共通になります。しかしBGPの通信の許可設定はBGPピアを張るIPアドレスがピアごとに変わりますので、ネットワークトポロジが複雑になるほど、BGPの許可設定をIPアドレス指定で実施するのは管理が煩雑になり、設定漏れが発生しやすくなります。VPCが同じENIには同じセキュリティグループをアタッチして、自身のセキュリティグループからの179番ポートを許可することで、ピアごとのIPアドレスの差分の個別設定を避けるのがいいでしょう。

おわりに

ネットワーク検証環境をAWS上に構築する方法をご紹介しました。
AWS MarketPlaceを利用すると様々なベンダーのネットワークOSが過去のバージョンに遡って利用可能なため、検証環境をさくっと作って検証するのには便利だと思います。
また、今回利用したCatalyst8000Vは60日間のFree Tierがあるため、まだ試したことがない方は一度お試ししてはいかがでしょうか。