CML遠隔構築支援システムユーザーマニュアル

対象: 初期版

本書は、CML遠隔構築支援システムを利用する方向けの操作ガイドです。

1. このマニュアルについて

このマニュアルは、Cisco Modeling Labs上にネットワーク構成を作成・確認するための利用手順をまとめたものです。システムの内部設計ではなく、利用者がCodexへ構築依頼を出し、結果を確認し、必要に応じて追加依頼を行うための操作に絞っています。

依頼する
作りたいネットワークを自然な文章でCodexへ伝えます。

確認する
依頼フォルダ内の設定、結果、検証サマリーを確認します。

調整する
疎通不可や設計変更があれば、追加依頼として修正します。

2. できること

操作	内容
新規ラボ作成	構築依頼ごとにCMLラボを作成し、ノード、インターフェース、リンク、初期設定を反映できます。
既存ラボ確認	既にCML上にあるラボを依頼フォルダへ紐付け、状態やトポロジを確認できます。
ノード・リンク操作	ルーターなどのノード追加、インターフェース追加、リンク作成を行えます。
コンフィグ投入	ノードごとの初期設定ファイルを作成し、CML上のノードへ投入できます。
状態確認	ラボ状態、ノード状態、イベント、L3アドレス、トポロジ情報を取得できます。
CLI検証	コンソール経由で `show`、`ping`、`traceroute` などを実行できます。
結果保存	操作結果、ログ、検証結果を依頼フォルダ内に保存できます。

3. 利用前に準備するもの

CMLへアクセスできるネットワーク環境
CMLへログインできるユーザー名とパスワード
このシステムが配置された作業フォルダ
Python仮想環境が作成済みであること

依頼文や共有資料には、CMLの実IPアドレス、実ホスト名、ユーザー名、パスワード、ラボIDを記載しないでください。必要な場合は、<CML_HOST>、<USERNAME>、<LAB_ID> のようなプレースホルダーを使います。

4. 基本的な使い方

4.1 Codexへ構築依頼を出す

まず、作りたいネットワークを文章で伝えます。ルーター台数、接続関係、ルーティング方式、IPアドレス方針、検証したい通信を含めると、構築と確認が進めやすくなります。

ルーター4台でフルメッシュWANを作成してください。
WAN内はBGPでルーティングしてください。
ユーザー側ルーターを1台接続し、VRFを2つ作成してください。
双方のLoopback間でpingとtracerouteが通ることを確認してください。
IPアドレスはプライベートIPで設計してください。

4.2 Codexが作成するものを確認する

Codexは構築依頼ごとに依頼フォルダを作成します。依頼フォルダには、設計内容、CML操作用の設定、ノードごとのコンフィグ、実行結果、ログが保存されます。

場所	見るもの
`request.md`	構築依頼、設計方針、IP設計、検証項目
`configs/`	各ノードへ投入するコンフィグ
`results/`	CMLから取得した状態、CLI結果、検証サマリー
`logs/`	ツール実行ログ

4.3 結果を確認する

構築完了後は、Codexから検証結果の要約が返されます。詳細は依頼フォルダ内の results/ を確認します。

確認する代表例:
- verification_summary.md
- cml_lab_topology.json
- cml_lab_status.json
- console_*.json

5. 依頼フォルダの考え方

このシステムでは、1つの構築依頼を1つのフォルダで管理します。 1つの依頼フォルダは、原則として1つのCMLラボに対応します。

フォルダ単位で管理することで、「どの依頼で、どのラボに、どの設定を入れ、どの検証をしたか」が後から追えるようになります。

項目	説明
新規構築	新しい依頼フォルダを作成し、新しいCMLラボを作成します。
既存ラボの確認	新しい依頼フォルダを作成し、既存CMLラボを紐付けます。
追加変更	既存の依頼フォルダを使うか、新しい変更依頼フォルダを作るかをCodexに伝えます。

6. よい依頼文の書き方

依頼文は詳細であるほど、設定ファイルと検証内容が明確になります。不明点がある場合は、Codexが想定を置いて実装し、結果に残します。

含めるとよい情報	例
目的	疑似WAN、拠点間接続、検証用BGP、VRF検証など
ノード	ルーター4台、ユーザー側ルーター1台、スイッチ2台など
接続関係	フルメッシュ、スター、二重化、P1とP4にC1を接続など
ルーティング	BGP、OSPF、static route、default routeなど
IP方針	すべてプライベートIP、特定レンジを使用、Codexに任せるなど
検証	Loopback間ping、traceroute、BGP neighbor確認、経路表確認など
制約	既存ラボを削除しない、特定ノードを停止しない、テスト用ラボで削除確認するなど

例: 「C1のVRF BLUEとREDのLoopback間で、送信元指定pingだけでなく、通常のpingとtracerouteも確認してください」と書くと、利用者目線の検証まで含められます。

7. 認証情報の扱い

通常利用では、ツール実行時にCMLユーザー名とパスワードを入力します。
パスワードをマニュアル、依頼文、設定ファイル、ログに書かないでください。
共有する資料では、ユーザー名も実値ではなく <USERNAME> のように表記してください。
自動実行や検証用に環境変数を使う場合も、値を資料やログへ書かないでください。

禁止: 実IPアドレス、実ユーザー名、実パスワード、実ラボID、社内ネットワーク名を依頼文や共有資料に記載すること。

8. ラボの停止と削除

ラボはCMLのリソースを消費します。検証が終わったラボは、必要に応じて停止してください。削除は元に戻せない操作のため、慎重に扱います。

操作	扱い
停止	検証後にリソースを解放したい場合に行います。依頼フォルダや設定ファイルは残ります。
削除	テスト用ラボなど、不要であることが明確な場合のみ行います。
既存ラボ	利用者が明示的に許可しない限り、既存ラボは削除しません。

削除テストを行う場合は、必ず削除テスト専用のラボを作成してから実行してください。

9. 結果の見方

ファイル	内容	確認ポイント
`verification_summary.md`	検証結果の要約	全体結果、成功/失敗、どのコマンドで確認したか
`cml_lab_status.json`	ラボの状態	ラボが起動中か、停止中か
`cml_lab_topology.json`	ノードとリンクの状態	期待した台数、リンク数になっているか
`cml_l3_addresses.json`	CMLが認識しているL3アドレス	想定したIPアドレスが入っているか
`console_*.json`	CLIコマンドの実行結果	show、ping、tracerouteの出力

10. よくあるトラブル

症状	確認すること
CMLへ接続できない	CMLへ到達できるネットワークにいるか、CML接続先が正しいか、認証情報が正しいかを確認します。
ノードが起動しない	CMLのライセンス、リソース不足、イメージ定義、ノード定義を確認します。
pingが通らない	送信元アドレス、戻り経路、VRF、インターフェース状態、ルーティングテーブルを確認します。
tracerouteが途中で止まる	途中ルーターから送信元へ戻る経路があるかを確認します。送信元指定あり/なしの両方で確認すると原因を切り分けやすくなります。
CLI出力が混ざる	同じノードへ複数のコンソールコマンドを同時実行していないか確認します。同一ノードのCLI確認は直列実行してください。
削除してよいか不安	既存ラボは削除せず、削除テスト専用ラボを作成して確認します。

11. Codexへの追加依頼例

このラボのBGP neighbor状態を確認してください。
結果を依頼フォルダのresultsに保存してください。

C1のVRF REDからVRF BLUE側Loopbackへtracerouteしてください。
途中経路と戻り経路に問題がないか確認してください。

この依頼フォルダの検証サマリーを更新してください。
認証情報や環境固有の値は含めないでください。

既存ラボは削除しないでください。
削除確認が必要な場合は、テスト用ラボを新規作成してから行ってください。

12. 用語

用語	意味
CML	Cisco Modeling Labs。ネットワーク機器を仮想的に構築・検証する環境。
ラボ / Workbench	CML上で作成する1つのネットワーク構成。本システムでは1依頼フォルダに1ラボを対応させます。
依頼フォルダ	構築依頼、設定、実行結果、ログをまとめるフォルダ。
コンフィグ	ルーターなどのノードへ投入する設定。
VRF	1台のルーター内でルーティングテーブルを分離する仕組み。
検証サマリー	構築後の確認結果をまとめたファイル。