１．はじめに
私はネットワークの勉強に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を使って、楽しみながら色々なネットワークをシミュレーションしていきたいと思います。