NSO 4.7.1 から Audit Netwrok Log が導入されました。これは、デバイスへの変更に関して誰が、いつ、どのような内容で、といった Traceability を向上するものです。   デフォルトでは無効になっていますので、有効にするためには ncs.conf に以下の設定を追加する必要があります。 <logs> <audit-network-log> <enabled>true</enabled> <file> <name>./logs/audit-network.log</name> <enabled>true</enabled> </file> </audit-network-log> </logs>   有効にしている状態でデバイスに対して変更を実施すると、audit-network.log ファイルに詳細な変更内容が記録されます。各エントリのヘッダーにはユーザ名、セッション ID、Transaction ID、デバイス名などの情報が記載されます。 <INFO> 28-Oct-2018::23:35:41.499 TOOKADA-M-4198 ncs[9938]: audit_network user: admin/58 thandle 102 device c1 BEGIN EDIT <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <target> <candidate/> </target> <test-option>test-then-set</test-option> <error-option>rollback-on-error</error-option> <config> <configuration xmlns="http://example.com/device"> <system> <host>test</host> </system> </configuration> </config> </edit-config> </rpc> END EDIT <INFO> 28-Oct-2018::23:36:31.347 TOOKADA-M-4198 ncs[9938]: audit_network user: admin/58 thandle 129 device c1 BEGIN EDIT <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <target> <candidate/> </target> <test-option>test-then-set</test-option> <error-option>rollback-on-error</error-option> <config> <configuration xmlns="http://example.com/device"> <system> <host xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/> </system> </configuration> </config> </edit-config> </rpc> END EDIT   運用上の Requirement で詳細な変更履歴を記録しておく必要が場合などに有用ですので、必要に応じてお試しください。         ... View more

NSO 4.5.2 / 4.6 以降では RFC 8040 に記載されている RESTCONF Event Notification がサポートされています。   Event Steam のリストは以下のリソースにアクセスして確認することができます。 ❯ curl -kisu admin:admin \ -X GET \ -H "Accept: application/yang-data+xml" \ "http://localhost:8080/restconf/data/ietf-restconf-monitoring:restconf-state/streams" HTTP/1.1 200 OK Server: Date: Sun, 28 Oct 2018 12:43:05 GMT Last-Modified: Sun, 28 Oct 2018 12:36:58 GMT Cache-Control: private, no-cache, must-revalidate, proxy-revalidate Etag: 1540-730218-163393 Content-Type: application/yang-data+xml Transfer-Encoding: chunked Pragma: no-cache <streams xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring" xmlns:rcmon="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"> <stream> <name>NETCONF</name> <description>default NETCONF event stream</description> <replay-support>false</replay-support> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/NETCONF/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/NETCONF/json</location> </access> </stream> <stream> <name>ncs-alarms</name> <description>NCS alarms according to tailf-ncs-alarms.yang</description> <replay-support>false</replay-support> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/ncs-alarms/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/ncs-alarms/json</location> </access> </stream> <stream> <name>ncs-events</name> <description>NCS event according to tailf-ncs-devices.yang</description> <replay-support>true</replay-support> <replay-log-creation-time>2018-10-28T12:36:56+00:00</replay-log-creation-time> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/ncs-events/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/ncs-events/json</location> </access> </stream> <stream> <name>device-notifications</name> <description>NCS events forwarded from devices</description> <replay-support>true</replay-support> <replay-log-creation-time>2018-10-28T12:36:56+00:00</replay-log-creation-time> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/device-notifications/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/device-notifications/json</location> </access> </stream> <stream> <name>service-state-changes</name> <description>Plan state transitions according to tailf-ncs-plan.yang</description> <replay-support>false</replay-support> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/service-state-changes/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/service-state-changes/json</location> </access> </stream> <stream> <name>exevent</name> <description>Example event of RESTCONF notification</description> <replay-support>true</replay-support> <replay-log-creation-time>2018-10-28T12:36:56+00:00</replay-log-creation-time> <access> <encoding>xml</encoding> <location>http://localhost:8080/restconf/streams/exevent/xml</location> </access> <access> <encoding>json</encoding> <location>http://localhost:8080/restconf/streams/exevent/json</location> </access> </stream> </streams>   Event Steam への subscribe は以下のように実施します。 ❯ curl -kisu admin:admin \ -X GET \ -H "Accept: text/event-stream" \ "http://localhost:8080/restconf/streams/ncs-events/xml" HTTP/1.1 200 OK Server: Date: Sun, 28 Oct 2018 12:57:19 GMT Cache-Control: private, no-cache, must-revalidate, proxy-revalidate Content-Type: text/event-stream Transfer-Encoding: chunked Pragma: no-cache   Notification の受信例 data: <notification xmlns='urn:ietf:params:xml:ns:netconf:notification:1.0'> data: <eventTime>2018-10-28T21:58:47.442302+00:00</eventTime> data: <test-notif xmlns='http://example.com/notif'> data: <status>OK - Notif from service</status> data: </test-notif> data: </notification> ... View more

Python API のログフォーマットが NSO 4.5 から他のログファイルと同様のフォーマットに統一されました。 4.5 より古いバージョンのフォーマット 2018-04-29 21:36:13 - pyservice - INFO - Starting... 2018-04-29 21:36:13 - pyservice - INFO - Started 2018-04-29 21:36:16 - pyservice - INFO - Main RUNNING 2018-04-29 21:38:01 - pyservice - INFO - Service create(service=/pyservice:pyservice{test}) 4.5 以降のバージョンのフォーマット <INFO> 29-Apr-2018::21:44:29.535 pyservice MainThread: - Python 2.7.14 (default, Sep 24 2017, 11:38:22) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] <INFO> 29-Apr-2018::21:44:29.535 pyservice MainThread: - Starting... <INFO> 29-Apr-2018::21:44:29.537 pyservice MainThread: - Started <INFO> 29-Apr-2018::21:44:34.557 pyservice ComponentThread:main: - Main RUNNING <INFO> 29-Apr-2018::21:46:58.175 pyservice ncs-dp-81846-pyservice:main-1-th-85: - Service create(service=/pyservice:pyservice{test}) 新しいフォーマットではミリセカンド単位の時間も表示されるように変更されています。 また、NSO 4.6 からはパッケージ単位でロギングレベルを設定することが可能になっています。 python-vm logging vm-levels pyservice level level-debug debug レベルに設定したサンプル <INFO> 29-Apr-2018::22:00:51.300 pyservice MainThread: - Setting log level debug on pyservice <DEBUG> 29-Apr-2018::22:00:51.300 pyservice MainThread: - log_level 20 -> 10 on pyservice (root) <INFO> 29-Apr-2018::22:00:51.300 pyservice MainThread: - Setting log level debug on pyservice (root) <DEBUG> 29-Apr-2018::22:00:51.300 pyservice MainThread: - Waiting for Json msgs <DEBUG> 29-Apr-2018::22:01:10.175 pyservice ncs-dp-81846-pyservice:main: - TransactionCallback.cb_init(_ncs.TransCtxRef : fd=-1 : vfd=-1 : th=191) <DEBUG> 29-Apr-2018::22:01:10.175 pyservice ncs-dp-81846-pyservice:main: - _WsockCb.create_item() = <ncs.dp._Wsock object at 0x104ae0050> Python API を使用したパッケージの開発に役立つと思いますので、試してみてください。 ... View more

wait-for-lock とは NSO 4.4.2 からデバイスの sync-from/sync-to/check-sync/partial-sync-from アクションに wait-for-lock パラメータが追加されました。compare-config に関しては NSO 4.5 から追加されています。wait-for-lock は他のアクションが実行されていてデバイスが lock されている場合、lock がリリースされるまでどのくらい待つかを指定するものです。意味合いとしてはアクション同士の排他制御のようなものです。wait-for-lock を指定しない場合に lock が既に取得されていた場合は、すぐにエラーとなります。   CLI での実行例 以下のようにアクションの後にパラメータとして指定します。 admin@ncs# devices device c3650 check-sync ? Possible completions: wait-for-lock The action can't be performed while the device is being committed to (or waiting in the commit queue). | Output modifiers <cr> admin@ncs# devices device c3650 check-sync wait-for-lock { Possible completions: infinity Wait infinitely for the lock, this is the default. timeout Specifies a maximum number of seconds to wait for the device to be locked. } The action can't be performed while the device is being committed to (or waiting in the commit queue). admin@ncs# admin@ncs# devices device c3650 check-sync wait-for-lock { timeout 10 } まずは wait-for-lock を指定しないで２つのアクションを同時に実行してみます。バックグラウンドで 5 秒程度かかる sync-from を実行しています。 admin@ncs# devices device c3650 check-sync result error info c3650: Device is locked in a sync-from operation by session 91 他のアクションによって lock されているのですぐにエラーとなりました。 次は wait-for-lock を 10 に指定して実行してみます。 admin@ncs# devices device c3650 check-sync wait-for-lock { timeout 10 } result in-sync バックグラウンドの sync-from の完了を待って check-sync も正常に実行されました。   Python API での実行例 wait-for-lock は CLI 以外の API でも指定可能です。ここでは Python のサンプルを実行してみます。 #cat sync.py import ncs with ncs.maapi.Maapi() as m: with ncs.maapi.Session(m, 'admin', 'python'): with m.start_write_trans() as t: root = ncs.maagic.get_root(t) device = root.devices.device['c3650'] input = device.check_sync.get_input() input.wait_for_lock.create() input.wait_for_lock.timeout = 10 result = device.check_sync(input) print result.result print result.info 先程の例と同様にバックグラウンドで sync-from を実行しながらテストします。 #python sync.py in-sync None 正常に完了しました。では wait-for-lock を指定しないで実行してみます。 #python sync.py error c3650: Device is locked in a sync-from operation by session 91 やはり他のアクションにより lock されているのですぐにエラーとなりました。   まとめ デバイスアクション同士の排他制御はアクションが競合してしまうことにより想定されない結果となってしまうことを防ぐために実装されました（in-sync なのに out-of-sync と判断されてしまうなど）。wait-for-lock を活用することによりユーザアプリケーション側でリトライなどをせずに競合をハンドルすることが可能になりますので、試してみてください。 ... View more

  RESTCONF とは NSO 4.4 など比較的新しいバージョンでは RESTCONF API をサポートしています。 RESTCONF は YANG で定義されたデータにアクセスする RESTFul なインターフェースを提供する HTTP をベースにしたプロトコルです。データストアのオペレーションは以下のように NETCONF に似ていますが、 NETCONF のトランスポートが SSH であるのに対し RESTCONF  は HTTP ベースであること、 RESTCONF では JSON 形式もサポートしているなど違いがあります。 また、 NSO は元々 REST API をサポートしていて RESTCONF と非常に似ていますが、 NSO の REST API が独自の実装であるのに対し RESTCONF は RFC8040 で標準化されたプロトコルという違いがあります。   RESTCONF の準備 RESTCONF を有効にするためには ncs.conf に以下の設定を加えて適用してください。   <restconf>     <enabled>true</enabled>   </restconf> Root リソースはデフォルトでは /restconf ですが、必要に応じて変更することも可能です。   <restconf>     <enabled>true</enabled>     <root-resource>my_own_restconf_root</root-resource>   </restconf> RFC8040 に定義されているとおり、 root リソースは以下の方法で取得することが可能です。 curl -s 'http://admin:admin@localhost:8080/.well-known/host-meta' <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>     <Link rel='restconf' href='/my_own_restconf_root'/> </XRD>   実行サンプル RESTCONF は HTTP ベースですので、テストには curl や Postman などのツールが使用できます。ここでは curl を使用していくつかのサンプルを実行してみます。 本記事では NSO 4.5.2 と curl 7.54.0 を使用しています。   Root リソースの確認 curl -s 'http://admin:admin@localhost:8080/restconf/' <restconf xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">   <data/>   <operations/>   <yang-library-version>2016-06-21</yang-library-version> </restconf> コンフィグデータにアクセスする場合は data リソースを、 action などの operational リソースにアクセスする場合は operations リソースを使用します。   Capability の取得 RFC8040 に記載されているとおり、 RESTCONF サーバの capability を確認するには data/restconf-state/capabilities にアクセスします。 curl -s 'http://admin:admin@localhost:8080/restconf/data/restconf-state/capabilities' <capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"   xmlns:rcmon="urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring">   <capability>urn:ietf:params:restconf:capability:defaults:1.0?basic-mode=explicit</capability>   <capability>urn:ietf:params:restconf:capability:depth:1.0</capability>   <capability>urn:ietf:params:restconf:capability:fields:1.0</capability>   <capability>urn:ietf:params:restconf:capability:with-defaults:1.0</capability>   <capability>urn:ietf:params:restconf:capability:filter:1.0</capability>   <capability>urn:ietf:params:restconf:capability:replay:1.0</capability>   <capability>urn:ietf:params:restconf:capability:yang-patch:1.0</capability>   <capability>http://tail-f.com/ns/restconf/collection/1.0</capability>   <capability>http://tail-f.com/ns/restconf/query-api/1.0</capability> </capabilities>   データへのアクセス curl -s 'http://admin:admin@localhost:8080/restconf/data/devices/device=router0/config/interface/Loopback'   <Loopback xmlns="urn:ios"   xmlns:ios="urn:ios"   xmlns:ncs="http://tail-f.com/ns/ncs">   <name>0</name>   <ip>   <address>   <primary>     <address>127.0.0.1</address>     <mask>255.0.0.0</mask>   </primary> </address> </ip> </Loopback>    データの更新 まずは commit dryrun を実行します。 curl -s -X PUT 'http://admin:admin@localhost:8080/restconf/data/devices/device=router0/config/interface/Loopback=0/ip/address/primary ? dryrun=cli' -H "Content-Type: application/yang-data+xml" -d '<primary><address>127.0.0.2</address><mask>255.0.0.0</mask></primary>' <dryrun-result xmlns='http://tail-f.com/ns/rest/dryrun'> <cli> <local-node> <data> devices {      device router0 {          config {              ios:interface {                  Loopback 0 {                      ip {                          address {                              primary { -                                 address 127.0.0.1 ; +                                 address 127.0.0.2 ;                              }                          }                      }                  }              }          }      } } </data> </local-node> </cli> </dryrun-result> Commit します。 curl -s -X PUT 'http://admin:admin@localhost:8080/restconf/data/devices/devig/interface/Loopback=0/ip/address/primary' -H "Content-Type: application/yang-data+xml" -d '<primary><address>127.0.0.2</address><mask>255.0.0.0</mask></primary>' 変更を確認します。 curl -s   'http://admin:admin@localhost:8080/restconf/data/devices/device=router0/config/interface/Loopback=0/ip/address/primary' <primary xmlns="urn:ios"   xmlns:ios="urn:ios"   xmlns:ncs="http://tail-f.com/ns/ncs">   <address>127.0.0.2</address>   <mask>255.0.0.0</mask> </primary>   Action の実行 sync-from を実行する例です。アクションなので operations リソースを使用しています。 curl -s -X POST 'http://admin:admin@localhost:8080/restconf/operations/devices/device=router0/sync-from' <output xmlns='http://tail-f.com/ns/ncs'>   <result>true</result> </output> IOS NED の live-status exec show コマンドの実行例です。 curl -s -X POST 'http://admin:admin@localhost:8080/restconf/operations/devices/device=router0/live-status/exec/show' -H "Content-Type: application/yang-data+xml" -d '<input><args>version</args></input>' <output xmlns='urn:ios-stats'>   <result> > show version&#13 ; Cisco IOS Software , NETSIM&#13 ; router0# </result> </output>   Query API 基本的には REST API と同様です、ただし URI が異なります（tailf/query を指定します）。 http://admin:admin@localhost:8080/restconf/tailf/query   リファレンス RFC8040 RESTCONF Protocol: http://www.ietf.org/rfc/rfc8040.txt NSO Northbound APIs の Chapter 4. The RESTCONF API のセクション examples.ncs/getting-started/developing-with-ncs/13-restconf   ... View more

  Kicker とは Kicker は NSO 4.2 から導入された新機能で、CDB の変更や Netconf notification をトリガーにして action を起動する仕組みを提供するものです。以前のバージョンから存在していた CDB subscriber とほぼ同等の機能ですが、トリガーの定義やアクションを起動するロジックをコーディングすることなくコンフィグとして定義できるのでより簡単に実装できるというメリットがあります。 Kicker には data-kicker と notification-kicker があります。 data-kicker CDB subscriber とほぼ同じです。CDB の変更をモニターしてアクションを実行することができます。 notification-kicker Southbound デバイスから送られてくる Netconf notificaiton をトリガーにしてアクションを実行することができます。Kicker が実装される前は、受信した notification を CDB に格納しそのパスを CDB subscriber によってモニターする必要がありました。notification-kicker を使用すると受信した nofiticaiton を CDB に格納する必要はありませんし CDB subscriber も不要になります。 Kicker はデフォルトで hidden に設定されていますので、CLI で見えるようにするには unhide する必要があります。まず ncs.conf に以下の設定を追加します。 <hide-group> <name>debug</name> </hide-group> ncs --reload で設定を適用後、以下の CLI コマンドで unhide してください。 admin@ncs(config)# unhide debug admin@ncs(config)# これで kicker が見えるようになります。 admin@ncs(config)# kickers Possible completions: data-kicker notification-kicker This list contains declared notification kickers. send-kicker-triggered Kicker action to Send a kicker-triggered notification   Data Kicker Data Kicker は以下のフォーマットで記述します。 admin@ncs(config)# kickers data-kicker e1 \ > monitor /sys/ifc[name='port-0'] \ > kick-node /sys/ifc[name='port-0']\ > action-name local_me monitor: モニターするノードです。このノードのサブツリーに変更があった場合アクションを kick します。 kick-node: ここで定義されるノード配下のアクションが kick されます。 action-name: 起動するアクションです。 さらに trigger-expr を定義してより細かくアクションを起動する条件を設定することもできます。 admin(config)# kickers data-kicker k1 monitor /sys/ifc \ > trigger-expr "hw/mtu > 800" \ > trigger-type enter \ > kick-node /sys \ > action-name kick_me monitor に設定している /sys/ifc に変更があった場合 trigger-expr が評価されます。上記の例では"hw/mtu > 800" が true であればアクションが実行されます。実行の挙動は trigger-type でコントロールでき、enter だと false から true になった場合のみ、enter-and-leave だと true から false になった場合もアクションが実行されます。 また、以下のように variable を使用することもできます。 admin@ncs(config)#kickers data-kicker k3 monitor $PATH/c kick-node /x/y[id='n1'] action-name kick-me variable PATH value "/a/b[k1=3][k2='3']" 上記の例では PATH という variable にパスを設定し、monitor 内で $PATH として参照しています。 NSO インストールディレクトリ 配下の examples.ncs/web-server-farm/web-site-service が Kicker の サンプルとなっていますので、試しに実行してみます。README_KICKER に Kicker の説明とサンプルの実行手順が記載されています。ここでは実行手順に従って実行してみます。(事前に source ncsrc を実行してください。本記事では NSO 4.4.4 を使用しています。) まずラボを起動し CLI を接続します。 make all make start ncs_cli -u admin -C kicker が CLI で見えるようにするために unhide します。 admin@ncs# config admin@ncs(config)# unhide debug sync-from を実行します。 admin@ncs# devices sync-from sync-result { device lb0 result true } sync-result { device www0 result true } sync-result { device www1 result true } sync-result { device www2 result true } Data Kicker を作成します。 admin@ncs(config)# kickers data-kicker a1 monitor /services/properties/wsp:web-site/profile kick-node /services/wse:actions action-name diffcheck admin@ncs(config-data-kicker-a1)# commit この設定例では /services/properties/wsp:web-site/profile をモニターし、変更があれば /services/wse:actions の diffcheck アクションを実行します。diffcheck アクションは本サンプルに含まれているもので、トランザクションにアタッチして diffiterate を実行し変更内容を表示します。 それでは kicker が実行されるように monitor のパスに変更を加えてみます。Kicker の実行の様子は commit にパイプして debug kicker を付けることで確認できます。 admin@ncs(config)# services properties web-site profile lean lb lb0 admin@ncs(config-profile-lean)# commit | debug kicker kicker: a1 at /ncs:services/ncs:properties/wsp:web-site/wsp:profile[wsp:name='lean'] changed, invoking diffcheck Commit complete. 期待通り diffcheck が実行されました。ncs-java-vm.log でも diffcheck の出力が確認できます。 ------------------- {[669406386|kicker-id], a1} {[669406386|path], /ncs:services/properties/web-site/profile{lean}} {[669406386|tid], 126} path = /ncs:services/properties/wsp:web-site/profile{lean} op = MOP_CREATED newValue = null path = /ncs:services/properties/wsp:web-site/profile{lean}/name op = MOP_VALUE_SET newValue = lean path = /ncs:services/properties/wsp:web-site/profile{lean}/lb op = MOP_VALUE_SET newValue = lb0   Notification Kicker Notification Kicker は以下のフォーマットで記述します。 admin@ncs(config)# kickers notification-kicker k4 \ > selector-expr "$NOTIFICATION_NAME=linkUp and address[ip=$IP]" \ > kick-node /x/y[id='n1'] \ > action-name kick-me \ > variable IP value '192.168.128.55' ほぼ Data Kicker と同様ですが、monitor ではなく selector-expr を使用してどの Netconf notification を対象とするか定義します。前提として /devices/device/netconf-notification/subscription でサブスクリプションの設定がされていて Netconf notification を受信できる状態である必要があります。以下の predefined variables が使用可能ですので、これらを使用してトリガーとなる notification をフィルターすることができます。 DEVICE The name of the device emitting the current notification. SUBSCRIPTION_NAME The name of the current subscription from which the notification was received. the kicker NOTIFICATION_NAME The name of the current notification. NOTIFICATION_NS The namespace of the current notification. ここで使用するサンプルは Data Kicker と同様の web-site-service です。起動までの手順は同じですのでここでは割愛し、kicker を設定するところから始めます。 admin@ncs(config)# kickers notification-kicker n1 selector-expr "$SUBSCRIPTION_NAME = 'mysub'" kick-node /services/wse:actions action-name diffcheck admin@ncs(config-notification-kicker-n1)# commit この例ではサブスクリプションの名前が mysub の notification を受信した場合に diffcheck を実行します。このサンプルラボでは各デバイスが定期的に Netconf notification を送信する仕様になっていますので、サブスクリプションを設定すればすぐに Kicker が実行されます。 admin@ncs(config)# devices device www0 netconf-notifications subscription mysub local-user admin stream interface admin@ncs(config-subscription-mysub)# commit ncs-java-vm.log でも実行の出力が確認できます。 ------------------- {[669406386|kicker-id], n1} {[669406386|path], /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0}/data/linkUp} {[669406386|tid], 185} path = /ncs:devices/device{www0} op = MOP_MODIFIED newValue = null path = /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0} op = MOP_CREATED newValue = null path = /ncs:devices/device{www0}/netconf-notifications/received-notifications/notification{2018-01-13T09:17:54.783182+00:00 0}/event-time op = MOP_VALUE_SET   Sample package 最後に簡単なオリジナルパッケージを作成してみます。Cisco StarOS の新しいバージョンでは logging を Netconf notification として送信する機能がありますので、特定のログを受信したら任意の show コマンドを実行してタイムリーにログを取得するというものです。 まずはスケルトンパッケージを作成します。ここでは python を使用します。 ncs-make-package --service-skeleton python pyservice 任意のコマンドを実行できるように、pyservice/src/yang/pyservice.yang に command ノードを追加します。 // may replace this with other ways of refering to the devices. leaf device { type leafref { path "/ncs:devices/ncs:device/ncs:name"; } } // command to execute leaf-list command { type string; } pyservice/python/pyservice/main.py の cb_create を以下のように定義します。サービスと同じ名前の Kicker が存在する場合のみ command で定義されたコマンドをデイバスに対して実行し、ログに残します。Kicker が存在しない場合は何もせず終了します。 @Service.create def cb_create(self, tctx, root, service, proplist): self.log.info('Service create(service=', service._path, ')') service_name = service.name if service_name not in root.kickers.notification_kicker: self.log.info('kicker for this service does not exist.') return dev = root.devices.device[service.device] input = dev.live_status.staros_exec.staros_exec__exec.get_input() input.args = service.command result = dev.live_status.staros_exec.staros_exec__exec(input) self.log.info(result.result) 対象の notification は以下とします。ポートがダウンしたことを示すものです。 data event facility csp data event id 7207 data event severity 3 data event critical-info true data event text "2018-Jan-12+19:12:28.411 [csp 7207 warning] [1/0/5701 <cspctrl:0> spctrl_events.c:11887] [port: 1/10] [hardware external system critical-info syslog] Port link down" まずはサービスを作成します。取得するコマンドは show port utilization table を指定しています。 admin@ncs(config)# pyservice ps1 device ssi command "show port utilization table" admin@ncs(config-pyservice-ps1)# commit この時点では Kicker が存在しないため何も実行しません。 ncs-python-vm-pyservice.log 2018-01-13 19:10:59 - pyservice - INFO - kicker for this service does not exist. Kicker を設定します。上記のログをフィルターするために、id を指定しています。また、コード内で同じ名前の Kicker を条件として探すため、名前はサービスと同じである必要があります。 admin@ncs(config)# kickers notification-kicker ps1 selector-expr id=7207 kick-node /pyservice[name='ps1'] action-name reactive-re-deploy admin@ncs(config-notification-kicker-ps1)# commit Netconf notification のサブスクリプションは以下のように設定済みです。 netconf-notifications subscription foo stream StarOS local-user admin それでは Netconf notification を送ってみます。マニュアルでインターフェースを shutdown します。 [local]qvpc-si# configure [local]qvpc-si(config)# port ethernet 1/10 [local]qvpc-si(config-port-1/10)# shut Kicker が正しく動作し、以下のようにコマンド出力がログに保存されました。 ncs-python-vm-pyservice.log 2018-01-13 20:04:30 - pyservice - INFO - Service create(service=/pyservice:pyservice{ps1}) 2018-01-13 20:04:30 - pyservice - INFO - ------ Average Port Utilization (in mbps) ------ Port Type Current 5min 15min Rx Tx Rx Tx Rx Tx ----- ------------------------ ------- ------- ------- ------- ------- ------- 1/1 Virtual Ethernet 0 0 0 0 0 0 1/10 Virtual Ethernet 0 0 0 0 0 0 1/11 Virtual Ethernet 0 0 0 0 0 0 1/12 Virtual Ethernet 0 0 0 0 0 0 1/13 Virtual Ethernet 0 0 0 0 0 0 今回は簡単な例ですが、何かの障害に応じて必要なリカバリアクションを実行したりログ取得を実施したりするようなもう少し複雑なアプリケーションも作成可能ですので、ぜひお試しください。   リファレンス Kicker に関しては以下のデータソースがありますので、参照してみてください。 NSO Development Guide の Kicker セクション examples.ncs/web-server-farm examples.ncs/getting-started/developing-with-ncs/21-kicker src/ncs/yang/tailf-kicker.yang ... View more

Snapshot database とは NSO 4.4 から追加された commit-queue 用の拡張機能です。そもそも c ommit-queue とは commit の内容が全てのデバイスに適用されるまで待つのではなく、commit-queue にキューイングして transaction としては終了することによりスループット改善を図っています。これに加え snapshot database は config  change-set  の計算を transaction lock の外で実行することでさらなるパフォーマンス向上を実現しています。Snapshot database は NSO が元々使用している running database とは別に各デバイスの config を保存していますので、このデータを元に change-set を計算することで transaction の時間を短縮できます。 Snapshot database は CDB のディレクトリに S.cdb という名前で保存されています。 cisco@ncs-run$[4.4.4] tree ncs-cdb ncs-cdb ├── A.cdb ├── C.cdb ├── O.cdb ├── S.cdb   実際に試してみる 事前準備 実際に効果があるかどうか試してみます。なお、本記事では NSO 4.4.4 を使用してテストしています。 まず、snapshot database  は commit-queue が前提ですので commit-queue を有使用する必要があります。以下の例は global レベルでデフォルト有効にしていますが、デバイス毎にも設定できますし、commit 単位でも有効にできます。 admin@ncs(config)# devices global-settings commit-queue enabled-by-default true admin@ncs(config)# commit Snapshot database に config を保存させる方法は二通りあります。一つは /ncs-config/cdb/snapshot/pre-populate を true に設定する方法で、この場合自動で config が保存されます。False の場合はデバイスに対して最初に commit-queue を通じて commit が実行された時に保存されます。   結果を計測する方法 効果を見るうえで比較的時間がかかる transaction が必要ですので、自動で 5000 の static route 設定を生成する genIpRoute というサービスパッケージを作成しました。seed は IP の最初のオクテットに使用されます。 admin@ncs(config)# genIpRoute 1 seed 1 device ios0 CDB の running に対してどの程度 lock が発生しているか確認するため、ncs --status の出力に含まれる以下をモニターして lock 時間を計測するスクリプトを作成しました。 cdb: current transaction id: 1512-896657-925449 running: --- snip --- read locks: 0 write lock: unset また、transaction に関しては devel.log の内容を見て確認します。 Commit-queue なしの場合（snapshot を使用しない） Commit-queue を使用しないで先程の genIpRoute をデバイス ios0 に適用してみます。 admin@ncs(config)# genIpRoute 1 seed 1 device ios0 admin@ncs(config-genIpRoute-1)# commit Commit complete. CDB lock python measure_lock.py read lock started write lock started read lock finished:9.6635 secs read lock started write lock finished:20.530179 secs read lock finished:0.448463 secs devel.log <DEBUG> 10-Dec-2017::17:58:21.088 XXXXXXXXXXXXXX ncs[96448]: devel-c trans_lock request daemon id: 4 session id: 109 <DEBUG> 10-Dec-2017::17:58:21.088 XXXXXXXXXXXXXX ncs[96448]: devel-c trans_lock succeeded daemon id: 4 session id: 109 <DEBUG> 10-Dec-2017::17:58:53.640 XXXXXXXXXXXXXX ncs[96448]: devel-c close_trans request daemon id: 4 session id: 109 <DEBUG> 10-Dec-2017::17:58:53.641 XXXXXXXXXXXXXX ncs[96448]: devel-c close_trans succeeded daemon id: 4 session id: 109 Transaction が lock を取得してから完了するまで約 32 秒程度かかっています。また、CDB の write lock は 20 秒ほどかかっています。   Commit-queue ありの場合（snapshot を使用） 今後は commit-queue を使用して同様の commit を実行してみます。 admin@ncs(config)# genIpRoute 1 seed 1 device ios0 admin@ncs(config-genIpRoute-1)# commit commit-queue async commit-queue-id 1512896658100 Commit complete. CDB lock read lock started write lock started read lock finished:9.685041 secs write lock finished:1.994608 secs devel.log <DEBUG> 10-Dec-2017::18:04:08.053 XXXXXXXXXXXXXX ncs[96448]: devel-c trans_lock request daemon id: 4 session id: 166 <DEBUG> 10-Dec-2017::18:04:08.053 XXXXXXXXXXXXXX ncs[96448]: devel-c trans_lock succeeded daemon id: 4 session id: 166 <DEBUG> 10-Dec-2017::18:04:19.920 XXXXXXXXXXXXXX ncs[96448]: devel-c close_trans request daemon id: 4 session id: 166 <DEBUG> 10-Dec-2017::18:04:19.920 XXXXXXXXXXXXXX ncs[96448]: devel-c close_trans succeeded daemon id: 4 session id: 166 CDB write lock の時間が大幅に短縮され、約 2 秒になりました。また、transaction も 10 秒程度で完了しています。 今回のテストケースでは大きく改善が見られましたが、ユースケースによって効果は必ずしも同様ではないかもしれません。ただ transaction のスループットを改善したいと考えている場合は一度検討されても良いかもしれません。   リファレンス Commit-queue に関する説明は NSO User Guide の CHAPTER 3 The NSO Device Manager / Commit Queue に記載されています。また、snapshot database に関しても同じセクション内の Commit Queue Tuning に説明が載っていますので、参照してみてください。 ... View more

[toc:faq]   NED パッケージのリリースポリシー 新しいバージョンの NED パッケージがリリースされる場合、特定バージョンの NSO 向けにコンパイルされて配布されます。この際、ターゲットとなる NSO のバージョンは各ブランチの最新版のみとなります。例えば、以下は cisco-ios NED 5.4 のターゲットブランチです（ncs-x.x.x が NSO のバージョンです）。 ncs-3.4.9-cisco-ios-5.4.tar.gz ncs-4.1.6-cisco-ios-5.4.tar.gz ncs-4.2.4-cisco-ios-5.4.signed.bin ncs-4.3.3-cisco-ios-5.4.signed.bin ncs-4.4.2-cisco-ios-5.4.signed.bin これはあくまで基本的なガイドラインになりますので、例外がある場合もあります。 異なるバージョンの NSO に NED をロードする場合 コンパイルされたものとは異なるバージョンの NSO に NED をロードする場合、まずは NED に含まれる package-meta-data.xml に記載されている ncs-min-version を確認してください。各ブランチにおいて ncs-min-version より新しいバージョンである必要があります。  <ncs-min-version>3.4.5</ncs-min-version> <ncs-min-version>4.0.5</ncs-min-version> <ncs-min-version>4.1.1</ncs-min-version> <ncs-min-version>4.2</ncs-min-version> <ncs-min-version>4.3.0.2</ncs-min-version> 要件を満たしていて、かつ maintenance バージョン以降が異なるだけの場合（4.2.3 と 4.2.2 など）、多くの場合そのまま使用できます。ロードして問題が無いようでしたらそのまま使用してください。 もし問題が発生した場合、NED のリコンパイルをする必要があります。使用する NSO で NED をリコンパイルしてロードできるかお試しください。 ╭─ ~/Downloads/cisco-ios ╰─$ source ~/ncs/4.4.1.3/ncsrc ╭─ ~/Downloads/cisco-ios ╰─$ cd src;make rm -f *-snippet.yang rm -f *-snippet.fxs rm -f *.properties ----- snip ----- BUILD SUCCESSFUL Total time: 2 seconds ... View more

[toc:faq]   はじめに NSO は一般的な Cisco 製品で使用されているバグ ID（例:CSCta04879） に対応していないので、Bug Search Tool でバグ情報を確認することができません。代わりに、NSO では CHANGES ファイルで各リリースで修正されたバグ情報を確認することができます。 CHANGES ファイルの場所 CHANGES ファイルは NSO のインストールディレクトリにあります。Local install の場合は指定したディレクトリ、system install の場合は指定したディレクトリもしくはデフォルトで /opt/ncs/current となります。 4.4.2$ ls CHANGES README bin erlang examples.ncs java man ncsrc.tcsh packages src var LICENSE VERSION doc etc include lib ncsrc netsim scripts support ちなみに、各種 NED パッケージにも同様に CHANGES ファイルが含まれており、修正されたバグ情報を確認することができます。 CHANGES ファイルの内容 CHANGES ファイルには修正されたバグ情報がリリース毎にリストされています。また、バグ情報だけでなく機能のエンハンスメント情報なども含まれます。バグ情報はカテゴリ毎にリストされています。 4.4.2$ grep -e ^NSO- -e ^Removals -e ^Non-backwards -e ^Enhancements -e ^Corrections CHANGES NSO-4.4.2 [June 14, 2017] Removals: Non-backwards compatible enhancements: Enhancements: Non-backwards compatible corrections: Corrections: NSO-4.4.1.3 [May 25, 2017] Corrections: NSO-4.4.1.2 [May 7, 2017] Corrections: NSO-4.4.1.1 [May 5, 2017] Corrections: NSO-4.4.1 [April 26, 2017] Removals: Non-backwards compatible enhancements: Enhancements: Corrections: NSO-4.4.0.2 [April 26, 2017] Corrections: NSO-4.4.0.1 [April 25, 2017] Corrections: NSO-4.4 [March 20, 2017] Removals: Non-backwards compatible enhancements: Enhancements: Non-backwards compatible corrections: Corrections: 各カテゴリの一般的なガイドラインは以下のとおりです。 （NED に関しては各 NED パッケージにより異なります） Removals: 削除された機能。 Non-backwards compatible enhancements: Backward compatibility が無いエンハンスメント。API の変更などが含まれます。 Enhancements 上記以外のエンハンスメント。 Non-backwards compatible corrections バグ修正かつ、backward compatibility が無いもの。 Corrections バグ修正 通常は major/minor/maintenance リリース（4.0, 4.0.1 など）には全てのカテゴリが含まれ、patch リリース（4.0.2.1 など）には主に Corrections のみが含まれます。ただし例外もありますのでご注意ください。  また、各バグ情報の最初の部分は関連するコンポーネント名になりますので、特定のコンポーネントに関しての修正を探す場合には参考にしてください。 - CLI: A new NED capability has been added. This capability allows NEDs to use the CLI parser in strict mode, which uses the indentation of given commands to enter and exit sub modes. - Java API: Improved error message when null is passed as a value to putQuoted method in TemplateVariables class. なお、各エントリの最後に記載されている Issue tracker 番号は主に内部的な管理番号となります。 ... View more

  はじめに NSO では yang model のデータにアクセスするために様々な場面で XPath を使用します。例えば、以下のような場面で使用します。 yang model 内の leafref/must/when など config template サービスモデルの Java/Python コード REST API や NETCONF northbound interface でのクエリ NSO では XPath 1.0 をサポートしていますので、より詳しい情報は以下のリンクを参照してみてください。 XML Path Language (XPath) Version 1.0 https://www.w3.org/TR/xpath/ また、NSO では独自の拡張機能が実装されています。より詳細は man tailf_yang_extensions に含まれている XPATH FUNCTIONS セクションを参照してください。 本ドキュメントでは、XPath の基本的なサンプルをいくつか紹介していきたいと思います。また、確認用のツールとして NSO CLI の xpath コマンドを使用していますので、こちらの詳細については以下のドキュメントを参照ください。 NSO: CLI の便利なツール - devtools https://supportforums.cisco.com/ja/document/13286076    要素へのアクセス 例えば以下のようなデータがあるとします。 devices device router0  address 127.0.0.1  port 10022  device-type cli ned-id cisco-ios devices device router1  address 127.0.0.1  port 10023  device-type cli ned-id cisco-ios デバイスの name にアクセスする場合は以下のように記載することができます。 admin@ncs(config)# xpath eval /devices/device/name /ncs:devices/ncs:device[ncs:name='router1']/ncs:name :: router1 /ncs:devices/ncs:device[ncs:name='router0']/ncs:name :: router0 上の例では Root(/) からの絶対パスで指定していますが、現在の XPath コンテキストから相対パスで指定することもできます。 admin@ncs(config)# devices device router0 admin@ncs(config-device-router0)# xpath eval ./name /ncs:devices/ncs:device[ncs:name='router0']/ncs:name :: router0 admin@ncs(config-device-router0)# xpath eval ../device[name='router1']/port /ncs:devices/ncs:device[ncs:name='router1']/ncs:port :: 10023 // を使用することで途中のパスを省略することもできます。 admin@ncs(config)# xpath eval /devices//ned-id /ncs:devices/ncs:device[ncs:name='router1']/ncs:device-type/ncs:cli/ncs:ned-id :: cisco-ios /ncs:devices/ncs:device[ncs:name='router0']/ncs:device-type/ncs:cli/ncs:ned-id :: cisco-ios ノードの属性(attribute) にアクセスするには @ を使用します。router0 が以下のような annotation を持っているとします。 admin@ncs(config)# show full-configuration devices device router0 | display xml <config xmlns="http://tail-f.com/ns/config/1.0"> <devices xmlns="http://tail-f.com/ns/ncs"> <device annotation="testannotate"> @ を使用して以下のように annotation 属性にアクセスできます。 admin@ncs(config)# xpath eval /devices/device/@annotation /ncs:devices/ncs:device[ncs:name='router0'] :: testannotate 評価 Xpath では値を評価する際に以下の表現が使用できます。 or and =, != <=, <, >=, > admin@ncs(config-device-router0)# xpath eval "./name='router0' and ./address='127.0.0.1'" true admin@ncs(config-device-router0)# xpath eval "./name='router1' or ./address='127.0.0.1'" true admin@ncs(config-device-router0)# xpath eval count(./config/ios:interface/FastEthernet) 4 admin@ncs(config-device-router0)# xpath eval count(./config/ios:interface/FastEthernet)>3 true admin@ncs(config-device-router0)# xpath eval count(./config/ios:interface/FastEthernet)>5 admin@ncs(config-device-router0)# admin@ncs(config-device-router0)# xpath eval count(./config/ios:interface/FastEthernet)>=4 true   Core function XPath 1.0 に記載されている Core function が使用できます。詳しくは上述の XPath 1.0 のドキュメントを参照ください。以下によく使用される function をいくつか記載します。 count() - ノードの個数を返します。 admin@ncs(config)# xpath eval count(/devices/device[name='router0']/config/ios:interface/FastEthernet) 4 cotains() - ノードの値に指定の文字列が含まれている場合 true を返します。 admin@ncs(config-device-router0)# xpath eval contains(./address, '127') true starts-with() - ノードの値が指定の文字列で始まる場合 true を返します。 admin@ncs(config-device-router0)# xpath eval starts-with(./name,'router') true admin@ncs(config-device-router0)# xpath eval starts-with(./name,'routers') false not() - 引数が false の場合 true を返します。 admin@ncs(config-device-router0)# xpath eval starts-with(./name,'router') true admin@ncs(config-device-router0)# xpath eval starts-with(./name,'routers') false position() - コンテキストの position を数字で返します。 admin@ncs(config)# xpath eval /devices/device[position()=1] /ncs:devices/ncs:device[ncs:name='router0'] admin@ncs(config)# xpath eval /devices/device[position()=2] /ncs:devices/ncs:device[ncs:name='router1'] NSO Extention XPath 1.0 の Core function に加え、NSO で独自に拡張した function を使用することができます。使用できる function のリストについては  man tailf_yang_extensions に含まれている XPATH FUNCTIONS セクションを参照してください。以下にいくつかサンプルを記載します 。 re-match() - 第 1 引数の値が第 2 引数の regular expression にマッチする場合に true を返します。 admin@ncs(config-device-router1)# xpath eval re-match(./name,'.*0') false admin@ncs(config-device-router1)# xpath eval re-match(./name,'.*1') true マニュアルにも記載されていますが、implicit anchoring が適用される点に注意してください。上述の例は最後の文字を対象にしていますが、通常の  regular expression のように最後に $ を付けてしまうと true になりません。 max() - 一番大きい数字を返します。 admin@ncs(config)# xpath eval max(/devices/device/port) 10023 実際にはさらに複雑な XPath が多く使われています。興味がある方は NSO や NED に含まれている yang ファイルの中身を一度見てみると面白いかもしれません。 ... View more

  はじめに NSO CLI に実装されている便利なツールを紹介します。これらの機能はデフォルトでは表示されないようになっていますので、使用する際には devtools を有効にする必要があります。 admin@ncs# show cli | include devtools devtools false admin@ncs# devtools true admin@ncs# show cli | include devtools devtools true 本ドキュメント作成時点では以下の2つのコマンドが実装されていますので、それぞれ紹介します。 timecmd   Time command xpath   Evaluate XPath expression   timecmd 本コマンドは NSO 4.3 から実装されています。timecmd コマンドを先頭につけて他のコマンドを実行すると、コマンド実行にかかった時間を表示してくれます。timecmd コマンドは Operational mode/Configure mode どちらでも使用できます。 syntax: timecmd <コマンド> admin@ncs# timecmd devices sync-from sync-result { device router0 result true } sync-result { device staros result true } Command executed in 6.74 sec admin@ncs(config-config)# timecmd commit Commit complete. Command executed in 0.10 sec NSO User Guide の Operational mode commands セクションにも説明がありますので合わせて参照ください。 xpath 本コマンドは NSO 4.3 から実装されています。xpath コマンドは xpath expression をテストすることができます。xpath コマンドは Configure mode で使用できます。 admin@ncs(config)# xpath ? Possible completions: ctx <xpath context> eval <xpath expression> must <xpath expression> when <xpath expression> <cr>   context を指定した場合はその path が current context として xpath が評価されます。指定しない場合は現在の CLI の sub mode が current context になります。その他のオプションの意味は以下のとおりです。 eval - Evaulate an XPath expression. must - Evaluate the expression as a YANG 'must' expression. when - Evaluate the expression as a YANG 'when' expression. admin@ncs(config)# xpath eval count(/devices/device[name='staros']) 1 admin@ncs(config)# xpath ctx devices device staros when current()/device-type/cli/ned-id = 'cisco-staros-id:cisco-staros' true また、パイプで trace オプションを指定すると debug 情報を取得することができます。 admin@ncs(config)# xpath ctx devices device staros when current()/device-type/cli/ned-id = 'cisco-staros-id:cisco-staros' | trace XPATH_DEBUG compiling: boolean(current()/device-type/cli/ned-id='cisco-staros-id:cisco-staros') XPATH_DEBUG compiling OK XPATH_DEBUG current node: /ncs:devices/device{staros} XPATH_DEBUG evaluating expression XPATH_TRACE exists("/ncs:devices/device{staros}/device-type/cli") = true XPATH_TRACE get_elem("/ncs:devices/device{staros}/device-type/cli/ned-id") = cisco-staros-id:cisco-staros true   NSO User Guide の Configure mode commands セクションにも説明がありますので合わせて参照ください。 ... View more

  概要 本ドキュメントでは tailf-hcc パッケージを使用して NSO の HA(High Availability) を構築する際によく発生する問題についてまとめます。    前提条件 本ドキュメントは以下のバージョンをベースに作成しています。バージョンによって動作が変わる可能性がありますので注意してください。   NSO: 4.2.1.4 Tail-f HCC Package : 4.0.6   また、HA の基本的な設定に関しては tailf-hcc package に含まれる deployment_guide.pdf を参照してください。  　 ncs.conf で HA を有効にしていない  HA を有効にするには、NSO CLI 上の設定以外に ncs.conf に以下の設定が必要です。デフォルトではコメントアウトされていますので、アンコメントしてください。 <ha> <enabled>true</enabled> </ha>   アンコメントされていない場合、devel.log に以下のようなエラーが出力されます。 <ERR> 10-Jan-2017::08:51:26.239 foo-1 ncs[1544]: devel-econfd tailf_viperl_server: Got unexpected info: {'EXIT',<0.249.0>, {badmatch, {error, {1, <<"/tfnm:ncs-state/ha does not exist">>}}}} <ERR> 10-Jan-2017::08:51:27.596 foo-1 ncs[1544]: ncs Socket connection from "HA socket" rejected - probably due to NCS being in phase0 or service not enabled in config file   また、ncs-java-vm.log には以下のようなエラーが出力されます。 <ERROR> 10-Jan-2017::08:51:46.321 TcmApp (tailf-hcc:tailf-hcc)-Run-0: - NCS HA is likely not enabled   HA を activate していない NSO 起動後に CLI で HA を activate しなければなりません。 admin@ncs# ha commands activate status activated   HA が activate されていないと status  が none と表示されます。  admin@ncs# ha commands status status foo-1[none] admin@ncs# show ncs-state ha ncs-state ha mode none   Hostname がマッチしていない NSO 設定上のホスト名が Linux 上で名前解決できる状態で、かつマッチしていないと  tailf-hcc package は正常に動作しません。以下のようにホスト名が合っているかどうか確認してください。   NSO 上の設定 ha member foo-1 address 172.17.0.2 default-ha-role master vip-interface eth0   Linux 上のホスト名 root@foo-1:/home/nso# cat /etc/hosts | grep foo-1 172.17.0.2 foo-1.cisco.com foo-1 root@foo-1:/home/nso# hostname foo-1   例えば、上記の設定で foo-1 を foo-1-wrong に変更した場合、ha commands status の表示は以下のようになります。foo-1 とは NSO が設定されている IP から解決したホスト名になりますので、設定されているホスト名と異なっていることが分かります。 admin@ncs# ha commands status status foo-1[none]   なお、Java 実行環境のバージョンや Linux OS 上の IPv6 有効・無効の設定によって FQDN がホスト名として NSO に認識されてしまうことがあるようです。そのような場合、/etc/modprobe.conf 内の options ipv6 disable=1 を削除して IPv6 を有効にしてみるか、どうしても回避できない場合は FQDN で NSO 上の設定も実施してみてください。ただし、将来的にはこの動作は tailf-hcc packge 内で改善される可能性があります。   Master/Slave 間が通信できていない HA の通信にはデフォルトでポート番号 4570 を使用します。また、本ポート番号は ncs.conf の設定で変更できます。この通信ができないとリモートノードが認識できないなどの問題が発生します。 <ha> <enabled>true</enabled> <ip>0.0.0.0</ip> <port>4570</port> <tick-timeout>PT20S</tick-timeout> </ha>   Firewall などで通信がブロックされていないか確認してください。また、telnet <master NSO> 4570 などで接続が可能かなど確認してください。   Master/Slave で異なる Key を使用している ncs.conf の encrypted-strings 内の値は Mater/Slave で同じ値が設定されている必要があります。これらの値を元に NSO 設定内のパスワードは暗号化・復号化されますので、もし Master/Slave  間で異なる場合切り替え後にデバイスと接続できないという問題が発生します。   Master 上 admin@ncs# devices device nxos connect result true   Slave に切り替え後 admin@ncs# devices device nxos connect result false info Failed to authenticate towards device nxos: Bad password for local/remote user admin/admin Auth failed   ncs.conf の encrypted-strings は 必ず同じ値を使用するようにしてください。   HA 関連の一般的なログ NSO CLI のコマンド show ncs-state ha show packages package tailf-hcc ha commands status show running-config ha   ログファイル（通常 Master/Slave 両方のものが必要です） ncs-java-vm.log devel.log syslog (/var/log/messages)　※ VIP に関するログが出力されます。 ※ ncs-java-vm.log により詳しい情報を残したい場合は、以下の設定を入れることで tailf-hcc package のログレベルを debug に設定します。ログ取得が完了したら設定を削除してください。ログ出力増加に伴い負荷も増す可能性がありますので、ラボで確認のうえ実施してください。 root@ncs(config)# java-vm java-logging logger com.tailf.ns.tailfHcc level level-debug root@ncs(config-logger-com.tailf.ns.tailfHcc)# commit       ... View more

  問題の概要 ロードされていない NED  を使用しているデバイスがコンフィグ内に存在する場合、エラーが発生し NSO は起動できません。これは、例えば以下のようなシナリオで発生します。   １．環境 A では以下のデバイスが登録されていて、必要な NED もロードされています。 admin@ncs# show devices list NAME ADDRESS DESCRIPTION NED ID ADMIN STATE ------------------------------------------------------- device0 127.0.0.1 - cisco-ios unlocked device1 127.0.0.1 - cisco-nx unlocked admin@ncs# show packages | display-level 1 packages package cisco-ios packages package cisco-nx ２．環境 A の CDB ファイルを新しい環境 B にコピーして NSO を起動します。ただし、環境 B に cisco-nx NED がロードされていない場合、以下のようなエラーが発生して NSO は起動できません。 #ncs CDB: Upgrade failed: Upgrade transaction failed to validate: /ncs:devices/device{device1}/device-type/cli/ned-id is not configured   ３．ただし、上記のエラーでは NED のタイプが不明なため、どの NED を環境 B にロードすれば良いのか分かりません。   本ドキュメントではこのような状況で問題の NED タイプを調べる方法について記載します。   devel.log で確認する devel.log のログレベルを info 以上に設定すれば以下のようなログが出力されますので NED タイプを確認することができます。 <INFO> 10-Jan-2017::10:55:40.239 TOOKADA-M-4198 ncs[64608]: devel-cdb removing entries in deleted namespace http://tail-f.com/ned/ cisco-nx <INFO> 10-Jan-2017::10:55:40.239 TOOKADA-M-4198 ncs[64608]: devel-cdb removing entries in deleted namespace http://tail-f.com/ned/cisco-nx-id <INFO> 10-Jan-2017::10:55:40.239 TOOKADA-M-4198 ncs[64608]: devel-cdb removing entries in deleted namespace http://tail-f.com/ned/cisco-nx/meta <INFO> 10-Jan-2017::10:55:40.239 TOOKADA-M-4198 ncs[64608]: devel-cdb removing entries in deleted namespace http://tail-f.com/ned/cisco-nx/stats   devel.log の設定に関しては man ncs.conf を参照してください。     ncs --cdb-debug-dump で確認する ncs --cdb-debug-dump ＜CDB directory＞ コマンドで CDB の内容を確認することができますので、この出力から NED タイプを確認することができます。 #ncs --cdb-debug-dump ncs-cdb | grep device1 | grep ned-id /ncs:devices/device{device1}/'device-type'/cli/'ned-id' = {44,{ 1850480213 ,1488855246}}, #ncs --cdb-debug-dump ncs-cdb | grep 1850480213 1850480213 http://tail-f.com/ned/ cisco-nx-id /ncs:devices/device{device1}/'device-type'/cli/'ned-id' = {44,{1850480213,1488855246}},     (Optional) 対象のデバイスを削除する もし必要な NED が手元に無い場合、問題となっているデバイスの設定を CDB から削除することで NSO を起動することも可能です。 #ncs --start-phase0 #ncs_load -Fp -P "/ncs:devices/device/name[not (../device-type/netconf or ../device-type/*/ned-id!='')]" \ > | sed 's/<device>/<device nc:operation="delete" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">/' \ > | ncs_load -lmi #ncs --start-phase1 #ncs --start-phase2 #ncs_cli -u admin -C admin@ncs# admin@ncs# show devices list NAME ADDRESS DESCRIPTION NED ID ADMIN STATE ------------------------------------------------------- device0 127.0.0.1 - cisco-ios unlocked   ncs_load コマンドについては man ncs_load を参照してください。上記の例では device-type が netconf 以外で ned-id が設定されていない device を検索して削除しています。 ... View more

NSO CLI で Config を Copy & Paste しようとするとうまくできない場合があります。その場合は以下の CLI 設定を試してみてください。   admin@ncs# autowizard false admin@ncs# complete-on-space false admin@ncs# ignore-leading-space true いずれも CLI の Operational mode で実行するもので、設定は CLI セッション単位で有効になります。現在の設定は show cli で確認できます。 admin@ncs# show cli autowizard true complete-on-space true devtools false display-level 99999999 history 100 idle-timeout 1800 ignore-leading-space false output-file terminal paginate true prompt1 \u@ncs# prompt2 \u@ncs(\m)# screen-length 22 screen-width 99 service prompt config true show-defaults false terminal xterm-256color timestamp disable 以下は各パラメータの説明です。   autowizard ( true | false ) When enabled, the CLI will prompt the user for required settings when a new identifier is created. For example: admin@ncs(config)# aaa authentication users user John Value for 'uid' (<int>): 1006 Value for 'gid' (<int>): 1006 Value for 'password' (<hash digest string>): ****** Value for 'ssh_keydir' (<string>): /var/ncs/homes/john/.ssh Value for 'homedir' (<string>): /var/ncs/homes/john This helps the user set all mandatory settings. It is recommended to disable the autowizard before pasting in a list of commands, in order to avoid prompting. A good practice is to start all such scripts with a line that disables the autowizard: autowizard false ... autowizard true   complete-on-space ( true | false ) Controls if command completion should be attempted when <space> is entered. Entering <tab> always results in command completion.     ignore-leading-space ( true | false ) Controls if leading spaces should be ignored or not. This is useful to turn off when pasting commands into the CLI.   例えば autowizard を true にしている状態で Paste する内容に autowizard 対応の Config  が入っていると、以下のようにプロンプトが出てきてしまい Config は投入されません。 ＜Paste する Config＞ aaa authentication users user test1 aaa authentication users user test2 admin@ncs(config)# aaa authentication users user test1 Value for 'uid' (<int>): aaa authentication users user test2 Error: bad value: "aaa authentication users user test2" is not a valid value. Value for 'uid' (<int>): Error: bad value: "" is not a valid value. autowizard を false にすると Config は投入されます。 admin@ncs(config)# aaa authentication users user test1 admin@ncs(config-user-test1)# aaa authentication users user test2 admin@ncs(config-user-test2)# また、complete-on-space を true にしている状態でスペースが余計に含まれている Config を Paste しようとすると、以下のようになり投入されません。   ＜Paste する Config＞ ios:access-list 1 permit 1.1.1.1 255.255.255.255＜複数のスペースが存在＞ ios:access-list 2 permit 2.2.2.2 255.255.255.255 ＜複数のスペースが存在＞   admin@ncs(config)# devices device ios0 config admin@ncs(config-config)# ios:access-list 1 permit 1.1.1.1 255.255.255.255 Possible completions: <cr> admin@ncs(config-config)# ios:access-list 1 permit 1.1.1.1 255.255.255.255 admin@ncs(config-config)# ios:access-list 2 permit 2.2.2.2 255.255.255.255 Possible completions: <cr>       complete-on-space を false にすると、Config は投入されます。 admin@ncs(config)# devices device ios0 config admin@ncs(config-config)# ios:access-list 1 permit 1.1.1.1 255.255.255.255 admin@ncs(config-config)# ios:access-list 2 permit 2.2.2.2 255.255.255.255 admin@ncs(config-config)#   なお、ncs.conf の <cli> 配下に以下を追加することで永続的な設定変更も可能です。 （既に NSO が稼働している場合は ncs --reload  で変更を適用する必要があります）   <space-completion><enabled>false</enabled></space-completion> <ignore-leading-whitespace>true</ignore-leading-whitespace> <auto-wizard><enabled>false</enabled></auto-wizard>   ... View more

show logs や evlogd プロセスに関する問題をトラブルシュートする場合、以下のコマンド出力が必要な場合があります。 show logging verbose 残念ながら本コマンドは SSD（show support detail） に含まれていません。将来的に SSD に含まれるように エンハンスされる可能性はありますが、現時点では該当の問題の場合は SSD と合わせて別途取得ください。 ... View more