1.2Cisco Catalyst SD-WAN

従来のWANでは、拠点ごとにルータへログインして経路とポリシーを個別に設定していました。Cisco Catalyst SD-WAN（旧 Viptela）は、この「経路をどう選ぶか」という制御と「実際にパケットを運ぶ」データ転送を分離し、制御を集中コントローラに寄せることで、拠点を増やしても設定作業が線形に増えない構造を作ります。ENCOR で問われるのは製品名の羅列ではなく、4つのコンポーネントの責務がどう分かれているか、そしてあるコンポーネントが落ちたとき何が止まり、何が止まらないかという診断です。

1.2.1コンポーネントの責務

• vSmart＝制御プレーン。各エッジからOMP（Overlay Management Protocol）で受け取った経路・TLOC（トランスポート接続点）・サービス情報を集約し、ポリシーを適用したうえで各エッジへ再配布する。BGP のルートリフレクタに近い立ち位置で、エッジ同士は直接経路交換せず vSmart 経由で学習するのが要点。
• vManage（SD-WAN Manager）＝管理プレーン。GUI/API による集中設定（テンプレート）、監視、ソフトウェア管理、トラブルシュートの入口を提供する。設定変更と可視化の窓口であって、パケットの転送判断にも経路配布にも直接は関与しない。したがって vManage が落ちても既に投入済みの設定でデータ転送は継続する。
• vBond＝オーケストレーションプレーン。新規/再起動したエッジを認証し、vSmart・vManage の所在を教えてファブリックへ参加させる仲介役。NAT の背後にいるエッジのために NAT トラバーサルも担う。常時の経路配布には関与しないが、vBond に到達できないエッジは新規にオンボードできないという形で効いてくる。
• cEdge/vEdge＝データプレーン。実際にトラフィックを転送するルータで、拠点や DC に置かれる。エッジ間には IPsec トンネルが張られ、vSmart から受け取った経路とポリシーに従ってどのトランスポート（MPLS・インターネット・LTE 等）へ流すかを決める。cEdge は IOS XE ベース、vEdge は Viptela OS ベースという系譜の違いがある。

1.2.2利点と限界

• 利点＝回線コストの最適化（高価な MPLS 専用線に加えて安価なインターネット回線やLTEを束ね、アプリケーション単位で使い分ける）、集中ポリシー（テンプレートとポリシーを vManage/vSmart から一括適用し、拠点ごとの設定ドリフトを抑える）、ゼロタッチに近い展開（vBond によるオンボーディング）、可視化（アプリ単位の性能監視と経路の動的切替）。
• 限界＝コントローラ依存（制御と管理が集中するため、コントローラの可用性設計と到達性が新たな設計課題になる）、学習/移行コスト（従来のルーティング運用とは別のテンプレート/ポリシー体系を習得する必要がある）、トラブルシュートの階層が増える（オーバーレイの障害か、下のトランスポート回線の障害かを切り分ける必要がある）。「SD-WAN にすれば回線品質そのものが良くなる」わけではない点は設計上重要。

1.2.3OMP による経路配布と障害の切り分け

• OMPはエッジと vSmart の間で OMP 経路（宛先プレフィックス）・TLOC（どのトランスポートのどの接続点から到達できるか）・サービス経路（ファイアウォール等のサービス挿入先）を交換する。エッジは vSmart から受け取った情報でオーバーレイの転送表を作るため、vSmart との制御接続が切れると新しい経路情報が入ってこなくなる。
• 切り分けの原則：vManage 障害＝設定変更と監視ができないがデータ転送は継続／vSmart 障害＝新しい経路配布とポリシー更新が止まり、トポロジ変化に追随できなくなる／vBond 障害＝既存の通信は継続するが新規エッジのオンボードができない。「全拠点が同時に通信不能」なら、まず疑うのはコントローラよりも共通のトランスポート回線側である。

あなたは40拠点を Catalyst SD-WAN で運用しており、ある朝「vManage の GUI にログインできない」という報告を受けました。ここでまず確認すべきは、拠点の業務通信が実際に止まっているかどうかです。利用者に確認すると、既存拠点間の業務アプリは正常に動いており、監視ダッシュボードだけが見えない状態でした。この事実から障害は管理プレーンに限定されていると判断できます。vManage は設定テンプレートの投入と可視化を担いますが、エッジは既に受け取った設定と、vSmart から学習した OMP 経路に従って自律的に転送を続けるため、vManage が落ちてもデータプレーンは動き続けるのです。したがってこの時点で「全拠点のエッジを再起動して復旧を図る」のは最悪の一手で、再起動したエッジは復帰時に vBond への到達と vSmart との制御接続確立を必要とするため、管理面だけの障害を、通信断を伴う本物の障害に格上げしてしまいます。正しい手順は、まず vManage 自身の可用性（クラスタ構成なら他ノード、到達経路、証明書の有効期限）を確認し、その間にエッジ側で show sdwan control connections に相当する確認を行って vSmart への制御接続が維持されていることを裏取りすることです。逆に、もし報告が「特定拠点だけが、新設した拠点との間だけ通信できない」であれば、疑うべきは vManage ではなく、vSmart でのポリシー適用（TLOC やプレフィックスのフィルタで意図せず経路が配布されていない）か、新拠点のオンボーディング（vBond 到達性・証明書）です。さらに「全拠点が同時に、しかもインターネット回線経由のトンネルだけ落ちた」のであれば、コントローラではなく共通のトランスポート回線（ISP側）を先に疑うのが筋です。SD-WAN のトラブルシュートは、症状の範囲（全拠点か一部か）と、止まっている機能の種類（転送か、設定変更か、新規参加か）の2軸で切り分けると、疑うコンポーネントが一意に絞り込めます。

1.2.4この節のまとめ

• vSmart＝制御（OMPで経路/TLOCを集約し再配布）、vManage＝管理（設定/監視）、vBond＝オーケストレーション（認証・オンボーディング）、cEdge/vEdge＝データ（IPsecで実転送）
• 障害切り分けは症状の範囲（全拠点か一部か）と止まった機能（転送／設定変更／新規参加）の2軸で行う。vManage 障害でも転送は継続する
• 利点は回線コスト最適化・集中ポリシー・展開の容易さ、限界はコントローラ依存・学習コスト・切り分け階層の増加。回線品質そのものが良くなるわけではない