ネットワーク自動化について私が共有した関連記事については、カタログ「NetDevOps from Scratch」を参照してください。
近年、世界的なクラウドコンピューティング分野の発展とビジネスの継続的な成長に伴い、ネットワーク技術も発展を続け、SDN技術も登場しています。 Openflow に基づく転送と制御の分離という当初の中心的なアイデアから、人々は拡張を続けています。 SDN の拡張において、人々は現在、Openflow がもはや必須条件ではないという合意に達することができています (ただし、転送と制御の分離はネットワーク プログラマビリティは、SDN アーキテクチャを評価するための重要な基準の 1 つになりつつあります。
従来のネットワーク機器のプログラム可能な操作は、通常、CLI および SNMP プロトコルに基づいています。 スクリプトであれ、ネットワーク管理ソフトウェアであれ、それらはすべて、今日説明する広範なネットワーク プログラマビリティを実現するために、これに基づいて開発されています。 機能を追加し、多くのシナリオの自動化を実現します。 一部のデバイスは、一部の Web インターフェイスの構成と、XML を介した全体的な構成の置き換えをサポートしています。 これらは非常にまれであるため、この記事では詳しく説明しません。
CLIの
CLI (コマンドライン インターフェイス) は、コマンド ラインを介して人間とコンピュータの対話を実現します。 ネットワークワーカーには必須のスキルです。 ユーザーは毎日、デバイスに対してソフトウェア SSH または Telnet を開き、構成を貼り付けて保存し、有効にします。 そんな繰り返しに飽きた人々は、ある日、プログラムを使って設定スクリプトを自動生成し、デバイスに一括ログインし、設定を発行して有効にすることで自動化を実現しました。 これはネットワークでプログラム可能な方法です。 人々の考え方、アイデア、既存の技術システムと非常に一致する利点について話しましょう。 しかし、最終的には、このアプローチはネットワーク デバイスよりも人間に有利になります。 次のような欠点があります。
-メーカーごとにコマンドセットに大きな違いがあります。 メーカーだけでなく、同じモデルでもソフトウェアのバージョンが異なると、相違点が大きく異なる場合があります。
- 開発者はコマンド セットとその使用方法に精通している必要があります。 構成レベルではセキュリティ上のリスクがあります。 例えば、開きたかったポートが、手をフリックするだけで閉じられてしまう…。
- 伝送プロトコル (SSH および Telnet) には必須の要件はありませんが、実稼働環境のセキュリティ リスクがあります。
- 構成を解析して生成するプロセスは非常に複雑です。 多くの場合、書かれた規則的なルールは限りなく「真実」に近づくことしかできませんが、「真実」全体ではありません。
- トランザクション性はなく、構成は部分的に有効になり、一部が有効にならない場合があります。
-自動化された検査機構はなく、完全に人手に頼っています。 たとえば、生成されたスクリプトが正しいかどうかをテストしたいとします。 方法はありますが、非常に難しく、簡単に実行するのが難しいことがよくあります。
-データモデリングの概念がない
CLI は常に人間とコンピューターの対話の手段です。 プログラムを通じてネットワークに特定のプログラマビリティ機能を与えることはできますが、結局のところ、本質的にネットワークでプログラマブルな方法ではありません。 現在のクラウド コンピューティングと SDN の波の下では、ネットワーク内での大規模な自動展開には適しておらず、プログラマビリティも限られています。 開発の大変さは部外者にはわかりにくい。
SNMP (英語)
SNMP (SNMP、Simple Network Management Protocol) は、ネットワーク管理システムをサポートし、ネットワークに接続されているデバイスに管理上の注意を引くような状況があるかどうかを監視するプロトコルです。 これは、アプリケーション層プロトコル、データベース スキーマ、およびデータ オブジェクトのセットを含む、一連のネットワーク管理標準で構成されます。
Wikipedia のコンテンツでは、ネットワーク管理、監視、データ オブジェクトに焦点を当てています。 これはネットワークの管理に使用され、構成および収集が可能で、主に監視に使用されます。 ネットワーク機器の一部のモジュール、特性、ステータスデータを構造化するデータモデリングを備えています。 主にネットワーク管理システム (主に監視) に使用されます。 次に、その欠点について話しましょう。
・可読性が悪い。 人間対機械の「機械」を好みます。 使用時に読み取れなくなり、モデリングデータも読み取れなくなります。 ASN.1 のスーパーセットを使用します。
- セキュリティには制限があります。 v1、v2c、v3の3つのバージョンがあり、順次セキュリティが強化されています。 ただし、最も一般的なのは v2c であり、セキュリティが制限されています。 v3 バージョンは設計上非常に安全ですが、ユニバーサルではありません。 。 。
- バックアップ、リカバリ、ロールバックのメカニズムはありません。 コマンド ラインをバックアップするための show run やその他の方法もありますが、snmp. 。 。
・書き込みが少ない。 読み取りは多く、書き込みは少なく、主に監視に使用されます。
・収集できるデータ項目は限られており、装置全体の構成は取得できません。 多くの場合、cli を使用して収集することはできますが、snmp を使用して収集することはできません。
- パフォーマンスのボトルネックがあります。 収集されるデータの上限は 64K であり、収集の粒度が大きすぎます。 大規模で複雑なネットワークでは、数分以上かかる場合があります。 これも重要な点を強調しています。 粒度に対する要件も非常に厳しいです。 多くの場合、ポートのトラフィックを数秒ごとに収集したいと考えています。 大規模なネットワークでは、従来のネットワーク管理ソフトウェアは次のようなものだと思います... もう 1 つの文を拡張すると、現在の手法はマイクロ秒レベルを達成できる Telemetry (gRPC など) であり、一部にはソフトウェアとハードウェアの組み合わせが必要です。 まだ普及していませんが、将来的にはトレンドになるはずです。 それが将来いつになるかというと…
-SNMPは、その誕生以来、監視用のデータを取得するためにネットワーク監視の分野で広く使用されてきました。 構成機能の欠如と複雑さにより、ネットワーク構成ではほとんど使用されていません。 読み取り専用ネットワークはプログラム可能。
Netconf プロトコルと YANG モデル
次世代ネットワークに直面して、ネットワークのプログラマビリティをより良く実現し、自動化のレベルを向上させるには、どのようなネットワーク管理プロトコルが必要でしょうか?
IETF は 2002 年に RFC3535 で次のアイデアを提案しました (実際には 33 個あります。オンライン情報と著者の知識に基づいて、次のアイデアを書きました)。
1. ネットワーク設定用のプログラム可能なインターフェイスがあります
2. メーカーやモデルを超えて同じ構成が使用可能
3. 可読性の高いモデリング言語を統一する必要がある
4. 完全なエラーチェックおよびリカバリ機能
5. トランザクション
アイデアがあれば、あとはそれを実行するだけです。 2006 年に IETF は、RFC3535 によって提起された問題を解決する Netconf プロトコルを提案しました。 初期の Netconf では、プロトコルの基本的なフレームワークと動作のみが規定され、RFC3535 のいくつかの問題を考慮した解決策が定義されました。 統一されたモデリング言語は規定されていませんでした。 したがって、一部の初期のメーカーの機器は Netconf の一部の基本操作のみをサポートし、統合された最下層を使用していませんでした。 データモデリング言語。
RFC6020 は 2010 年にリリースされ、YANG Model モデリング言語とそれを NETCONF と組み合わせる方法を提案しました。 1 つの定義は、メーカー間で基礎となるリソース ロジックを統一するデータ モデリング言語であり、もう 1 つの定義は、構成データとステータス データに対する各メーカーの操作のための統一されたコマンド セットです。 YANG モデルによって作成されたデータ インスタンスは、Netconf プロトコルでラップされます。 送信、この 2 つは相互に結合され、YANG モデルに基づいて Netconf プロトコルによって駆動される新時代のユニバーサル ネットワーク プログラマブル インターフェイスの新しいセットを構築します。
2016 年以降、Netconf プロトコルは YANG モデルと密接に統合され、普及しました。 これまで、SDN アーキテクチャ ソフトウェアのいくつかの側面を見るとき、多かれ少なかれこれら 2 つの用語を聞いてきました。
YANG と Netconf は、陰と陽のように、一方は静的で、もう一方は動的です。 二人は次の時代のネットワークプログラマブルの世界を導き出しました。 (github 上の YANG 倉庫を見ると、そのアイコンが太極拳であることもわかります。また、その名前と「Yang」の関係から、元のデザイナーのデザイン アイデアがある程度明らかになります)。
次に、YANG モデルと Netconf プロトコルについて簡単に説明します。 まず、データ モデリング言語 YANG について説明し、この言語がこのネットワーク世界のデジタル ツインをどのように記述するかを見てみましょう。
ヤンモデル
RFC6020 文書の冒頭の章では、「YANG (ネットワーク構成プロトコル用のデータ モデリング言語)」と明確に述べられています。 Yet Another Next Generation (Yang) Data Modeling Language の略称です。 これは、ネットワークの概念を記述するために使用されるモデリング言語です。
リスト、辞書、さらに複雑なデータ構造の定義をサポートし、制約、列挙、参照インポート、バージョン管理、名前空間をサポートします。 紙面の都合上、簡単に説明させていただきます。 詳細については、以下を参照してください。
このネットワーク デバイスを構造化言語で非常に簡単に記述することができます。 たとえば、ポートの定義の場合は次のようになります。
プロの運用および保守担当者は、ネットワークの基本とプログラミングの基本を少し理解していれば、ポートの定義を比較的明確に理解できます。 これはリスト構造であり、複数存在する可能性があります。 その属性の 1 つは、interface-name (キーでもあります) です。 、一意、反復不可能）、およびスピード属性とデュプレックス属性（どちらも文字列）。
構成ステータスや動作ステータスなど、ネットワーク デバイスの多くの属性は YANG モデルによって記述されます。
このように、YANG モデルは構造化言語を使用してオンライン世界を記述します。 ご興味がございましたら、非常に詳細な説明が記載されている上記のインターネット ブログ投稿をご覧ください。
これは XML データにうまく変換でき、Netconf プロトコルにラップして送信できます (これについては後で説明します)。
同時に、ベンダー間の差異を平準化するために、Google 主導の Openconfig がデータ モデルを標準化しました。 公式Webサイトを見ると、「ユーザーが設計したベンダー中立、モデル駆動型のネットワーク管理」というキャッチコピーがあり、ユーザーが設計し、クロスプラットフォームで設計されています。 ベンダー共通のモデル駆動型ネットワーク プログラミング (最初にこのように翻訳しましょう)。 簡単に言うと、さまざまなメーカー間のモデリングを同じにすることで、特定のデータを設定するときに、各メーカーのプライベート陽モデルを 1 つずつ調べる必要がなくなります。 しかし、インターネットには常にプライベート プロトコルがあり、さまざまなメーカーが「より良いユーザー エクスペリエンス」と「より良いビジネス戦略」のために、常に新しいより良いプライベート プロトコルを作成します (これは実際、ネットワーク メーカーの原罪です)。 この図は、より一般的に使用される openconfig yang モデルの実装の一部を示しています。
写真を見る限りかなりの数があり、よく使われる構成は比較的揃っていると思います。 ただし、実際には、メーカーがこれらの陽モデルもサポートしているかどうかによって異なります。 特定の主題の一部の上位バージョンのデバイスは基本的にサポートされます。 国内のものはまだ詳しく見ていません。
ネットワークはまったく同じであることはできません。 ネットワークの運用保守開発に携わるエンジニアにとって、同じ目標を達成できるのはありがたいことです！
openconfig は https://github.com/openconfig/public/tree/master/release/models にあります。
プライベートヤンモデルはさまざまな公式ウェブサイトで見つけることができます。
Netconf プロトコル
yang モデルについて話した後は、Netconf プロトコルについて話しましょう。 yang モデルはネットワーク世界のデジタル記述を定義し、Netconf はデータの取得 (get) と調整 (config) を定義します。
Netconf は、ヤンモデルで記述された世界のデータをカプセル化し、ネットワーク世界の管理を実現します。
Yang データは XML にカプセル化され、Netconf プロトコルを通じて管理されます。 これは、階層的な方法でプロトコルの詳細を説明する、優れた階層化されたアイデアを備えたプロトコルです。 上の写真を見てみましょう。
- 送信: Netconf は SSH プロトコルを通じて送信され、接続指向であり、セキュリティが保証されています。
- メッセージ: RPC 経由でネットワーク デバイスにリモート呼び出しを行い、ネットワーク マネージャーが rpc 要求を発行し、ネットワーク デバイスが rpc 応答を再開します。
- 操作: これは Netconf の魂です。 get (構成および実行データ)、get-config (構成データの取得、デバイスは複数の構成データ、1 つの実行中、1 つの起動、複数の候補候補を持つことができます)、edit -config (ネットワーク デバイス パラメーターの構成、追加のサポート、削除と変更）、delete-config、copy-config（設定を宛先にコピーします。宛先は FTP、ファイル、実行コンフィギュレーションなどです）、lock\unlock（設定の競合や次のような原因による失敗を防ぐために設定をロックします）マルチプロセス操作) など。
-データ: データは、XML でラップされた陽データです。 上で説明したポートと同様に、構造化データはプログラミングが簡単です。 設定、削除、または取得するデータを記述するために使用されます。
これらは Netconf の 4 つの層です。 制御側とネットワーク デバイスは、Netconf サブシステムを使用して、従来の ssh プロトコルを介して Netconf 経由で通信します。デフォルトのポートは 830 です。以下に示すように。
この図は、生の ssh を使用した対話を示していますが、実際には、このプロセスはプログラミングによって実装されます。 プログラミングの実装方法については後ほど説明します。
Netconf はネットワーク デバイスを構成します。 インタラクションのプロセスは大まかに次のとおりです。
この絵はとても低いので、私が描いたものであることもわかります... Netconf についての私の理解は上記のとおりです。 インターネット上には正しくない画像がたくさんあると思います。また、サーバー エージェントの動作の多くは正しくありません。 これはデバイスにログインしたときに直感的に感じたことで、もちろん公式ドキュメントと1対1に対応しています。
Netconf の例をいくつか見てみましょう。
こんにちは、リンクを作成します。
Netconf のバージョン、サポートされている YANG モデル、セッション ID などのキーワードがいくつかありました。 同時に、hello はどの名前空間で動作しているかを示します。この場合、それは Netconf の対応するバージョンです。
構成の取得
get-cofig のパラメータの 1 つは、source です。これは、構成データ (実行中、起動時など) が取得される場所です。 もう 1 つのパラメータはフィルター、つまりどのヤン モデルで記述されたデータ モデルからどのデータを取得するかです。 これは、ネットワーク デバイスによって最初に送信された機能に対応します。 成功すると、対応する構成データが返されます。
構成または実行データを取得する
get-config に似ていますが、取得されるのは実行構成 (個人的な理解) または実行データです。 フィルタを指定することができます。
設定のコピー
コピー操作には、ソースと宛先という 2 つのパラメーターがあります。 成功した応答には ok タグが付きます。
構成の編集
構成を編集する場合は、編集するデータ項目、機能の名前空間、および対応するラベルを指定します。 たとえば、これは dhcp を構成するためのもので、これは yang モデル http://tail-f.com/ns/example/dhcp で記述されています。
セッションを正常に終了する
ssh で送受信されるのはこの種のメッセージです。 皆様にご理解いただきやすいよう、メッセージの一部を抜粋させていただきました。
次に、参照用のコンテンツを追加するだけです。
-Netconf はセッションに基づいており、すべての成功にはセッション ID が付けられます。
- リクエストが徐々に大きくなる限り、各リクエストにはメッセージ ID が含まれます。
・データ構成はロック、排他、ロックによる操作が可能です。
-Netconf はトランザクション型であり、操作はすべて実装されるか、まったく実装されないかのどちらかです。 同時に、公式 Web サイトのドキュメントによると、このトランザクション性は N 個のネットワーク デバイスの構成に対するものであり、つまり、ワンタイム構成ポリモーフィズムはトランザクション性をサポートできます。 でもまだやってないんです…
-Netconf はサブスクリプションをサポートします。 デバイスのパフォーマンスの点では、約 5 セッションほど大きくなります。 特定のデータ項目をサブスクライブすると、データ項目が変更されるとデバイスが通知をくれます。
-能力、これが私が理解している方法です。 ネットワークデバイスは Netconf と YANG Model のバージョンを送信し、制御端末は Netconf のバージョンを送信します。 Netconf のバージョンが 2 つと一致する場合にのみ、続行できます。 これが私の直感です。 アドバイスは大歓迎です。
- get edit などの操作では、変更するデータを指定します。これは、filter を使用してフィルタリングできます。
-copy-config は、構成の完全なセットをある場所から別の場所にコピーすることをサポートします。 場所は、デバイス上の FTP ファイル、実行中、スタートアップ、および候補設定です。
-Netconf は、検証操作を使用した構成の検証もサポートします。
この記事は依然として科学の普及を目指しており、詳細には触れません。 RFC の関連プロトコルを読むことができますが、実際にはそれほど長くありません。
実際には、Python の ncclient などのオープン ソース ソフトウェアに基づいて、ネットワーク デバイスを自動的に構成し、ネットワーク プログラマビリティを簡単に実現できます。 これが Netconf と YANG Model の使命です。
ネットワーク担当者は、適切にフォーマットされた YANG モデル定義を読み取り、関連するプログラミング言語を使用して、Netconf で定義された操作に基づいてネットワーク デバイス上でプログラム可能な操作を実行します。 このようにして、ネットワーク プログラマビリティへの道が築かれます。
YANG モデルがネットワーク デバイスのデータ構造を定義していると想像してみましょう。 Netconf を通じて操作できます。 他のプロトコルでも操作できますか?
答えは「はい」です。 実際、RESTConf など、他の多くのプロトコルが Netconf から派生しています。 以下に示すように、
YANG モデル (パブリックおよびネイティブ) はデータ構造を定義し、その上に新しいネットワーク管理プロトコル、Netconf、RESTCon、gRPC などがあります。このようにして、HTTP RESTful API に基づいた RESTConf を通じてネットワーク デバイスを操作でき、ネットワークも操作できます。 SSH ベースの Netconf 経由でデバイスを操作することも、HTTP2 ベースの gRPC 経由でネットワーク デバイスを操作することもできます。0。 これらはすべて、優れたデータ構造を備えた YANG に基づいています。 モデル化して、対応するデータを書き込み、それを XML または JSON にカプセル化し、ネットワーク デバイスをプログラムします。 これはネットワーク プログラマビリティの未来です。 正確に言うと、モデル駆動型プログラム、つまりモデルベースのネットワーク プログラマビリティです。 ネットワーク エンジニアは、コマンド セットではなくデバイスのパラメータに徐々に注目し、対応するデータ モデルを読み取ることでネットワーク パラメータを構成します。
最後に、なぜこの公開アカウントを開設する必要があるのかを書きます。 私は学生時代にコンピューターサイエンスとテクノロジーを学びました。 入社後はネットワークの運用保守業務に従事しました。 考えてみると、私がチームに分かれていたのは、私がネットワーク技術研究所の大学院生だったからかもしれません（マニュアルおかしい）。 私は当初からネットワーク運用に携わっていました。 運用保守後期では、CLIをベースにツールを活用して作業の簡素化と効率化を図りました。 その後、ツールは BS 構造の Web アプリケーションに徐々に開発されました。 彼らは常に新しいテクノロジーに触れ、新しい機能を強化し続けました。
幸いなことに、彼らはオープンソース テクノロジーと SDN の開発に追いつき、私は徐々に NetDevOps の仕事に移行し、自分のプログラミング スキルを使ってチームの運用と保守の能力を向上させました。 このコード行を書くのも楽しかったです。 執筆が進むにつれて、NetDevOps は、高レベルの計画と迅速な実装の両方を達成できるように、将来的にすべてのネットワーク エンジニアが持つべきスキルであることが徐々にわかります (誰もが火に油を注ぐことになります)。 ネット上の情報を見てみると、正直、中国の情報は非常に少なく、国内の雰囲気はあまり強くありません。 国内のソフトウェアの多くは古い CLI や snmp をベースにしており、誰もが今でもテキスト ツールや SSH ツールを仕事で使用しています。 だから私はそう願っています他の人に釣り方を教えたり、自分の経験（ピット）やスキルをより多くのネットワーク運用および保守エンジニアと共有したりできます、頑張ってください。 Xiao Chu 氏は、作業負荷を軽減するために何かを学ぶことができ、遠い将来に焦点を当てることで、国内ネットワークの運用と保守は真の自動化に向けて進化できると述べました。
今後は動画を撮ったり、記事を書いたりするつもりです。 書類を書くのは本当に大変だと思います。 購読、収集、「いいね！」をクリックして視聴することを歓迎します。
付録: Netconf の一般的な操作
DWDM OTN ソリューションの設計とコストの見積もり。Taylor Huang にご連絡ください。
