NSO: NEDを使用した実機のConfig変更実施時の動作について

Akira Iwamoto · ‎2019-11-08

はじめに
Commit時の流れ
Change Set の作成
NED による Native Config への変換

はじめに

NSO からNEDでを使用して、各種デバイスのConfigを変更することが可能です。CDB上の/devices/device 配下のConfigを変更することで、NEDはそれに従って実機で使用するConfigに変換し、適用します。本記事では、その動作について説明します。

Commit時の流れ

NSO は NED を通してデバイスへ設定を行います。その過程では、NSOは変更セットをNEDへ送り、それを参考にしてNEDはデバイスが認識できる形へ変換します。「参考に」と書きましたが、「忠実に」では無いことに注意してください。

Change Set の作成

例えば以下のようにCLI を使用して、Device Model に従ってCDBの変更をトランザクションに作成します。

admin@ncs# conf
Entering configuration mode terminal
admin@ncs(config)# devices device c1 config
admin@ncs(config-config)# ios:interface Ethernet 1
admin@ncs(config-if)# description service 1

NSOのCDBは XML データベースであり、作成した Change Set も中身は XML です。これは、以下のコマンドで確認することが出来ます。

admin@ncs(config-if)# commit dry-run outformat xml
result-xml {
    local-node {
        data <devices xmlns="http://tail-f.com/ns/ncs">
               <device>
                 <name>c1</name>
                 <config>
                   <interface xmlns="urn:ios">
                     <Ethernet>
                       <name>1</name>
                       <description>service 1</description>
                     </Ethernet>
                   </interface>
                 </config>
               </device>
             </devices>
    }
}
admin@ncs(config-if)#

Change Set の元データは XML ですが、CLIで表示することも可能です。以下のコマンドで、XML の元データをCLI に変換して表示します。表示する内容自体は同じですが、変換する作業が必要となるため、素のデータを表示する outformat xml より時間がかかります。

admin@ncs(config-if)# commit dry-run
cli {
    local-node {
        data  devices {
                  device c1 {
                      config {
                          ios:interface {
             +                Ethernet 1 {
             +                    description "service 1";
             +                }
                          }
                      }
                  }
              }
    }
}
admin@ncs(config-if)#

NED による Native Config への変換

NSOが Change Set を実際に commit する際、/devices/device については NEDへそれが送られます。

それを受けたNEDは、入力を元に変換を行います。当然ながら、この変換方法はNED毎に違うロジックで行われます。

NEDが変換作業を終えた後、Prepare フェーズ中にリモート機器上に設定がされます。commit dry-run outformat native では、NEDが変換した結果のみを確認することが出来ます。

admin@ncs(config-if)# commit dry-run outformat native
native {
    device {
        name c1
        data interface Ethernet1
              description service 1
             exit
    }
}
admin@ncs(config-if)#

また、show configuration コマンドでも、同等の動作を行います。

admin@ncs(config-if)# show configuration
devices device c1
 config
  ios:interface Ethernet1
   description service 1
  exit
 !
!
admin@ncs(config-if)#

Generic NED では、実際にリモート機器に送られるコードが生成されていることが、よくわかります。

以下は、openstack-cos NED によって、admin プロジェクトの description を変更している様子です。openstack-cos NED は、RESTを用いて操作をしますが、以下の例では HTTP PATCH method が表示されているPayloadとともに呼ばれています。

admin@ncs(config)# devices device os config openstack-cos:projects admin description abcde
admin@ncs(config-openstack-cos:projects-admin)# commit dry-run outformat native
native {
    device {
        name os
        data PATCH http://192.168.1.1:5000/v3/projects/36ec01eb9c464f018377f564e1ff2cef
             {"project": {
               "domain_id": "default",
               "is_domain": false,
               "name": "admin",
               "description": "abcde",
               "enabled": true
             }}
    }
}
admin@ncs(config-openstack-cos:projects-admin)#

NED による変換作業

基本的には、Yang モデル上に加えられたannotation などを参考に、その順にリモート機器のConfigを生成します。

また、設定を行うにあたり機器毎に特有のルールが有る場合が多いため、それらに対する補正も行っています。例えば、vrf definition 設定がGlobalで先にされていない場合、インターフェース配下に vrf forwarding 設定を行うことは出来ませんので、順序付けを行いエラーが発生しないようにします。

これら変換作業の結果を確認するためには、上で説明したcommit dry-run outformat native が使用できます。

また、変換結果が期待したものではない場合、そもそも作成されたChange Setが正しいかを確認することも重要です。