手動CLIからNetwork-as-Codeへの転換
深夜2時のメンテナンス時間、10行のACL変更が重大障害（SEV-1）を引き起こさないことを祈りながら、点滅するカーソルを凝視した経験が何度もあります。誰もが経験したことがあるはずです。単純なprefix-listの更新がリージョン拠点をブラックホール化していないか、show ip bgp summaryを10回も入力して確認するような状況を。GNS3やEVE-NGのような標準的なラボ環境は学習には最適ですが、リソースを大量に消費します。500台のルーターで構成される本番環境のバックボーンを仮想ラボで再現しようとすれば、ワークステーションがクラッシュするのが関の山です。
200ノードのバックボーンでBatfishを6ヶ月間運用した結果、私は「幸運を祈る」のをやめました。Batfishはシミュレータやエミュレータではありません。設定解析ツールです。Cisco IOS-XE、Juniper JunOS、Arista EOS、Palo Altoなどの生の設定ファイルを解析し、ネットワーク全体の厳密な数学的モデルを構築します。仮想マシンを1台も起動することなく、SQLデータベースのようにネットワークの状態をクエリできるのです。
従来のネットワークエンジニアからNetDevOpsのプロフェッショナルへと移行するには、このマインドセットの転換が必要です。Network-as-Code（NaC）のワークフローでは、設定はソースコードです。本番環境のシリアル番号に触れる前に、自動化されたユニットテストをパスしなければなりません。
Batfish環境のセットアップ
Batfishはクライアント・サーバー・アーキテクチャを採用しています。重い処理はDockerコンテナ（エンジン）内で行われ、ユーザーはPythonライブラリであるPybatfishを使用して操作します。この構成は非常に軽量で、現代的なCI/CDパイプパイプラインに完璧に統合できます。
1. Batfishサービスの起動
まずは公式のDockerイメージを取得します。サイズは約1GBで、ベンダー各社のVMを揃えるよりもはるかに軽量です。
docker pull batfish/allinone
docker run -d --name batfish -p 9997:9997 -p 9996:9996 batfish/allinone2. Pybatfishのインストール
ローカルマシンにPythonクライアントをインストールします。他の自動化ツールとのバージョン競合を避けるため、仮想環境（venv）を使用しましょう。
python3 -m venv batfish-env
source batfish-env/bin/activate
pip install pybatfishスナップショットの設定とPython統合
Batfishはデータを「スナップショット」として管理します。スナップショットは、設定ファイルが含まれるフォルダに過ぎません。機器同士がどのように接続されているかをBatfishに教える必要はありません。テキストファイル内のインターフェースIPやルーティングプロトコルを解析して、トポロジーを自動的に判別します。
ディレクトリ構造は以下のように構成します：
network_snapshot/
├── configs/
│ ├── border-router-01.cfg
│ ├── leaf-01.cfg
│ └── fw-dmz-01.cfg
└── hosts/ (サーバーシミュレーション用のオプション)次に、Pythonスクリプトを使用して環境を初期化します。このステップで、解析のために設定ファイルがDockerコンテナにアップロードされます。
from pybatfish.client.commands import bf_session, bf_init_snapshot
from pybatfish.question import bfq
# ローカルのBatfishエンジンに接続
bf_session.host = "localhost"
# スナップショットを初期化
SNAPSHOT_PATH = './network_snapshot'
bf_init_snapshot(SNAPSHOT_PATH, name='prod-network', overwrite=True)ルーティングとセキュリティポリシーの検証
モデルが構築されると、Batfishはトポロジーを理解します。LLDPデータやサブネットのマッチングに基づいて、どのインターフェースが隣接しているかを把握します。これにより、通常なら手動のshowコマンドで数時間かかるようなクエリを実行できるようになります。
隠れたエラーの発見
設定はクリーンですか？「未定義の参照（undefined references）」、例えば実際には存在しないroute-mapを参照しているBGPネイバーなどをチェックできます。5,000行を超えるような大規模な設定ファイルでは、こうしたタイポは見落としがちですが、サイレント障害の原因となります。
# prefix-listやroute-mapの欠落といったタイポを見つける
undefined_refs = bfq.undefinedReferences().answer().frame()
print(undefined_refs)ファイアウォールの到達性テスト
これは私のチームで最も時間を節約できた機能です。ACLが機能するかどうかを推測する代わりに、特定のパケットフローをシミュレートできます。例えば、VLAN 100 (10.10.1.0/24)がポート5432でPostgres_DB (192.168.50.10)に到達できるか検証する必要があるとしましょう。
# フローの到達性クエリを定義
reachability = bfq.reachability(
pathConstraints=bfq.pathConstraints(startLocation="leaf-01"),
headers=bfq.headerConstraints(
srcIps="10.10.1.0/24",
dstIps="192.168.50.10",
ipProtocols=["tcp"],
dstPorts="5432"
)
).answer().frame()
print(reachability)フローがブロックされた場合、Batfishは単に「拒否（Deny）」と答えるだけではありません。トラフィックをドロップしたACLまたはファイアウォールポリシーの正確な行数を指摘してくれます。10台もの機器でpacket-tracerコマンドを実行する必要はもうありません。
影響分析による変更のシミュレーション
Network-as-Codeの真の力は「差分分析（Differential Analysis）」にあります。Aristaのスパインスイッチに変更をプッシュする前に、修正案を含めた一時的なスナップショットを作成します。そして、それを現在の本番環境のスナップショットと比較します。
「爆発半径（影響範囲）」テスト
differentialReachabilityクエリは、どのフローが追加され、どのフローが切断されるかを正確に示します。古いサブネットを廃止する場合、このテストを行えば、存在を忘れていたサービスのトラフィックを誤って遮断していないかを確認できます。
# 「現在」と「変更案」のスナップショットを比較する
comparison = bfq.differentialReachability(
baseSnapshot='prod-network',
snapshot='proposed-change'
).answer().frame()
if not comparison.empty:
print("警告：この変更は既存のトラフィックフローに影響を与えます！")
print(comparison)GitLabでの継続的バリデーション
現在の私の環境では、これらのスクリプトはGitLab CIパイプライン内で実行されています。チームメンバーが設定変更のマージリクエストを作成するたびに、パイプラインが自動的にトリガーされます。Batfishが起動し、新しい設定をロードし、ルーティングループがないか、内部ルートがISPに漏洩していないか、SSHアクセスが管理サブネットに制限されているかといった一連のテストを実行します。
このワークフローにより、データセンターにおけるヒューマンエラー起因の障害を事実上排除できました。変更が安全かどうかを推測することはもうありません。数学を用いてそれを証明するのです。Pybatfishには、特にPandasのDataFrameに慣れていない場合には多少の学習曲線がありますが、変更作業中に得られる安心感は、その労力に見合う以上の価値があります。
管理するネットワーク機器が20台を超えるなら、手動の検証ではもはや不十分です。Batfishモデルを構築し、ツールに監査を任せましょう。
