tym78さんの投稿一覧
変数dataは波括弧「{}」で囲まれた「key: value」の形式になっており、辞書型データとして定義しているように見えますが、なぜそのように思われたのでしょうか？
試しに変数dataのデータ型をtype()を使って確認すると、以下のようになります。
(dataの中身は長いので少し省略してますがご了承ください)
[test.py]
import json
data = {
"hostname": "RouterA",
"interfaces": {
"Loopback0": {
"ipv4-address": "1.1.1.1",
"subnet-mask": "255.255.255.255",
"shutdown": "no"
}
}
}
#変数dataのデータ型を出力
print(type(data))
#辞書型の変数dataを文字列型に変換して、変数data2に代入
data2 = (json.dumps(data, separators=(',', ':')))
#変数data2のデータ型を出力
print(type(data2))
#変数data2を出力
print(data2)
[実行結果]
C:\> python test.py
<class 'dict'>
<class 'str'>
{"hostname":"RouterA","interfaces":{"Loopback0":{"ipv4-address":"1.1.1.1","subnet-mask":"255.255.255.255","shutdown":"no"}}}
1行目の<class 'dict'>という出力から変数dataは辞書型だとわかります。
2行目の<class 'str'>という出力から変換後の変数data2は文字列型だとわかります。
これはそういうもんだと覚えるしかないのでしょうか？
はい、そうです。
RESTCONFでネットワーク機器の設定を変更するということは、YANGモデルのデータを操作するということです。
POSTで設定を追加する際に対象のネットワーク機器が対応しているYANGモデルを使ってデータを指定してあげないと、機器側は何を追加したいのか認識できません。
つまり、あらかじめ決められているデータ構造に従って設定を追加したり変更したりする必要があります。
あなたが「"source"」や「"destination"」の方がしっくりくるなと思っても、決められたデータ構造と異なる場合、機器側には通じないということです。
試しに「"source":"any"」を使ってリクエストしてみましたが、以下のようにエラーになりました。
"error-message"に「unknown element: source」と書かれています。これは機器側が「source」というキーを知らない(あらかじめ決められているデータ構造にはない)からです。
{
"ietf-restconf:errors": {
"error": [
{
"error-type": "application",
"error-tag": "malformed-message",
"error-path": "/Cisco-IOS-XE-native:native/ip/access-list",
"error-message": "unknown element: source in /ios:native/ios:ip/ios:access-list/ios-acl:extended[ios-acl:name='ACL4']/ios-acl:access-list-seq-rule[ios-acl:sequence='100']/ios-acl:ace-rule/ios-acl:source"
}
]
}
}
じゃあどうやってデータ構造を知ることができるのかという話になると思いますが、GETリクエストで実際にデータを取得したり、GitHubなどで公開されているYANGモデルを取得したりできます。
詳しくは以下のサイトが参考になると思います。
https://www.infrastudy.com/?p=1262
https://www.it-enjoy.com/entry/2021/01/26/190000#%E5%89%8D%E6%9B%B8%E3%81%8D
https://ccieojisan.net/post-2031/#RESTCONF
ネクストホップの情報=IPヘッダに含まれる宛先IPアドレス という勘違いをされているのではないでしょうか。
実際に、次のホップの宛先アドレスを示すのは、イーサネットヘッダの宛先MACアドレスです。
ネットワークデバイスがIPパケットを転送する際、ルーティングテーブルを参照して次のホップのIPアドレスを決定しますが、このIPアドレスは直接IPヘッダに含まれるわけではありません。(IPヘッダに含まれる宛先IPアドレスは最終的な目的地であるため)
そのため、ARPを使用して、その次のホップのIPアドレスに対応するMACアドレスを取得します。
そして、このMACアドレスが外部イーサネットヘッダの宛先MACアドレスとして設定されます。
なので、VXLANパケットの転送においてネクストホップの情報を示すのは、外部イーサネットヘッダの宛先MACアドレスです。
参考URLに載っている以下のサイトに詳しく説明されています。
https://milestone-of-se.nesuke.com/nw-basic/grasp-nw/ethernet-ip-address/#toc2