RFC準拠のNETCONFセッションを設定する
NETCONF を使用して Junos デバイスを管理する場合、NETCONF セッション中に、NETCONF サーバーに RFC 4741、NETCONF 構成プロトコルに準拠した特定の動作を強制する必要があります。RFC コンプライアンスを適用するには、 階層レベルで ステートメントを[edit system services netconf]設定rfc-compliantします。ステートメントを設定するとrfc-compliant、NETCONF セッションの以下の側面に影響します。
-
NETCONF サーバーから発信された名前空間に対する返信
-
RPC で返される要素は、 に対して
<get>返信し<get-config>、返す構成データがない場合は操作を行います。 -
NETCONF サーバーは、重大度レベルの警告を
<ok/>含む要素と<rpc-error>要素の両方を返す応答を返します。 - NETCONF サーバーは、 および
<validate>操作に対して<commit>返信します。
違いについては、以下のセクションで詳細に説明します。
名前 空間
デフォルトでは、NETCONF サーバーは、サーバーの応答の開始タグで NETCONF 名前空間にデフォルトの名前空間を設定し、NETCONF タグ名は修飾されません。例えば：
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
...
</capabilities>
<session-id>27700</session-id>
<hello>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
ステートメントを rfc-compliant 設定すると、NETCONFサーバーは、その返信でデフォルトの名前空間を定義しません。代わりに、サーバーには、プレフィックスにバインド nc された NETCONF 名前空間の名前空間宣言が含まれており、そのプレフィックスで応答内のすべての NETCONF タグを修飾します。RPC リクエストでデフォルト名前空間を NETCONF 名前空間に設定した場合、サーバーはデフォルトの名前空間を破棄し、プレフィックスにバインドされている宣言された名前空間のみを使用して応答を nc 送信します。
次のサンプル出力は、 ステートメントが設定されている場合にNETCONFサーバーの <hello> メッセージと機能交換を rfc-compliant 示しています。タグには <hello> 宣言が xmlns:nc 含まれており、すべてのNETCONFタグにはプレフィックスが nc 含まれています。
<nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:capabilities>
<nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability>
...
</nc:capabilities>
<nc:session-id>27703</nc:session-id>
</nc:hello>
以下の出力は、 ステートメントが設定されている場合のRPC返信の例を rfc-compliant 示しています。
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
<nc:data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"
junos:changed-seconds="1417554471"
junos:changed-localtime="2014-12-02 13:07:51 PST">
<!--configuration data-->
</configuration>
<database-status-information>
<database-status>
<user>root</user>
<terminal></terminal>
<pid>47868</pid>
<start-time junos:seconds="1417560303">2014-12-02 14:45:03 PST</start-time>
<edit-path></edit-path>
</database-status>
</database-status-information>
</nc:data>
</nc:rpc-reply>
Junos OSリリース17.2R1以降、NETCONFセッションで ステートメントを設定 rfc-compliant し、設定データを要求すると、サーバーは対応するYANGモデルと同じ名前空間に要素のデフォルト <configuration> 名前空間を設定します。
<rpc>
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
]]>]]>
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<nc:data>
<configuration
xmlns="http://yang.juniper.net/yang/1.1/jc/configuration/junos/17.2R1.13"
junos:commit-seconds="1493761452"
junos:commit-localtime="2017-05-02 14:44:12 PDT"
junos:commit-user="user">
...
</configuration>
</nc:data>
</nc:rpc-reply>
]]>]]>
<get>および<get-config>運用の変更
ステートメントは rfc-compliant 、 <get> および <get-config> サーバーが返す設定データがない場合に、および サーバーの返信に影響を与えます。たとえば、フィルターを適用して設定のサブセットを返し、その部分が空の場合などに、このようなことが発生する可能性があります。
または <get-config> の操作を<get>実行し、要求された階層に設定データがない場合、ステートメントが設定されていない場合rfc-compliant、RPC応答には要素内に空<configuration>の要素が<data>含まれます。
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1D0/junos"> <data> <configuration> </configuration> </data> </rpc-reply>
または 操作を<get>実行し、要求された階層に設定データがない場合rfc-compliant、RPC 応答は空<data>の要素を返し、要素を<configuration>省略<get-config>します。
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos"> <nc:data> </nc:data> </nc:rpc-reply>
<rpc-error> RPC の返信で重大度レベルの警告を持つ要素
Junos OS リリース 17.4R3、18.2R2、18.3R2、および 18.4R1 以降、 ステートメントを設定rfc-compliantすると、NETCONF サーバーは要素と<ok/>要素の両方<rpc-error>を含む RPC 応答を返すことはできません。操作が成功しても、サーバーの応答には、要素に加えて<ok/>重大度レベルの警告が含まれる要素が 1 つ以上<rpc-error>含まれる場合、警告は省略されます。さらに、Junos OS リリース 21.2R1 以降、操作中<commit>に省略される警告は、追跡のためにシステム ログ ファイルにリダイレクトされます。
以前のリリースでは、または ステートメントが構成されていない場合 rfc-compliant 、NETCONF サーバーは重大度レベルの警告と要素の両方を <rpc-error> 含む RPC 応答を <ok/> 発行することがあります。例えば、コミット操作は成功する可能性がありますが、次の NETCONF サーバーの応答のように警告を返します。
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<nc:rpc-error>
<nc:error-severity>warning</nc:error-severity>
<nc:error-message>
uid changed for jadmin (2001->2014)
</nc:error-message>
</nc:rpc-error>
<nc:ok/>
</nc:rpc-reply>
]]>]]>
ステートメントを設定した rfc-compliant 場合、警告は省略されます。
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.4R1/junos"> <nc:ok/> </nc:rpc-reply> ]]>]]>
NETCONF Server Response to <commit> and <validate> Operations
Junos OS リリース 21.2R1 以降、 ステートメントを rfc-compliant 設定すると、NETCONF サーバーの操作に対する <commit> 応答には、以下の変更が含まれます。
-
操作が成功すると
<commit>、1 つ以上の警告を含む応答が返された場合、警告は応答から除外されるのに加えて、システム ログ ファイルにリダイレクトされます。 -
NETCONF サーバーの応答は、要素ではなく
<source-daemon>要素の<error-info>子として要素を<rpc-error>送信します。 -
また、 階層レベルで ステートメントを
flatten-commit-results[edit system services netconf]設定した場合、NETCONF サーバーはその応答で または<rpc-error>要素のみを送信<ok/>し、XML サブツリーを<commit-results>抑制します。
Junos OS リリース 23.2R1 以降、 ステートメントをrfc-compliant設定すると、NETCONF サーバーは操作に応答して <ok/> <validate> または <rpc-error> 要素のみを送信します。以前のリリースでは、RPC リプレイには 要素も含まれています<commit-results>。
rfc-compliant設定すると、NETCONF サーバーは操作に応答して
<ok/>
<validate> または
<rpc-error> 要素のみを送信します。以前のリリースでは、RPC リプレイには 要素も含まれています
<commit-results>。
rfc-compliant 設定すると、NETCONF サーバーの操作に対する
<commit> 応答が変更されます。
rfc-compliantすると、NETCONF サーバーは要素と
<ok/>要素の両方
<rpc-error>を含む RPC 応答を返すことはできません。