１．はじめに

私はネットワークの勉強にGNS3を愛用しています。

以前、Qiitaで「【神ツール】ネットワーク勉強の最適解！GNS3について」という記事を書きました。

本を読んで仕組みを理解することも大切ですが、ルータを実際に起動し、設定を入れ、pingを飛ばし、経路が切り替わるところまで確認すると、理解度が一気に上がります。

しかし、少し複雑なネットワークをGNS3で作ろうとすると、

機器を配置する
配線する
IPアドレスを考える
各機器のコンフィグを作る
疎通確認する

と、勉強を始めるまでの準備にかなり時間がかかります。

そこで今回は、ネットワーク構成図の写真をCodexに渡して、

「これをGNS3でシミュレーションしたいです。プロジェクトを作成して」

とお願いしてみました。

結果は……

本当にGNS3プロジェクトができた！！！

しかも、機器を並べただけではなく、OSPF、eBGP、VRRP、DMVPN、ファイアウォールの設定から端末間の疎通確認までできました。

今回は、CodexからGNS3検証環境を自動作成し、実際に動作確認した内容を紹介します。

２．今回Codexへお願いしたこと

今回、Codexへ渡したものは、ネスペ問題集のネットワーク構成図を撮影した画像です。

構成図を見ながら機器や接続を一つずつ説明したわけではありません。

問題集を写真に撮って、その画像を渡すだけ！！！

Codexが画像から、機器名、接続関係、VLAN、OSPFの範囲などを読み取り、GNS3のトポロジへ変換しました。

Codexへ渡したネスペ問題集のネットワーク構成図

最初の依頼は、とてもシンプルです。

添付したネスペ問題集の画像を確認してください。
これをGNS3でシミュレーションしたいです。プロジェクトを作成して。

最初から完璧なプロンプトを書いたわけではありません。

出来上がった内容を見ながら、次のように追加でお願いしました。

ファイアウォールの仮想イメージがあるけど？

GNS3 VMは第4オクテット102しか使いません。

トポロジにネットワークアドレスや端末のアドレスを記載して。
見た目が悪くならないように、第4オクテットだけ表示でもよいです。

途中で構成図との違いも見つかりましたが、その都度Codexへ伝えて修正しました。

会話しながらラボを完成させられる！！！

この使い方が非常に便利でした。

画像を渡してGNS3プロジェクトの作成を依頼

３．作成されたGNS3ラボ

最終的に、次の規模のラボになりました。

種類	台数
ルータ／L3スイッチ	8
ファイアウォール	1
Ethernet switch	8
VPCS	9
合計	26

リンク数は27本です。

Codexが構成図から作成したGNS3トポロジ

再現した主な機能はこちらです。

大阪本社、東京支社、C社データセンター／SaaS
広域イーサ網上のOSPF
R11、R21、R31によるDMVPN／IPsec
東京LANのVRRP
C社SaaS接続用のeBGP
prefix-list、route-mapを使ったOSPF・BGP間の経路再配送
VLAN 10、20、30、40
ファイアウォールによるインターネット接続

さらに、Codexは次のファイルも作成しました。

.gns3プロジェクトファイル
ルータ／L3スイッチのstartup-config
VPCSのIPアドレス設定
ファイアウォール用のCLI設定
ルータ／L3スイッチへ設定を投入するPythonスクリプト
ファイアウォールへ設定を投入するPythonスクリプト
トポロジへIPアドレスを記載するPythonスクリプト
起動手順、確認コマンドをまとめたREADME

構成図からコンフィグまで作ってくれる！！！

これはかなり助かります。

なお、ルータやファイアウォールの仮想イメージそのものをCodexが用意するわけではありません。利用権のあるイメージを、自分のGNS3環境へ登録しておく必要があります。

今回は、GNS3 VMのアドレスを192.168.100.102へ統一し、登録済みのルータとファイアウォールの仮想イメージを使用しました。

４．アドレス設計

元の構成図には、全てのIPアドレスが書かれていたわけではありません。

そこで、Codexにラボ用のアドレスを割り当ててもらいました。

用途	ネットワーク	主なアドレス
インターネット	`198.51.100.0/24`	ファイアウォール `.10`、試験端末 `.1`
広域イーサ網	`10.0.0.0/24`	R10 `.10`、R20 `.20`、R30 `.30`
DMVPN underlay	`203.0.113.0/24`	R11 `.11`、R21 `.21`、R31 `.31`
DMVPN Tunnel	`10.255.1.0/24`	R11 `.11`、R21 `.21`、R31 `.31`
VLAN 10	`10.10.10.0/24`	L3SW10 `.1`、ファイアウォール `.254`
VLAN 20	`10.10.20.0/24`	L3SW10 `.1`、R10 `.10`、R11 `.11`
VLAN 30	`10.10.30.0/24`	GW `.1`、サーバ `.10`
VLAN 40	`10.10.40.0/24`	GW `.1`、PC `.101`、`.102`、`.111`、`.112`
東京LAN	`10.20.20.0/24`	VRRP `.1`、R20 `.20`、R21 `.21`
SaaS eBGP	`172.30.0.0/24`	PE `.1`、R30 `.30`、R31 `.31`
SaaSサービス	`10.100.0.0/24`	PE `.1`、APP `.100`

ネットワークアドレスと端末IPをトポロジ上へ直接表示

トポロジ上にはネットワークアドレスを直接記載し、各端末の下には.101のように第4オクテットだけを表示しました。

全てをフルアドレスで書くと、せっかくの構成図が文字だらけになります。

分かりやすさと見やすさの両立！！！

細かいところですが、検証中に迷子にならないためには重要でした。

５．実際に疎通確認してみる

設定投入後、OSPF、eBGP、DMVPNの隣接状態を確認しました。

確認に使用した主なコマンドはこちらです。

show ip ospf neighbor
show ip route
show ip bgp summary
show vrrp brief
show crypto isakmp sa
show crypto ipsec sa

OSPF

R10では、L3SW10、R11、R20、R30とのOSPF隣接関係を確認できました。

R21、R31は、DMVPNのTunnelインタフェースを通してハブルータとのOSPF隣接関係がFULLになりました。

eBGP

R30とC-SAAS-PE、R31とC-SAAS-PEのeBGPピアが確立し、SaaS側ネットワークの経路を学習できました。

OSPFの隣接関係とeBGPピアの確立を確認

東京LANのVRRP

東京LANのデフォルトゲートウェイは、R20とR21で構成したVRRPの仮想IPです。

デフォルトゲートウェイ：10.20.20.1
R20：10.20.20.20
R21：10.20.20.21

端末は、R20とR21のどちらがMasterになっているかを意識せず、10.20.20.1をデフォルトゲートウェイとして利用できます。

東京LANのデフォルトゲートウェイをVRRPで冗長化

端末間のping

実際に次の疎通を確認しました。

送信元	宛先	結果
大阪PC `10.10.40.101`	デフォルトゲートウェイ `10.10.40.1`	成功
大阪PC `10.10.40.101`	SaaS `10.100.0.100`	成功
東京PC `10.20.20.100`	VRRP仮想IP `10.20.20.1`	成功
東京PC `10.20.20.100`	SaaS `10.100.0.100`	成功
SaaS `10.100.0.100`	大阪PC `10.10.40.101`	成功

拠点をまたいだ端末間通信に成功

最初の1パケットだけARP解決などでタイムアウトする場合がありますが、その後は正常に応答しました。

本当に通信できた！！！

構成図の写真から始まったラボが、最後には大阪、東京、SaaS間で通信できる状態になりました。

６．途中でハマったところ

もちろん、最初から全て一発で動いたわけではありません。

DMVPNの設定

使用したIOSでは、NHRP authenticationの文字数制限や、利用できるISAKMP Diffie-Hellmanグループに制約がありました。

そのため、実機のコンソール出力をCodexが確認しながら、次のように修正しました。

NHRP認証文字列を8文字以内へ変更
ISAKMPのDH groupを対応している値へ変更
IPsec profileを定義してからTunnelへ適用

作って終わりではなく、動作を見ながら直す！！！

AIが生成した設定を、そのまま正しいと思い込まないことが大切です。

コンソールログ、隣接状態、経路表、ping結果を確認し、想定と違えば修正する。この作業自体がネットワークの勉強になりました。

７．ネスペ等のネットワーク勉強に最適

ネットワークスペシャリスト試験では、用語の暗記だけでなく、構成図、経路制御、冗長化、障害対応を読み解く力が必要になります。

今回のラボだけでも、次のような検証ができます。

OSPFコストを変更すると、どの経路が選ばれるか
R20を停止すると、VRRPのMasterはどう切り替わるか
eBGPで受信した経路がOSPFへどう再配送されるか
広域イーサ側を停止すると、DMVPN経路へ切り替わるか
route-mapやprefix-listを変更すると、経路表がどう変わるか

おすすめの進め方はこちらです。

正常時の経路を予想する
showコマンドで現在の状態を確認する
機器やリンクを停止する
経路や隣接状態がどう変わるか確認する
なぜその結果になったか説明する
設定を戻して、もう一度試す

ネットワークは壊して覚える！！！

もちろん、仮想環境の中だけでお願いします。（笑）

GNS3なら、実環境ではできない障害試験を何度でも繰り返せます。

ただし、GNS3だけで試験対策が完結するわけではありません。過去問や参考書で理論を学び、その内容をGNS3で確かめる組み合わせがおすすめです。

８．Codexへ依頼するときのポイント

構成図をラボ化したい場合は、次の情報を伝えると精度が上がります。

構成図や要件
使用したいルータ、スイッチ、ファイアウォール
GNS3へ登録済みのイメージ
使用するGNS3 VM
再現したいルーティングプロトコル
確認したい正常系、障害系のシナリオ

例えば、次のように依頼できます。

添付したネットワーク構成図をGNS3プロジェクトにしてください。

条件：
- 登録済みのルータとファイアウォールを使用する
- OSPF、eBGP、VRRP、DMVPN/IPsecを設定する
- 全ノードを指定したGNS3 VMへ配置する
- 各端末から疎通確認できるようにする
- トポロジへネットワークアドレスと端末IPを記載する
- 障害試験の手順と確認コマンドをREADMEへまとめる

最初は短い依頼でも問題ありません。

生成された内容を確認して、

この接続が構成図と違います。

各ネットワーク機器へ設定を投入してください。

のように、具体的に修正をお願いする方法でも十分だと思います。

９．さいごに

今回、ネスペ問題集を写真に撮り、その画像をCodexへ渡すだけで、26ノード、27リンクのGNS3プロジェクトを作成し、端末間の疎通確認までできました。

これまでは、「この構成を試したいけれど、作るのが大変そうだな」と諦めることもありました。

Codexを使えば、機器配置、配線、アドレス設計、コンフィグ作成、確認手順の準備をかなり短縮できます。

CodexからGNS3プロジェクトを自動作成できる！！！

そして、作ったラボでOSPF、eBGP、VRRP、DMVPN、IPsec、経路再配送、障害時の切替を実際に確認できます。

ネスペ等のネットワーク勉強に最適！！！

問題集の構成図を読むだけで終わらせず、写真を撮ってCodexへ渡し、実際に動かし、壊し、確認する。

私も引き続き、CodexとGNS3を使って、楽しみながら色々なネットワークをシミュレーションしていきたいと思います。