【RTX830×Python】コンフィグ変更を安全に自動化|Codexで差分確認・切り戻し

RTX830とPythonで差分確認、SSH確認、切り戻しを行う安全なコンフィグ変更自動化

この記事を読み終えると、通信に影響しない一時設定を使って、安全装置付きPythonツールを実行し、変更前と切り戻し後のCONFIGが一致するところまで確認できます。

完成版スクリプトとマスク済みの練習用CONFIGをダウンロードできるようにしました。最初にオフラインで差分判定を試し、読み取り専用確認に成功してから、RTX830実機へ一時的なシステム説明を1行だけ追加します。最後は自動で削除し、CONFIGハッシュの一致まで確認します。

  • 変更前の機種・ファームウェア・CONFIG・SSH疎通を確認
  • 人間が変更内容と切り戻しコマンドを承認
  • 動作に影響しない一時設定を1行だけ追加
  • 期待した1行以外の差分がないことを確認
  • SSH疎通を再確認してから切り戻し
  • 変更前と復元後のCONFIGハッシュ一致を確認
RTX830の設定変更をPythonで安全に自動化する6段階の流れ。変更前確認、人間承認、一時変更、差分とSSH確認、切り戻し、CONFIGハッシュ一致による原状復帰確認
安全な自動化は、コマンド送信よりも「変更前確認・停止条件・切り戻し・原状復帰の判定」を先に設計します。異常時も後続変更を止めて切り戻しへ進みます。

対象読者:中小規模ネットワークのRTX830を手作業で管理しており、コマンド送信だけでなく、変更前確認・差分検査・通信確認・切り戻し・原状復帰の判定まで安全に自動化したい初級〜中級エンジニア。

この記事の主題はdescriptionの設定方法ではなく、設定変更を安全に止め、戻し、確認する仕組みです。実機では通信へ影響しないシステム説明のdescriptionを、安全装置を試すための一時設定として1行だけ使用しました。任意の本番設定をAIへ任せても安全、という検証ではありません。

目次

最初に:このハンズオンで実現すること

このハンズオンのゴールは、RTX830へコマンドを送ることではありません。読者自身が次の完了条件をすべて確認することです。

  • 変更前にRTX830の機種、ファームウェア、SSH到達性、候補IDの未使用を確認できる
  • 接続先、追加コマンド、切り戻しコマンドを人間が確認するまで書き込みを始めない
  • 予定したdescriptionが1行だけ増え、既存行が消えていないことを自動判定できる
  • 変更後もSSHへ到達できることを確認してから切り戻せる
  • 変更前と復元後のCONFIGハッシュが一致した場合だけ成功と判定できる

禁止事項:本番機では実行しないでください。今回のサンプルは、検証用RTX830でシステム全体の説明を一時変更する用途に限定しています。インタフェースdescriptionや、経路・NAT・フィルターなど通信へ影響する設定には対応していません。

ZIPには、完全版のrtx830_change_guard.py、実行手順、秘密情報を除いた変更前後のfixtureを収録しています。SHA-256は次のとおりです。

f29b6c63d02470f88aca8e2a5165c5b89e2ba659f5b3914494f2d9a038edfbc2

準備するものと安全条件

  • 本番から切り離した検証用RTX830
  • Python 3.9以降を実行できるPC
  • RTX830へSSHログインできるユーザーと、管理者モード用パスワード
  • SSHが切れた場合に手動復旧できるコンソール接続
  • RTX830のSSHホスト鍵を別経路で照合できること

サンプルはRTX830 Rev.15.02.31とNetmiko 4.6.0で検証しました。異なるファームウェアではプロンプトや表示が異なる可能性があります。実行中に既存の設定作業を行わず、変更対象の数値IDも事前に未使用であることを確認してください。

RTX830ハンズオン手順

手順1:ZIPを展開し、オフラインで差分判定を試す

まずRTX830へ接続せず、同梱したマスク済みfixtureで「予定した1行だけが追加された」と判定できるか確認します。ZIPを展開したフォルダーで次を実行してください。

python rtx830_change_guard.py fixture-check --before config-before-sanitized.txt --after config-after-sanitized.txt --description-id 21474836

次の3項目になればオフライン試験は成功です。実CONFIG本文は表示されません。

項目期待値
expected_diff_onlytrue
added_count1
removed_count0

手順2:仮想環境を作り、Netmiko 4.6.0を入れる

実機接続時だけNetmikoが必要です。ほかのPython環境へ影響させないため、展開したフォルダーに仮想環境を作ります。

macOS/Linux:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install "netmiko==4.6.0"

Windows PowerShell:

py -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install "netmiko==4.6.0"

初回接続前に、SSHホスト鍵の指紋をコンソールなど別経路で照合し、PCのknown_hostsへ登録してください。サンプルには未知のホスト鍵を許可するオプションもありますが、偽装機器へ資格情報を渡す危険があるため、この手順では使用しません。

手順3:precheckで書き込み前の状態を確認する

以下の192.0.2.1は説明用アドレス、adminはユーザー名の例です。必ず検証用RTX830の管理IPとSSHログイン用ユーザーへ置き換えてください。21474836も未使用の場合だけ使います。

python rtx830_change_guard.py precheck --host 192.0.2.1 --username admin --description-id 21474836

precheckは設定コマンドを送りません。パスワードを対話入力し、success: truedevice_model: "RTX830"candidate_available: truessh_reachable_before: trueを確認します。1つでも満たさなければ、次へ進まないでください。

手順4:admin-checkで管理者モードとCONFIG不変を確認する

python rtx830_change_guard.py admin-check --host 192.0.2.1 --username admin --description-id 21474836

SSHログイン用パスワードと管理者モード用パスワードを別々に入力します。この処理も設定コマンドを送りません。success: trueadmin_mode_entered: truerestored_to_before: truestage: "complete"を確認してください。

ここで失敗する場合、SSHログイン用パスワードと管理者モード用パスワードの取り違え、ユーザーの権限、一般モードと管理者モードの表示差を確認します。成功するまで書き込み試験へ進みません。

手順5:一時descriptionを追加し、自動で切り戻す

precheckadmin-checkが両方成功し、コンソール復旧経路を用意できた場合だけ実行します。

python rtx830_change_guard.py apply --host 192.0.2.1 --username admin --description-id 21474836 --apply

ツールは、接続先、追加するdescription 21474836 CODEX_AUTOMATION_TEST、切り戻し用のno description 21474836Persistent save: disabledを表示します。内容を読み、画面に表示された確認文を完全一致で入力した場合だけパスワード入力へ進みます。

変更後は予定した1行以外の差分がないこととTCP/22への到達を確認し、同じ管理者セッション内で一時設定を削除します。処理途中で例外が起きた場合も切り戻しを試みます。

手順6:成功条件をJSONで確認する

「削除コマンドを送れた」だけでは完了ではありません。出力されたJSONで次の項目をすべて確認してください。

確認項目成功条件
successtrue
stage"complete"
expected_diff_onlytrue
added_count / removed_count1 / 0
ssh_reachable_before / ssh_reachable_after両方true
rollback_succeededtrue
restored_to_beforetrue
before_hash / final_hashコメント行を除いて正規化したCONFIGのSHA-256が完全一致

失敗時:rollback_succeededまたはrestored_to_beforefalseの場合は、ツールを繰り返し実行しないでください。コンソールからCONFIGを確認し、一時descriptionが残っていれば手動で削除します。SSHへ到達できない場合も、後続の自動処理ではなく手動復旧へ切り替えます。

ここまで完了すれば、このハンズオンのゴール達成です。以降では、なぜ各安全装置が必要なのかと、同じツールをRTX830実機で検証した証拠を説明します。

RTX830の設定変更自動化で怖いのは「実行できること」ではない

Netmikoを使えば、SSH接続とCLIコマンド送信自体は短いPythonコードでも実装できます。しかし、実運用では次の判断が必要です。

  • 接続先や機種を取り違えていないか
  • 変更対象が事前条件を満たしているか
  • 意図しない設定まで変わっていないか
  • 設定後も管理経路へ接続できるか
  • 削除コマンドを送っただけでなく、本当に元へ戻ったか

以前公開したNetmikoでRTX830のコンフィグを取得する記事は、show configの取得とファイル保存が中心です。今回の記事では取得後の「変更可否・差分・疎通・切り戻し」まで広げます。

注意:以前の記事にはパスワードをコードへ直接記載する古い例があります。その方法は使わず、後述する対話入力などで秘密値をソースやログへ残さないでください。

確認項目既存の取得記事今回の実機検証
CONFIG取得ありあり
実行前の人間承認なしあり
一時変更なし1行だけ
差分検査なし期待した1行に限定
変更後のSSH確認なしあり
切り戻しなしあり
原状復帰の判定なしCONFIGハッシュ一致

今回の検証環境と安全条件

項目検証値
機種Yamaha RTX830
ファームウェアRev.15.02.31
接続SSH/管理者モード
Netmiko4.6.0
変更対象description 21474836 CODEX_AUTOMATION_TEST
切り戻しno description 21474836
永続保存saveは実行しない

Yamaha公式のdescriptionコマンドリファレンスには、システム全体の説明とインタフェースの説明という2つの書式があります。対向先や回線用途を記録するインタフェース説明とは異なり、今回使ったdescription 21474836 ...はシステム全体の説明です。どちらも説明用で、設定内容自体は通信動作へ影響しません。

システム説明を選んだ理由は、実務上の設定例として紹介するためではなく、安全装置を実機で検証する際に通信へ影響する変更を避けるためです。事前に未使用と確認した行へ一時追加し、既存設定を上書きせず、saveも実行していません。

パスワードはgetpassで実行時に入力し、ソースコード、コマンド引数、JSONレポートへ保存しない設計にしました。

password = getpass.getpass(
    "RTX830 SSH login password: "
)
admin_password = getpass.getpass(
    "RTX830 administrator-mode password: "
)

Codexからローカルネットワーク機器へ常に接続できるわけではありません。今回の環境では接続先を限定し、人間の承認を経てローカルのPythonツールを実行しました。Codexのsandbox・承認・ネットワークアクセスは環境設定に依存します。詳細はOpenAI公式のAgent approvals & securityを確認してください。

Codexに作らせた4つの安全装置

1. 既定は読み取り専用にする

最初に実行するprecheckadmin-checkは、設定コマンドを送りません。RTX830へ到達できること、機種とファームウェア、running/default CONFIG、変更対象が未使用であること、管理者モード内でCONFIGが変わらないことを確認します。

書き込み処理は--applyがなければ開始せず、確認文が完全一致しない場合もSSH認証前に停止します。

2. 変更内容と切り戻しを実行前に表示する

実行前に、接続先、追加コマンド、切り戻しコマンド、永続保存しないことを表示します。人間が内容を確認し、完全一致の確認文を入力して初めてパスワード入力へ進みます。

RTX830への一時設定前に対象コマンド、切り戻し、save禁止、人間の最終承認を表示する安全ゲート
接続先IPは記事用にマスクしています。確認文が一致しなければ機器へ接続しません。

3. 期待した1行以外の差分があれば停止する

変更前後のCONFIGを正規化して比較し、予定したdescriptionが1行増え、削除が0行、既存行の順序が変わっていない場合だけ次へ進みます。

expected_diff_only = (
    expected_command not in before_counter
    and added_counter == Counter({expected_command: 1})
    and removed_count == 0
    and order_unchanged
)

想定外のCONFIG行には内部IPや認証情報が含まれる可能性があるため、エラー時もその行をJSONや画面へ出しません。記録するのは件数と成否だけです。

4. 成否にかかわらず切り戻し、元へ戻ったことを判定する

変更コマンドを送った後は、応答待ちのタイムアウトや差分検査の失敗が起きても、finally相当の終了処理で切り戻しを試みます。成功扱いにする条件は削除コマンドの送信ではなく、再取得したCONFIGのハッシュが変更前と一致することです。

try:
    send_change()
    verify_expected_diff()
    verify_ssh()
finally:
    rollback_if_required()
    verify_original_config_hash()

自動切り戻し自体が失敗する可能性もあるため、本番ではコンソールなどの手動復旧経路が必要です。ツールが例外を処理できることと、ネットワークが必ず復旧することは同じではありません。

RTX830実機で一時設定を追加した結果

実機試験では、次の1行だけを追加しました。

description 21474836 CODEX_AUTOMATION_TEST

変更後の安全なレポート項目は次のとおりです。

項目結果
処理時間43.039秒
期待した差分のみtrue
追加行数1
削除行数0
変更前SSH到達可能
変更後SSH到達可能
save未実行
RTX830の変更後CONFIGが予定した1行追加、削除0行でSSH疎通も維持された自動判定結果
実CONFIG本文は出さず、期待した1行だけが追加されたという判定結果を残します。

CONFIGに1行追加されたことだけでなく、変更後もTCP/22へ到達できることを確認してから切り戻しへ進みました。ただし、TCP/22の到達成功はアプリケーション通信全体の正常性を保証するものではありません。変更対象に応じて、実際の業務通信も別途確認する必要があります。

切り戻し後に「元へ戻った」をどう証明したか

追加後は、あらかじめ用意した次のコマンドで一時設定を削除しました。

no description 21474836

ここで「削除コマンドを送信できた」だけを成功条件にはしません。管理者モードで再取得した完全CONFIGを同じ方法で正規化し、変更前と復元後のSHA-256ハッシュが一致したときだけ切り戻し成功と判定します。

項目結果
変更前ハッシュc17c570b...
復元後ハッシュc17c570b...
rollback_succeededtrue
restored_to_beforetrue
RTX830の変更前と切り戻し後のCONFIGハッシュが一致し原状復帰を確認した結果
完全ハッシュとCONFIG本文は非掲載です。先頭8文字の一致と判定結果だけを示しています。

終了後には、RTX830宛の経路、Ping、TCP/22、通常のインターネット経路から公開サイトへのHTTPS通信も確認しました。一時descriptionは残っていません。

実機で失敗して分かった「止める仕組み」が必要な3つの理由

生成されたコマンドが公式仕様に合うとは限らない

最初に生成したdescription codex-lab ...は、システム説明の書式に合わずRTX830から拒否されました。この失敗で重要なのはIDの数字ではなく、生成されたコマンドをそのまま送らず、公式仕様に合わない値を実行前に拒否することです。対象コマンドごとに許可する書式と値を定義し、既存設定へ衝突する場合も停止させます。

CONFIG内の#を管理者プロンプトと誤認する

症状:CONFIG取得の途中で読み取りが終了し、ハッシュが安定しませんでした。
原因:show configのコメント行に含まれる#を、管理者プロンプトとして扱っていました。
対策:CONFIG取得は単純な#待ちではなく、チャネルがアイドルになるまで読み取る方法へ変更しました。

一般モードと管理者モードで表示範囲が異なる

症状:設定コマンドを送っていないのに、確認前後のCONFIGハッシュが変わりました。
原因:一般モードで取得したCONFIGと、管理者モードで取得したCONFIGを比較していました。
対策:変更・差分・復元の基準を、すべて管理者モード移行直後のCONFIGへ統一しました。

生成AIが最初に出したコードやコマンドを、そのまま実機へ流さないことが重要です。公式仕様、マスク済みfixtureを使ったテスト、読み取り専用確認、限定した実機試験の順で狭める必要があります。

本番ネットワークへ広げる前に必要なこと

  • 検証用機器:本番と同じ機種・ファームウェアで事前検証する
  • 手動復旧経路:SSHが切れた場合に備えてコンソール接続を用意する
  • 許可リスト:実行可能な機器・コマンド・パラメーターを限定する
  • 期待差分:変更内容ごとに追加・変更・削除される行を定義する
  • 通信確認:管理SSHだけでなく、変更対象の業務通信を確認する
  • 停止条件:認証失敗、timeout、期待外差分、通信断で後続変更を止める
  • 永続化:saveは今回未検証。別の変更工程として設計・承認する

RTX830へCLIで接続するところから確認したい場合は、RTX830へCLIログインしてコンフィグを取得する手順を参照してください。GUIでコンフィグを取得する場合は、RTX830のWeb GUIログインとコンフィグ取得で説明しています。

RTXシリーズの既存記事は、Yamaha RTX設定ガイドから目的別に確認できます。

まとめ

  • 付属サンプルを使い、オフライン差分試験、読み取り専用確認、一時変更、切り戻し、CONFIGハッシュ一致まで自分で確認できる
  • 自動化の価値はコマンド送信ではなく、変更しない条件・止まる条件・戻った証明にある
  • システムdescriptionは実務上の目的ではなく、安全装置を通信へ影響させず検証するための一時設定として使用した
  • RTX830実機で、1行追加、期待差分の確認、SSH確認、切り戻し、ハッシュ復元まで成功した
  • パスワード、完全CONFIG、想定外の差分行はソース・会話・JSONへ残さない
  • 今回の結果を任意の本番設定変更へそのまま一般化しない
  • AIは変更判断の責任者ではなく、計画・コード・検査の補助として使う

中小規模ネットワークの変更前確認や、Pythonによる定型作業の自動化で迷っている場合は、お問い合わせから相談できます。


公式資料:Yamaha descriptionコマンドNetmiko API documentationOpenAI Agent approvals & security

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

30歳未経験からネットワークエンジニアに転職し、運用→構築→設計の仕事をやってます。色んな機器(Cisco、YAMAHA、Fortigate、PaloAlto)を触らせてもらいとても楽しい仕事です!

現在は派遣にて主にCiscoを中心としたネットワーク設計~構築をしております。

また、2023年より副業で個人事業主や小規模企業からのパソコン設定~ネットワーク作業の仕事を請け負っておりますので、もしお困りの方がいましたらお気軽にお問い合わせください。

●今までの作業履歴
- パソコンの新旧入れ替え
- 拠点間のインターネットVPN接続(YAMAHA-Fortigate)

コメント

コメントする

目次