ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

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 を構成要素と用語の側から並べました。仕事は Design Guide の数え方では 4 つの平面に割れ (新しい資料は 2 平面から数えることも 6-3 で扱いました)、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〜§6Cisco 公式資料。設計の定義と既定値 (見出しに ※出典)
§7〜§9本ラボの実機出力。C8000v 2 台で撮った逐語 (見出しに ※実測)
§10Cisco 公式資料。アプリ認識ルーティングの位置づけ (見出しに ※出典)
§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 です。Design Guide によれば、private color 同士は互いに相手の private IP アドレス (インタフェースに設定した NAT 前のアドレス。名前に反して、公衆網で経路制御できるアドレスのこともあります) へ接続を試みます。引用のとおり、local と remote の機器のあいだに NAT (Network Address Translation) 装置が挟まると公衆網では使えません。閉域網に付ける色と、インターネット回線に付ける色を取り違えると、この一行が効いてきます。

ただし、この制約には carrier の設定による例外があります (Design Guide・逐語)。

If you are using a private color and need NAT to communicate to another private color, the carrier setting in the configuration dictates whether you use the private or public IP address. Using this setting, two private colors can establish a session when one or both are using NAT. If the carrier setting is the same between the interfaces, the private IP address is used between them, and if the carrier setting is different, then the public IP address is used.

private color 同士では、両端の carrier が同じなら private IP アドレス (NAT 前) が、異なれば public IP アドレス (NAT 後) が使われます。 carrier を分ければ、NAT を挟んでもセッションを張れます。

本ラボが 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 は繋げる指定ではなく、既定の全対全を切り詰める指定。付けると 4 通りが 2 通りに減る。

読み違えやすいのは向きです。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 IP1 台に 1 つ。機器を決めた時点で決まる
color回線ごとに選ぶ。同じ値を 1 台で 2 回は使えない (§2.3)
encapsulationIPsec か GRE。同じ tunnel-interface に 2 つ書ける (§3.4)

この図を大きく開く ↗

TLOC の 3 つ組（system IP × color × encapsulation）と、本ラボが作る TLOC 3 本。cEdge1 が 2 本、cEdge2 が 1 本という非対称になる。

3.2 1 台に TLOC を複数立てる

TLOC は 1 台に 1 本とは限りません。transport を増やせば、その数だけ立ちます。6-3 は TLOC の定義 (§4.2) と、実機で transport を 1 本与えて TLOC が 1 本ローカルに立つところ (§7.5) までを扱いましたが、設計の実際では 1 台に何本立てるかが最初の判断になります。

その上限については、現行の Cisco 資料の記述が一致していません。 同じ Configuration Guide の中でも 2 通りの数字が書かれています。

資料 / 位置逐語値
Routing Configuration Guide — Configure OMP (GUI フィールドの説明)A Cisco IOS XE Catalyst SD-WAN device can have up to four TLOCs4
同 (同一ページの別パラメータ「Number of Paths Advertised Per Prefix」の説明)A Cisco IOS XE Catalyst SD-WAN device can have up to eight TLOCs8
同 (同一ページ・WAN インタフェース数から)This means that each router can have up to eight TLOCs8
Policies Configuration Guide — Application-Aware RoutingEach Cisco IOS XE Catalyst SD-WAN device supports up to eight TLOCs8
Segmentation Configuration Guideyou can configure up to eight tunnel interfaces8
Design Guide (CVD)you can configure up to eight tunnel interfaces, which is equivalent to eight TLOCs8

“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 restricttunnel-interface の color 指定に付けるキーワード (§2.4)
max-control-connections 0tunnel-interface 配下
carrier carrier1tunnel-interface 配下
encapsulation ipsec preference 100 weight 2encapsulation 行の引数
encapsulation gre (ipsec と併記)tunnel-interface 配下 (§3.4)
low-bandwidth-linktunnel-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

拠点が提供する機能 (ファイアウォールや侵入防御など) がどこに在るかを表し、他の拠点がその機能を経由させたいときに使われます。

この図を大きく開く ↗

OMP が運ぶ 3 種類（OMP route / TLOC route / service route）。宛先と出口は別々に配られる。

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 CommandsConnected 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.」としたうえでControl Components Release 20.9.x より前のリリースでは 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 IDsystem IPGi1 (管理)Gi2 (biz-internet)Gi3 (mpls)Lo10 (service VPN 10)vbond の宛先
cEdge11010.255.0.1172.16.1.22110.0.12.1/2910.0.13.1/30192.168.10.1/2410.0.12.2
cEdge22010.255.0.2172.16.1.22210.0.12.2/29結線のみ (IP と tunnel-interface なし)192.168.20.1/2410.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。IP も置いていないので、どちらが効いているかは切り分けていません・§11)。

service VPN 10 (Lo10) は両機に作ってありますが、本節では扱いません。 作る手順と Routing Table: 10 の見え方は 6-3 §9 と同じ VRF 番号・同じインタフェース名・同じアドレスで、内容が重複するためです。本節がこれを用意したのは、OMP が広告する対象になる接続経路を機器に持たせるためです。

vbond の宛先は 6-3 と同じく、対向の cEdge を指しています。6-3 ではこの置き方で、宛先には届くが待ち受ける 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・時刻を確定させます。

snippet 
! ===== [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
snippet 
! ===== [cEdge1] show sdwan version =====
show sdwan version
17.16.01a.0.1625

cEdge1#
snippet 
! ===== [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#
snippet 
! ===== [cEdge1] show vrf =====
show vrf
  Name                             Default RD            Protocols   Interfaces
  65528                            <not set>             ipv4        Lo65528
  65529                            <not set>             ipv4        Lo65529
cEdge1#
snippet 
! ===== [cEdge1] show clock =====
show clock
*08:48:55.344 UTC Sun Aug 30 2026
cEdge1#

5 つの出力から、本節が前提として置く事実が確定します。

確定した前提根拠にした出力
リリースは 17.16.01a、動作モードは Controller-Managedshow version / show sdwan version
物理は Gi1 / Gi2 / Gi3 の 3 本で、いずれも up/upshow ip interface brief
管理アドレス 172.16.1.221 は Gi1 = VPN 0 (グローバル表) に載っているshow ip interface brief (Gi1 のアドレス) と show vrf (Gi1 がどの VRF の Interfaces 列にも無い)
既定の 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 の時点で撮ったもので (cEdge1 の uptime と Last reload reason の行は上の抜粋で中略しており、cEdge2 の show version は貼っていません)、初期化が終わり切る前に撮った可能性があります。前節 6-3 §6.3 は vmanage_system が何も設定していない状態で既に立つことを実機で示しており、本節の cEdge1 の出力はそれと食い違って見えます。どちらが正しいかを本ラボは確かめていません (§11)。Gi3 が up/up で見えていることが、この後の §7.6 の前提になります。

snippet 
! ===== [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 を撮っておきます。

snippet 
! ===== [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 コミットで身元と物理インタフェースを入れます。

snippet 
! ===== [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 を与えるのはここです。

snippet 
! ===== [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 以降は同じ表の抜粋を使います。

snippet 
! ===== [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 の設定側からも見ておきます。

snippet 
! ===== [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
 appqoe

allow-service all の 1 行は、個別の許可・不許可の一覧と並んで残ります (中略した部分にその一覧が並びます)。all と個別の行の関係は 6-3 §11 で扱いました。本節が使うのは、encapsulation と color がこのブロックに並ぶという形の方です (§8)。

7.6 2 本目の transport を cEdge1 だけに足す

cEdge1 に Gi3 を足し、color mpls の tunnel-interface を置きます。cEdge2 には何もしません。 手順は §7.5 と同じ 2 段階です。

snippet 
! ===== [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.
snippet 
! ===== [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 と同じなので中略します。

snippet 
! ===== [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 は §7.5 の第 1 コミットで入れた 10.255.0.1 で 2 行とも共通 (行に出ている 10.0.12.1 / 10.0.13.1 は Gi2 / Gi3 のアドレスで、system IP ではありません)、encapsulation も投入した config のとおり両方 IPsec で、違うのは color だけです。3 つ組のうちこの 2 行を分けている唯一の要素は color で、§2.3 の「同じ color を 1 台で 2 回は使えない」という制約が、1 台の中では color が必ず違う値になることを保証しています。

同じ時点で cEdge2 を撮ると、1 行のままです。

snippet 
! ===== [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 本のままです。 この Gi3 には tunnel-interface を置いていません (IP も設定していないので、どちらが効いているかは切り分けていません・§11)。「物理リンクがある」ことと「TLOC が立つ」ことは別で、この主張は number-active-wan-interfaces 1 という正の出力で示せます。transport を数えるときの単位は、回線の本数ではなく tunnel-interface を置いた本数になります。

8. 実機: 設計ノブを入れると出力のどこが変わるか (※実測)

§3.5 で挙げた 6 つのノブを、1 つずつ別のトランザクションで投入します。狙いは受理されることの確認ではなく、投入後に出力のどの列が変わるかを撮ることです。比較の基準は §7.6 の出力です。

8.1 投入した 6 つ

1 つ目は restrict です。Gi3 (mpls) に付けます。

snippet 
! ===== [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 に付けます。

snippet 
! ===== [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) に付けます。

snippet 
! ===== [cEdge1] config-transaction で投入した行 =====   (逐語・... は中略)
sdwan
 interface GigabitEthernet2
  tunnel-interface
   carrier carrier1
  exit
 exit
exit
...
cEdge1(config)# commit
Commit complete.
snippet 
! ===== [cEdge1] config-transaction で投入した行 =====   (逐語・... は中略)
sdwan
 interface GigabitEthernet2
  tunnel-interface
   encapsulation ipsec preference 100 weight 2
  exit
 exit
exit
...
cEdge1(config)# commit
Commit complete.
snippet 
! ===== [cEdge1] config-transaction で投入した行 =====   (逐語・... は中略)
sdwan
 interface GigabitEthernet2
  tunnel-interface
   encapsulation gre
  exit
 exit
exit
...
cEdge1(config)# commit
Commit complete.

6 つ目の low-bandwidth-link は Gi3 に戻ります。

snippet 
! ===== [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 の設定側を撮ります。

snippet 
! ===== [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
 exit

Gi2 の 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 を撮り直します。

snippet 
! ===== [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 の出力 (ノブを入れる前) と比べると、設定に対応して変わったのは Gi3 の行の 3 列です (ポート番号や経過時間の列も動いていますが、これは設定とは無関係に変動する列です。§12)。

投入したノブ投入前 (§7.6)投入後出た場所
color mpls restrictRESTRICT/CONTROL/STUN が no/yes/noyes/ no/nolocal-properties の列
max-control-connections 0MAX CNTRL が 20local-properties の列
low-bandwidth-linkLR/LB が No/NoNo/Yeslocal-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 つが「列に現れない」のは、印字されている列見出しの一覧に該当する列が無いためです。 見出し行は §7.5 の出力に逐語で残っています (§8.3 の出力は抜粋で、見出しの 1 行目を省いています)。これはノブが効いていないという意味ではありません。 §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 で受理されます。

snippet 
! ===== [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 の下に置く形です。

snippet 
! ===== [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 の直下に置く形です。

snippet 
! ===== [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 手順は、その例で sdwan → omp → address-family ipv4 → advertise と入る階層を示しており、これと一致します。

9.2 tloc-extension は SD-WAN 側のインタフェース設定モードにだけ在る

§6.4 の逐語は「SD-WAN physical interface configuration mode」と場所を指定していました。同じコマンドを 2 つのモードへ投げて確かめます。 SD-WAN 側は受理されます。

snippet 
! ===== [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 配下に同じ行を置くと拒否されます。

snippet 
! ===== [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 のブロックが入っています。 なお下に貼った出力は 6 つのノブを入れた後 (§8) に撮った show sdwan running-config sdwan ですが、設定を入れる前 (§7.4 の基準線と同じ段階) に撮った show sdwan running-config の OMP ブロックと同じ内容であることを確認しています。

snippet 
! ===== [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 は受理されます。

snippet 
! ===== [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 直下の可視化の設定も受理されます。

snippet 
! ===== [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 側の語彙として資料に現れる書き方です。これも受理されます。

snippet 
! ===== [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 側の階層に置かれるものです。

snippet 
! ===== [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 command

sla-class の行でキャレットが立ち、続く latency と loss も同じ理由で拒否されます。 sla-class のモードに入れなかったため、2 行目以降は (config-policy)# のまま解釈されています。

投入後に SD-WAN 側の policy ブロックを撮ると、policy 配下へ入れた 3 つが残っています。

snippet 
! ===== [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 台も起動していないため、本数が揃った状態を作れません。
  • cEdge1 と cEdge2 の vmanage_system の食い違い。 §7.3 のとおり cEdge2 には現れ、cEdge1 には現れていません。cEdge1 は初期化が終わり切る前に撮った可能性があり、どちらが正しいかは確かめていません。
  • 時刻を合わせた場合との差。 §7.3 のとおり本ラボの機体は未同期のままで、証明書を持たないため比較対象がありません。

12. 落とし穴・補足

  • show sdwan running-config sdwan omp というコマンドの形はありません。 OMP のブロックだけを絞り込もうとすると弾かれます。omp ブロックは show sdwan running-config sdwan の出力の中に含まれています (§9.3 はそこから抜粋しています)。
snippet 
! ===== [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 になっており (抜粋では中略した行です)、本節はこの値に主張を負わせていません。 列を横に読み比べるときは、ポート番号と時間の列が変動することを前提にしてください。

  • 拒否のあとに続けて送った exit で、投入していた設定モードから出てしまうことがあります。 拒否された 3 行はいずれも (config-policy)# のままで、拒否そのものではモードは変わっていません。§9.4 の sla-class の候補では、sla-class のモードに入れないまま、続く 2 つの exit が (config-policy) → (config) → 特権 EXEC とモードを 2 段戻したため、その後に送った commit と end が特権 EXEC のコマンドとして解釈されました。

snippet 
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 の結果が次のコマンドのヘッダより後に現れています。
snippet 
! ===== [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 に下げると通りやすくなります。なお Cisco の Field Notice FN72511 は、IOS XE 17.11.1 以降では 2048 ビット未満の RSA 鍵が既定で SSH に使えない (Catalyst 8000V も対象) と書いています。本ラボは SSH で取得できていますが、実際に使われた SSH の鍵の長さは確かめていません。鍵長を下げる対処は、この条件と合わせて読んでください。ただしこれで確実になるわけではありません。 その後の追試では、同じ順序でも 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 に存在する、と Policies Configuration Guide は書いています。本ラボはこちらを確かめていません)。確かめていないことは §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 に帰属させる記述もあり、こちらは誤記の可能性がありますが本節では判断しません)。更新日を併記してあるのはそのためで、利用するリリースの資料で確認してください。

資料更新日URL
Cisco Catalyst SD-WAN Routing Configuration Guide (IOS XE 17.x) — OMP routing mechanisms2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/omp-routing-protocol-sd-wan.html
同 — OMP route advertisements2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/omp-route-advertisements.html
同 — OMP paths2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/omp-paths.html
同 — OMP graceful restart2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/omp-graceful-restart.html
同 — OMP route redistribution2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/omp-route-redistribution.html
同 — Configure OMP2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/OMP-routing-protocol-ref/configure-omp.html
同 — Route filtering by TLOC color2026-03-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-configuration-guide-17-x/cisco-sd-wan-controller-route-filtering-by-tloc-color/route-filtering-by-tloc-color.html
Cisco Catalyst SD-WAN Systems and Interfaces Configuration Guide (17.x) — TLOC2026-07-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/17-x/systems-interfaces/systems-interfaces-guide-17-x/tloc.html
同 — TLOC Extension2026-07-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/17-x/systems-interfaces/systems-interfaces-guide-17-x/tloc-extension.html
同 — Network Interfaces2026-07-09https://www.cisco.com/c/en/us/td/docs/routers/sdwan/17-x/systems-interfaces/systems-interfaces-guide-17-x/network-interfaces.html
Cisco Catalyst SD-WAN Policies Configuration Guide (IOS XE 17.x) — Application-Aware Routing2025-12-19https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/application-aware-routing.html
同 — Localized Policy2025-12-19https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/localized-policy.html
同 — Centralized Policy2025-12-19https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/ios-xe-17/policies-book-xe/centralized-policy.html
Cisco Catalyst SD-WAN Command Reference — Configuration Commands2026-03-15https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html
Cisco Catalyst SD-WAN Design Guide (CVD)2024-08-21https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html
Cisco Catalyst SD-WAN Command Reference — Operational Commands2026-03-15https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/operational-cmd.html
Cisco Catalyst SD-WAN Segmentation Configuration Guide (IOS XE 17.x)2025-12-19https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/segmentation/ios-xe-17/segmentation-book-xe/segmentation.html
Cisco IOS XE Catalyst SD-WAN Qualified Command Reference — SD-WAN Tunnel Interface Commands2026-05-12https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/iosxe/qualified-cli-command-reference-guide/m-sdwan-tunnel-interface-cmds.html

本節での主な用途は次のとおりです。TLOC の 3 つ組・color の重複禁止・既定の全対全と restrict・private color 同士が相手の private IP アドレス (NAT 前) へ接続を試みること・private color が carrier の設定で NAT を越える例外・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 章の立て方に基づいています。

§12 の day0 の鍵長の補足で参照した Cisco Field Notice FN72511 (https://www.cisco.com/c/en/us/support/docs/field-notices/725/fn72511.html) は、2026 年 9 月 29 日に取得しました。