4.3コントローラとプログラマブル管理（Catalyst Center・NETCONF・RESTCONF）

CLIで1台ずつ設定する世界では、設定ドリフト（同じ役割の機器なのに設定が微妙に食い違う）と、変更の途中失敗（40台のうち17台目でエラーになり半分だけ適用された状態）が慢性的な事故要因になります。プログラマブル管理はこれを構造的に解消する試みで、鍵はトランザクション性と意図（intent）の宣言です。NETCONFは書き換えを一旦candidateに溜めてcommitで全か無かに適用でき、RESTCONFは既存のHTTPツールチェーンでYANGデータへ手軽に触れます。そしてCatalyst Centerは「どうやるか」ではなく「どうあってほしいか」を入力させ、差分の検出と保証（Assurance）まで面倒を見ます。同じ変更でも規模と失敗時の影響で選ぶべき機構が変わるという視点で読んでください。

4.3.1Cisco Catalyst Center（旧 DNA Center）

• Cisco Catalyst Center（旧DNA Center）はキャンパスの意図ベースネットワーキングコントローラで、Design（サイト階層・共通設定の設計）→Policy（グループ/SGTベースのポリシー）→Provision（機器への展開・SD-Accessファブリック構築）→Assurance（監視と保証）という4つのワークフローで運用を回す。北向きのIntent API（RESTful）で外部システムから同じ操作を自動化でき、南向きにはNETCONF/RESTCONF/SNMP/CLIで機器を制御する。
• Assuranceは機器・クライアント・アプリからテレメトリを継続収集し、ヘルススコアとして正常度を数値化する。単なる閾値監視ではなく機械学習でベースラインを学習し、そこからの逸脱を異常として提示したうえで、根本原因の候補と推奨アクションを示すのが特徴。Network Time Travelにより「昨日の15時にこのクライアントで何が起きていたか」を過去にさかのぼって再生できるため、再現しにくい断続障害の解析に強い。
• AI活用のワークフローは「AIが勝手に直す」ものではなく、ベースライン学習→異常検知→根本原因の絞り込み→推奨アクションの提示→運用者の承認による適用という人が判断を持つ流れで設計されている。トラブル時の価値は、CLIで何十台もshowを叩いて突き合わせる作業を、相関済みの候補提示に置き換える点にある。

4.3.2NETCONF（XML / SSH 830 / candidate と commit）

• NETCONFはXMLでエンコードしたRPCをSSH上のポート830でやり取りする設定管理プロトコル。IOS XEではnetconf-yangで有効化する。主なRPCは<get>（状態＋設定）／<get-config>（設定のみ）／<edit-config>（変更）／<lock>・<unlock>／<commit>。データの構造はYANGモデルが規定する。
• データストアはrunning（現在の稼働設定）・candidate（編集用の下書き）・startup（起動時設定）。candidateへ<edit-config>で複数の変更を積み、最後に<commit>することで全て適用されるか全く適用されないか（原子性）を確保できる。これが「途中でエラーになって半分だけ適用された」事故を構造的に防ぐ仕組み。<lock>で他管理者の同時編集を排除でき、confirmed-commitを使えば一定時間内に確定操作がないと自動ロールバックする。
• 検証はshow netconf-yang sessionsやshow netconf-yang statisticsで行い、エラーは<rpc-error>として返る。トランザクション性・ロック・購読（telemetry subscription）が必要な自動化ではNETCONFを選ぶのが原則。

4.3.3RESTCONF（HTTP + JSON / CRUD とメソッド）

• RESTCONFは同じYANGモデルのデータをHTTPS上で扱うプロトコルで、ペイロードはJSONまたはXML（Content-Type: application/yang-data+json）。IOS XEではrestconfとip http secure-serverで有効化する。URIは/restconf/data/<YANGモジュール>:<コンテナ>/<リスト>=<キー>の形（例：/restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1）。
• CRUDとHTTPメソッドの対応が要：作成＝POST／取得＝GET／置換（全体差し替え）＝PUT／部分更新＝PATCH／削除＝DELETE。PUTは指定リソースを丸ごと置き換えるため、送らなかった要素は消える。1つのleafだけ変えたいときにPUTを使うと他の設定を失う——ここは実務でも試験でも事故と出題の定番で、正しくはPATCHを使う。
• 応答コードの解釈も頻出：200（取得成功）／201（作成成功）／204（成功だが本文なし＝更新/削除で典型）／400（構文やモデル不整合）／401（認証失敗）／403（権限不足）／404（URIのパス・モジュール名・キーの誤り）／409（競合）／5xx（サーバ側）。RESTCONFは1リクエスト単位の適用で、candidate／commitのようなトランザクション境界を持たない点がNETCONFとの決定的な違い。

40台のキャンパススイッチに対し、ACLの追加とルートマップの修正という互いに依存する複数行の変更を一斉投入する計画を立てました。担当者は使い慣れたRESTCONFで、変更ごとにPATCHを投げるPythonスクリプトを書いて実行しましたが、17台目でルートマップ側のPATCHが400 Bad Requestを返して停止し、その機器ではACLだけが入りルートマップは未適用という中途半端な状態が残りました。ここでの本質的な問題はスクリプトのバグではなく機構の選択です。RESTCONFは1リクエスト単位で適用され、candidate／commitのようなトランザクション境界を持たないため、複数リクエストにまたがる整合性は設計上保証できません。同じ変更をNETCONFで行えば、<lock>で他管理者の割り込みを排除したうえで、ACLとルートマップの両方をcandidateへ<edit-config>で積み、最後に<commit>することで全て入るか全く入らないかにできます。さらにconfirmed-commitを併用すれば、投入後に到達性が失われて確定操作を送れなくなった場合でも自動でロールバックし、遠隔地の機器を締め出す事故を防げます。なお400 Bad Requestという応答コードの解釈も重要で、これはペイロードの構文またはYANGモデルとの不整合を示すため、認証（401）や権限（403）、URIの誤り（404）とは切り分けて考えます。もう一段上の視点では、この種の「多数機器への一貫した設定」はそもそも1台ずつAPIを叩く問題ではなく、Catalyst Centerのテンプレート/Intent APIで意図として一度宣言し、差分のある機器を検出して収束させるほうが、設定ドリフトの再発まで含めて構造的に解決できます。逆に「まず全台にRESTCONFでPUTし直せば整う」という発想は最悪手で、PUTは指定リソースを丸ごと置換するため、送らなかった既存設定を消し飛ばす危険があります。

4.3.4この節のまとめ

• NETCONFはXML／SSH830で、candidateへedit-configを積みcommitで全か無かに適用（lockで排他・confirmed-commitで自動ロールバック）＝多数機器への一貫した一括変更に選ぶ
• RESTCONFはHTTPS＋JSONでCRUDをメソッドに対応（POST作成／GET取得／PUT置換／PATCH部分更新／DELETE削除）。トランザクション境界がないため途中失敗は半適用として残る。応答コード（400/401/403/404）で原因を切り分ける
• Catalyst Center（旧DNA Center）はDesign→Policy→Provision→Assuranceの意図ベース運用とIntent APIを提供し、AssuranceはMLでベースラインを学習して異常検知・根本原因候補・推奨アクションを示し、Network Time Travelで過去の状態を再生できる