CLIを超えて：NETCONFとYANGでネットワーク自動化をマスターする

Table of Contents

手動CLIの脆弱性

以前、火曜日の夜に40台のアクセススイッチのVLANタグを手動で更新するのに6時間を費やしたことがあります。それは気が遠くなるような作業でした。作業の途中で、コアトランクリンクのIPアドレスを1つ入力ミス（タイポ）してしまい、瞬時に200人のユーザーがネットワークから切断されました。これがコマンドラインインターフェース（CLI）に内在するリスクです。500台のデバイスを管理している場合、1%のエラー率でも5つの重大な障害が発生することを意味します。

CLIは人間の目向けに作られたものであり、スクリプト向けではありません。CLIが出力するのは非構造化テキストであり、それはIOS-XEを実行しているCisco CatalystとJuniper MXシリーズでは異なります。CLIを自動化する場合、通常は正規表現（Regex）を使用してデータを「スクレイピング」する必要があります。この手法は非常に脆いです。コマンド出力のスペースが1つ変わるような単純なソフトウェアアップデートだけで、自動化パイプライン全体が壊れてしまう可能性があります。ハードウェアと通信するためには、より堅牢な方法が必要です。

YANGとNETCONF：現代の標準規格

真のInfrastructure as Code（IaC）へと移行するには、データをモデル化するための標準化された方法と、そのデータを転送するための信頼できるプロトコルが必要です。ここで、YANGとNETCONFの組み合わせがゲームチェンジャーとなります。この移行により、私たちは「コマンド」の送信から「状態（state）」の管理へと進化します。

YANG：データモデリングの設計図

YANG（Yet Another Next Generation）は、ルーターのスキーマとして機能します。データベースを扱ったことがあるなら、YANGをテーブル定義のようなものだと考えてください。これは、どのデータが有効であるかを正確に規定します。例えば、インターフェース用のYANGモデルは、「MTU」が単なるランダムな文字列ではなく、64から9216の間の整数であることを保証します。

OpenConfigのようなYANGモデルを使用すると、複数のベンダー間で動作する1つのスクリプトを作成できます。特定のコマンドがip addressなのかset addressなのかを気にする必要はもうありません。モデルに適合するデータを提供するだけで、デバイスが残りの処理を行ってくれます。この標準化により、ベンダー固有のロジックを記述する時間を最大70%削減できます。

NETCONF：信頼できる運び屋

YANGがメッセージを定義するなら、NETCONF（Network Configuration Protocol）は安全な配送トラックです。IETFによってRFC 6241で標準化されたこのプロトコルは、老朽化したSNMPや予測不可能なCLIに代わるものです。NETCONFはSSH上で動作し、XMLを使用してすべてのやり取りが構造化され、マシンが読み取れることを保証します。

ここで最も強力な機能は、変更の「トランザクション」性です。途中で失敗してルーターが壊れた状態のままになる可能性があるCLIスクリプトとは異なり、NETCONFは「candidate configuration（候補設定）」をサポートしています。大規模な変更をプッシュし、検証してから、単一のアトミックなアクションとしてコミットできます。検証が失敗した場合、ルーターはブロック全体を拒否します。この機能だけで、多くの本番障害の原因となる「半分だけ設定された」状態を排除できます。

ラボ環境の準備

過去5年間のほとんどのエンタープライズグレードのハードウェアはNETCONFをサポートしています。実際に試すには、CSR1000vやC9000シリーズスイッチなどのCisco IOS-XEデバイスを使用できます。まず、デバイスでNETCONFサブシステムを有効にします。

conf t
netconf-yang
username admin privilege 15 password 0 cisco
line vty 0 4
 login local
 transport input ssh

管理用のワークステーションにncclientライブラリをインストールします。これは、NETCONFデバイスと対話するための最も人気のあるPythonライブラリです。

pip install ncclient

正規表現を使わずにデータを取得する

running configurationを取得してみましょう。膨大なテキストの壁をパースする代わりに、Pythonが辞書のように読み取れる構造化されたXMLを取得します。

from ncclient import manager
import xml.dom.minidom

device = {
    "host": "10.1.1.5",
    "port": 830,
    "username": "admin",
    "password": "cisco",
    "hostkey_verify": False
}

with manager.connect(**device) as m:
    # running configurationをリクエストする
    config = m.get_config(source='running')
    
    # XML出力を整形して表示する
    parsed_xml = xml.dom.minidom.parseString(config.xml)
    print(parsed_xml.toprettyxml())

出力は予測可能なXMLツリーです。PythonのElementTreeを使えば、わずか3行のコードでGigabitEthernet1のIPを取得できます。複雑な正規表現パターンは不要であり、ルーターが出力に新しい説明行を追加したとしても、スクリプトが壊れることはありません。

自信を持って変更を反映する

インターフェースの説明（description）の更新は、一連のコマンド入力ではなく、構造化された操作になります。デバイス上の特定のYANGモジュールをターゲットにしたXMLスニペットを送信します。

config_data = """
<config>
  <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
    <interface>
      <GigabitEthernet>
        <name>2</name>
        <description>Uplink_to_Core_01</description>
      </GigabitEthernet>
    </interface>
  </native>
</config>
"""

with manager.connect(**device) as m:
    response = m.edit_config(target='running', config=config_data)
    if response.ok:
        print("設定が正常に適用されました！")

response.okのチェックは非常に重要です。これにより、ルーターがデータを受け入れ、適用したことが確認されます。もし誤ったXMLタグを送信した場合、ルーターはrpc-errorを返します。これにより、エラーがネットワーク全体に広がる前に、スクリプトで即座にエラーをキャッチできます。

これがキャリアにとって重要な理由

「Infrastructure as Code」への移行は、シニアエンジニアにとって、もはや避けて通れない道です。企業は、手動による1台ずつの設定から脱却しつつあります。彼らは、再現可能でバージョン管理されたワークフローを求めています。NETCONFとYANGを採用したチームでは、デプロイメントの作業時間が数時間から数分に短縮されることがよくあります。

これらのツールをマスターすることで、ネットワークをCI/CDパイプラインに統合できるようになります。仮想ラボ（CMLやGNS3など）で設定変更をテストし、それと全く同じXMLペイロードを本番環境にデプロイできます。このレベルの精度は、手動のCLI入力では不可能です。

結論

CLIからNETCONFおよびYANGへの移行には、思考の転換が必要です。「どのように（どのコマンドを打つか）」に焦点を当てるのをやめ、「何を（データの望ましい状態）」に焦点を当て始めます。XMLは素早いCLIコマンドに比べると冗長に見えるかもしれませんが、大規模環境で提供される信頼性は比類のないものです。まずは、ラボ環境でNTPやDNSの更新といった単純なタスクを自動化することから始めてみてください。構造化データの安定性を一度体験すれば、CLIは過去の遺物のように感じられるはずです。