このような場面を考えてください。
サービスの変更によりPoD（Point of Delivery）内の数十台スイッチのQoS（Quality of Service）設定を変更する必要がある場合、あなたはどのように対応しますか？または、データセンター内の数千台スイッチの場合は、どのように対応すればいいでしょうか？
インターネット業界では、現在、広くDevOps（Development & Operations）システムプロセスが使用されています。管理者がデバイス毎に設定を変更することは、もはや正しい考え方ではありません。何故か？それは時間の無駄というだけではなく、マシンはミスをしないが、人はミスをするからです。
従って、DevOpsプロセスを使用してマシンに任せるのが正しい方法と言えます。例えば、PythonベースのSSHライブラリ、Paramikoライブラリ、Netmikoライブラリと、AnsibleやSaltStackなどの自動化ツールを使用して実現することです。
NetmikoライブラリやAnsibleなどのツールはスクリプトを介してネットワークデバイスのバッチ管理を実現できますが、管理者はネットワークデバイスのCLI（Command Line Interface）を深く理解し、事前にスクリプトでコマンドリストを確立する必要があります。
CLI
CLI最大の問題とは、異なるメーカーのデバイス間、または異なるバージョン間でも大きな違いがあることです。例えば、Aメーカーのスイッチでエッジポートを設定する場合、異なるOS（Operating System）バージョンのコマンドは同じではありません。
▲ バージョンで異なるコマンド
他のメーカーの場合は、設定コマンドが更に異なります。例えば、Bメーカースイッチのエッジポートの設定コマンドは次の通りです。
▲ Bメーカーのコマンド
そのため、デバイスのバージョンがアップグレードされた場合、オペレーションスクリプトのコードも変更する可能性が高くなります。通常、ネットワーク内には複数のメーカーデバイスが同時に存在しています。それに応じて、複数のオペレーションスクリプトを用意するか、またはオペレーションスクリプトを非常に複雑にする必要がある――最初にデバイスモデルやバージョン番号を確認し、次にその対応するコマンドリストを実行する必要があります。
従って、CLIはAPI（Application Programming Interface）としては適していません。自動化ツールを使用してコマンドを処理すると、管理者の作業負荷を軽減できますが、技術の複雑さとメンテナンスコストはかなり高くなります。SNMPの方がより良い選択のようです。
SNMP
▲ SNMP Overview
SNMPは長い歴史を持ちます。最初のバージョンRFC1065は、30年前の1988年に公表されました。SNMPアーキテクチャの中では、ネットワークデバイスがデーモンとしてSNMP Agentを実行します。NMS（Network Management System）と管理者が使用するSNMP管理ツールは、SNMP Managerと呼ばれます。SNMP Agentは、SNMP Managerからの様々な要求に応答できます。
SNMP AgentはMIB（Management Information Base）を維持し、大量のOID（Object Identifier）がその内部に保存されています。一つのOIDは唯一のKey-Valueであり、SNMP ManagerはSNMP Agentに検索やKey-Valueを変更することにより、ネットワークデバイスの情報収集や設定変更を実現できます。
▲ MIBの例
この図はMIB一つの例であり、黄色の部分にご覧ください。OID 1.3.6.1.2.1.2.2.1.5は、インターフェイストラフィックの評価に使用され、RFC 1213標準MIBに所属し、読み取り専用です。その名前はifSpeedです。このMIBは、非実行中のデバイスから読み取れた為、Value値はNullです。
SNMP Manager側のMIBは必要ではありません。OID 1.3.6.1.2.1.2.2.1.5が使用されている場合、SNMP Managerは、完全なMIBをインストールせずに、SNMP Agentからインターフェイストラフィック帯域幅を直接取得できます。
SNMPは良さそうですが、実はいくつかの問題があるため、適切なAPIではありません。例えば：
公表年代が古くてスループット性能が低いです。
UDPプロトコルに基づいた通信である為、信頼性が低いです。アプリケーション層における、パケットロス後に再取得/設定する保証応答メカニズムがありますが、パフォーマンスと遅延に影響を与えます。
一番大きいな問題は、各メーカーがプライベートMIBを使用しているため、統合管理ができないことです。管理員は、各メーカーからネットワークデバイスのMIBを個別に取得し、必要なOIDを整理するために多くの時間がかかります。最後に、それをオペレーションプラットフォームやスクリプトに手動でインポートします。
したがって、SNMPは依然として情報収集にのみ適しており、アラームと可視化レポートを提供しますが、自動化オペレーションAPIは他の技術を考慮する必要があります。管理員の視点から、この自動化オペレーションAPIは次の要件を満たす必要があります：
使いやすい事――ユーザビリティはすべての製品のコアバリューです。
「設定データ」「デバイス稼働状況データ」「統計データ」を明確に区別できる事。ます。
上記3種類のデータを各ネットワークデバイスから個別に取得し、異なるデバイスのデータを容易に比較できる事。
管理者は、個別のデバイスを管理するのではなく、ネットワーク全体のデバイスを統一的に管理できる事。
異なるメーカーのデバイスでも同じ設定方法が使用できる事。
設定変更によるネットワークサービスへの影響を最小限に抑えられる事。
デバイス設定のバックアップとリストアのニーズを満たす為、デバイスの設定ファイルPullingとPushingの標準化プロセスを提供できる事。
便利かつ継続的に、設備設定ファイルの整合性を確認できる事。
テキストベースの設定方法を提供でき、設定が変わらない事。例えば、ACLルールの順序が変わらない事。
これらの要件を満たすネットワークデバイスのノースバウンドAPIインターフェイスはNetconfです。
Netconf
Netconf（Network Configuration Protocol）は, IETF（Internet Engineering Task Force）によって公表された標準プロトコルです。Netconfの役割は、ネットワークデバイスの設定をインストール、操作、削除することです。Netconfアーキテクチャの中で、ネットワークデバイスはNetconfサーバーとして機能し、管理者側はNetconf Clientです。OSI標準モデルと同様に、Netconfは階層構造になっています。
▲ Netconf 4 Layers
下から上まで4つの階層があります：
•トランスポートプロトコル層
この層は、Netconf ClientとNetconf Server間の安全なエンドツーエンド接続を提供します。SNMPで使用されるコネクションレス型UDPプロトコルとは異なり、Netconfはコネクション型TCPプロトコル（通常はSSHプロトコル）を使用して、接続の信頼性とセキュリティを確保します。
• RPC層
NetconfアプリケーションはNetconf Server（ネットワークデバイス）に搭載され、Netconf Clientは、Netconf Serverのアプリケーションによって提供された関数やメソッドを呼び出す必要があります。しかし、Netconf ClientとNetconf Serverは同じメモリスペースではないため、直接呼び出すことはできません。そのため、データはネットワークを介して通信する必要があります。このプロセスはRPCと呼ばれます。これによって、オペレーション層とコンテクスト層のデータをカプセル化するため、トランスポートプロトコル層と関係ない簡単なメカニズムを提供します：
RPC呼び出し：<rpc>要素によってカプセル化されたメッセージ。
RPC結果：<rpc-reply>要素によってカプセル化されたメッセージ。
通知：<notification>要素によってカプセル化されたメッセージ。
•オペレーション層
オペレーション層は、9つの基本操作を定義します：
<get>、<get-config>は、デバイスで値演算を実行するために使用されます。
<edit-config>、<copy-config>、<delete-config>は、デバイスの設定に使用されます。
<lock>、<unlock>は、デバイスを操作する時、同時実行を防ぐためのロック操作に使用されます。
<close-session>、<kill-session>は、セッションを終了するために使用されます。
•コンテクスト層
コンテント層は設定データとステータスデータを表現するために使用されます。管理員は、デバイスの関連コマンドではなく、データに注意します。ネットワークデバイスがコンテント層で使うデータ形式通常はXMLですが、一部のメーカーはJSONを使用しています。
しかし、管理員はデバイスの関連コマンドに注意必要がなくなりましたが、Netconfを直接使用し、デバイスを設定することはできません。「設定構造」も考慮する必要があります。
「設定構造」とは何ですか？二つの例を挙げます。
例えば、スイッチのポート10をVLAN 20に割り当てたいとします。Ruijieスイッチは、その物理ポート10で設定します。
しかし、ÐメーカーのスイッチはVLAN 20で設定します。
以上の2つの例では、RuijieスイッチとÐメーカースイッチの「設定構造」が明らかに異なる為、XMLまたはJSONを使用してデバイス設定を直接変更することはできません。
設定構造の問題を解決するために、XMLおよびJSONを統合された標準モデルは必要があり、それはYANG（Yet Another Next Generation）モデルです。YANGモデルは、Netconfが操作する設定データとステータスデータを表すテンプレートであり、デバイスの期待に応えるデータを記述します。これにより、「設定構造」はYANGモデルに任されており、管理員はクローズテストを行うだけで済みます。
クローズテストの問題は次のようになります：
クローズテストの答案は次のようになります：
このプロセスは、SNMPのOID値への入力/読み取りと似ています。
NetconfとYANGモデルの出現により、ネットワーク自動化に大きな利便性がもたらしました。プログラムにより、ネットワークデバイスの設定を自動に読み取り、デバイスのデータ転送機能と制御機能を分離し、SDN（Software Defined Network）を形成します。実際、Netconfは、OpenDayLightなどのオープンソースSDN Controllerで広く使用されているサウスバウンドインターフェイスの1つです。さらに、AnsibleもNetconfのモジュールを統合し、Pythonを介してNncclientやNxpyなどのライブラリを搭載し、機能拡張を実現できます。
しかし、NetconfとYANGモデルは理想的なAPIですか？管理者の視点から言えば、答えはNoです。
なぜなら、その理由は、多くのメーカーがNetconfをサポートしていますが、各メーカーのKey-Valueの違いが存在しています。例えば、「ポート」を表現するために、一部のメーカーはintfをKeyとして使用しますが、他のメーカーはinterfaceをKeyとして使用します。もう1つの例はUptimeです。デバイスの稼働時間、各メーカーのデバイスから返される時間形式も違います。これは、管理者がデータを処理する際に多くの問題を引き起こします。各メーカーのNetconfドキュメントを読んだり、正規表現をたくさん書いたりせねばならず、多くの時間がかかります。
また、主流のSDN ControllerのサウスバウンドインターフェイスはすべてNetconfをサポートしていますが、実際の実行中では、単一のControllerを使用して複数のメーカーネットワークデバイスを制御することはできません。通常、各メーカーは独自のSDN Controllerを使用して独自のデバイスを制御し、REST APIを使用してユーザーのSDN Controllerと接続します。
▲マルチコントローラーアーキテクチャ
Netconfは、管理者が懸念している主要な問題にほぼ対応できますが、まだ完全に対応できるとは言えません。
もう1つの解決策は、NAPALMを使用することです。
NAPALM
NAPALM（Network Automation and Programmability Abstraction Layer with Multivendor support）はPythonライブラリです。現在、Ansibleは3つのNAPALMモジュールを搭載しています。それぞれは：
napalm_parse_yang：デバイスまたはファイルからの設定データ/ステータスデータを解析するために使用されます。
napalm_diff_yang：2つのYANG Objectの違いを比較するために使用されます。
napalm_translate_yang：YANG Objectをデバイスの元設定に変換するために使用されます。
デバイスから元の設定データ/ステータスデータをフェッチした後、NAPALMを使用してそれを標準形式のNAPALMデータに変換できます。逆に、標準形式のNAPALMデータは、デバイスの元設定データに変換し、ネットワークデバイスにプッシュし、デバイスの設定ファイルを変更することもできます。
しかし、これでもまだNAPALMはネットワーク自動化が直面する問題を完全に解決するとは言えません。
各メーカーのNetconfのデータ表現には多くの違いがあるため、NAPALMはサードパーティのモジュールを利用して元のデータの分析と変換をします。AメーカーのOS設定を解析する場合は、OSA_Moduleが必要です。BメーカーのOS設定を解析する場合は、OSB_Moduleが必要です。現在、NAPALMは比較的少数のOSをサポートしており、主に外国メーカーのOSに限定されています。
これらの少数の外国メーカーでさえ、NAPALMは現在完全な機能セットを実現することができません。そのため、Googleなどの企業は、Netconfに代わる標準化されたインターフェイスであるOpenConfigの宣伝に取り組んできました。
OpenConfig
IETFは、NetconfとYANG Modelに対して多くのRFCを公開しています。2006年のNetconf RFC 4741、2010年のYANG Model RFC 6020から今まで、10年以上が経過しています。最新のRFCはいつですか？ 2018年4月3日、3つのデバイスメーカーが共同でOSPF YANGモデルのドラフトを提出しました）――標準化の進捗は遅すぎます。
Netconfの標準はネットワークデバイスメーカーによって推進されており、各メーカーはSDN時代にハードウェアデバイスの重要性を維持し続け、自社製品の差別化によるメリットを望んでいます。
しかし、管理者の視点から言えば、これは明らかに不合理です。デバイスメーカーが推進しているNetconf標準は、彼らが本当に望んでいるものではありません。そのため、Google、AT＆T、British Telecom、Facebook、Apple、MicrosoftなどのインターネットサービスプロバイダーはOpenConfigワーキンググループを設立し、中立な標準APIが提供されることを期待しています。
OpenConfigはNetconfプロトコルフレームワークに従いますが、アンダーレイのデータ通信には注意を払わず、オーバーレイのデータ表示とデータモデリングに集中します。すなわち、AメーカーであろうとBメーカーであろう、すべてのデータはOpenConfig YANGモデルに準拠している必要があり、Key-ValueもOpenConfigが指定された標準形式にしなければなりません。
OpenConfigのもう1つのコアポイント：ネットワークデバイスは、デバイスメーカーの豊富な機能やプライベート機能をサポートするかもしれませんが、OpenConfigは、インターネット業界のユーザーのネットワークオペレーションとネットワークデザインに関連する機能のみを考慮します。例えば、BGP、OpenFlow、Telemetryなどです。OpenConfigは、デバイスメーカーの独自特性をYANGモデルで定義せず、デバイスメーカーに固有のKey-Valueも定義しないため、互換性が良い。
一方、OpenConfigは、一部のデバイスメーカーと互換性を持たせる為にYANGモデルを単純にしすぎない。よって、デバイスメーカーは、独自の機能をOpenConfig YANGモデルの要件に適合させ、すべてのKeyをモデルで定義し、そのKeyにKey-Valueを提供します。
Key-Valueの形式が固定された後、管理者はデータを分析することが非常に便利です。ネットワークデバイスが標準のOpenConfig YANGをサポートしている限り、NAPALMは元のデータを解析でき、マルチメーカーとマルチOSネットワークを管理できます。サードパーティのモジュールに依存しなく、ネットワーク自動化を実現できます。
▲OpenConfig & NAPALM
OpenConfigを使用するもう1つのメリットは、SDNネットワークアーキテクチャを簡素化できることです。ユーザーは、一つのコントローラークラスターを使用して複数のメーカーネットワーク機器を同時に制御でき、デバイスメーカーの商用コントローラーを使用する必要がなくなります。
▲シングルコントローラーアーキテクチャ
2015年、OpenConfigワーキンググループは、2つのYANG標準ドラフトをIETFに提出しました。正式RFCリリースはまだですが、もうネットワーク自動化技術の開発トレンドになっています。そのため、主流なネットワークデバイスメーカーがOpenConfigの開発を始めました。Ruijie Networks Japan株式会社のデータセンタースイッチは、Netconf YANGとOpenConfig YANGをサポートしています。現在、中国国内のパブリッククラウドプロバイダーと協力し、SDN標準化テストを実施しています。
