Clever Geek Handbook

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について簡単に話したかったのは、 ハブレで彼の言及すら見つけられませんでした。

このプロトコルは、生きて利益をもたらすことができると思います。

また、コメントで他の意見、特に異なる機器での興味深いパフォーマンスを聞きたいです。


More articles:


All Articles