6-3 Cisco SD-WAN 概要 — 拠点側の機器がオーバーレイを張る

1. 前節の振り返りと本節の内容

前節 6-2 MPLS L3VPN では、1 つの MPLS 網の上に顧客ごとの経路表を載せる仕組みを追いました。VRF が 1 台の中で経路表を分け、RD が同じ prefix を 2 本のまま運べる形にし、RT が入れ先を決めます。パケットにはラベルが 2 枚積まれ、外は道順を、内は誰の経路表かを表しました。この一式は、すべて事業者が用意した網の上で成り立っていました。 顧客は PE に接続するだけで、経路表の分離も経路の運搬も事業者側の設定に委ねています。

6-2 の末尾では 3 つを予告しました。拠点側の機器がオーバーレイを張ること、vManage / vSmart / vBond / cEdge という 4 種類の構成要素がそれぞれどの平面を担当するのか、そして事業者網主導の分離と何が入れ替わるのかです。本節はこの 3 つを順に扱います。

入れ替わるものを先に並べます。

1.1 名前の橋 — 改名されたのは 3 つだけ

6-2 が挙げた 4 語のうち、3 つは旧名です。Cisco の Design Guide は改名の範囲を次のように書いています (逐語)。

Cisco SD-WAN has been rebranded to Cisco Catalyst SD-WAN. As part of this rebranding, the vManage name has been changed to SD-WAN Manager, the vSmart name has been changed to SD-WAN Controller, and the vBond name has been changed to SD-WAN Validator. Together, the vManage, vSmart, and vBond will be referred to as the SD-WAN control components in this document.

改名の対象は vManage / vSmart / vBond の 3 つだけで、この 3 つをまとめて control components と呼ぶ、と書いてあります。cEdge はこの 3 つに入っていません。 cEdge は旧名ではなく、現行の資料が今も使っている語です。Getting Started Guide は “Cisco vEdge Devices and Cisco IOS XE Catalyst SD-WAN Devices” という見出しで両者を併存するカテゴリとして扱い、Troubleshoot 文書 (Document ID 214509) は本文中で cEdge1#show sdwan control local-properties のように現行の語として使っています。

正しい構図は次のとおりです。

したがって「WAN Edge (旧 cEdge)」という書き方は誤りです。WAN Edge router がカテゴリで、cEdge と vEdge はその中の 2 つの実装を指し分ける語になります。本節が実機で扱うのは cEdge の側です。

1.2 本節で「何が何を支えているか」

本節は実機で撮れる範囲が構造的に狭い節です。制御接続を最後まで張るには control components が要り、control components を動かすには証明書が要ります。そこで、支えている根拠を節ごとに分けます。

2. 4 つの平面と 4 つの構成要素

Cisco Catalyst SD-WAN は、仕事を 4 つの平面に分けます。Design Guide の記述は次のとおりです (逐語)。

The Cisco Catalyst SD-WAN solution is comprised of separate orchestration, management, control, and data planes.

• The orchestration plane assists in the automatic onboarding of the SD-WAN routers into the SD-WAN overlay.
• The management plane is responsible for central configuration and monitoring.
• The control plane builds and maintains the network topology and makes decisions on where traffic flows.
• The data plane is responsible for forwarding packets based on decisions from the control plane.

平面と構成要素は 1 対 1 で対応します。Design Guide は「SD-WAN Manager が管理平面、SD-WAN Controller が制御平面、SD-WAN Validator がオーケストレーション平面、WAN Edge router がデータ平面」と並べています。6-2 では PE 1 台が分離も運搬も転送も担っていました。SD-WAN ではその仕事が 4 つに割れ、拠点に置かれる WAN Edge に割り当てられている平面はデータ平面だけになります。これは平面の割り当ての話で、WAN Edge に制御の機能が無いという意味ではありません。 Getting Started Guide は edge router の構成要素として、control components との DTLS 制御接続や、SD-WAN Controller とのあいだで制御情報だけを運ぶ OMP を挙げています (§4.3)。

各構成要素の役割は、Design Guide が次のように書いています。

Controller が「ルートリフレクタとして働く」という書き方は、3-7 Route Reflector で扱った iBGP の反射と同じ発想です。全 WAN Edge がフルメッシュで経路を交換するのではなく、Controller が中央で受けて配り直します。

2.1 平面の数は資料によって違う

4 平面は Design Guide (2024-08-21 更新) の書き方です。 より新しい Solution Overview (2026-07-06 更新) は、同じ構成を 2 平面で説明しています (逐語)。

The components of the Cisco Catalyst SD-WAN fabric can be described as operating in two planes:

• Data plane
• Control plane

Some discussions Catalyst SD-WAN further divide the control plane into a management plane mostly relating to SD-WAN Manager operations, and an orchestration plane for SD-WAN Validator operations that relate to onboarding devices into the fabric.

データ平面と制御平面の 2 つを基本とし、制御平面を管理とオーケストレーションに細分する説明の仕方がある、という書き方になっています。区切り方が違うだけで、担当する部品の対応は変わりません。本節は 6-2 の予告を回収するために 4 平面の側で書きますが、現行の資料を開くと 2 平面から始まります。

3. 制御接続はどう張られるか

この節の内容は、すべて Cisco 公式資料の記述です。本ラボは control components を 1 つも起動していないため、ここで書く順序を実機では観測していません (§10)。

Getting Started Guide は、オーバーレイの立ち上がりを 10 段階で書いています (逐語)。

1. The Cisco SD-WAN Manager software starts on a server in the data center.
2. The Cisco SD-WAN Validator starts on a server in the DMZ.
3. The Cisco SD-WAN Controller starts on a server in the data center.
4. Cisco SD-WAN Manager and the Cisco SD-WAN Validator authenticate each other, Cisco SD-WAN Manager and the Cisco SD-WAN Controller authenticate each other, and the Cisco SD-WAN Controller and the Cisco SD-WAN Validator securely authenticate each other.
5. Cisco SD-WAN Manager sends configurations to the Cisco SD-WAN Controller and the Cisco SD-WAN Validator.
6. The routers start in the network.
7. The routers authenticate themselves with the Cisco SD-WAN Validator.
8. The routers authenticate themselves with Cisco SD-WAN Manager.
9. The routers authenticate themselves with the Cisco SD-WAN Controller.
10. Cisco SD-WAN Manager sends configurations to the routers.

拠点のルータが登場するのは 6 番目です。それまでの 5 段階は control components だけで進み、ルータが起動した時点で相手側はすでに互いを認証し終えています。 ルータが自分を認証させる順序は Validator → Manager → Controller で、最後に Manager から設定を受け取ります。

3.1 何がどの protocol で張られるか

Design Guide は protocol と接続の常設性について、Getting Started Guide より細かく書いています (逐語)。

Control connections to the SD-WAN Validator are always DTLS. By default, connections to the SD-WAN Manager and Controller are DTLS as well, but this can be changed on any device by configuring TLS for the security control protocol.

Validator への制御接続は常に DTLS です。Manager と Controller への接続は既定で DTLS ですが、機器側の設定で TLS に変えられます。TLS は TCP を使うので、ファイアウォールが接続の状態を保持できるという違いが付きます。

接続の張り方と、その後の切断についてはこう書かれています (逐語)。

The WAN Edge router tries to establish control connections over all provisioned transports by default, first initiating contact with the SD-WAN Validator over each transport before attempting to connect to the other control components. Only one SD-WAN Validator control connection is made per transport when multiple Validators exist.

The WAN Edge router establishes a permanent connection to the SD-WAN Controller over each transport, and establishes a single, permanent connection to the SD-WAN Manager over only one transport, the first one which establishes a connection. The SD-WAN Validator connection is then terminated.

3 者への接続は性質が異なります。

Validator への接続は、役目を終えると切られます。 Validator は入口の認証と仲介を担当する部品なので、Manager と Controller への常設接続が揃った時点で用が済みます。

なお、Design Guide の “first initiating contact with the SD-WAN Validator over each transport before attempting to connect to the other control components” という書き方は、他の control component との前後関係を述べています。比較の相手が存在しない構成では、この「先」に対する「後」が発生しません (§10)。

3.2 数が揃わないときの状態 — out of equilibrium

制御接続の本数が足りない状態には名前が付いています (逐語)。

It is important to note that if WAN Edge routers are not able to connect to the proper number of control components (DTLS/TLS to the SD-WAN manager, DTLS/TLS connections per transport to each of two Controllers, and 1 OMP session to each of the two Controllers by default), then the WAN Edge connections are considered “out of equilibrium”. When this occurs, the WAN Edge establishes a permanent connection over the TLOC to the Validator until the correct number of control connections have been re-established.

括弧の中が「本来あるべき数」の定義です。Manager への DTLS/TLS が 1 本、2 台の Controller それぞれに対して transport ごとの DTLS/TLS、その 2 台それぞれに対して OMP セッションが 1 本ずつ という既定を指しています。これを満たさない状態が out of equilibrium で、そのあいだ WAN Edge は TLOC 経由で Validator への常設接続を張り続けます。§3.1 で「Validator への接続は切られる」と書いた前提が、ここで戻ります。

Controller への接続が全部落ちた場合の猶予も定義されています (逐語)。

If all SD-WAN Controller connections are lost, the WAN Edge router continues to operate with the latest control plane information for the length of the OMP graceful restart timer (12 hours by default).

既定で 12 時間、直前の制御平面情報で動き続けます。制御が落ちた瞬間に転送が止まる設計ではありません。

安全な接続ができた後の段取りも、Design Guide に書かれています (逐語)。

Once a secure connection is built, NETCONF is used by the SD-WAN Manager to provision the WAN Edge device, and OMP peering is established between the SD-WAN Controller and WAN Edge … OMP peering is established using the system IP addresses and only one peering session is established between a WAN Edge device and an SD-WAN Controller, even if multiple DTLS/TLS connections exist.

設定の投入には NETCONF が使われます。OMP のピアリングは system IP で張られ、DTLS/TLS の接続が transport の数だけあっても OMP セッションは 1 本です。制御接続の本数と OMP セッションの本数は別に数える必要があります。

4. 機器を識別する値と、TLOC / color / OMP

4.1 site ID / system IP / organization name

Design Guide の定義は次のとおりです。

site ID は拠点の一意な識別子で、値は 1〜4294967295 です。同じ拠点にある WAN Edge には同じ値を付けます。副作用が 1 つあります (逐語)。

By default, IPsec tunnels are not formed between WAN Edge routers within the same site which share the same site-id.

同じ site ID を持つ WAN Edge 同士は、既定では IPsec トンネルを張りません。 同一拠点の機器同士をオーバーレイ経由で結ぶ必要が無いためです。

system IP はインタフェースのアドレスとは独立に機器を識別する IPv4 アドレスで、ルータ ID に近い役割を持ちます。ここは引用の切り取り方に注意が要ります (逐語)。

It is assigned to the system interface that resides in VPN 0 and is never advertised. A best practice, however, is to assign this system IP address to a loopback interface and advertise it in any service VPN.

“is never advertised” は system インタフェースに割り当てた system IP そのものの話で、同じ段落が「同じアドレスを loopback にも割り当てて service VPN で広告するのが best practice」と続けています。前半だけを引くと、資料が薦めている運用と正面から衝突します。広告した後は SNMP や syslog の送信元アドレスとして使えます。

organization name はオーバーレイに付ける名前です (逐語)。

Organization Name is a name that is assigned to the SD-WAN overlay. It is case-sensitive and must match … It is used to define the Organization Unit (OU) field to match in the Certificate Authentication process

大文字小文字が区別され、オーバーレイ内の全機器で一致している必要があります。単なるラベルではありません。

ただし証明書との関係はリリースで変わっています。 Certificate Management のドキュメントは、enterprise certificate について次のように書いています (逐語)。

From Cisco Catalyst SD-WAN Control Components Release 20.12.1, when onboarding a device, Cisco Catalyst SD-WAN does not require that the associated enterprise certificate have any OU fields defined. However, if at least one OU field is defined, then Cisco Catalyst SD-WAN requires that one of the OU fields match the organization name of the fabric.

From Cisco Catalyst SD-WAN Control Components Release 20.12.2, when onboarding a device, if the associated enterprise certificate has one or more OU fields defined, the OU fields need not match the organization name of the fabric.

Design Guide が書く「OU フィールドとして照合される」は、この変更より前の説明です。本ラボの機体が申告する Controller Compatibility は 20.16 で、20.12.2 より後にあたります。組織名を全機器でそろえる必要があることは変わりませんが、enterprise certificate の OU と一致させる要件はリリースによって違います。

4.2 TLOC と color

TLOC (Transport Location) は、WAN Edge が WAN transport 網につながる接続点です (逐語)。

A TLOC, or Transport Location, is the attachment point where a WAN Edge router connects to the WAN transport network. 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).

TLOC を一意にするのは system IP・color・encapsulation の 3 つ組です。

color は TLOC を見分けるためのラベルで、Internet 側に biz-internet、MPLS 側に mpls のように付けます。制約が 1 つあります (逐語)。

You cannot use the same color twice on a single WAN Edge router.

1 台の WAN Edge で同じ color を 2 回使うことはできません。 上に引いた 3 つ組に照らすと、system IP は 1 台に 1 つなので、color が重なると TLOC を区別する材料が encapsulation しか残らないためです。

その encapsulation で区別する形は、実際に用意されています (Qualified Command Reference・逐語)。

For a single tunnel, you can configure both IPsec and GRE encapsulations, by including two encapsulation commands. Cisco SD-WAN then creates two TLOCs for the tunnel interface. Both TLOCs have the same IP address and color, but one has IPsec encapsulation while the other has GRE encapsulation.

1 本の tunnel に IPsec と GRE を両方設定すると、IP も color も同じ TLOC が 2 つできます。 3 つ組の 3 番目に encapsulation が入っているのは、この区別のためです。

4.3 OMP

OMP (Overlay Management Protocol) はオーバーレイを管理する経路制御プロトコルです (逐語)。

The OMP routing protocol, which has a structure similar to BGP, manages the SD-WAN overlay network. The protocol runs between SD-WAN Controllers and between SD-WAN Controllers and WAN Edge routers where control plane information, such as route prefixes, next-hop routes, crypto keys, and policy information, is exchanged over a secure DTLS or TLS connection. The SD-WAN Controller acts similar to a BGP route reflector

構造が BGP に似ていると明記されています。走る場所は Controller 同士と、Controller と WAN Edge のあいだです。WAN Edge 同士では走りません。

運ぶものは 4 種類あります。

鍵が制御平面を通って配られるのが 6-2 との一番大きな差です。§2 の表で引いた “reflecting crypto key information originating from WAN Edge routers, allowing for a very scalable, IKE-less architecture” がこれにあたります。4-8 Site-to-Site VPN では拠点の対ごとに IKE で鍵を交換していました。SD-WAN では WAN Edge が出した鍵情報を Controller が反射するので、拠点数が増えても対ごとの鍵交換が要りません。

5. VPN 0 / VPN 512 / service VPN

SD-WAN は拠点の中を VPN 番号で分けます。Design Guide の定義は 6-2 の VRF を明示的に引き合いに出しています (逐語)。

In the SD-WAN overlay, virtual private networks (VPNs) provide segmentation, much like Virtual Routing and Forwarding instances (VRFs) that many are already familiar with. Each VPN is isolated from one another and each have their own forwarding table.

現行の Solution Overview は、類比よりも強い言い方をしています (逐語)。

The data plane enforces network segmentation, implemented with the Virtual Routing and Forwarding (VRF) technology, operationally equivalent to VPNs.

分離の実装は VRF そのもので、VPN とは運用上等価であるという書き方です。6-2 で扱った VRF の理解がそのまま使えます。

VPN 番号は 0〜65535 の整数ですが、内部用に予約されたものがあります。**設定できる上限については、現行の Cisco 資料の記述が一致していません。**Systems and Interfaces Configuration Guide (2026 年 7 月 9 日更新) は、同じ文書の中で 「service VPN (range 1 – 65527, except 512)」と書く一方、別の箇所では 「VPNs 1–511, 513–65530—Service VPNs」とも書いています。Design Guide (2024 年 8 月 21 日更新) は 「the maximum VPN that can or should be configured is 65527」、Segmentation Configuration Guide (2025 年 12 月 19 日更新) は 「Range: 1 to 65525, excluding 512」で、あわせて VRF の範囲に関する挙動変更へ参照を張っています。**上限として 65525 / 65527 / 65530 の 3 つが現行資料に併存しています。数値を覚えるのではなく、使用するリリースの資料で確認する扱いが安全です。**どの資料も一致しているのは 0 と 512 が予約されていることで、Design Guide は service VPN に 1〜511 を選ぶことを目安として挙げています。既定で 2 つの VPN が存在します。

5.1 IOS XE SD-WAN では VPN が VRF として現れる

本節の実機は IOS XE SD-WAN 版の C8000v です。この系統では、SD-WAN Manager から設定が配られる際に、機器側のパーサが受け付ける形へ表現が変換されます (逐語)。

• VRF terminology is used instead of the VPN keyword
• The global table is used to represent VPN 0
• VRF Mgmt-intf is enabled by default on the management interface and is used to represent VPN 512

VPN という語ではなく VRF という語が使われ、VPN 0 はグローバル表が、VPN 512 は VRF Mgmt-intf が受け持ちます。 VPN 0 に対応する VRF は作られないので、show ip route をそのまま打った結果が VPN 0 の中身になります。

命名には制約が付きます (逐語)。

While IOS XE routers accept names for VRF definitions, with IOS XE SD-WAN code, VRF definitions must be numbers only.

IOS XE SD-WAN では VRF 名に数字しか使えません。 6-2 の Routing Table: CUST-A という名前付きの表示と、§9 で見る Routing Table: 10 という数字の表示の差は、この 1 行から来ています。

6. 実機: 参加前の cEdge は何を持っているか

ここから §9 までが本ラボの実機出力を扱う節です。 貼った出力は改変していません。ただし §6.2 のように、なぜその構成にしたかの理由づけは出典の側にあります。

6.1 ラボ構成

CML 上に cat-sdwan-edge を 2 台置き、管理用のスイッチと外部接続をつなぎます。cEdge1 と cEdge2 の Gi2 同士を /30 で直結し、そこを VPN 0 の transport に見立てます。

vbond の宛先を対向の cEdge にしてあるのは意図的です。 到達はするが、そこで待ち受けている Validator は居ない、という状態を作ります。宛先へ届くことと、そこで制御接続が成立することを切り分けて観測するための配置で、§8 でその結果を見ます。認証まで進むかどうかは本ラボでは観測できません (§8.3 / §10)。

6.2 control components を起動していない理由

5 種類のイメージが CML に登録されています。 DevNet の資料は供給されるイメージを “the Manager, Controller, Validator, and vEdge (Viptela Edge) and Cisco Edge (Catalyst 8000v for SD-WAN)” と列挙しており、「CML に無いから起動できない」という説明は成り立ちません。起動していない理由は 3 つで、それぞれ効く範囲が違います。

② は資料に明記されています。DevNet の CML 資料は次のように書いています (逐語)。

Before edge nodes (those that form the dataplane of an SD-WAN fabric) can be bootstrapped, certificates must be generated and loaded into the SD-WAN Manager.

その証明書の照合に使う認可済みシリアル一覧の入手先も決まっています。ここからの 2 つは CML のドキュメントではなく、Cisco の Control Components Certificates and Authorized Serial Number File Prescriptive Deployment Guide からの引用です (逐語)。

Authorized serial number list for WAN Edge devices: The digitally-signed, authorized serial number list for the WAN Edge devices can be retrieved from the Plug and Play Connect portal at https://software.cisco.com/#pnp-devices.

The authorized serial number file on the PnP Connect portal also contains IOS XE SD-WAN router information.

一覧は PnP Connect ポータルから取得し、Smart Account と Virtual Account に紐づきます。この一覧は IOS XE SD-WAN ルータの情報も含むと書かれているので、本ラボの C8000v にもそのまま効く関所です。

6.3 実機の前提を測る

まずインタフェース番号と既定の VRF を確定させます。

! ===== [cEdge1] show ip interface brief =====
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       unassigned      YES unset  up                    up      
GigabitEthernet2       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

物理は Gi1 と Gi2 の 2 本です。それに加えて vmanage_system と Loopback65528 / Loopback65529 が、何も設定していない状態で既に立っています。 これらは SD-WAN のために用意された内部インタフェースです。

! ===== [cEdge1] show vrf =====
  Name                             Default RD            Protocols   Interfaces
  65528                            <not set>             ipv4        Lo65528
  65529                            <not set>             ipv4        Lo65529

既定の VRF は内部用の 65528 と 65529 だけです。§5.1 で出てきた Mgmt-intf がありません。 この仮想プラットフォームには専用の管理ポートが無いためで、VPN 512 は本ラボでは実測できません (§10)。

! ===== [cEdge1] show clock =====
*23:46:59.625 UTC Thu Aug 27 2026

先頭の * は時刻が同期していない (authoritative でない) ことを表します。この出力から言えるのはそこまでで、証明書の有効期間に入っているかや、他の構成要素と時刻が合っているかまでは確かめていません。

6.4 素の cEdge が既に持っているもの

この機体は IOS-XE のルータでもあります。

! ===== [cEdge1] 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.
...
Router operating mode: Controller-Managed
2 Gigabit Ethernet interfaces

Router operating mode: Controller-Managed の 1 行が、この機体が SD-WAN 側のモードで動いていることを示します。SD-WAN 側の版数は別のコマンドで出ます。

! ===== [cEdge1] show sdwan version =====
17.16.01a.0.1625

! ===== [cEdge1] show sdwan system status =====   (抜粋)
Viptela (tm) vEdge Operating System Software
Copyright (c) 2013-2026 by Viptela, Inc.
Controller Compatibility: 20.16
Version: 17.16.01a.0.1625
Build: Not applicable
...
System state:            GREEN. All daemons up
System FIPS state:       Disabled
...
Personality:             vEdge
Model name:              C8000V
Device role:             cEdge-SDWAN
Services:                None
vManaged:                false
Commit pending:          false
Configuration template:  None
Chassis serial number:   SSI130300YK

Personality: vEdge は製品名ではなくロール値です。 Command Reference は personality を “Cisco vEdge device personality.” と説明しており、vedge / vsmart / vmanage / vbond のどれであるかを表します。この行は「この機体は control component ではなく edge のロールである」という意味で、§1.1 で扱った旧名とは別の話です。Device role: cEdge-SDWAN と Model name: C8000V が並んでいることも、§1.1 の構図と一致します。

SD-WAN の設定ブロックも最初から入っています。

! ===== [cEdge1] show sdwan running-config =====   (抜粋: sdwan ブロック)
sdwan
 appqoe
  no tcpopt enable
  no dreopt enable
  no httpopt enable
 !
 omp
  no shutdown
  graceful-restart
  no as-dot-notation
  address-family ipv4
   advertise connected
   advertise static
  !
  address-family ipv6
   advertise connected
   advertise static
  !
 !
!

OMP は no shutdown で、graceful-restart も advertise connected / advertise static も既に構成済みです。 何も設定していない機体が、OMP を動かす準備をした状態で起動しています。

6.5 出典が挙げる前提と、機器の出力を突き合わせる

Troubleshoot 文書 (Document ID 214509) は、制御接続を切り分ける前に確認すべき前提を挙げています (逐語)。

Before you troubleshoot, ensure that the WAN Edge that is in question has been configured properly.

It includes:

• A valid certificate that is installed.
• These configurations are put in place under the system block:
  • System-IP
  • Site-ID
  • Organization-Name
  • vBond address
  • VPN 0 Transport interface that is configured with the Tunnel option and IP address.
• System Clock that is configured correctly on the vEdge and those that match with other devices/controllers

証明書が 1 つ、system ブロックに入れる 5 項目、そして時計です。素の cEdge1 の出力を並べます。

! ===== [cEdge1] show sdwan control local-properties =====
personality                       vedge
sp-organization-name               
organization-name                  
root-ca-chain-status              Installed
root-ca-crl-status                Not-Installed

certificate-status                Not-Installed
certificate-validity              Not Applicable
certificate-not-valid-before      Not Applicable
certificate-not-valid-after       Not Applicable

enterprise-cert-status            Not Applicable
enterprise-cert-validity          Not Applicable
enterprise-cert-not-valid-before  Not Applicable
enterprise-cert-not-valid-after   Not Applicable

dns-name                          
site-id                           0
domain-id                         1
protocol                          dtls
tls-port                          0
system-ip                         0.0.0.0
chassis-num/unique-id             C8K
serial-num                        No certificate installed
subject-serial-num                N/A
enterprise-serial-num             No certificate installed
token                             <insert otp/token here>
keygen-interval                   1:00:00:00
retry-interval                    0:00:00:15
no-activity-exp-interval          0:00:00:20
dns-cache-ttl                     0:00:00:00
port-hopped                       FALSE
time-since-last-port-hop          0:00:00:00
embargo-check                     success
device-role                       edge-router
region-id-set                     N/A
mrf-migration-mode                disabled
mrf-management-region             no
number-vbond-peers                0
number-active-wan-interfaces      0

1 対 1 で並べるとこうなります。

7 つのすべてが未充足です。 証明書についてはもう 1 つ分かることがあります。

! ===== [cEdge1] show sdwan certificate serial =====
Certificate not yet installed ... giving up.
Chassis number: C8K serial number:  Subject S/N: N/A

上の local-properties で root-ca-chain-status は Installed でした。ルート CA の連鎖は入っているが、この機体自身の証明書は入っていません。 相手を検証するための材料は持っているが、自分を名乗るための材料が無い状態です。

Troubleshoot 文書は前提の並びの直後に、TLOC が上がっていることを show control local-properties で確認するよう続けています。上の出力では number-active-wan-interfaces が 0 で、TLOC の表そのものが印字されていません。

7. 実機: 身元と transport を与えると何が変わるか

7.1 設定モードは config-transaction

IOS XE SD-WAN の機器では設定モードの入り方が違います。Command Reference の記述は次のとおりです (逐語)。

Cisco IOS XE routers such as aggregation and integrated services routers should use the command config-transaction to enter configuration mode. The config terminal command is not supported on SD-WAN routers.

configure terminal は使えず、config-transaction を使います。 投入した内容は commit で確定します。

7.2 IOS-XE 側の Tunnel を作らずに SD-WAN 側の tunnel-interface を入れると拒否される

system ブロック・物理インタフェース・SD-WAN の tunnel-interface を 1 回の config-transaction にまとめて投入した結果です。

! ===== [cEdge1] config-transaction — 1 回で全部入れた場合 =====
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.252
 no shutdown
exit
sdwan
 interface GigabitEthernet2
  tunnel-interface
   encapsulation ipsec
   color biz-internet
  exit
 exit
exit
commit
Aborted: 'sdwan interface GigabitEthernet2 tunnel-interface' : No Tunnel interface found with tunnel source set to SDWAN interface

Aborted: で commit ごと拒否されます。 SD-WAN 側の tunnel-interface は、IOS-XE 側の interface TunnelN が先に存在していないと参照できません。

ここが configure terminal との一番大きな違いです。 Command Reference は設定モードの仕組みを次のように書いています (逐語)。

In configuration mode, you are editing a copy of the running configuration, called the candidate configuration, not the actual running configuration. Your changes take effect only when you issue a commit command.

編集しているのは candidate configuration という控えであり、変更が効くのは commit を出したときだけです。したがって commit が拒否されれば、その回に入れた行は running configuration へ移りません。通った行だけが残る挙動を前提に切り分けると、状態を読み違えます。ただし本ラボは、拒否された直後の状態を show で撮っていません。 ここは出典の記述に基づく説明です (§11 の補足も参照)。

同じ文面は Cisco の原典にも載っています。Document ID 218137 はこの文字列を 2 か所で示しており、1 つは「IOS-XE 側のトンネルを残したまま SD-WAN 側のトンネルだけを外そうとした場合」、もう 1 つは **「順序を変えて commit した場合」**です (逐語)。

If the changes are committed in a different order, it can lead to an error because the Cisco IOS XE Tunnel interface is not associated with the SD-WAN Tunnel Interface.

本ラボの拒否は後者、順序の側にあたります。

7.3 2 段階に分けると両方通る

Document ID 218137 が定める順序は次のとおりです。物理インタフェース → 既定経路 → commit → 物理インタフェースを source にした XE のトンネル → SD-WAN 側のトンネル → commit。

本ラボでは既定経路を入れていません。vbond の宛先が直結の /30 の上にあるためです。

! ===== [cEdge1] config-transaction — 第 1 コミット =====
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.252
 no shutdown
exit
commit
Commit complete.

! ===== [cEdge1] config-transaction — 第 2 コミット =====
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
commit
Commit complete.

両方とも Commit complete. になります。 cEdge の transport は 2 つの層でできています。interface Tunnel2 が IOS-XE 側のトンネルで、tunnel mode sdwan を持ち、tunnel source に物理インタフェースを指します。sdwan interface GigabitEthernet2 の下の tunnel-interface が SD-WAN 側で、encapsulation と color を持ちます。後者が前者を参照するので、先に前者が要るという順序になります。

投入した system ブロックは次のように収まります。

! ===== [cEdge1] show sdwan running-config system =====
system
 system-ip             10.255.0.1
 site-id               10
 admin-tech-on-failure
 organization-name     chillarin-sdwan-lab
 vbond 10.0.12.2
!

7.4 0 値から実値へ変わる

§6.5 と同じコマンドを、投入後に撮ります。

! ===== [cEdge1] show sdwan control local-properties =====   (投入後)
personality                       vedge
sp-organization-name              chillarin-sdwan-lab
organization-name                 chillarin-sdwan-lab
root-ca-chain-status              Installed
root-ca-crl-status                Not-Installed

certificate-status                Not-Installed
certificate-validity              Not Applicable
certificate-not-valid-before      Not Applicable
certificate-not-valid-after       Not Applicable

enterprise-cert-status            Not Applicable
enterprise-cert-validity          Not Applicable
enterprise-cert-not-valid-before  Not Applicable
enterprise-cert-not-valid-after   Not Applicable

dns-name                          10.0.12.2
site-id                           10
domain-id                         1
protocol                          dtls
tls-port                          0
system-ip                         10.255.0.1
chassis-num/unique-id             C8K
serial-num                        No certificate installed
subject-serial-num                N/A
enterprise-serial-num             No certificate installed
token                             <insert otp/token here>
keygen-interval                   1:00:00:00
retry-interval                    0:00:00:15
no-activity-exp-interval          0:00:00:20
dns-cache-ttl                     0:00:00:00
port-hopped                       TRUE
time-since-last-port-hop          0:00:01:04
embargo-check                     success
device-role                       edge-router
region-id-set                     N/A
mrf-migration-mode                disabled
mrf-management-region             no
number-vbond-peers                1

INDEX   IP                                      PORT
----------------------------------------------------
0       10.0.12.2                               12346  

number-active-wan-interfaces      1

前後を並べます。

number-vbond-peers が 1 になったことは、「Validator に接触した」ことを意味しません。 これは解決済みの vBond ピアアドレス一覧の件数です。Command Reference には、vSmart 上で clear dns cache を打つ前後にこの値が 1 → 0 →(再解決後)1 と遷移する実例が載っており、INDEX / IP / PORT の表が付くのも 1 のときです。設定した宛先が名前解決を経て一覧に載った、というところまでを表す値になります。

身元が揃っても証明書は入りません。 「自分が誰であるかを設定する」ことと「それを相手に認めさせる」ことは別の段です。

! ===== [cEdge1] show sdwan certificate serial =====   (投入後)
Certificate not yet installed ... giving up.
Chassis number: C8K serial number:  Subject S/N: N/A

7.5 TLOC がローカルに立つ

同じコマンドの続きに、§6.5 では印字されなかった表が現れます。

! ===== [cEdge1] show sdwan control local-properties =====   (続き: WAN インタフェースの表)
                         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       12386  10.0.12.1       ::                                      12386    0/0  biz-internet     up     2      no/yes/no   No/No  0:00:00:05   0:11:40:38  N    5  Default N/A

GigabitEthernet2 が biz-internet の color を持ち、WAN STATE が up になっています。§4.2 で見た TLOC の 3 つ組のうち、system IP と color と encapsulation が機器のローカル情報として揃った状態です。PUBLIC IPv4 と PRIVATE IPv4 はどちらも 10.0.12.1 です。Design Guide は “In the absence of NAT, the private and public IP address of the SD-WAN device are the same.” と書いており、本ラボの構成に NAT はありません。この出力だけからは NAT の有無を判定できません。 同じ出力の NAT TYPE 列は N で、凡例は N -- indicates Not learned としています。両者が一致していることは構成と整合しますが、機器が NAT 無しと判定した結果ではありません。

8. 実機: 下回りは繋がっている。それと制御接続が成立することは別

8.1 cEdge2 も同じ形にする

cEdge2 には site ID 20 と system IP 10.255.0.2 を与えます。organization-name は cEdge1 と同じ値にします。§4.1 のとおり、オーバーレイ内で一致している必要があるためです。

! ===== [cEdge2] config-transaction — 第 1 コミット =====
system
 system-ip 10.255.0.2
 site-id 20
 organization-name chillarin-sdwan-lab
 vbond 10.0.12.1
exit
interface GigabitEthernet2
 ip address 10.0.12.2 255.255.255.252
 no shutdown
exit
commit
Commit complete.

第 2 コミットの内容は cEdge1 と同じ形です。結果は cEdge1 と対称になります。

! ===== [cEdge2] show sdwan control local-properties =====   (抜粋)
personality                       vedge
sp-organization-name              chillarin-sdwan-lab
organization-name                 chillarin-sdwan-lab
...
dns-name                          10.0.12.1
site-id                           20
domain-id                         1
protocol                          dtls
tls-port                          0
system-ip                         10.255.0.2
...
number-vbond-peers                1

INDEX   IP                                      PORT
----------------------------------------------------
0       10.0.12.1                               12346  

number-active-wan-interfaces      1

8.2 underlay は疎通する

cEdge1 から cEdge2 へ、VPN 0 の transport を送信元にして ping を打ちます。

! ===== [cEdge1] ping 10.0.12.2 source GigabitEthernet2 repeat 10 =====
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
Packet sent with a source address of 10.0.12.1 
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/1/2 ms

10 発すべて通ります。 経路はグローバル表にあります。

! ===== [cEdge1] show ip route =====   (VPN 0 = グローバル表)
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
...
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.12.0/30 is directly connected, GigabitEthernet2
L        10.0.12.1/32 is directly connected, GigabitEthernet2

§5.1 のとおり、IOS XE SD-WAN では VPN 0 に対応する VRF が作られないので、show ip route をそのまま打った結果が VPN 0 の中身になります。凡例の 4 行目に m - OMP があり、OMP で学習した経路を表す記号が最初から用意されています。 本ラボの表には m の行が 1 本もありません。

8.3 同じ相手・同じ経路に対して、DTLS は失敗している

制御接続の試行の記録を撮ります。このコマンドは、同じ機体で設定前に撮ったとき (§6) は 1 バイトも返しませんでした。 設定後は凡例と試行の行を返します。

! ===== [cEdge1] show sdwan control connection-history =====   (抜粋: 試行の行)
                                                                       PEER                      PEER
PEER     PEER     PEER             SITE        DOMAIN PEER             PRIVATE  PEER             PUBLIC                                   LOCAL      REMOTE     REPEAT
TYPE     PROTOCOL SYSTEM IP        ID          ID     PRIVATE IP       PORT     PUBLIC IP        PORT    LOCAL COLOR      STATE           ERROR      ERROR      COUNT ORGANIZATION            DOWNTIME
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vbond    dtls     0.0.0.0          0           0      10.0.12.2        12346    10.0.12.2        12346   biz-internet     connect         DCONFAIL   NOERR      3     2026-08-27T23:55:37+0000
vbond    dtls     0.0.0.0          0           0      10.0.12.2        12346    10.0.12.2        12346   biz-internet     connect         DCONFAIL   NOERR      8     2026-08-27T23:54:37+0000

この 1 行から読めることを並べます。

理由コードは同じ出力の凡例にあります。

! ===== [cEdge1] show sdwan control connection-history =====   (抜粋: Legend for Errors)
Legend for Errors
...
DCONFAIL   - DTLS connection failure.                  STNMODETD - Teardown extra vBond in STUN server mode.
...
NOERR      - No Error.                                 VS_TMO    - Peer vSmart Timed out.

Troubleshoot 文書は DCONFAIL を次のように説明しています (逐語)。

This is one of the common issues of control connectivity that does not come up. Probable causes include a firewall or some other connectivity issues.

原因として挙げられているのは 3 つです (逐語)。

The next hop (NH) router is not reachable. The default gateway is not installed in the Routing Information Base (RIB). The Datagram Transport Layer Security (DTLS) port is not open in the controllers.

上の 3 つのうち、前の 2 つは本ラボの状況に当てはまりません。 1 つ目 (next hop が到達不能) は、§8.2 のとおり宛先へ 10 発すべて届いていることと合いません。2 つ目 (既定ゲートウェイが RIB に無い) について、本ラボの show ip route はたしかに Gateway of last resort is not set と出ていますが、宛先 10.0.12.2 は直結の /30 上にあるので既定ゲートウェイを経由しません。残るのは 3 つ目です。宛先の 10.0.12.2 は Validator ではなく、もう 1 台の WAN Edge なので、そこで 12346/UDP を待ち受けている Validator は居ません。 ただし相手側のポートの状態を直接観測してはいないので、対応させたのは原因の分類までです。

この 2 つの観測が同じ網の状態で採られていることを、時系列で示しておきます。

記録された 2 行の DOWNTIME は、どちらも ping が通ったあとの時刻です。 ただし REPEAT COUNT は繰り返した回数の集約値なので、8 回のうち何回目までが ping より前だったかは、この出力からは分かりません。言えるのは、宛先が実在し ping が通っている時間帯にも、同じ宛先への DTLS が失敗し続けているということです。「宛先の IP に届くこと」と「そこで制御接続が成立すること」が、同じ相手・同じ経路・同じ時間帯で分かれて見えています。

ここで観測できているのは「制御接続が成立しない」ところまでで、認証の失敗ではありません。 相手は Validator ではなくもう 1 台の WAN Edge なので、証明書を見せ合う段まで進んでいません。証明書の不備・組織名の不一致・時刻のずれといった認証の失敗を切り分けるには、実際の Validator を相手にした対照が要ります。本ラボはそこを扱っていません (§10)。

8.4 オーバーレイを成立させる配布は、別の部品の仕事

underlay が疎通していることと、拠点間のオーバーレイが立つことのあいだには段があります。§4.3 のとおり、鍵と経路の配布は Controller の仕事です (逐語)。

It also orchestrates the secure data plane connectivity between the WAN Edge routers by reflecting crypto key information originating from WAN Edge routers, allowing for a very scalable, IKE-less architecture.

IKE-less であるということは、WAN Edge 同士が直接鍵を交換する経路を持たないということでもあります。IPsec の鍵は WAN Edge が生成しますが、それを相手へ届けるのは Controller です。本ラボは Controller を起動していないので、配布を担当する部品が構成の中に存在しません。

9. 実機: VPN の分離は Controller が無くても成立する

両機に service VPN 10 を作り、拠点 LAN の代わりに Loopback10 を入れます。

! ===== [cEdge1] config-transaction — service VPN 10 =====
vrf definition 10
 address-family ipv4
 exit-address-family
exit
interface Loopback10
 vrf forwarding 10
 ip address 192.168.10.1 255.255.255.0
 no shutdown
exit
commit
Commit complete.

投入した vrf definition 10 は数字だけの名前です。§5.1 で引いた “VRF definitions must be numbers only” の追認になります。6-2 では vrf definition CUST-A と名前を付けていました。

! ===== [cEdge1] show vrf =====
  Name                             Default RD            Protocols   Interfaces
  10                               <not set>             ipv4        Lo10
  65528                            <not set>             ipv4        Lo65528
  65529                            <not set>             ipv4        Lo65529

内部用の 65528 / 65529 と並んで VPN 10 が立ちます。

! ===== [cEdge1] show ip route vrf 10 =====   (抜粋)

Routing Table: 10
...
Gateway of last resort is not set

      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, Loopback10
L        192.168.10.1/32 is directly connected, Loopback10

Routing Table: 10 が表題です。 6-2 の Routing Table: CUST-A と並べると、分けているものは同じで、名前の付け方だけが違うことが見て取れます。

グローバル表の側には VPN 10 の経路が入りません。

! ===== [cEdge1] show ip route =====   (グローバル表には VPN 10 の経路が無い)
...
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.12.0/30 is directly connected, GigabitEthernet2
L        10.0.12.1/32 is directly connected, GigabitEthernet2

cEdge2 側も同じ形になります。番号は同じ 10 で、中身が違います。

! ===== [cEdge2] show ip route vrf 10 =====   (抜粋)

Routing Table: 10
...
      192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.20.0/24 is directly connected, Loopback10
L        192.168.20.1/32 is directly connected, Loopback10

分離は 1 台の中で完結する機能なので、Controller が居なくても成立します。 Controller が要るのは「その分離を拠点間でそろえて運ぶ」段からです。6-2 の言い方に直すと、VRF を作るところまでは PE 単体でできて、MP-BGP が要るのは経路を運ぶ段からだったのと同じ構造になります。ただし本ラボは、運ばれる側を実測していません (§10)。

10. 本ラボで確かめていないこと

本ラボが実機で確かめたのは §6〜§9 の範囲です。それ以外は出典の記述であり、次の各項は実測していません。

• 「ルータは Validator に最初に当たる」という順序。 §3.1 で引いた Design Guide の記述は “before attempting to connect to the other control components” であり、他の control component との前後関係を述べています。本ラボには比較対象となる control component が 1 つも無いため、「先」に対する「後」が存在せず、順序という事象そのものが発生しません。 §8.3 の connection-history に vbond の行が出たことは「最初に当たった」の証拠ではありません。ルータが Validator 宛ての接続として当たりに行った (PEER TYPE が vbond)、までを表します。本ラボの宛先は Validator ではなく、もう 1 台の WAN Edge です。
• Manager / Controller / Validator の実挙動。 起動・相互認証・設定配布 (§3 の 10 段階のうち①〜⑤) は、いずれも出典の記述であり実測ではありません。
• OMP による経路交換。 OMP セッションが存在しないため、§4.3 で扱った 4 種類の情報がどう運ばれるかは確かめていません。
• 証明書のフローと PnP による認可。 §6.2 で扱った関所は資料の記述で、本ラボは通していません。
• 認証が失敗する理由の切り分け。 §8.3 で観測した DCONFAIL は「宛先には届くが制御接続が成立しない」ところまでで、証明書の不備・組織名 (OU) の不一致・時刻のずれといった認証側の失敗とは別です。 これらを見分けるには実際の Validator を相手にした対照が要りますが、本ラボは Validator を起動していません。
• VPN 512 が OMP に載らないこと。 §5 で扱った「VPN 512 は OMP に無視される」(Design Guide の “This VPN is ignored by OMP”) は確かめていません。OMP が動いていないことに加えて、§6.3 のとおり この機体には Mgmt-intf そのものがありません。

! ===== [cEdge1] show ip route vrf Mgmt-intf =====
% IP routing table vrf Mgmt-intf does not exist

• 拠点間でのデータ転送。 オーバーレイの上をパケットが通る様子は撮っていません。§8.4 のとおり、鍵と TLOC を配る Controller が構成の中に存在しないためです。
• 何も返さなかったコマンド。 設定後の cEdge1 で show sdwan control connections / show sdwan omp peers / show sdwan bfd sessions の 3 つは何も返しませんでした。本節はこれを根拠にした主張を 1 つも置いていません。 出力が無いことは「機器にその能力が無い」ことを意味しないためです。

なお、show sdwan control connection-history が空であること自体は異常ではありません。 Troubleshoot 文書は “When no connection attempts are seen in the show control connection-history command, you can check for DNS resolution failure towards the vBond with these steps:” と書いて、試行が 1 行も記録されない状態に節を割いています。本ラボでも、同じ機体で設定前に撮ったときは何も返らず、設定後に行が現れました。

11. 落とし穴・補足

• allow-service all は個別の許可・不許可の一覧に展開されます。 §7.3 で投入したのは allow-service all の 1 行だけですが、running-config には次のように展開されて残ります。本ラボはこの展開の意味を追っていないので、all を入れたのに no が付く項目がある理由は確かめていません。

! ===== [cEdge1] show sdwan running-config =====   (抜粋: sdwan interface ブロック)
sdwan
 interface GigabitEthernet2
  tunnel-interface
   encapsulation ipsec
   color biz-internet
   allow-service all
   no allow-service bgp
   allow-service dhcp
   allow-service dns
   allow-service icmp
   no allow-service sshd
   no allow-service netconf
   no allow-service ntp
   no allow-service ospf
   no allow-service stun
   allow-service https
   no allow-service snmp
   no allow-service bfd
  exit
 exit

• vEdge 向けに書かれた資料のコマンドは、IOS XE SD-WAN では sdwan を挟んだ形になります。 Troubleshoot 文書は冒頭で “Enter the sdwan keyword in order to get the same outputs on Cisco IOS XE SD-WAN software. For example, show sdwan control connections instead of show control connections.” と断っています。SD-WAN の資料には vEdge の出力で書かれたものが多く、本節が show sdwan ... の形で撮っているのはこの対応関係によります。
• Personality: vEdge を旧名の痕跡と読むと誤ります。 §6.4 のとおり、これは control component か edge かを表すロール値です。同じ出力の Device role: cEdge-SDWAN と矛盾しません。
• system IP の “never advertised” を単独で引くと運用と衝突します。 §4.1 のとおり、同じ段落が「loopback にも割り当てて service VPN で広告する」ことを best practice として薦めています。広告されないのは system インタフェースに割り当てられた側です。
• 制御接続の本数と OMP セッションの本数は別に数えます。 §3.2 のとおり、DTLS/TLS の接続が transport の数だけあっても、WAN Edge と 1 台の Controller のあいだの OMP セッションは 1 本です。
• 同じ site ID を持つ機器同士は既定で IPsec を張りません。 §4.1 のとおりです。本ラボが site ID を 10 と 20 に分けているのはこのためですが、トンネルが張れる構成でも試していないので、site ID を揃えたときの挙動は確かめていません。
• organization-name は大文字小文字が区別されます。 証明書認証で OU フィールドとして照合される値なので、表記ゆれがそのまま不一致になります。本ラボは 2 台とも chillarin-sdwan-lab で揃えています。
• 時計は前提の 1 つに数えられています。 §6.5 の表のとおり、本ラボの機体は * 付きの未同期状態のままです。Troubleshoot 文書は CRTVERFL (証明書の検証失敗) の切り分けとして “Check the time with the show clock command. It must be at least within vBond certificate validity range” を挙げており、時刻のずれは証明書の検証に直接効きます。本ラボは証明書を持たないため、時刻を合わせた場合との差は確かめていません。
• config-transaction は candidate configuration を編集します。 §7.2 で引いたとおり、変更が効くのは commit を出したときだけです。configure terminal の「通った行だけ残る」挙動を前提にすると、拒否された後の状態を読み違えます。本ラボは拒否直後の状態を撮っていないので、ここは出典の記述に基づく説明です。
• VPN 番号には予約があります。 §5 のとおり 0〜65535 の整数で、0 と 512 が予約されています。設定できる上限は現行資料のあいだで 65525 / 65527 / 65530 に割れており、本節はどれか 1 つを正としません。 本ラボの機体に既定で見えた 65528 / 65529 の VRF は、65525 と 65527 よりは上、65530 よりは下の番号です。これらが資料のいう予約と同じものを指しているかどうかは、資料の記述からは決まりません。

12. 次節

本節では、事業者網主導だった 6-2 までの構成から、拠点側の機器がオーバーレイを張る Cisco Catalyst SD-WAN へ主語を移しました。仕事は 4 つの平面に割れ、Manager が管理、Controller が制御、Validator がオーケストレーション、WAN Edge がデータを担当すること。改名されたのは control components の 3 つだけで、cEdge は今も使う語であること。TLOC は system IP と color と encapsulation の 3 つ組で識別され、OMP は経路だけでなく鍵とポリシーも運ぶこと。分離は VPN 番号で行い、IOS XE SD-WAN では数字だけの VRF として現れること。

実機では、参加前の cEdge が SD-WAN の器を持ちながら 7 つの前提をすべて欠いている状態から始め、身元と transport を与えて TLOC がローカルに立つところまでを撮りました。設定には順序があり、IOS-XE 側の Tunnel を作らないまま SD-WAN 側の tunnel-interface を入れると commit ごと拒否されること。下回りは ICMP が 10 発すべて通るのに、同じ相手への DTLS は DCONFAIL になること (制御接続が成立しないところまでで、認証の失敗ではありません)。VPN の分離は Controller が居なくても 1 台の中で成立すること。確かめていないことは §10 にまとめてあります。

次節 6-4 SD-WAN 設計と運用では、本節が構成要素と用語の側から並べた内容を、設計と運用の側から見ていきましょう。transport の選び方、TLOC とポリシーの設計、冗長の取り方が主な論点になります。どこまでを実機で確かめられるかは本節と同じ制約を受けるので、扱う範囲は §10 の宣言と同じ形で明示します。

出典

本節が引用した Cisco 公式資料です。いずれも 2026 年 8 月 28 日に取得したもので、 本文中の引用はその時点のページの逐語です。

資料によって記述が食い違う項目があります（§5 の VPN 番号の上限は 65525 / 65527 / 65530 の 3 つが併存）。更新日を併記してあるのはそのためで、利用するリリースの資料で確認してください。

本節での主な用途は次のとおりです。4 平面と 4 構成要素・OMP / TLOC / color・VPN 0 / 512 は Design Guide、制御接続が張られる順序は Getting Started Guide、2 平面での説明は Solution Overview、設定モードと commit の意味は Command Reference、制御接続が張れない ときの理由コードと前提は Document ID 214509、cEdge の設定順序は Document ID 218137、 edge の bootstrap に認可ファイルが要ることは Certificates Deployment Guide と CML の DevNet ドキュメントです。