1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@FKeen

NETCONF 【CCIEメモ_20260523-0606】

1
Posted at

参考資料・時間

資料：
INE Network Security
`
python初学者向けスライド
https://mitani.cs.tsukuba.ac.jp/book_support/python/python_slides.pdf

Learn YAML essentials
https://redocly.com/learn/yaml

YANGおよびデータモデリングの概要
https://community.cisco.com/legacyfs/online/attachments/document/files/d-06_yang-and-data-modeling-overview.pdf

勉強時間：
20260518: 約3時間
20260519: 約2.5時間
20260520: 約3時間
20260521: 約3.5時間
20260522: 約2.5時間
20260523: 約3.5時間
20260524: 約3時間
20260525: 約3時間
20260526: 約3時間
20260527: 約3時間
20260528: 約3時間
20260529: 約3時間
20260530: 約3時間
20260531: 約3時間
20260601: 約2.5時間
20260602: 約3時間
20260603: 約3時間
20260604: 約3時間
20260605: 約3時間
20260606: 約2時間

学習内容

前提として、python初学者向けスライドのp1～p276, XML, YAML, JSONについて理解していること。
XML/JSON/YAMLは相互に変換(XML⇔JSON, JSON⇔YAMLなど)が出来れば多分大丈夫…

NETCONF

参考資料：

SNMPとの違い

SNMPもNETCONFもネットワークの設定を参照(GET)・変更(SET)が可能。
一般的にSNMPは情報の監視(Polling, Trap)のみで利用される。

また、MIBのOIDを指定してPollingを行うため、
複数の機種を使う場合、複数のMIBを監視に使用する形になる。

この問題に対し、より汎用的な方法で情報取得・設定変更出来る手段としてNETCONFがある。
一般的にはTCP830でSSHを使い、セキュアな通信路を使用する。

NETCONFの特徴

NETCONFはスイッチ・ルータ等のNW機器がNETCONFサーバとなり、主にYANG等で定義されたデータモデルに沿って、
設定の取得・変更を行うRPCベースのプロトコル。

データストアというコンフィグ区分が存在する。
Running DataStore, Startup DataStoreに加え、オプションでCandidate DataStoreがある。
Candidate DataStoreは非アクティブな設定…つまり設定変更中で未確定のコンフィグとなる。
これを確定させるにはCommitすることで、Running DataStoreが変更される形となる。

このような設定方式のため、Netconfでは排他的に設定するためのLockがある。
これはDatastore毎に設定変更を行う。

Juniperとほぼ同じ動作になる。ただし、機器によってはCandidate Datesroreが無い場合もある。
これはHelloメッセージにより、お互いのCapabilityを開示する項目で明らかになる。

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>

<!-- ----中略----- --> 

<capability>
        urn:ietf:params:netconf:capability:notification:1.1
      </capability>
</capabilities>
<session-id>27</session-id></hello>]]>]]>

<capabilities>の中に"urn:ietf:params:netconf:capability:candidate:1.0"が無いため、この機器ではCandidateが使用できない。

もし"urn:ietf:params:netconf:capability:candidate:1.0"があれば、candidate datestoreが使用可能となる。

NETCONFのオペレーション

NETCONFではいくつかのオペレーションが存在する。

<get>：Running-Configの設定とデバイスの状態を取得

<get-config>：指定されたデータストアの設定の全て/一部を取得

<edit-config>：指定されたデータストアの設定の全て/一部を変更

<copy-config>：設定のコピー。外部出力だけでなく、あるデータストアの設定を別のデータストアにコピー可能。
CandidateをRunningにコピーしたり、RunningをStartupにコピー可能。

<delete-config>：設定の削除。Runningは削除できない。

<lock>：排他制御を行うため設定データストアをロックし、複数人での設定変更ができないようにする。

<unlock>：lockの解除を行う。

<close-session>：自身のNETCONFセッションを終了

<kill-session>：他のNETCONFセッションを終了


■ 以下はcapability:candidateが有効な場合に使用可能

<commit>：Candidate設定をRunningに反映する。

<comfirmed-commit>：仮コミット。<comfirmed/>と待機時間オプションが付与されている。
    設定は一旦コミットされているが、待機時間を過ぎると設定がロールバックされる。
    通常のCommitを行うと設定が確定される。commit後に管理通信断が起きることを想定

<discard-changes>：Candidateを破棄

<cancel-commit>：confimed-commit後、仮変更を即座に取り消す。

<validate>：candidateの設定を検証する。

RPC message-id

上記のオペレーションはRPC(Remote-Procedure-Call)であり、設定の取得などは特定の手続きとなる。

クライアントがサーバに対してRPCを呼び出す際、<rpc> メッセージが送信される。
サーバがクライアントにRPCメッセージの返答を行う際、<rpc-reply>メッセージが送信される。
これらのrpc/rpc-replyメッセージで使うIDは「Request-Reply」で同じものを使用する。
基本的にMessage-idは重複しても問題ないが、ncclientは自動的に繰り上げする。

NETCONFを手動で送信する

イメージを掴むために各シーケンスごとにNETCONFを手動で送付する。
流れとしては以下

  1. SV：NETCONFサーバ(今回はルータ)への設定
  2. CL：NETCONFサーバへの接続
  3. CL：NETCONFサーバへのHello送信
  4. CL：NETCONFサーバへのオペレーション送信　SV：サーバからの返答

1. SV：NETCONFサーバへの設定

SSHを行うので、機器によってRSA鍵生成は必要。
今回はCSR1000vを使用している

<事前設定>

# 使用バージョン
RT#show version | i Version
Cisco IOS XE Software, Version 17.03.08a


# SSH設定(CSR1000vではVTYのみ設定)
(config)#

hostname RT

ip domain name cisco.com

crypto key generate rsa
  How many bits in the modulus [1024]:
    % Generating 1024 bit RSA keys, keys will be non-exportable...
    [OK] (elapsed time was 1 seconds)

line vty 0 4
 transport input ssh
 login local


# NETCONF設定

! 特権(privilege 15)ユーザ作成
username admin privilege 15 password 0 cisco

! NETCONF有効化
netconf-yang

! secure-server有効化(CSR1000vではdefault-enabled)
ip http secure-server

! オプション：ACL設定
ip access-list standard NETCONF
 10 permit 0.0.0.0 255.255.255.0
netconf-yang ssh ipv4 access-list name NETCONF

! オプション：権限設定
aaa new-model
aaa authorization exec default local

<確認>

netconf-yang: enabled
netconf-yang ssh port: 830
netconf-yang candidate-datastore: disabled
　※candidateは使用できないため、disableのまま

2. CL：NETCONFサーバへの接続

デフォルトでTCP/830に対してSSH接続を行う。
接続後、Capabilitiesが表示され、最後にHelloが記載。
NETCONF base:1.0では、末尾の]]>]]>はXMLの終端を示す。
NETCONF base:1.1では、chunked framing(\n##\n)を使用。

サーバ側のCapabilityが示されたので、クライアント側もCapabilityを送ることで互いに何が出来るかが分かる。
RPCの送信はその後となる。

PS C:\Users\TESTUSER> ssh -p 830 -l admin 192.168.0.96
admin@192.168.0.96's password:

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
 ～～～～～～中略～～～～～～
<capability>
        urn:ietf:params:netconf:capability:notification:1.1
      </capability>
</capabilities>
<session-id>27</session-id></hello>]]>]]>

3. CL：NETCONFサーバへのHello送信

先述の通り、Client側のHelloを送付し、Clientのcapabilityを送付。
ClientのHelloを送付してもServer側からの返答は無いが、それが正常動作となる。

Pythonからncclientを使った場合、明示的な動作を書くところではない。
これはncclient側が自動的に処理してくれる部分となる。

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>
      urn:ietf:params:netconf:base:1.0
    </capability>
  </capabilities>
</hello>]]>]]>

4. CL：NETCONFサーバへのオペレーション送信　SV：サーバからの返答

ここで初めて先述のオペレーション(get, get-config等)が確認可能。

<!-- 以下がクライアントからサーバへの送信 -->
<rpc message-id="101"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get/>
</rpc>]]>]]>
<!-- 以下がサーバからの返答 -->
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"><data>
<!-- 中略。実際は改行なし。-->
<namespace>http://tail-f.com/ns/common/query</namespace><conformance-type>import</conformance-type>

<rpc message-id="101" に対して、
<rpc-reply xmlns="～中略～" message-id="101" となり、
rpc message-idが要求と応答で対になっている。

5. CL：NETCONFサーバへのオペレーション送信(Filter)

<!-- リクエスト -->
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <!-- get-configを実行。対象DatastoreはRunning -->
  <get-config>
    <source>
      <running/>
    </source>
    <!-- Filterを設定 -->
    <filter type="subtree">
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <hostname/>
      </native>
    </filter>
  </get-config>
</rpc>]]>]]>

<!-- 応答 -->
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <data>
    <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
      <hostname>RT</hostname>
    </native>
  </data>
</rpc-reply>]]>]]>

6. CL：NETCONFサーバへのオペレーション送信(edit-config)

応答として、<ok/> と表示される。
これはRPCが正常終了した意味。
もし失敗した場合、<rpc-error> が返ってくる。

<!-- リクエスト -->
<rpc message-id="102"
 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <!-- 対象データストアはRunning -->
    <target>
      <running/>
    </target>
    <config>
      <!-- 変更コンフィグの対象。 native > hostnameを指定 -->
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <hostname>CCIE-R1</hostname>
      </native>
    </config>
  </edit-config>
</rpc>]]>]]>

<!-- 応答 -->
</rpc>]]>]]>
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="102"><ok/></rpc-reply>]]>]]>

実際のコンソールログは以下

RT#
RT#
CCIE-R1#

hostnameを変更するためのYANGについて知るため、以下のTREEを見てみる。
<native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">

pyang -f tree .\Cisco-IOS-XE-native.yang > atree.txt
module: Cisco-IOS-XE-native
  +--rw native
     +--rw default
     |  o--rw crypto
     |     o--rw ikev2
     |        o--rw proposal?   empty
     |        o--rw policy?     empty
～～～～～中略～～～～～～～～～
     +--rw hostname?                  string
     +--rw enable
     |  +--rw password
     |  |  +--rw level?    uint8
     |  |  +--rw type?     enumeration
     |  |  +--rw secret?   string
     |  +--rw last-resort?   enumeration
     |  +--rw secret
     |  |  +--rw level?    uint8
～～～～攻略～～～～～～～～～～～

native container 配下に hostname leafがあるのが分かる。

また、Cisco-IOS-XE-native.yangの中身は以下
hostnameの最大文字数や使用できる文字が分かる。

    leaf hostname {
      description
        "Set system's network name";
      type string {
        length "1..246";
        pattern '([0-9.]*[A-Za-z\-_]+[A-Za-z0-9.\-_]*)';
      }
    }

また、Edit-ConfigにはOperation Attributeとしていくつかの種類がある。

  • merge
    指定された変更要素のみ変更、変更対象が既存設定に無い場合は新規作成。

  • replace
    指定された変更のみ変更、変更対象が既存設定に無い場合は新たに作成。
    　※全て置き換えるため、mergeと比べて未指定要素が削除される恐れあり

  • create
    変更対象が既存設定に無い場合は作成。変更対象が既存設定にあれば<rpc-error>
    <error-tag>はdata-existsとなる。

  • delete
    削除対象が既存設定にある場合は削除。削除対象が既存設定に無ければ<rpc-error>
    <error-tag>はdata-missingとなる。

  • remove
    削除対象が既存設定にある場合は削除。削除対象が既存設定に無ければそのままとなる

YANG

YANGはデータモデル。
実際の設定としてはXML/JSONで表現される。

そのため。YANGはXML/JSONのデータ構造を定義するデータモデル言語といえる。

module

先述の項目で使用したCisco-IOS-XE-nativeもModuleとなる。
他モジュールと関連するところを最初に説明する。

以下がステートメントとなる。
[キーワード] [引数];

　[キーワード] [引数]{
サブステートメント
}

module Cisco-IOS-XE-native {

  // yang-versionはYANGモデルを記述するバージョン。Ver1.0はオプション、Ver1.1は必須。
  yang-version 1.1;
  // YANGモデルの名前空間を記述
  namespace "http://cisco.com/ns/yang/Cisco-IOS-XE-native";
  // 他のYANGやXPath/XML namespaceを参照する際に使用する接頭語としてiosを使用する。
  prefix ios;

  // 別moduleを利用する
  import cisco-semver {
    prefix cisco-semver;
  }
  import ietf-inet-types {
    prefix inet;
  }
  import Cisco-IOS-XE-types {
    prefix ios-types;
  }
  import Cisco-IOS-XE-features {
    prefix ios-features;
  }
  import Cisco-IOS-XE-interface-common {
    prefix ios-ifc;
  }

  // 同一モジュールを複数ファイルに分割するため、Submoduleをincludeする
  include Cisco-IOS-XE-parser;
  //また、Submodule側では親モジュールをbelong-toで所属させる。

  // 参考 … Cisco-IOS-XE-parser.yang
  // submodule Cisco-IOS-XE-parser {
  //   yang-version 1.1;
  //   belongs-to Cisco-IOS-XE-native {
  //     prefix ios;
  //  ～～～～～～～～ 略 ～～～～～～～～  

  include Cisco-IOS-XE-license;
  include Cisco-IOS-XE-line;
  include Cisco-IOS-XE-logging;
  include Cisco-IOS-XE-ip;
  include Cisco-IOS-XE-ipv6;
  include Cisco-IOS-XE-interfaces;
  include Cisco-IOS-XE-hsrp;
  include Cisco-IOS-XE-location;
  include Cisco-IOS-XE-transceiver-monitor;

  // YANGモデルを管理する組織
  organization
    "Cisco Systems, Inc.";
    
  // YANGモデルを管理する組織の連絡先
  contact
    "Cisco Systems, Inc.
     Customer Service"
//  ～～～～～～～～ 中略 ～～～～～～～～

  // YANGモデルの説明
  description
    "Cisco XE Native Parser Yang model."

  // 改定した日付を記載
  revision 2022-11-01 {
    description
      "- Update yang-version to 1.1";
    cisco-semver:module-version "1.1.0";
  }
//  ～～～～～～～～ 中略 ～～～～～～～～
  }

Container

子ノードを階層的に格納するためのノードを表わす。
XMLでは親要素となる。

以下の例ではYANGのコンテナーとXMLにした際の表現について記載。


  +--rw native
     +--rw default
     |  o--rw crypto
     |     o--rw ikev2
     |        o--rw proposal?   empty ※leaf
 ! ---------中略--------

  // native配下に以下のコンテナが存在する
  container native {
    container default {
      description
        "Set a command to its defaults";
      container crypto {
        description
          "Encryption module";
        status obsolete;
        container ikev2 {
          description
            "Configure IKEv2 Options";
          status obsolete;
          leaf proposal {
            description
              "Define IKEV2 proposals";
            status obsolete;
            type empty;
          }
        }
      }
    }

これをXMLで表現すると以下になる。


<native>
  <default>
    <crypto>
      <ikev2>
        <proposal/> <!-- これだけleaf --> 
      </ikev2>
    </crypto>
  </default>
</native>

Leaf

Leafは単一の値を保持するノード
XMLでは要素として表現される。

    leaf hostname {
      description
        "Set system's network name";
      type string {
        length "1..246";
        pattern '([0-9.]*[A-Za-z\-_]+[A-Za-z0-9.\-_]*)';
      }

上記をXMLにすると、以下のようになる。


〇Tree表示
module: Cisco-IOS-XE-native
  +--rw native
     +--rw hostname?                  string

〇XML

<!-- get-config時のFilterはこの形式 -->
<native>
  <hostname/>
</native>


<!-- get-configのサーバ応答はこの形式(見やすいよう改行済) -->
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
    <data>
        <native
            xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
            <hostname>CCIE-R1</hostname>
        </native>
    </data>
</rpc-reply>


<!-- edit-config時はこの形式 -->
<native>
  <hostname>CCIE-RT1</hostname>
</native>

OpenConfig

参考資料：

OpenConfigはベンダ共通(vendor-neutral)なYANGデータモデル群を指す。

例を挙げるならば、Cisco-IOS-XE-native.yangはCiscoベンダ依存のYANGだった。
結果、マルチベンダー・OSが異なる環境では機器毎に使用するYANGが異なる。

そのため、OSPF設定の変更を行う際、
NETCONFではベンダーやOS毎に異なる設定を投入していたところが
共通のデータモデルで設定できるようになる。
ただし、ベンダー独自の設定によりモデル化されていない物も存在する。

特徴的なのは運用者目線で開発されているところ。
そのため設定取得・変更や機器の状態取得が中心となっており、
運用・監視・検証自動化に対して強みを持つ。

モデル構造と操作API

〇モデル構造
OpenConfigはYANG Module単位でツリー構造になっている。

〇操作API
検証自動化フレームワークでは以下のAPIを使って機器の操作を行う。
基本的にはgRPC(HTTP/2で通信するRPCプロトコル)をベースとしている。

  • gNMI (gRPC Network Management Interface):
    機器の設定取得や設定変更、機器の状態(Telemetry)が可能。

  • gNOI (gRPC Network Operation Interface):
    機器の操作(Pingやreload、Tracerouteなど運用系コマンド)が可能。

RESTCONF

HTTP/HTTPSをベースとしてリモートデバイスを操作する。

NETCONFとの共通点

・YANGモデルを使用する

・データフォーマットにXMLを使用可能
　※RESTCONFはJSONを主に使用する。

・Client - Server間の通信にTCPを使用する。

NETCONFとの差異

・TCP/830によるSSHではなく、RESTCONFではHTTP・HTTPSを使った接続を行う。
　※基本的にはHTTPSを使用

・HTTPベースのため、ブラウザやcurl, requestsからもクエリを実行可能

・データエンコーディングとしてJSONを使用(XMLもサポート)

・NETCONFはステートフルでありSSHセッションを維持する必要があるが、
　RESTCONFはステートレスでありセッションを維持しない。

データ送信について

〇メソッド・CRUDの比較
RESTCONF, NETCONF, データベースのCRUD(Create, Read, Update, Delete)の比較以下となる

RESTCONF NETCONF Database
GET <get>, <get-config> READ
POST <edit-cofnig>(operation="create") CREATE
PUT <edit-cofnig>(operation="replace") UPDATE
PATCH <edit-cofnig>(operation="merge") PUT
DELETE <edit-cofnig>(operation="delete") DELETE

〇NETCONF/RESTCONF エンコーディングの違い

YANGモデルを元にしてNETCONFはXML, RESTJSONでエンコーディングされる。

〇YANG Tree
 module: Cisco-IOS-XE-native
   +--rw native
      +--rw hostname? string

〇YANG コンテナー・ノード
  container native {
    container default {
      description
        "Set a command to its defaults";
          }
    leaf hostname {
      description
        "Set system's network name";
      type string {
        length "1..246";
        pattern '([0-9.]*[A-Za-z\-_]+[A-Za-z0-9.\-_]*)';
      }
    }
}

NETCONFはリクエスト・リプライ両方でXMLを使用

〇サーバへのリクエスト(XML形式)
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
    <filter type="subtree">
      <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
        <hostname/>
      </native>
    </filter>
  </get-config>
</rpc>


〇サーバからのリプライ(XML形式)
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <data>
    <native xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-native">
      <hostname>RT</hostname>
    </native>
  </data>
</rpc-reply>]

RESTCONFはリクエストではURIを使用。リプライではJSONを使用

〇サーバへのリクエスト(URI)
GET /restconf/data/Cisco-IOS-XE-native:native/hostname

〇サーバからのリプライ(JSON形式)
{
    "Cisco-IOS-XE-native:hostname": "VALIDATION-HOST"
}

RESTCONFでは以下の構文で記載される。

データ操作：機器の設定を参照・変更する
RPC・オペレーション操作：機器の設定保存など、

〇設定取得・変更などデータ操作
[Method] /restconf/data/[モジュール]:[コンテナ]/[リスト]=[キー]/[リーフ]

〇RPCなどオペレーション操作
[Method] /restconf/operations/[モジュール]:[コンテナ]/[リスト]=[キー]/[リーフ]


データ操作(/data/)の取得・変更
設定取得 例)
GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2

設定変更 例)
PATCH https://[ip-address:443]/restconf/data/Cisco-IOS-XE-native:native/hostname
bodyは以下
{
    "Cisco-IOS-XE-native:hostname": "CHANGED-HOST"
}

RPC

〇RPCの実行例
ツリーを見ると「RPC」の記載有り

module cisco-ia {
  namespace "http://cisco.com/yang/cisco-ia";
  prefix cisco-ia;

  // ------------(中略)------------

  rpc save-config {
    description
      "Copy the running-config to
       startup-config on the Network
       Element.";
    output {
      uses cisco-ia-output;
    }
  }



POST https://[ip-address]:443/restconf/operations/cisco-ia:save-config

<実行結果>
CMD: 'wr' 05:00:57 UTC Sat May 30 2026
*May 30 05:00:57.279: %DMI-5-AUTH_PASSED: R0/0: dmiauthd: User 'admin' authenticated successfully from 192.168.0.15:0 and was authorized for rest over http. External groups: PRIV15
CMD: 'show history all ' 05:01:05 UTC Sat May 30 2026

RESTCONFの有効化設定

ルータ等のNW機器がRESTCONF サーバとなる。


! HTTPSでの通信のため、自己署名証明書が必要
ip http secure-server

! Privilege 15のusername
username admin privilege 15 password 111

! RESTCONFの有効化
restconf

! ローカルユーザ/パスワードを使った認証
ip http authentication local

テレメトリ

テレメトリの概要

テレメトリは単独のプロトコル名でなく、NW機器からコンフィグ・状態情報・運用状態情報をPush型で配信する仕組みの総称。

テレメトリは定期的なデータ受信によって、リアルタイムで状態を監視することを目的とする。
自動的な通信であり、NW機器などで測定された情報をモニタリング用の受信機で受信する。

NETCONF, gNMIといったYANGデータモデルを使用するプロトコルで通信を行い、gRPC等の通信基盤を利用してテレメトリを実現する。
そのため、YANGデータモデル単位での情報取得を行う。

先述のRESTCONFは基本的に設定変更・設定取得用のプロトコルであり、テレメトリとして使用することはない。
NETCONFも設定取得・変更用だが、テレメトリが一応できるため以下にて紹介している。

テレメトリの方法は2種類に分かれる。
ポリシーベース：JSONにてポリシーファイルを作成し、ファイル内で何をどのくらいの頻度で取得するかを定義。
モデル駆動型：YANGモデルに従ってデータが表現されている。目的のデータをサブスクライブし、定期的にデータを取得する

基本的にテレメトリではモデル駆動型テレメトリ(MDT:Model Driven Telemetry)が使用される。

■ テレメトリの実行方式
MDT
├─ Dial-In
│   ├─ NETCONF
│   └─ gNMI
│
└─ Dial-Out
    └─ gRPC

■ テレメトリの実行頻度
MDT
├─ Periodic
│
└─ On-change

SNMPとの比較

機器の管理・監視にSNMPを使用する場合、取得間隔が広くリアルタイムでの設定の変化が分かりづらい。
SNMPは管理サーバ(NMS)が定期的に情報取得依頼(GET)を送信し、SNMPサーバがデータを返答するPull型。
また、OIDを基準とした情報取得であり、YANGモデルのようにツリー化された構造化データ取得に向いていない。

gNMI

OpenConfigが策定したネットワーク管理用プロトコル。テレメトリによく使用されることが多い。
クライアント・サーバ間の通信はgRPCを使用
データエンコーディングにはptotobuf(Google Protocol Buffer)を主に使用

NETCONFやRESTCONF、gNMIはCisco Native YANG, Openconfigのどちらも使用できるが、
gNMIではOpenConfig YANGを使用する事が多い。

テレメトリに使用される要因としては、
OpenConfigに対応しており、マルチベンダ環境でも共通データモデルで設定取得・監視が可能。

gNMIのオペレーション

gNMI NETCOF
設定取得 Get <get>, <get-config>
設定変更 Set <edit-config>
Telemetry購読 Subscribe Telemetry

SubscribeはgNMIの特徴的な機能
以下の通り階層的になっている。

〇gNMIのSubscribeの動作

gMNI
 + GET           ： 設定・状態取得
 + SET           ： 設定変更
 + SUBSCRIBE     ： Telemetry購読
   + ONCE          ：→ テレメトリデータを1度だけ取得
   + POLL          ：→ テレメトリデータを要求時に取得
   + STREAM        ：→ テレメトリデータを継続取得
     + SAMPLE        ：→ 一定間隔で送信
     + ON_CHANGE     ：→ 値が変化した場合のみ送信

テレメトリロール

Publisher：テレメトリデータの送信者。主にNW機器を指す

Collector(Receiver)：テレメトリデータの受信者。

Subscriber：サブスクリプションの作成者。Publisher、Collectorのどちらもなりうる。

Controller：サブスクリプションを作成するが、テレメトリデータを受信しない者を指す。
管理エージェント・管理エンティティとも呼ばれる。

Dial-In, Dial-Out

テレメトリ方式だが大まかに分けて2種類存在する。

・Dial-Out(発呼)方式
　Publisher側から接続開始。事前設定されたSubscription設定に従い、Collectorへデータ送信を実施する。

・Dial-In(着呼)方式
　Collector側から接続開始。NW機器にテレメトリ設定を投入し、CollecterからSubscribeを開始する
　このテレメトリ設定はRunningコンフィグを変更するものではない。

■ Dial-Out方式の特徴は以下の通り。
・静的/設定済み
・サブスクリプションはRunning-Configに保存される。
　設定が削除されるまでデバイス設定として残る。
・再起動してもサブスクリプションは継続される。
・サブスクリプションIDは固定であり、設定の一部。
　

■ Dial-In方式の特徴は以下の通り。
・動的
・テレメトリはサブスクリプションを作成した接続に結びついており、
　セッションが停止するとテレメトリも終了する。設定は機器に残らない。
・NW機器など、Publisherが停止・リロードするとテレメトリも終了するため、
　新たにテレメトリを開始させる必要がある。
・サブスクリプションIDはサブスクリプションが確立したときに動的に生成される。

テレメトリではNETCONF, RESTCONFなどがDial-In, Dial-Outを自由に使えるわけではない。
プロトコルによってDial-Inが可能、Dial-Outは不可…などが決まっている。

+----------------------+------------------+-------------------+-------------------+
|                      | NETCONF          | gRPC              | gNMI              |
+----------------------+------------------+-------------------+-------------------+
|                      |   IN   |  OUT    |   IN   |    OUT   |   IN     |  OUT   |
+----------------------+--------+---------+--------+----------+----------+--------+
| yang-push            |   ○    |   ×     |   ×    |     ○    |   ○      |   ×    |
+----------------------+--------+---------+--------+----------+----------+--------+
| yang-notif-native    |   ○    |   ×     |   ×    |     ○    |   ×      |   ×    |
+----------------------+--------+---------+--------+----------+----------+--------+
| Encodings            |   XML  |   -     |   -    | protobuf | protobuf |   -    |
| 　　　　　            |        |         |        | + kvGPB  |+JSON_IETF|        |
+----------------------+--------+---------+--------+----------+----------+--------+

テレメトリの実行間隔について

テレメトリを設計するにあたり、最も重要なのが情報取得の頻度となる。
結局データ取得の頻度が遅いとリアルタイム性が失われるため、何を基準に情報取得を行うかが問題となる。
　・Cadence-based：ケイデンス(周期)的に情報を取得する。(Periodic)
　・Event-based　：インターフェースdown等のイベント毎に情報を取得する。(On-Change)

テレメトリの設定

ここではDial-Outでどのような設定が入るかを説明。
また、XPATH, Sensor Pathについて説明を行う。

(config)#
telemetry ietf subscription 101     ! サブスクリプション設定 IDは101
 stream yang-push                   ! YANGモデルでPushする。YANGモデル駆動テレメトリ
 ! Sensor PATH設定、XPATHで取得する情報を指定
 filter xpath /memory-ios-xe-oper:memory-statistics/memory-statistic
 update-policy periodic 6000        ! 定期的に取得。1/100秒で指定なので、60秒に1度取得
 encoding encode-kvgpb              ! エンコーディングにkvGPBを使用
 ! CollectorのIPアドレス、TCPポート、Collectorとの通信で使用するプロトコルを指定
 receiver ip address 10.28.35.45 57555 protocol grpc-tcp

※On-Changeを使用する場合、「update-policy on-change」となる。
　この際は値が変化した場合のみテレメトリデータを送信

テレメトリで取得する対象となる情報の指定をセンサーパスと呼ぶ。
センサーパスはYANGモデルを使用し、一般的にはXPATHが使用される。

Telemetory Broker

1つのPublisherに対して、複数のCollecterがある場合について。
Publisherは複数コレクターがあると各自に対してSubscriptionデータを送信する。
その際、コレクターの数だけデータを送信するため、その分帯域を消費する。

この対策として、テレメトリブローカーを使用する。
Publisherはテレメトリブローカーにテレメトリデータを送信し、テレメトリブローカーが各collectorに対してデータを送信する。
これにより、Publisherからテレメトリブローカーまでの経路は1度の通信で済む。
Telemetry BrokerはPublisherとControllerの間で、中継・集約・変換を行う。

テレメトリブローカーはフィルター設定が可能。
Netflow, IPFIX, sFLOW, Syslog, SNMPなどにも対応している。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?