6-4 SD-WAN 設計と運用 — transport の選び方と TLOC・OMP の設計
Cisco Catalyst SD-WAN の設計を color と TLOC、OMP、冗長の順に押さえます。cEdge 2 台の非対称構成で TLOC が 2 本と 1 本に割れる様子と、restrict などの設計ノブが出力のどこに出るかを実機で確かめます。
1. 前節の振り返りと本節の内容
前節 6-3 Cisco SD-WAN 概要 では、Cisco Catalyst SD-WAN を構成要素と用語の側から並べました。仕事は 4 つの平面に割れ、SD-WAN Manager が管理、SD-WAN Controller が制御、SD-WAN Validator がオーケストレーション、WAN Edge router がデータを担当します。TLOC (Transport Location) は system IP・color・encapsulation の 3 つ組で識別され、OMP (Overlay Management Protocol) は経路だけでなく鍵とポリシーも運びます。分離は VPN 番号で行い、IOS XE SD-WAN では数字だけの VRF として現れます。
6-3 の末尾は 3 つの論点を予告しました。transport の選び方、TLOC とポリシーの設計、冗長の取り方です。本節はこの 3 つをこの順で扱います。
| 6-3 が予告した論点 | 本節のどこで扱うか |
|---|---|
| transport の選び方 | §2。color の語彙、private color と NAT、既定の全対全と restrict |
| TLOC とポリシーの設計 | §3 で TLOC の 3 つ組と設計ノブ、§4〜§5 で OMP が運ぶものと最適経路選択、§9 と §10 でポリシーの語彙がどちら側に在るか |
| 冗長の取り方 | §6。制御接続の本数、transport 冗長、TLOC extension |
6-3 との重複は避けます。6-3 が概要として触れた TLOC・color・OMP・VPN について、本節が足すのは 1 台に TLOC を複数立てるとどう見えるか、OMP が運ぶ 3 種類の経路と属性、冗長を数で設計する方法の 3 点です。
1.1 出典層と実測層を分ける
本節も 6-3 と同じ制約を受けます。本ラボは SD-WAN Controller / Manager / Validator を 1 つも起動していません。 そのため BFD (Bidirectional Forwarding Detection) セッションが張れず、OMP の経路交換・restrict の効果・アプリ認識ルーティングの SLA 判定は原理的に成立しません。これは「撮らなかった」のではなく「この構成では発生しない」という意味です。
根拠は出典の側にあります。Routing Configuration Guide は OMP のピアリングについて次のように書いています (逐語)。
The OMP peering sessions between the centralized controller and the edge devices are exclusively for exchanging control plane traffic. They do not transmit data traffic.
Edge devices do not advertise routing information to each other using OMP or any other method.
OMP は Controller 同士と、Controller と edge のあいだで張られます。edge 同士では張られません。 Controller が構成の中に居なければ、OMP の経路交換は起こりようがありません。
そこで本節は、どの節が何に支えられているかを見出しに明示します。
| 節 | 支えている根拠 |
|---|---|
| §2〜§6 | Cisco 公式資料。設計の定義と既定値 (見出しに ※出典) |
| §7〜§9 | 本ラボの実機出力。C8000v 2 台で撮った逐語 (見出しに ※実測) |
| §10 | Cisco 公式資料。アプリ認識ルーティングの位置づけ (見出しに ※出典) |
| §11 | 確かめていないことの宣言。実測の範囲を明示する |
実機の節では、空の出力を主張の根拠にしません。表示されなかったこと・セッションが張られなかったことは証拠として使わず、機器が印字した正の出力にだけ主張を負わせます。
2. transport の選び方 (※出典)
この節の内容はすべて Cisco 公式資料の記述です。 本ラボは Controller を起動していないため、ここで書く選び方の帰結 (どの TLOC 同士がセッションを張るか) を実機では観測していません (§11)。
2.1 color は transport に付ける札
color は TLOC がどの transport に属するかを表すラベルです。任意の文字列ではなく、あらかじめ決められた語彙から選びます。Systems and Interfaces Configuration Guide は選べる値を次のように挙げています (逐語)。
includes options such as 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, private1 through private6, public-internet, red, and silver
3g / lte / biz-internet / mpls のように回線種別を示すものと、gold / silver / bronze / blue / red / green のように等級や記号として使えるものが混在しています。名前が機能を決めるわけではありません。 ただし後述する private color だけは扱いが変わります。
2.2 private color は NAT を挟めない
color のうちいくつかは private color として区別されます (逐語)。
designates metro-ethernet, mpls, and private1 through private6 as private colors that use private addresses for private networks, which can be used on public networks only if there is no NAT device between the local and remote Cisco IOS XE Catalyst SD-WAN devices.
metro-ethernet / mpls / private1 〜 private6 が private color です。これらは私設アドレスを前提としており、local と remote の機器のあいだに NAT (Network Address Translation) 装置が挟まると公衆網では使えません。閉域網に付ける色と、インターネット回線に付ける色を取り違えると、この一行が効いてきます。
本ラボが biz-internet と mpls を選んでいるのは、public 側と private 側を 1 つずつという最小の対比になるからです。
2.3 同じ color を 1 台で 2 回は使えない
color の選び方が設計になる理由は、1 台あたりの重複が禁じられているためです (Design Guide・逐語)。
You cannot use the same color twice on a single WAN Edge router.
TLOC を一意にするのは system IP・color・encapsulation の 3 つ組で、system IP は 1 台に 1 つです。したがって同じ color を 2 本の回線に付けると、区別する材料が encapsulation しか残りません。回線が 2 本あるなら、色も 2 つ選ぶというのが出発点になります。
2.4 既定は全対全 — restrict はそれを切り詰める
color を選ぶだけでは、どの TLOC 同士が繋がるかは絞られません。既定の挙動は次のとおりです (Design Guide・逐語)。
By default, WAN Edge routers attempt to connect to every TLOC over each WAN transport, including TLOCs that belong to other transports marked with different colors.
既定では、色が違っていても全部の TLOC へ接続を試みます。 インターネット回線と閉域網のあいだにもセッションを張ろうとします。これを切り詰めるのが restrict キーワードです (同ガイド・逐語)。
the restrict keyword is used on the MPLS color, resulting in MPLS TLOCs only being able to form sessions with other MPLS TLOCs.
mpls の color に restrict を付けると、その TLOC は同じ mpls の TLOC としかセッションを張らなくなります。閉域網が公衆網と混ざらないようにする使い方が代表的です。
読み違えやすいのは向きです。restrict は繋げるための指定ではなく、既定の全対全を減らすための指定です。付けなければ色をまたいで試み、付けると同じ色だけになります。
本ラボが確かめたのは、この効果の手前までです。 どのセッションが張られるかは Controller が居ないと観測できないため、実測したのは設定が受理されることと、6 つのノブを入れた後の show sdwan control local-properties で RESTRICT 列の値が変わっていることの 2 つに限られます (§8)。どの列がどのノブで変わったかは切り分けていません (§8.3)。
3. TLOC の設計 (※出典)
この節の内容も Cisco 公式資料の記述です。 本ラボの実機出力は §7 と §8 で扱います。
3.1 TLOC を一意にする 3 つ組
TLOC の定義は 6-3 §4.2 で引いたとおりです (Design Guide・逐語)。
A TLOC is uniquely identified and represented by a three-tuple, consisting of system IP address, link color, and encapsulation (Generic Routing Encapsulation [GRE] or IPsec).
system IP・color・encapsulation の 3 つ組が TLOC を一意にします。設計の観点でこの 3 つを並べ直すと、それぞれ動かせる自由度が違います。
| 要素 | 自由度 |
|---|---|
| system IP | 1 台に 1 つ。機器を決めた時点で決まる |
| color | 回線ごとに選ぶ。同じ値を 1 台で 2 回は使えない (§2.3) |
| encapsulation | IPsec か GRE。同じ tunnel-interface に 2 つ書ける (§3.4) |
3.2 1 台に TLOC を複数立てる
TLOC は 1 台に 1 本とは限りません。transport を増やせば、その数だけ立ちます。6-3 は TLOC を概念として扱いましたが、設計の実際では 1 台に何本立てるかが最初の判断になります。
その上限については、現行の Cisco 資料の記述が一致していません。 同じ Configuration Guide の中でも 2 通りの数字が書かれています。
| 資料 / 位置 | 逐語 | 値 |
|---|---|---|
| Routing Configuration Guide — Configure OMP (GUI フィールドの説明) | A Cisco IOS XE Catalyst SD-WAN device can have up to four TLOCs | 4 |
| 同 (同一ページの別パラメータ「Number of Paths Advertised Per Prefix」の説明) | A Cisco IOS XE Catalyst SD-WAN device can have up to eight TLOCs | 8 |
| 同 (同一ページ・WAN インタフェース数から) | This means that each router can have up to eight TLOCs | 8 |
| Policies Configuration Guide — Application-Aware Routing | Each Cisco IOS XE Catalyst SD-WAN device supports up to eight TLOCs | 8 |
| Segmentation Configuration Guide | you can configure up to eight tunnel interfaces | 8 |
| Design Guide (CVD) | you can configure up to eight tunnel interfaces, which is equivalent to eight TLOCs | 8 |
“four” と書いているのは 1 か所だけで、残る 5 か所は “eight” です。 注意したいのは、4 と 8 のどちらも同じページの GUI パラメータ説明だという点です。4 は “Paths Advertised Per Prefix”、8 は “Number of Paths Advertised Per Prefix” の説明中にあり、ほとんど同じパラメータの説明が別の数を書いています。片方が古い記述の残りである可能性はありますが、資料からは決まりません。本節は 8 を主として扱い、同じページに 4 の記述が併存することを注記に留めます。どちらか 1 つを正とはしません。使用するリリースの資料で確認する扱いが安全です。
本ラボではこの食い違いを決着できません。 本ラボは transport を 2 本しか用意しておらず、そもそも上限に当たっていないためです (§11)。なお同じページは「WAN インタフェースは VPN 0 の中で tunnel-interface に設定した任意のインタフェースで、物理でもループバックでもよい」と書いているので、物理ポートの本数だけが上限検証の制約になるわけではありません。
3.3 encapsulation と既定 MTU
encapsulation は IPsec か GRE で、既定の MTU が違います (Systems and Interfaces Configuration Guide・逐語)。
sets the default MTU to 1442 bytes for IPsec and 1468 bytes for GRE, which is enabled by default on all TLOCs, based on BFD path MTU discovery.
IPsec が 1442 バイト、GRE が 1468 バイトで、この既定は BFD の path MTU discovery に基づいて全 TLOC で有効になっています。BFD が MTU の探索まで担っているという点は、§6 で再び出てきます。
3.4 同じ tunnel-interface に encapsulation を 2 つ書く
encapsulation は排他ではありません (同じ章・逐語)。
You can configure both IPsec and GRE encapsulation by including two encapsulation commands under the same tunnel-interface command.
同じ tunnel-interface の下に encapsulation を 2 行書けます。 6-3 §4.2 で引いた Qualified Command Reference は、この場合に IP も color も同じで encapsulation だけが違う TLOC が 2 つできる、と書いていました。3 つ組の 3 番目に encapsulation が入っているのは、この区別のためです。
本ラボは 2 行書けることまでは実測しましたが、それで TLOC が 2 本に増えるかは確認していません (§8.4 / §11)。
3.5 ローカルに設定する値が、配られる属性になる
TLOC には設計上のノブがいくつも付きます。本節が実機で投入するのは次の 6 つです。
| ノブ | 位置 |
|---|---|
color mpls restrict | tunnel-interface の color 指定に付けるキーワード (§2.4) |
max-control-connections 0 | tunnel-interface 配下 |
carrier carrier1 | tunnel-interface 配下 |
encapsulation ipsec preference 100 weight 2 | encapsulation 行の引数 |
encapsulation gre (ipsec と併記) | tunnel-interface 配下 (§3.4) |
low-bandwidth-link | tunnel-interface 配下 |
このうち carrier / preference / weight は、TLOC route の属性として OMP が配る値でもあります (§4.2)。ローカルに書いた値が、そのまま制御平面へ載っていく形になります。ただし配られるところは本ラボでは撮れません (§11)。
max-control-connections と low-bandwidth-link については、本節は意味を断定しません。Command Reference に「(on vEdge routers only)」という注記つきで載っているコマンドで、本ラボが確かめたのは cEdge で受理されることと、6 つのノブを入れた後の show sdwan control local-properties で MAX CNTRL 列と LB 列の値が変わっていることの 2 つだけです。どの列がどのノブで変わったかは切り分けていません (§8.3)。
4. OMP が運ぶもの (※出典)
この節の内容も Cisco 公式資料の記述です。 本ラボは Controller を起動していないため、OMP の経路交換そのものを観測していません (§11)。
4.1 OMP が張られる場所
§1.1 で引いたとおり、OMP のセッションは Controller 同士と、Controller と edge のあいだで張られ、edge 同士では張られません。Design Guide は「The protocol runs between SD-WAN Controllers and between SD-WAN Controllers and WAN Edge routers」と書いており、Controller 同士のあいだでも走ります (Design Guide・逐語)。前節 6-3 §4.3 が引いているのと同じ一文です。
引用の読み方に注意が要ります。 Routing Configuration Guide の「The OMP peering sessions between the centralized controller and the edge devices are exclusively for exchanging control plane traffic」という一文は、そのセッションが «何を運ぶか» を制御平面に限定しているのであって、OMP が «どこに張られるか» を Controller と edge のあいだだけに限定してはいません。
The OMP peering sessions between the centralized controller and the edge devices are exclusively for exchanging control plane traffic. They do not transmit data traffic.
OMP は制御平面専用で、利用者のデータは運びません。データは WAN Edge 同士のトンネルを直接通ります。制御が中央集約でデータが分散するという形は、3-7 Route Reflector で扱った iBGP の反射と同じ発想です。
4.2 運ぶのは 1 種類ではない
BGP の類推でこの protocol を読むと外れる箇所があります。宛先と出口が 1 つの経路に畳まれておらず、別々に配られます。 Design Guide は 3 種類を挙げています。
1 つ目は OMP route (vRoute) で、拠点側の網が持つ宛先を表します (逐語)。
OMP routes advertise attributes such as transport location (TLOC) information, which is similar to a BGP next-hop IP address for the route, and other attributes such as origin, origin metric, originator, preference, site ID, tag, and VPN.
2 つ目は TLOC route で、その宛先へ出ていくための出口を表します (逐語)。
TLOC routes advertise TLOCs connected to the WAN transports, along with an additional set of attributes such as TLOC private and public IP addresses, carrier, preference, site ID, tag, weight, and encryption key information.
ここに carrier / preference / weight が並んでいます。 §3.5 で挙げたローカルのノブが、そのまま TLOC route の属性として配られる値である、という接続です。
3 つ目は service route です (逐語)。
Service routes represent services (firewall, IPS, application optimization, etc.) that are connected to the WAN Edge local-site network
拠点が提供する機能 (ファイアウォールや侵入防御など) がどこに在るかを表し、他の拠点がその機能を経由させたいときに使われます。
4.3 宛先が届いていても、出口が落ちていれば使われない
3 種類に分けたことの帰結が次の 1 行です (Design Guide・逐語)。
An OMP route is only installed in the forwarding table if the TLOC to which it points is active.
OMP route は、指している TLOC が active なときにだけ転送表に載ります。 宛先の情報が届いていても、その出口が有効でなければ経路として使われません。宛先と出口を別々に配る構造は、この判定を成立させるためのものと読めます。
4.4 何が既定で広告されるかは、資料の中で食い違っている
edge がどの経路を OMP へ広告するかは advertise で決まります。この既定について、現行の Cisco 資料の記述が一致していません。しかも食い違いは資料間ではなく、同じ Configuration Guide の内部にあります。
| 資料 / 位置 | 逐語 |
|---|---|
| Routing Configuration Guide — Configure OMP (GUI フィールド “Advertise Ipv4 Connected” の説明) | By default, connected routes are not advertised to OMP. |
| 同 (同一ガイドの CLI 手順) | A Cisco IOS XE Catalyst SD-WAN device advertises connected routes, static routes, OSPF inter-area … to OMP |
| Command Reference — Configuration Commands | Connected routes are advertised by default. |
Command Reference は CLI 手順の側と一致し、GUI フィールドの説明だけが逆を書いています。 ただし CLI 手順の一文は「この機器はこれらの経路を OMP へ広告する」と述べたうえで「advertise コマンドを使って広告させることができる」と続いており、«既定でそうなっている» と明言してはいません。3 者のうちこの 1 本は、他の 2 本ほど強い根拠ではありません。 Command Reference 側の文は「vEdge device or Cisco IOS XE SD-WAN device」と両方を対象に書いているので、「vEdge の話だから食い違いではない」という整理は成立しません。
本ラボではこの食い違いを決着できません。 Controller が居ないため「広告される」ことを観測できないからです。ただし設定の既定値としてどちらが入っているかは実機で撮れます。結果は §9.3 に置きます。
5. OMP の最適経路選択と graceful restart (※出典)
5.1 転送表に載る本数の既定は 4
複数の経路が届いたとき、edge が転送表へ入れる本数には既定があります (Routing Configuration Guide — Configure OMP・逐語)。
By default, a Cisco IOS XE Catalyst SD-WAN device installs a maximum of four unique OMP paths into its route table.
既定で 4 本です。これを変えるのが ecmp-limit で、本ラボでも cEdge に投入して受理されることを確かめています (§9.1)。
5.2 Controller 側が配るパスの本数
edge が受け取る前に、Controller 同士が交換できるパスの本数にも上限があります (Routing Configuration Guide — OMP paths・逐語)。
the limit on the number of OMP paths that can be exchanged between Cisco Catalyst SD-WAN Controllers per VPN per prefix is extended to a maximum of 128
既定の送り方も定義されています (同じ章・逐語)。
The default configuration enables the controllers to send the information of all the paths available up to maximum of 128.
Cisco IOS XE Catalyst SD-WAN Release 17.5.1a 以降、VPN ごと・prefix ごとに最大 128 本で、既定では利用可能なパスを全部送ります。ただしこの 128 は Controller 同士でやり取りする本数で、Controller から edge へ配る本数とは別です。次の段が send-path-limit で、Command Reference の定義は edge 側にも Controller 側にも掛かります (§9 で cEdge に投入して受理されています)。edge が経路表に入れる側は ecmp-limit (既定 4) と、3 段で絞られていきます。send-path-limit の範囲もリリースで変わります — Routing Configuration Guide の Configure OMP のページは Control Components Release 20.8.x の Hierarchical 構成と 20.9.x 以降の任意の構成について「1 から 32 の route-TLOC tuple を edge へ広告できる」と書き、Command Reference は「Range: 1 to 32 routes.」としたうえでそれ以前のリリースでは 1 から 16 だったと添えています。本ラボは Controller が居ないため、この段は観測していません (§11)。
5.3 graceful restart は既定で有効
制御平面が落ちたときの振る舞いは、OMP の graceful restart が決めます (Routing Configuration Guide — OMP graceful restart・逐語)。
When OMP graceful restart is enabled, both Cisco IOS XE Catalyst SD-WAN devices and Cisco Catalyst SD-WAN Controllers cache OMP information received from their peers. This cache includes OMP routes, TLOC routes, service routes, IPsec SA parameters, and centralized data policies.
キャッシュされるのは経路だけではありません。 OMP route・TLOC route・service route に加えて、IPsec SA のパラメータと集中データポリシーまで含まれます。制御が落ちてもデータ平面が動き続けられるのは、鍵とポリシーまで手元に残っているためです。
既定値も明示されています (同ガイドの Configure OMP・逐語)。
Enable graceful restart. By default, the graceful restart for OMP is enabled.
既定で有効です。この既定は本ラボの実機でも running-config に現れます (§9.3)。
6. 冗長の設計 (※出典)
6.1 制御接続は本数で定義されている
6-3 §3.2 では、制御接続の本数が足りない状態に out of equilibrium という名前が付いていることを扱いました。その定義に出てくる本数が、そのまま冗長設計の既定値です (Design Guide・逐語)。
DTLS/TLS connections per transport to each of two Controllers, and 1 OMP session to each of the two Controllers by default
Controller は 2 台が既定で、その 2 台それぞれに対して transport ごとの DTLS/TLS 接続を張り、その 2 台それぞれに OMP セッションを 1 本ずつ張ります。ここで数え方が 2 種類に分かれます。
| 数えるもの | 数 |
|---|---|
| Controller への DTLS/TLS 接続 | Controller 2 台 × transport の本数 |
| Controller との OMP セッション | Controller 2 台 × 1 本 (transport の本数によらない) |
transport を増やすと DTLS/TLS の本数は増えますが、OMP セッションの本数は増えません。 6-3 §3.2 で扱ったとおり、DTLS/TLS が transport の数だけあっても、WAN Edge と 1 台の Controller のあいだの OMP セッションは 1 本です。
また 6-3 §3.2 で引いたとおり、Controller への接続がすべて失われても、WAN Edge は graceful restart のタイマの長さ (既定 12 時間) のあいだ、直前の制御平面情報で動き続けます。制御の冗長が尽きた瞬間に転送が止まる設計ではありません。
6.2 transport の冗長は TLOC の本数で表れる
拠点側の冗長は、transport を何本引くかとそこに何本の TLOC を立てるかで決まります。§3.2 のとおり本数の上限は資料の中で割れていますが、**設計としては「transport を増やす = TLOC が増える = 制御接続も増える」**という連動になります。
ここで §2.4 の restrict が効いてきます。既定は全対全なので、transport を増やすと組み合わせも増えます。 閉域網の色に restrict を付ければ組み合わせは減り、付けなければ公衆網との組み合わせも試みます。冗長を増やす方向と、経路を絞る方向は逆を向いているため、どちらを優先するかがそのまま設計の判断になります。
6.3 BFD は無効化できない
冗長の判定を担うのは BFD です (Design Guide・逐語)。
On Cisco WAN Edge routers, BFD is automatically started between peers and cannot be disabled.
BFD は自動的に開始され、無効化できません。 その役割は 2 つあります (同ガイド・逐語)。
Its purpose is to detect path liveliness and it can also perform quality measurements for application-aware routing, like loss, latency, and jitter.
経路の生存確認に加えて、アプリ認識ルーティングのための品質計測も担います。§3.3 で触れた path MTU discovery も BFD に乗っています。BFD が動くにはトンネルが張れている必要があり、トンネルが張れるには Controller が要ります。 本ラボで BFD セッションを観測できないのは、この連鎖のためです (§11)。
6.4 TLOC extension — 拠点内でもう 1 台へ transport を貸す
拠点に WAN Edge を 2 台置いて、片方にしか無い回線をもう片方にも使わせる構成があります。これを実現するのが tloc-extension です (IOS XE Qualified Command Reference・逐語)。
To bind an interface, which connects to another WAN edge device at the same physical site, to the local device’s WAN transport interface, use the tloc-extension command in the SD-WAN physical interface configuration mode.
同じ物理拠点にあるもう 1 台の WAN Edge へ繋がるインタフェースを、自分の WAN transport インタフェースに結び付けるコマンドです。注目すべきは末尾で、SD-WAN physical interface configuration mode と場所が指定されています。IOS XE 17.x の Systems and Interfaces Configuration Guide にも設定例が載っています (逐語)。
tloc-extension GigabitEthernet1
この「どのモードに在るか」は本ラボで実測できます。 同じコマンドを SD-WAN 側と IOS-XE 側の両方へ投げた結果は §9.2 に置きます。
7. 実機: 非対称な transport 構成で TLOC がどう見えるか (※実測)
ここから §9 までが本ラボの実機出力を扱う節です。 貼った出力は改変していません。省略した箇所には ... を置いています。
7.1 ラボ構成
CML 上に cat-sdwan-edge (C8000v の SD-WAN 版) を 2 台置き、transport 用の中継ノードを 2 つと、管理用のスイッチ・外部接続をつなぎます。2 台は意図的に非対称にしてあります。
| ノード | site ID | system IP | Gi1 (管理) | Gi2 (biz-internet) | Gi3 (mpls) | Lo10 (service VPN 10) | vbond の宛先 |
|---|---|---|---|---|---|---|---|
| cEdge1 | 10 | 10.255.0.1 | 172.16.1.221 | 10.0.12.1/29 | 10.0.13.1/30 | 192.168.10.1/24 | 10.0.12.2 |
| cEdge2 | 20 | 10.255.0.2 | 172.16.1.222 | 10.0.12.2/29 | 結線のみ (IP と tunnel-interface なし) | 192.168.20.1/24 | 10.0.12.1 |
cEdge1 は transport を 2 本、cEdge2 は 1 本持ちます。 拠点ごとに回線構成が違うのは実際の設計で普通に起こることで、同じ出力形式で 2 行と 1 行を並べられるという利点があります。対称にすると差分が出力に現れません。
cEdge2 の Gi3 は mpls セグメントへ結線してありますが、IP も tunnel-interface も置いていません。 結線してある理由は 2 つです。1 つは、リンクの無いインタフェースがゲスト OS に列挙されないことがあり、そうなると「コマンドが拒否された」のか「インタフェースが無い」のかを区別できなくなるためです。もう 1 つは、物理があっても tunnel-interface を置かなければ TLOC は立たないことを、正の出力で示せるためです (§7.6)。
service VPN 10 (Lo10) は両機に作ってありますが、本節では扱いません。 作る手順と Routing Table: 10 の見え方は 6-3 §9 と同じ VRF 番号・同じインタフェース名・同じアドレスで、内容が重複するためです。本節がこれを用意したのは、OMP が広告する対象になる接続経路を機器に持たせるためです。
vbond の宛先は 6-3 と同じく、対向の cEdge を指しています。到達はしますが、そこで待ち受けている Validator は居ません。本節は制御接続そのものを主題にしていないため、この宛先の扱いは 6-3 §8 の結論をそのまま引き継ぎます。
7.2 control components を起動していない理由
理由は 3 つで、それぞれ効く範囲が違います。 6-3 §6.2 と同じ整理をそのまま継承します。
この項だけは、機器の出力ではありません。 下の表に出てくる資源の値 (vCPU 数・data volume・空き容量) は、 ラボを組んだ環境の側で測った値と、構成をどこまでにするかという判断です。§7 の他の項が機器の出力を貼っているのに対し、 ここは「なぜその構成にしたか」の説明であり、出所が違います。 6-3 §6 も同じ断りを置いています。
| # | 理由 | どこまで効くか |
|---|---|---|
| ① | SD-WAN Manager の node definition が要求する資源が、本ラボの CML の空きを超える (8 vCPU は CML 仮想マシンの全量、data volume 256GB に対して空きは 51.4GB) | Manager だけ |
| ② | edge の bootstrap には、PnP Connect ポータル由来の認可済シリアル一覧が要る | 全 edge |
| ③ | 本ラボが cEdge 単体の縮小構成というスコープを選んだ (人間の判断) | Controller と Validator |
SD-WAN Controller と SD-WAN Validator は 4096MB / 2 vCPU で、資源の面では起動できます。「CML に無いから」も「資源が足りないから」も、この 2 種については当てはまりません。②の根拠となる資料の逐語は 6-3 §6.2 に載せてあります。
この選択の帰結が §1.1 の宣言です。OMP の経路交換と SLA 判定は、撮らなかったのではなく、この構成では成立しません。
7.3 実機の前提を測る
設定を書く前に、機種・リリース・インタフェース・既定の VRF・時刻を確定させます。
! ===== [cEdge1] show version ===== (抜粋)
show version
Cisco IOS XE Software, Version 17.16.01a
Cisco IOS Software [IOSXE], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 17.16.1a, RELEASE SOFTWARE (fc1)
...
Technology Package License Information:
Controller-managed
...
cisco C8000V (VXE) processor (revision VXE) with 1889922K/3075K bytes of memory.
Processor board ID 9C5D1T2Z1J6
Router operating mode: Controller-Managed
3 Gigabit Ethernet interfaces! ===== [cEdge1] show sdwan version =====
show sdwan version
17.16.01a.0.1625
cEdge1#! ===== [cEdge1] show ip interface brief =====
show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 172.16.1.221 YES other up up
GigabitEthernet2 unassigned YES unset up up
GigabitEthernet3 unassigned YES unset up up
Loopback65528 192.168.1.1 YES other up up
Loopback65529 unassigned YES unset up up
cEdge1#! ===== [cEdge1] show vrf =====
show vrf
Name Default RD Protocols Interfaces
65528 <not set> ipv4 Lo65528
65529 <not set> ipv4 Lo65529
cEdge1#! ===== [cEdge1] show clock =====
show clock
*08:48:55.344 UTC Sun Aug 30 2026
cEdge1#5 つの出力から、本節が前提として置く事実が確定します。
| 確定した前提 | 根拠にした出力 |
|---|---|
リリースは 17.16.01a、動作モードは Controller-Managed | show version / show sdwan version |
| 物理は Gi1 / Gi2 / Gi3 の 3 本で、いずれも up/up | show ip interface brief |
| 管理アドレス 172.16.1.221 は Gi1 = VPN 0 (グローバル表) に載っている | 同上 |
既定の VRF は内部用の 65528 / 65529 だけで、Mgmt-intf は無い | show vrf |
時刻は 未同期 (先頭の *) | show clock |
Mgmt-intf VRF が無いことは 6-3 の実測と一致します。 その帰結として、本ラボの管理アドレスは VPN 512 ではなく VPN 0 に置かれています。時刻が未同期であることは、6-3 §11 で扱ったとおり証明書の検証に効く前提ですが、本ラボは証明書を持たないため、時刻を合わせた場合との差は確かめていません。
cEdge2 側もおおむね同じ形ですが、2 か所違います。1 つは vmanage_system で、cEdge2 には現れていて cEdge1 には現れていません。もう 1 つは Last reload reason で、cEdge1 は system report を伴う再起動、cEdge2 は factory-reset です。 cEdge1 のこの出力は uptime is 0 minutes、cEdge2 は uptime is 7 minutes の時点で撮ったもので、初期化が終わり切る前に撮った可能性があります。前節 6-3 §6.3 は vmanage_system が何も設定していない状態で既に立つことを実機で示しており、本節の cEdge1 の出力はそれと食い違って見えます。どちらが正しいかを本ラボは確かめていません (§11)。Gi3 が up/up で見えていることが、この後の §7.6 の前提になります。
! ===== [cEdge2] show ip interface brief =====
show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 172.16.1.222 YES other up up
GigabitEthernet2 unassigned YES unset up up
GigabitEthernet3 unassigned YES unset up up
vmanage_system unassigned YES unset up up
Loopback65528 192.168.1.1 YES other up up
Loopback65529 unassigned YES unset up up
cEdge2#7.4 参加前の基準線 — TLOC が 0 本の状態
設定を入れる前に show sdwan control local-properties を撮っておきます。
! ===== [cEdge1] show sdwan control local-properties ===== (抜粋)
show sdwan control local-properties
personality vedge
...
tls-port 0
system-ip 0.0.0.0
chassis-num/unique-id C8K
...
mrf-management-region no
number-vbond-peers 0
number-active-wan-interfaces 0
cEdge1#number-active-wan-interfaces が 0 で、TLOC の表そのものが印字されていません。この出力は比較のための基準線として置くだけで、本節はここに主張を負わせません。 「表が空である」ことは証拠として弱く、機器が印字した正の行 (§7.5 以降の 1 と 2) に主張を負わせます。
7.5 身元と 1 本目の transport を与える
投入は 2 段階に分けます。順序の理由は 6-3 §7.2 で扱ったとおりで、SD-WAN 側の tunnel-interface は IOS-XE 側の interface TunnelN が先に存在していないと参照できません。第 1 コミットで身元と物理インタフェースを入れます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
system
system-ip 10.255.0.1
site-id 10
organization-name chillarin-sdwan-lab
vbond 10.0.12.2
exit
interface GigabitEthernet2
ip address 10.0.12.1 255.255.255.248
no shutdown
exit
...
! ===== [cEdge1] 投入時の機器応答（逐語）=====
config-transaction
...
cEdge1(config)# commit
Commit complete.第 2 コミットで IOS-XE 側のトンネルと SD-WAN 側の tunnel-interface を入れます。color を与えるのはここです。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
interface Tunnel2
no shutdown
ip unnumbered GigabitEthernet2
tunnel source GigabitEthernet2
tunnel mode sdwan
exit
sdwan
interface GigabitEthernet2
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
exit
exit
exit
...
! ===== [cEdge1] 投入時の機器応答（逐語）=====
config-transaction
...
cEdge1(config)# commit
Commit complete.投入後の show sdwan control local-properties に TLOC の行が 1 本現れます。この節で列の名前を一度だけ全部出しておきます。 §7.6 以降は同じ表の抜粋を使います。
! ===== [cEdge1] show sdwan control local-properties ===== (抜粋)
show sdwan control local-properties
...
INDEX IP PORT
----------------------------------------------------
...
number-active-wan-interfaces 1
NAT TYPE: E -- indicates End-point independent mapping
A -- indicates Address-port dependent mapping
N -- indicates Not learned
Note: Requires minimum two vbonds to learn the NAT type
PUBLIC PUBLIC PRIVATE PRIVATE PRIVATE WAN MAX RESTRICT/ LAST SPI TIME NAT VM BIND
INTERFACE IPv4 PORT IPv4 IPv6 PORT VS/VM COLOR STATE CNTRL CONTROL/ LR/LB CONNECTION REMAINING TYPE CON REG INTERFACE
STUN PRF IDs
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
GigabitEthernet2 10.0.12.1 12366 10.0.12.1 :: 12366 0/0 biz-internet up 2 no/yes/no No/No 0:00:00:14 0:11:54:40 N 5 Default N/A
cEdge1#number-active-wan-interfaces が 1 になり、GigabitEthernet2 の行が 1 本立ちます。 COLOR 列に biz-internet が入り、WAN STATE が up、MAX CNTRL が 2、RESTRICT/CONTROL/STUN が no/yes/no、LR/LB が No/No です。この既定値が、§8 でノブを入れたときの比較対象になります。
同じ状態を SD-WAN の設定側からも見ておきます。
! ===== [cEdge1] show sdwan running-config sdwan ===== (抜粋)
show sdwan running-config sdwan
sdwan
interface GigabitEthernet2
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service all
...
no allow-service bfd
exit
exit
appqoeallow-service all の 1 行は、個別の許可・不許可の一覧に展開されて残ります (中略した部分にその一覧が並びます)。この展開そのものは 6-3 §11 で扱いました。本節が使うのは、encapsulation と color がこのブロックに並ぶという形の方です (§8)。
7.6 2 本目の transport を cEdge1 だけに足す
cEdge1 に Gi3 を足し、color mpls の tunnel-interface を置きます。cEdge2 には何もしません。 手順は §7.5 と同じ 2 段階です。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
interface GigabitEthernet3
ip address 10.0.13.1 255.255.255.252
no shutdown
exit
...
! ===== [cEdge1] 投入時の機器応答（逐語）=====
config-transaction
...
cEdge1(config)# commit
Commit complete.! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
interface Tunnel3
no shutdown
ip unnumbered GigabitEthernet3
tunnel source GigabitEthernet3
tunnel mode sdwan
exit
sdwan
interface GigabitEthernet3
tunnel-interface
encapsulation ipsec
color mpls
allow-service all
exit
exit
exit
...
! ===== [cEdge1] 投入時の機器応答（逐語）=====
config-transaction
...
cEdge1(config)# commit
Commit complete.同じコマンドの出力が 2 行になります。 列見出しは §7.5 と同じなので中略します。
! ===== [cEdge1] show sdwan control local-properties ===== (抜粋・列見出しは §7.5 と同じ)
show sdwan control local-properties
...
number-active-wan-interfaces 2
...
GigabitEthernet2 10.0.12.1 12386 10.0.12.1 :: 12386 0/0 biz-internet up 2 no/yes/no No/No 0:00:00:10 0:11:50:44 N 5 Default N/A
GigabitEthernet3 10.0.13.1 12366 10.0.13.1 :: 12366 0/0 mpls up 2 no/yes/no No/No 0:00:00:14 0:11:50:44 N 5 Default N/A number-active-wan-interfaces が 2 になり、GigabitEthernet2 と GigabitEthernet3 の 2 行が並びます。 COLOR 列はそれぞれ biz-internet と mpls です。§3.1 の 3 つ組に当てはめると、system IP は 2 行とも 10.255.0.1 で共通、encapsulation も投入した config のとおり両方 IPsec で、違うのは color だけです。§2.3 の「同じ color を 1 台で 2 回は使えない」という制約が、この 2 行を区別している唯一の要素になります。
同じ時点で cEdge2 を撮ると、1 行のままです。
! ===== [cEdge2] show sdwan control local-properties ===== (抜粋・列見出しは §7.5 と同じ)
show sdwan control local-properties
...
number-active-wan-interfaces 1
...
GigabitEthernet2 10.0.12.2 12366 10.0.12.2 :: 12366 0/0 biz-internet up 2 no/yes/no No/No 0:00:00:12 0:11:44:46 N 5 Default N/A cEdge2 の Gi3 は §7.3 のとおり up/up で存在していますが、TLOC は 1 本のままです。 tunnel-interface を置いていないためです。「物理リンクがある」ことと「TLOC が立つ」ことは別で、この主張は number-active-wan-interfaces 1 という正の出力で示せます。transport を数えるときの単位は、回線の本数ではなく tunnel-interface を置いた本数になります。
8. 実機: 設計ノブを入れると出力のどこが変わるか (※実測)
§3.5 で挙げた 6 つのノブを、1 つずつ別のトランザクションで投入します。狙いは受理されることの確認ではなく、投入後に出力のどの列が変わるかを撮ることです。比較の基準は §7.6 の出力です。
8.1 投入した 6 つ
1 つ目は restrict です。Gi3 (mpls) に付けます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet3
tunnel-interface
color mpls restrict
exit
exit
exit
...
! ===== [cEdge1] 投入時の機器応答（逐語）=====
config-transaction
...
cEdge1(config)# commit
Commit complete.2 つ目は max-control-connections 0 で、同じく Gi3 に付けます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet3
tunnel-interface
max-control-connections 0
exit
exit
exit
...
cEdge1(config)# commit
Commit complete.3 つ目の carrier carrier1 から 5 つ目までは Gi2 (biz-internet) に付けます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet2
tunnel-interface
carrier carrier1
exit
exit
exit
...
cEdge1(config)# commit
Commit complete.! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet2
tunnel-interface
encapsulation ipsec preference 100 weight 2
exit
exit
exit
...
cEdge1(config)# commit
Commit complete.! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet2
tunnel-interface
encapsulation gre
exit
exit
exit
...
cEdge1(config)# commit
Commit complete.6 つ目の low-bandwidth-link は Gi3 に戻ります。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet3
tunnel-interface
low-bandwidth-link
exit
exit
exit
...
cEdge1(config)# commit
Commit complete.6 つとも Commit complete. で受理されました。 受理されたこと自体は §9 の主題につながります。ここで見たいのは次の段です。
8.2 running-config には 6 つとも残る
まず SD-WAN の設定側を撮ります。
! ===== [cEdge1] show sdwan running-config sdwan ===== (抜粋)
show sdwan running-config sdwan
sdwan
interface GigabitEthernet2
tunnel-interface
encapsulation gre
encapsulation ipsec preference 100 weight 2
color biz-internet
carrier carrier1
...
no allow-service bfd
exit
exit
interface GigabitEthernet3
tunnel-interface
encapsulation ipsec
color mpls restrict
low-bandwidth-link
max-control-connections 0
...
no allow-service snmp
no allow-service bfd
exit
exitGi2 の tunnel-interface に encapsulation が 2 行並んでいます。 §3.4 で引いた「同じ tunnel-interface の下に 2 つ書ける」という記述が、この機体で実際にそう書けることを確認できました。preference 100 weight 2 は encapsulation ipsec の引数として同じ行に載り、carrier carrier1 は独立した行として残ります。
Gi3 側には color mpls restrict / low-bandwidth-link / max-control-connections 0 の 3 つが並びます。restrict は独立したコマンドではなく、color 行の引数として保存されます。
8.3 local-properties の列は 3 つだけ変わる
同じノードで show sdwan control local-properties を撮り直します。
! ===== [cEdge1] show sdwan control local-properties ===== (抜粋)
show sdwan control local-properties
...
number-active-wan-interfaces 2
...
INTERFACE IPv4 PORT IPv4 IPv6 PORT VS/VM COLOR STATE CNTRL CONTROL/ LR/LB CONNECTION REMAINING TYPE CON REG INTERFACE
STUN PRF IDs
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
GigabitEthernet2 10.0.12.1 12406 10.0.12.1 :: 12406 0/0 biz-internet up 2 no/yes/no No/No 0:00:00:08 0:11:59:08 N 5 Default N/A
GigabitEthernet3 10.0.13.1 12366 10.0.13.1 :: 12366 0/0 mpls up 0 yes/ no/no No/Yes 0:00:02:26 0:11:57:35 N 5 Default N/A §7.6 の Phase C と比べると、設定に対応して変わったのは Gi3 の行の 3 列です (ポート番号や経過時間の列も動いていますが、これは設定とは無関係に変動する列です。§12)。
| 投入したノブ | Phase C | Phase D | 出た場所 |
|---|---|---|---|
color mpls restrict | RESTRICT/CONTROL/STUN が no/yes/no | yes/ no/no | local-properties の列 |
max-control-connections 0 | MAX CNTRL が 2 | 0 | local-properties の列 |
low-bandwidth-link | LR/LB が No/No | No/Yes | local-properties の列 |
carrier carrier1 | — | — | running-config のみ |
encapsulation ipsec preference 100 weight 2 | — | — | running-config のみ |
encapsulation gre | — | — | running-config のみ |
ここで正確に書いておきます。本ラボは 6 つのノブを 1 つずつ別のトランザクションで投入しましたが、show sdwan control local-properties を撮ったのは 6 つすべてを入れ終えた後の 1 回だけです。 したがって上の表は、「この 3 列が変わった」ことと「この 3 つのノブを入れた」ことを並べたものであり、どの列がどのノブによって変わったかを 1 つずつ切り分けた結果ではありません。 列名とノブ名の対応から素直に読めば restrict → RESTRICT 列、max-control-connections 0 → MAX CNTRL 列、low-bandwidth-link → LB 列ですが、本ラボはそれを測っていません。 とくに RESTRICT/CONTROL/STUN の 3 つ組のうち中央の CONTROL が yes から no へ変わった点は、max-control-connections 0 の効果と読むほうが自然で、restrict が CONTROL を落とすとは出典にも書かれていません。残る 3 つのノブ (carrier / preference と weight / GRE の追加) は、この表のどの列にも現れませんでした。
下の 3 つが「列に現れない」のは、印字されている列見出しの一覧に該当する列が無いためです。 見出し行は上の出力に逐語で残っています。これはノブが効いていないという意味ではありません。 §4.2 のとおり carrier / preference / weight は TLOC route の属性として配られる値で、配られる先を持たない本ラボでは、running-config に入ったところまでしか観測できません。
8.4 encapsulation を 2 つ書いても、この出力では 1 行のまま
§3.4 の記述に照らして確かめたいことが 1 つ残ります。encapsulation を 2 つ書いたとき、TLOC は 2 本になるのかです。
number-active-wan-interfaces は 2 のままで、これは Gi2 と Gi3 というインタフェース 2 本を数えた値です。したがって、この出力からは「encapsulation を 2 つ書いたことで TLOC が 2 本に増えたかどうか」は分かりません。 本節はこれを確かめていない項目として §11 に置きます。確認していないことを、確認したように書かないためです。
9. 実機: どの構文が受理され、どの構文が拒否されるか (※実測)
§4〜§6 で扱った OMP と冗長の設計は、本ラボでは動作を観測できません。動作の代わりに観測できるのは、その設定がこの機体に存在するかどうかです。1 候補 = 1 トランザクションで 12 個の構文を投入し、機器の応答を逐語で保存しました。
| 候補 | 結果 |
|---|---|
sdwan > omp > graceful-restart | 受理 |
sdwan > omp > send-path-limit 8 | 受理 |
sdwan > omp > timers > holdtime 60 | 受理 |
sdwan > omp > ecmp-limit 8 | 受理 |
sdwan > omp > address-family ipv4 > advertise connected | 構文は通る (既定で入っているため差分なし) |
sdwan > omp > advertise connected (flat) | 拒否 |
sdwan > interface Gi3 > tloc-extension Gi2 | 受理 |
IOS-XE 側 interface Gi3 > tloc-extension Gi2 | 拒否 |
IOS-XE native class-map / policy-map | 受理 |
policy > app-visibility / flow-visibility | 受理 |
policy > class-map > class VOICE queue 0 | 受理 |
policy > sla-class GOLD | 拒否 |
この表の値打ちは、受理と拒否の対にあります。 受理だけを並べても「他の形も通るかもしれない」で終わります。同じ意味の 2 つの書き方で片方だけが通る組が 2 つ (OMP の階層・tloc-extension の置き場所)、別のコマンド同士を並べて語彙の在処を示す組が 1 つ (policy 配下の class-map と sla-class) あります。
なお、以下に貼る応答の逐語では、接続直後の 1 行と、その行に混ざる端末制御文字を中略しています。
9.1 OMP の階層は address-family の下にある
ecmp-limit は §5.1 で扱った既定 4 本を変えるコマンドです。cEdge で受理されます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
omp
ecmp-limit 8
exit
exit
...
cEdge1(config-sdwan)# omp
cEdge1(config-omp)# ecmp-limit 8
...
cEdge1(config)# commit
Commit complete.advertise connected は 2 通りの書き方で試します。1 つ目は address-family ipv4 の下に置く形です。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
omp
address-family ipv4
advertise connected
exit
exit
exit
...
cEdge1(config-sdwan)# omp
cEdge1(config-omp)# address-family ipv4
cEdge1(config-ipv4)# advertise connected
...
cEdge1(config)# commit
% No modifications to commit.syntax error は出ず、% No modifications to commit. が返ります。 構文としては受け付けられ、投入した内容が既に入っていたため差分が生じなかったという応答です。この点は §9.3 で running-config と突き合わせます。
2 つ目は omp の直下に置く形です。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
omp
advertise connected
exit
exit
...
cEdge1(config-sdwan)# omp
cEdge1(config-omp)# advertise connected
----------------------^
syntax error: unknown command
...
cEdge1(config)# commit
% No modifications to commit.syntax error: unknown command で拒否されます。 キャレットは advertise の位置を指しています。この 2 つを対にすると、この機体の OMP の階層は sdwan > omp > address-family ipv4 > advertise ... であり、omp の直下に置く形は存在しないと言えます。§4.4 で引いた Routing Configuration Guide の CLI 手順が示す階層と一致します。
9.2 tloc-extension は SD-WAN 側のインタフェース設定モードにだけ在る
§6.4 の逐語は「SD-WAN physical interface configuration mode」と場所を指定していました。同じコマンドを 2 つのモードへ投げて確かめます。 SD-WAN 側は受理されます。
! ===== [cEdge2] config-transaction で投入した行 ===== (逐語・... は中略)
sdwan
interface GigabitEthernet3
tloc-extension GigabitEthernet2
exit
exit
...
cEdge2(config-sdwan)# interface GigabitEthernet3
cEdge2(config-interface-GigabitEthernet3)# tloc-extension GigabitEthernet2
...
cEdge2(config)# commit
Commit complete.IOS-XE 側の interface 配下に同じ行を置くと拒否されます。
! ===== [cEdge2] config-transaction で投入した行 ===== (逐語・... は中略)
interface GigabitEthernet3
tloc-extension GigabitEthernet2
exit
...
cEdge2(config-if)# tloc-extension GigabitEthernet2
--------------------^
syntax error: unknown command
...
cEdge2(config)# commit
% No modifications to commit.同じ機体・同じインタフェース番号・同じ引数で、モードだけが違います。 §6.4 の逐語にある «SD-WAN» の一語が、ここで効いています。なお本ラボが確かめたのは構文の在り処だけで、拠点内のもう 1 台へ transport を貸す動作は観測していません (§11)。
9.3 OMP の既定は running-config に見える
§4.4 で扱った「advertise connected の既定はどちらか」という食い違いに、実機の側から 1 つだけ材料を出せます。設定を何も入れていない状態から、この機体の running-config には OMP のブロックが入っています。 なお下に貼った出力は設定を入れた後 (Phase D) に撮った show sdwan running-config sdwan ですが、設定前 (Phase A) に撮った show sdwan running-config の OMP ブロックと同じ内容であることを確認しています。
! ===== [cEdge1] show sdwan running-config sdwan ===== (抜粋: omp ブロック)
show sdwan running-config sdwan
...
omp
no shutdown
graceful-restart
no as-dot-notation
address-family ipv4
advertise connected
advertise static
!
address-family ipv6
advertise connected
advertise static
!
!
!読めることが 2 つあります。
1 つ目は graceful-restart が既定で入っていることです。 §5.3 で引いた「By default, the graceful restart for OMP is enabled」と一致します。
2 つ目は advertise connected が既定で入っていることです。 §4.4 の 3 つの記述のうち、Command Reference と CLI 手順の側に一致し、GUI フィールドの説明とは食い違います。 §9.1 の % No modifications to commit. も同じ側を指しています。同じ行を投入しても差分が出なかったのは、既に入っていたからです。
ただし、この観測が言えることには限界が 3 つあります。
| 限界 | 内容 |
|---|---|
| ① | これは設定の既定値であって、経路が実際に広告されることの証拠ではない。Controller が居ないため広告そのものは観測していない |
| ② | 1 機種・1 リリース (C8000v / 17.16.01a) の観測であり、他のリリースで同じとは限らない |
| ③ | §4.4 の GUI フィールドの説明は、テンプレートのチェックボックスの既定を述べている可能性がある。その場合、記述は食い違っていないことになるが、本ラボは Manager を起動していないので確かめられない |
したがって §4.4 の食い違いは、本節では決着しません。 3 つの記述を資料名つきで並べたうえで、利用するリリースの資料で確認する扱いに留めます。
9.4 集中ポリシーを 書く 階層は edge に無い (ただし SLA class 自体は edge に配られる)
Policies Configuration Guide は、ポリシーを Localized Policy と Centralized Policy の 2 つの章に分けています。この区分が機器の CLI にそのまま現れるかを、4 つの候補で確かめます。
IOS-XE 本来の class-map / policy-map は受理されます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
class-map match-any VOICE
match dscp ef
exit
policy-map QOS-6-4
class VOICE
priority level 1
exit
exit
...
cEdge1(config-pmap-c)# priority level 1
cEdge1(config-pmap-c)# exit
cEdge1(config-pmap)# exit
cEdge1(config)# commit
Commit complete.policy 直下の可視化の設定も受理されます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
policy
app-visibility
flow-visibility
exit
...
cEdge1(config-policy)# app-visibility
cEdge1(config-policy)# flow-visibility
...
cEdge1(config)# commit
Commit complete.policy > class-map は、vEdge 側の語彙として資料に現れる書き方です。これも受理されます。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
policy
class-map
class VOICE queue 0
exit
exit
...
cEdge1(config-policy)# class-map
cEdge1(config-class-map)# class VOICE queue 0
...
cEdge1(config)# commit
Commit complete.一方、SLA class は拒否されます。§10 で扱うとおり、これは Controller 側の階層に置かれるものです。
! ===== [cEdge1] config-transaction で投入した行 ===== (逐語・... は中略)
policy
sla-class GOLD
latency 50
loss 2
exit
exit
...
cEdge1(config-policy)# sla-class GOLD
------------------------^
syntax error: unknown command
cEdge1(config-policy)# latency 50
-------------------------^
syntax error: unknown command
cEdge1(config-policy)# loss 2
-------------------------^
syntax error: unknown commandsla-class の行でキャレットが立ち、続く latency と loss も同じ理由で拒否されます。 sla-class のモードに入れなかったため、2 行目以降は (config-policy)# のまま解釈されています。
投入後に SD-WAN 側の policy ブロックを撮ると、policy 配下へ入れた 3 つが残っています。
! ===== [cEdge1] show sdwan running-config policy =====
show sdwan running-config policy
policy
app-visibility
flow-visibility
class-map
class VOICE queue 0
!
!
cEdge1#app-visibility / flow-visibility / class-map の 3 つが正の出力として並びます。 IOS-XE 本来の class-map / policy-map はこの出力ではなく IOS-XE 側の running-config に入ります (§12 に出力を置いています)。
sla-class はこの出力に現れませんが、拒否の根拠はこの不在ではなく、上の syntax error: unknown command の 3 行です。 §10 で引く Policies Configuration Guide の「SLA class は Controller の階層に置く」という記述と整合します。
ただし、ここを「edge に SLA class は無い」と読むと外れます。 同じ Policies Configuration Guide は、SLA class の対応数を「Cisco SD-WAN Controller and SD-WAN Edge devices」について述べ、「Maximum SLA Classes Supported on Cisco IOS XE Catalyst SD-WAN Devices」という表を持ち、IOS XE 機での show sdwan policy from-vsmart の出力に from-vsmart sla-class の行を載せています。edge に無いのは「SLA class を書く設定階層」であって、SLA class そのものは Controller から配られて edge に存在します。 本ラボが確かめたのは前者だけです。書く場所と効く場所が別であるというのが、集中ポリシーの形です。
9.5 「(on vEdge routers only)」の注記は、当てにもならず、無視もできない
Command Reference の設定コマンド一覧には、コマンドによって 「(on vEdge routers only)」 という注記が付いています。本ラボは、この注記が付いたコマンドのうち 5 つを下の表で追跡しました。結果は 4 つが受理され、1 つが拒否されました。なお表に挙げた 5 つのほかにも、color と tloc-extension に同じ注記が付いており、どちらも本ラボで受理されています (§7.5 / §9.2)。受理された側は少なくとも 6 つあります。
| コマンド | 注記 | 本ラボの cEdge での結果 |
|---|---|---|
low-bandwidth-link | (on vEdge routers only) | Commit complete. (§8.1) |
max-control-connections | (on vEdge routers only) | Commit complete. (§8.1) |
encapsulation ... weight | (on vEdge routers only) | Commit complete. (§8.1) |
ecmp-limit | (on vEdge routers only) | Commit complete. (§9.1) |
advertise (bgp | connected | ...) (flat 形) | (on vEdge routers only) | syntax error: unknown command (§9.1) |
注記を「cEdge では使えない」と読むと、表の 4 件はいずれも外れます (表の外の color と tloc-extension を含めれば 6 件)。 IOS XE SD-WAN で使えるかどうかは、IOS XE 向けの Configuration Guide か Qualified Command Reference で確かめるのが確実です。§6.4 の tloc-extension はその例で、同じ注記が付いていながら IOS XE 17.x のガイドが cEdge の設定例を載せており、本ラボでも受理されました (§9.2)。
ただしこの 1 件も、注記が当たったのは「階層の形」についてだけです。advertise connected という機能そのものは cEdge にも既定で在り (§9.3)、無いのは omp 直下に直接書く形だけです。したがって、注記を「cEdge では使えない」と読むと 4 回外れ、5 件目も «機能が使えない» という意味では外れます。それでも「注記は無視してよい」と読むのは誤りです。注記は判断の材料にはなりますが、単独では決められません。受理できるかどうかは、使うリリースの実機で確かめるほかありません。
10. アプリ認識ルーティングの位置づけ (※出典)
この節は Cisco 公式資料の記述で、概要に留めます。 本ラボは判定に必要な計測基盤を持たないため、動作を観測していません (§11)。
10.1 AAR が見ているもの
アプリ認識ルーティング (AAR / Application-Aware Routing) は、アプリケーションごとに出口を選び分ける仕組みです。Policies Configuration Guide の定義は次のとおりです (逐語)。
Application-aware routing tracks network and path characteristics of the data plane tunnels between Cisco IOS XE Catalyst SD-WAN devices and uses the collected information to compute optimal paths for data traffic. These characteristics include packet loss, latency, and jitter.
見ているのは packet loss・latency・jitter の 3 つです。5-1 QoS の必要性と 3 モデル で扱った 4 指標のうち、帯域を除く 3 つがそのまま並びます。QoS が 1 本の回線の中で順番と配分を決めるのに対し、AAR はどの回線へ出すかを決めます。
10.2 判定の土台は BFD にある
計測を担うのは §6.3 で引いた BFD です。BFD は自動的に開始され無効化できず、経路の生存確認に加えて loss / latency / jitter の品質計測も行います。 つまり AAR の判定は BFD の計測に乗っており、BFD が動くにはトンネルが張れている必要があります。
本ラボが AAR を出典層でしか書けない理由がここにあります。 Controller が居ないためトンネルが張れず、BFD が動かず、計測値が生まれません。この連鎖のどこも「撮り忘れ」ではありません。
10.3 SLA class は Controller 側の階層に置く
AAR の判定基準は SLA class として定義します。置き場所は明示されています (Policies Configuration Guide・逐語)。
You can configure SLA classes under the policy sla-class command hierarchy on Cisco SD-WAN Controllers.
SD-WAN Controller の policy sla-class の階層です。§9.4 で cEdge に policy > sla-class GOLD を投げて syntax error: unknown command になったことは、この記述と整合します。設定を書く場所が edge ではなく Controller だからです。
SLA class の個数の上限は、リリースと対象機器によって違います。 Policies Configuration Guide の feature history には 8 / 6 / 16 という値が、それぞれ「Cisco SD-WAN Controller で」「Cisco IOS XE 機でポリシーあたり」「Cisco IOS XE 機で」と対象を明記して並んでいます (4 は 17.2.1r より前の値です)。これは §3.2 の TLOC 本数のような «同じ対象について資料が食い違っている» 状態ではなく、対象とリリースが違えば値も違うという書き分けです。 使用するリリースと機器に対応する値を読む必要があります。
10.4 掘り下げは 6-8 で扱う
経路の品質を測って出口を選ぶ仕組みは、Cisco の製品系列では PfR (Performance Routing) としても実装されています。AAR と PfR の対比、および測定値から経路が切り替わるまでの詳細は 6-8 で扱います。 本節が扱ったのは、AAR が BFD の計測に乗っていることと、その設定が Controller 側に置かれることの 2 点です。
11. 本ラボで確かめていないこと
本ラボが実機で確かめたのは §7〜§9 の範囲です。それ以外は出典の記述であり、次の各項は実測していません。
- BFD セッション。 Controller が居ないため張れません。したがって次の 2 つも観測していません。
restrictの効果 (どの TLOC 同士がセッションを張るか)。観測したのは設定が受理されることと、6 つのノブ投入後に RESTRICT 列の値が変わっていたことだけです。どの列がどのノブで変わったかの切り分けも行っていません (§8.3)- AAR の SLA 判定 (loss / latency / jitter による経路選択)
- OMP の経路交換。 §4 で扱った 3 種類の経路がどう配られるかは確かめていません。
advertise connectedが既定で入っていることは撮れましたが、それが実際に経路を運ぶかは観測していません (§9.3)。 carrier/preference/weightの効き方。 running-config に入ることは確認しましたが (§8.2)、これらは TLOC route の属性として配られて初めて意味を持つ値です。encapsulationを 2 つ書いたときに TLOC が 2 本になるか。 §8.4 のとおり、number-active-wan-interfacesはインタフェースの本数を数えた値なので、この出力からは判定できません。- TLOC 本数の上限。 本ラボは 2 本までしか立てていません。§3.2 の 4 と 8 の食い違いは、本ラボでは決着しません。
tloc-extensionの動作。 設定が受理されること (§9.2) だけを確かめました。拠点内の 2 台目へ transport を貸す動きは観測していません。- TLOC が立たない理由の切り分け。 §7.6 で cEdge2 の Gi3 に TLOC が立たないことを撮りましたが、この Gi3 は
tunnel-interfaceを置いていないだけでなく IP アドレスも設定していません。したがって「tunnel-interfaceが無いから立たない」と「IP が無いから立たない」の切り分けはできていません。 - 同一 site ID の挙動。 site 10 と 20 に分けており、揃えた場合は試していません。
- Controller 側のパス上限 128 と ECMP の実際の本数。 §5 の数値はいずれも出典の記述で、動作を観測していません。
- 制御接続の本数と out of equilibrium。 §6.1 の既定値は出典の記述です。本ラボは Controller を 1 台も起動していないため、本数が揃った状態を作れません。
- 時刻を合わせた場合との差。 §7.3 のとおり本ラボの機体は未同期のままで、証明書を持たないため比較対象がありません。
12. 落とし穴・補足
show sdwan running-config sdwan ompというコマンドの形はありません。 OMP のブロックだけを絞り込もうとすると弾かれます。omp ブロックはshow sdwan running-config sdwanの出力の中に含まれています (§9.3 はそこから抜粋しています)。
! ===== [cEdge1] show sdwan running-config sdwan omp =====
show sdwan running-config sdwan omp
^
% Invalid input detected at '^' marker.
cEdge1#show sdwan control local-propertiesの PUBLIC PORT は撮るたびに変わります。 本ラボの出力では Gi2 が 12366 → 12386 → 12406 と動いています。同じ出力のport-hoppedがTRUEになっており、本節はこの値に主張を負わせていません。 列を横に読み比べるときは、ポート番号と時間の列が変動することを前提にしてください。拒否の直後は、投入していた設定モードから出てしまうことがあります。 §9.4 の
sla-classの候補では、拒否のあとに続く 2 つのexitが(config-policy)→(config)→ 特権 EXEC とモードを 2 段戻したため、その後に送ったcommitとendが特権 EXEC のコマンドとして解釈されました。
cEdge1(config-policy)# exit
cEdge1(config)# exit
cEdge1#commit
% Bad IP address or host name% Unknown command or computer name, or unable to find computer address
cEdge1#end
% Bad IP address or host name% Unknown command or computer name, or unable to find computer address
cEdge1#% Bad IP address or host name は sla-class の拒否とは別の事象です。 特権 EXEC の commit / end が解決できないホスト名として扱われた結果で、機器が sla-class について述べたことではありません。 拒否の証拠は syntax error: unknown command の 3 行だけです。
- 出力が空でも「無い」ことの証拠にはなりません。 本ラボの取得では、
show running-config | section class-mapの結果が次のコマンドのヘッダより後に現れています。
! ===== [cEdge1] show running-config | section class-map =====
show running-config | section class-map
! ===== [cEdge1] show running-config | section policy-map =====
class-map match-any VOICE
match dscp ef
cEdge1#show running-config | section policy-map
policy-map QOS-6-4
class VOICE
priority level 1
cEdge1#1 つ目のコマンドは空を返したのではなく、出力が取得側の書き込みに間に合わなかっただけです。 class-map match-any VOICE の 2 行は 1 つ目のコマンドの結果です。取得の都合で空に見えた出力を「機器にその設定が無い」と読むと誤ります。 本節が §9.4 の主張を show sdwan running-config policy の正の出力に負わせているのは、この理由によります。
config-transactionは candidate configuration を編集します。 6-3 §7.1 で扱ったとおり、変更が効くのはcommitを出したときだけです。本節の 12 個の構文検査で% No modifications to commit.が返っているものは、候補の設定に差分が生じなかったことを表します。本ラボの取得はコンソール経由ではできませんでした。 pyats のコンソール接続が 4 回連続で応答を返さなくなったため、設定を day0 の起動スクリプトに焼き、SSH の永続セッションで取得する方式へ変更しています。これは取得側の事情であって、機器の性質ではありません。 本節はこの失敗を機器についての主張に使っていません。
day0 の起動スクリプトは行の順序が効きます。 鍵生成 (
crypto key generate rsa) を先に置いた版では、2 台目だけ管理アドレスが入りませんでした。 アドレスと vty を先に、鍵生成を最後に置き、鍵長を 1024 に下げると通りやすくなります。ただしこれで確実になるわけではありません。 その後の追試では、同じ順序でも 2 台のうちどちらか片方の起動スクリプトが最後まで流れないことがあり (どちらが落ちるかは固定ではありません)、落ちた側だけを停止・消去・起動し直しても復旧しない場合がありました。2 台を同時に起動する構成では、管理アドレスが入ったことを確かめてから先へ進む作りにしておくのが安全です。restrictは減らす方向に効きます。 §2.4 のとおり、既定が全対全で、付けると同じ color だけになります。「付けると繋がる」と読むと逆です。1 台あたりの TLOC 本数の上限は、現行資料の中で値が割れています (4 と 8・§3.2)。本節は 1 つに決めません。 一方 SLA class の個数上限は「割れ」ではなく、リリースと対象機器ごとの書き分けです (§10.3)。
13. 次節
本節では、6-3 が構成要素と用語の側から並べた内容を、設計と運用の側から見直しました。transport の選び方は color の選び方であり、private color には NAT の制約が付き、同じ color を 1 台で 2 回は使えないこと。既定は全対全で、restrict はそれを切り詰める指定であること。TLOC は 3 つ組で識別され、transport を増やせばその数だけ立つこと。OMP は宛先と出口と機能の在り処を別々に配り、OMP route は指す TLOC が有効なときにだけ転送表へ載ること。冗長は Controller 2 台という既定と、transport ごとの接続本数、そして拠点内で transport を貸す tloc-extension で組み立てること。
実機では、transport を 2 本持つ拠点と 1 本しか持たない拠点を同じ出力形式で並べ、number-active-wan-interfaces が 2 と 1 に割れることを撮りました。物理リンクがあっても tunnel-interface を置かなければ TLOC は立たないこと (本ラボの cEdge2 の Gi3 は IP も設定していないため、「IP はあるが tunnel-interface が無い」場合との切り分けはしていません)。設計ノブ 6 つを入れた後、local-properties では 3 つの列が変わり、残る 3 つのノブはどの列にも現れず running-config にしか出ないこと (どの列がどのノブによるかは切り分けていません)。OMP の階層は address-family の下にあり、omp 直下の書き方は拒否されること。tloc-extension は SD-WAN 側のインタフェース設定モードにだけ在ること。ローカルなポリシーの語彙は edge にあり、SLA class を 書く 階層は無いこと (SLA class 自体は Controller から配られて edge に存在します)。確かめていないことは §11 にまとめてあります。
次節 6-5 VXLAN / EVPN では、オーバーレイの舞台をデータセンタへ移します。SD-WAN が L3 の網の上に拠点間のトンネルを張るのに対し、VXLAN は L2 のセグメントを L3 網の上に延ばします。何をカプセル化し、宛先をどう学習し、その学習を BGP EVPN でどう置き換えるのかを見ていきましょう。
14. 出典
本節が参照した Cisco 公式資料です。上から 14 件は 2026 年 8 月 29 日に、下から 4 件は 2026 年 8 月 28 日に取得したもので、本文中の引用はその時点のページの逐語です。更新日は各ページに印字されている “Updated” の値です。
資料によって記述が食い違う項目があります。 §3.2 の 1 台あたりの TLOC 本数 (4 と 8) と、§4.4 の advertise connected の既定 (3 通り) の 2 つです。§10.3 の SLA class の個数上限は、feature history を読む限り食い違いではありません — リリースと対象機器ごとの書き分けです (同ガイドの本文には同じ「8」を SD-WAN Validator に帰属させる記述もあり、こちらは誤記の可能性がありますが本節では判断しません)。更新日を併記してあるのはそのためで、利用するリリースの資料で確認してください。
本節での主な用途は次のとおりです。TLOC の 3 つ組・color の重複禁止・既定の全対全と restrict・OMP が運ぶ 3 種類の経路と属性・制御接続の本数・BFD は Design Guide、color の語彙・private color と NAT・encapsulation の既定 MTU と 2 つ書ける仕様 は Systems and Interfaces Configuration Guide の TLOC の章、tloc-extension の設定例は同ガイドの TLOC Extension の章、tloc-extension が置かれるモードの定義は IOS XE Qualified Command Reference、ECMP の既定・パス上限 128・graceful restart・OMP の CLI 階層・advertise connected の既定 (2 通り) は Routing Configuration Guide (OMP のピアリング範囲のうち «Controller 同士でも走る» の根拠は Design Guide)、advertise connected の 3 通り目と「(on vEdge routers only)」の注記は Command Reference の Configuration Commands、AAR が見る 3 指標・SLA class の階層と個数上限は Policies Configuration Guide、TLOC 本数 “eight” と書く 5 か所のうち 1 つは Segmentation Configuration Guide です。
表に挙げた資料のうち OMP routing mechanisms / OMP route redistribution / Route filtering by TLOC color / Network Interfaces / Localized Policy / Centralized Policy / Command Reference — Operational Commands の 7 件からは、本文に逐語を引いていません。同じ資料群の中で記述が食い違っていないかを確かめるために取得したもので、§9.4 のポリシーの区分 (Localized と Centralized) はこの 2 章の立て方に基づいています。