Geekly Articles each Day

NETCONF。 開始する

SNMP （Simple Network Management Protocol）として知られている「 シンプルなネットワーク管理プロトコル 」があると聞いた人もいれば、確信している人もいます 。
しかし、私はNETCONFを知っている人々に会ったことはほとんどありません。NETCONFは 、その作成者が望むように、SNMPの代わりになるでしょう。

彼はどんな人ですか？ これはSNMPの類似物ですか？ これは管理の進化ですか？ それとも行き止まりのブランチですか？


NETCONFについて簡単に


したがって、 NETCONFはネットワーク構成プロトコルです（「シンプル」という言葉はありません。明らかにこれは彼の問題です）。 それはIETF NETCONF作業部会によって開発されています。 彼の「人生」はRFC 4741で2006年12月に始まり、2011年6月にRFC 6241が公開されました。
それはジュニパーの会社の腸から来ました。より正確には、ファイルJunos XML APIと呼ばれます。

SNMPが悪いのはなぜですか？


そして本当に、なぜNETCONFを再発明するのでしょうか？ 結局のところ、SNMPは80年代後半に登場した（1988年のSNMPv1）非常に「新鮮な」プロトコルです。 比較のために、telnetは1969年に開発され、現在も使用されています。 彼らは、暗号化されたSNMPv3を思い付きました。

それでも、2002年にはインターネットアーキテクチャ委員会（IAB）ネットワーク管理ワークショップの会議が開催され、 RFC 3535が発表されました 。 特に、以下を含むネットワーク管理技術の長所と短所の概要を説明しています（パラグラフ2）。 SNMP（2.1節）。

私の意見では、SNMPの不利な点の最も明白なものをいくつか挙げます。


NETCONFの準備



私の意見では、プロトコルは非常にシンプルで、RFCは非常によく書かれています。

概念的には、NETCONFは次のようになります。

ここで写真を撮りました 。

現在、4つのオプションがトランスポートとして定義されています。


操作は、XMLで表されるRPC要求で「ラップ」されます。

次の基本操作が定義されています。

< get > , < get-config > , < edit-config > , < copy-config > , < delete-config > , < lock > , < unlock > , < close-session > , < kill-session > .


クライアント/サーバープロトコルモデルが使用されます。 確立されたセッションは、必要な限り（接続があり、サーバーがまだ稼働している限り）保持できます。

接続が確立されると、クライアントとサーバーはサポートされているパラメーターを交換します（RPC通知を使用）。

何ができますか？ そして、例えば次のことができます。


NETCONFの操作方法を理解する最も簡単な方法は、一例だと思います。

ジュニパーのNETCONFの例



NETCONFをオンにします。
システムサービスを設定するnetconf ssh


そして、接続してみてください：
sshユーザー名@ host -s netconf


パスワードを入力（またはキーを確認）した後、「サーバー」からhelloを取得します。
<!-- No zombies were killed during the creation of this user interface -->
<!-- user test, class j-super-user -->
< hello >
< capabilities >
< capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability >
< capability > xml.juniper.net/netconf/junos/1.0 </ capability >
< capability > xml.juniper.net/dmi/system/1.0 </ capability >
</ capabilities >
< session-id > 666 </ session-id >
</ hello >
]] > ]] >

* This source code was highlighted with Source Code Highlighter .


サーバーから、その機能のリストが通知されました。
ゾンビについて-これは冗談です、Junosで時々起こります。 たとえば、 俳句を表示する隠しコマンドもあります。
バージョンと俳句を表示


helloに応答して、クライアントは、たとえば同じ機能のリストを使用してhelloで応答する必要があります。
< hello >
< capabilities >
< capability > urn:ietf:params:xml:ns:netconf:base:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </ capability >
< capability > urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </ capability >
< capability > xml.juniper.net/netconf/junos/1.0 </ capability >
< capability > xml.juniper.net/dmi/system/1.0 </ capability >
</ capabilities >
</ hello >
]] > ]] >

* This source code was highlighted with Source Code Highlighter .


それだけです これで、サーバーを操作できます。 たとえば、現在の構成の一部を確認します。
< rpc message-id ="100" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< get-config >
< source >
< running />
</ source >
< filter type ="subtree" >
< configuration >
< protocols />
</ configuration >
</ filter >
</ get-config >
</ rpc >

* This source code was highlighted with Source Code Highlighter .


答えを得るもの：
< rpc-reply message-id ="100" xmlns:junos ="http://xml.juniper.net/junos/11.2R5/junos" >
< configuration junos:commit-seconds ="1311003260" junos:commit-localtime ="2012-06-06 11:21:40 UTC" junos:commit-user ="test" >
< protocols >
SKIPPED
</ protocols >
</ configuration >
</ rpc-reply >

* This source code was highlighted with Source Code Highlighter .


リクエストで指定されたmessage-id = "100"は、レスポンスにも保存されます。 T.O. 異なる順序で受信できる異なる回答を区別できます。

rpc-replyに加えて、クライアントからのリクエストの処理中にエラーが発生したときにrpc-errorをキャッチできます。 RFCの例：
< rpc-reply message-id ="110" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< rpc-error >
< error-type > rpc </ error-type >
< error-tag > missing-attribute </ error-tag >
< error-severity > error </ error-severity >
< error-info >
< bad-attribute > message-id </ bad-attribute >
< bad-element > rpc </ bad-element >
</ error-info >
</ rpc-error >
</ rpc-reply >

* This source code was highlighted with Source Code Highlighter .


出力を必要としない要求（コマンドなど）が正常に実行された場合、サーバーは次のようにOKで応答します。
< rpc-reply message-id ="201" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< ok />
</ rpc-reply >

* This source code was highlighted with Source Code Highlighter .


ジョブを終了するには、セッションを閉じる必要があります。
< rpc message-id ="100500" xmlns ="urn:ietf:params:xml:ns:netconf:base:1.0" >
< close-session />
</ rpc >

* This source code was highlighted with Source Code Highlighter .


NETCONFはどこで機能しますか？


ジュニパー、ブロケード、シスコ、Huaweiなどのデバイスでは噂されています。

...しかし


それほど良くありません。 NETCONFによって十分に文書化および管理されており、ジュニパーでしか見たことがない。 残念ながら、Huaweiではテストしませんでした。 必要はありませんでした。ブロケードの場合、実験的な被験者はいませんでした。 しかし、シスコ...

少なくともiOSバージョン15までのCatalystラインでのNETCONFの操作について：

私の意見では、シスコの実装は仕事よりもショーのためのものです。

おわりに


NETCONFについて簡単に話したかったのは、 ハブレで彼の言及すら見つけられませんでした。
このプロトコルは、生きて利益をもたらすことができると思います。
また、コメントで他の意見、特に異なる機器での興味深いパフォーマンスを聞きたいです。

Source: https://habr.com/ru/post/J135259/

More articles:


All Articles