前回の評価版 Cisco NSO を使ってみよう NED 活用編 [2020年版] の記事では、NSO に Cisco IOS NED を組み込んでデバイスを制御するところまでをご紹介しました。その記事の最後にも触れたように、NSO の真価はサービスモデルによるネットワークの抽象化にあります。今回はそこにフォーカスしたいと思います。
参考記事
本記事を執筆中に気づきましたが、コミュニティサイトにサービスの作成についての素晴らしい解説記事がすでにありました。こちらもぜひ合わせて参照いただければと思います
NSO: テンプレートベースのサービス作成手順 – Cisco Community
事前準備
前回までは1つだけのデバイス (ios1) を使ってデバイスの操作を見てきましたが、今回はネットワーク全体としての挙動を操作したいのでデバイスを2台 (ios1 と ios2) にしておきます。以下のような構成を想定しています。
[pc1] ---- Gi3[ios1]Gi2 ---- Gi2[ios2]Gi3 ---- [pc2]
サービスのイメージとして、pc1, pc2 をそれぞれ收容する新しいサブネットを各ルータに作成して、相互にルーティングさせるようにしてみます。今回は、最初から ios1, ios2 間のリンクは設定され OSPF でルーティングできている状態とします。
サービスパッケージのひな型の作成
サービスモデルを使うと、外部のユーザや上位システムが、実際のデバイスコンフィグを理解することなく、NSO を通じて複数のデバイスを簡単に制御することができるようになります。具体的にサービスモデルを作ってみましょう。
NSO にはサービスモデルを含むパッケージを開発するためのキットが含まれています。NSO ランタイムフォルダ (ncsrun) の中の packages に移動し、以下のコマンドを実行します。
$ ncs-make-package --service-skeleton python-and-template demo
これで demo という名前のサービスパッケージのひな型が作成されました。フォルダ内の構造を確認します。
$ tree demo/ demo/ ├── package-meta-data.xml ├── python │ └── demo │ ├── __init__.py │ └── main.py ├── README ├── src │ ├── Makefile │ └── yang │ └── demo.yang ├── templates │ └── demo-template.xml └── test ├── internal │ ├── lux │ │ ├── Makefile │ │ └── service │ │ ├── dummy-device.xml │ │ ├── dummy-service.xml │ │ ├── Makefile │ │ ├── pyvm.xml │ │ └── run.lux │ └── Makefile └── Makefile 9 directories, 15 files
今回は、この中の src/yang/demo.yang と templates/demo-template.xml を編集していきます。
サービスモデル
まずは YANG サービスモデルを定義します。
src/yang/demo.yang を編集します。実際には、ひな型がすでにあるので、編集するのは list demo { 以下の変数 (leaf) のみです。
leaf device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf interface {
type string;
}
leaf ipaddress {
type inet:ipv4-address;
}
leaf ipmask {
type inet:ipv4-address;
}
テンプレート
テンプレートは、上で作成したサービスモデルの各変数 (leaf 等) を、デバイスのコンフィグ上の変数にマッピングするために用いるファイルです。XML で記述する必要がありますが、これはデバイス コンフィグから生成可能です。
今回、サービスとして実装したいコンフィグのサンプルを NSO CLI から投入してみると、以下のようになります。
admin@ncs(config)# devices device ios1 config
admin@ncs(config-config)# interface GigabitEthernet 3
admin@ncs(config-if)# ip address 172.20.1.254 255.255.255.0
admin@ncs(config-if)# exit
admin@ncs(config-config)# router ospf 1
admin@ncs(config-router)# network 172.20.1.254 0.0.0.0 area 0
admin@ncs(config-config)# top
admin@ncs(config)# show config
devices device ios1
config
interface GigabitEthernet3
ip address 172.20.1.254 255.255.255.0
exit
router ospf 1
no log-adjacency-changes
network 172.20.1.254 0.0.0.0 area 0
exit
!
!
最後の show config の表示はデフォルトでは Cisco IOS CLI スタイルですが、これを xml 表示することができます。
これをコピー & ペーストでテンプレートファイルに貼り付けましょう。templates/demo-template.xml を編集して上記を貼り付け、先頭と末尾に、テンプレートであることを示すための以下のタグを付加します。
先頭
末尾
さらに、XML テンプレートの中のコンフィグ値のなかで、サービスモデルの変数とマッピングしたい部分を指定します。サービスモデル変数は、{} で囲んだサービスモデル上の Leaf 名で指定します。
以下が具体的にマッピングを行ったあとのテンプレートファイルです
サービスのビルド
これでサービスモデルとコンフィグテンプレートが揃ったので、サービスの完成です。これをビルドして NSO にパッケージとして読み込ませましょう。
今回作ったサービスパッケージの src フォルダに移動して make を実行します
$ cd packages/demo/src
$ make
mkdir -p ../load-dir
mkdir -p java/src//
/tftpboot/nso-blog/nso-5.3/bin/ncsc `ls demo-ann.yang > /dev/null 2>&1 && echo "-a demo-ann.yang"` \
-c -o ../load-dir/demo.fxs yang/demo.yang
特にエラーがでなければ OK です
そして NSO CLI セッションからパッケージの再読み込みを行います
admin@ncs# packages reload
reload-result {
package cisco-ios-cli-6.42
result true
}
reload-result {
package demo
result true
}
これで NSO から今回作った demo サービスを使う準備ができました
サービスの利用
実際にサービスを使ってみましょう。デバイスコンフィグを変更したときと同じように NSO CLI 上から以下のようにサービスコンフィグを設定します。
admin@ncs(config)# demo pc1
admin@ncs(config-demo-test1)# device ios1 interface 3 ipaddress 172.20.1.254 ipmask 255.255.255.0
上記のように、サービスモデルで定義した変数を入力できるようになっています。
これをコミットする前に、これらの変数がテンプレートに適用されて生成される実際のデバイスコンフィグを確認しましょう。commit dry-run を使います
admin@ncs(config-demo-pc1)# commit dry-run
cli {
local-node {
data devices {
device ios1 {
config {
interface {
GigabitEthernet 3 {
ip {
no-address {
- address false;
}
address {
primary {
+ address 172.20.1.254;
+ mask 255.255.255.0;
}
}
}
}
}
router {
ospf 1 {
+ network 172.20.1.254 0.0.0.0 {
+ area 0;
+ }
}
}
}
}
}
+demo pc1 {
+ device ios1;
+ interface 3;
+ ipaddress 172.20.1.254;
+ ipmask 255.255.255.0;
+}
}
}
上記の – 印で示されているのが削除対象、 + 印が追加対象です。
より理解しやすいように、デバイス CLI の形式で表示してみます commit dry-run outformat native を使います。
admin@ncs(config-demo-pc1)# commit dry-run outformat native
native {
device {
name ios1
data interface GigabitEthernet3
ip address 172.20.1.254 255.255.255.0
exit
router ospf 1
network 172.20.1.254 0.0.0.0 area 0
exit
}
}
これを commit して、実際のデバイス側で正しくコンフィグが変更されているか確認してください。
さらに、同様のコンフィグを pc2 について行うことで、同様のコンフィグを次々と生成することが可能です
admin@ncs(config)# demo pc2
admin@ncs(config-demo-test1)# device ios2 interface 3 ipaddress 172.20.2.254 ipmask 255.255.255.0
demo サービスに対して追加していくコンフィグ（今回は pc1, pc2) のことを、サービスインスタンスと呼ぶこともあります。サービスインスタンスを削除すればそれに対応したデバイスコンフィグも削除されます。
まとめ
このようにサービスモデルを作ることで、ユーザや上位システムは最小限のパラメータのみを入力して(抽象化)、デバイス コンフィグにマッピングさせることができます。今回は簡単な例でしたが、よりデバイスのコンフィグが複雑化したり、紐付いていて連動する変数が増えたり、OS がマルチベンダー化したときに、メリットはさらに大きくなります。
NSO のサービスモデル・サービスパッケージには、便利な機能・プロ向けの高度な機能がまだまだあります。ブログでは紹介しきれませんが、より深い内容を紹介できる Cisco NSO How-To サイト（仮称）を企画していますのでぜひ、楽しみにお待ち下さい。
まずは試用版 NSO と NED を使ってここまでできる、ということを体験いただけたら幸いです。
Authors