はじめに
このドキュメントでは、Overlay Management Protocol(OMP)の障害シナリオのトラブルシューティングと、Cisco SD-WANでネットワークの復元力を提供するためのベストプラクティスについて説明します。
前提条件
要件
Cisco Software Defined Wide Area Network(SD-WAN)ソリューションに関する知識があることが推奨されます。
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- Cisco IOS Catalyst SD-WAN Manager(別名vManage)
- Cisco IOS Catalyst SD-WANバリデータ(別名vBond)
- Cisco IOS Catalyst SD-WANコントローラ(vSmart)
- vEdgeデバイス
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。稼働中のネットワークで作業を行う場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
OMPの概要
ご存知のように、Cisco SD-WANエッジデバイスは、Catalyst SD-WANコントローラとのみルートを共有します。ルートを有効にし、転送テーブルにインストールするには、次の手順を実行します。
- ネクストホップTransport Locator(TLOC)が到達可能である必要があります。つまり、エッジデバイスには、TLOCの有効なルートが必要です。
- 指し示すTLOCがアクティブです。TLOCをアクティブにするには、アクティブな双方向フォワーディング(BFD)セッションをそのTLOCに関連付ける必要があります。BFDセッションは各デバイスによって確立され、各リモートTLOCとの個別のBFDセッションが作成されます。BFDセッションが非アクティブになると、Cisco Catalyst SD-WANコントローラはそのTLOCを指すOMPルートをすべて転送テーブルから削除します。
- OMPルートは最適として計算する必要があります。
これらの文はすべて論理的でわかりやすいものですが、障害シナリオでは、OMPとEnhanced Interior Gateway Routing Protocol(EIGRP)やOpen Shortest Path First(OSPF)などの従来のルーティングプロトコルの間には大きな違いがあります。
EIGRP障害のシナリオ
次のNetworkには、Site1、Site3、Site4の3つのサイトがあり、それぞれ1つのWAN接続を持つルータRTR1/RTR2、RTR3、およびRTR4があります。従来のルーティングプロトコルEIGRPはIPSec上で実行され、IP1、IP2、IP3、およびIP4はそれぞれの場所のWANインターフェイスIPアドレスです。

ここでは、RTR3とRTR4に焦点を当てながら、ネットワークを切り離す必要があります。RTR3では、10.1.4.0/24に到達するためのルートは、RTR3-RTR4間の直接トンネルを経由します。トンネルがダウンした場合、EIGRPはこの場合にどのように反応しますか。トンネルがダウンするとすぐに、EIGRPは10.1.4.0/24ネットワークの隣接ルータにクエリーを実行して送信し、受信した応答に基づいてそれを検査し、ベストパスの計算の後にルーティングテーブルの宛先への新しいパスをインストールします。
これは、従来のルーティングプロトコルのコンバージェンスプロセスを非常に簡単に説明したものです。したがって、EIGRPのような従来のルーティングプロトコル全体では、ネットワークの再計算を実行できます。
- 宛先への現在のルートがダウンしたとき
- 宛先にフィジブルサクセサがない場合
- トポロジの変更が発生したとき
OMP障害のシナリオ
ここでは、OMPの2つの障害シナリオについて説明します。
- 直接的な障害
- 間接的な障害
直接的な障害
次のトポロジでは、単一のトランスポート接続を持つ3つのサイトがあります。
サイト
|
ルータ
|
トランスポートロケータ(TLOC)
|
システムIP
|
サブネット
|
SIte1
|
vEdge-1
vEdge-2
|
T1
T2
|
1.1.1.1
2.2.2.2
|
10.1.1.0/24
|
サイト 3
|
vEdge-3
|
T3
|
3.3.3.3
|
10.1.3.0/23
|
サイト4
|
vEdge-4
|
T4
|
4.4.4.4
|
10.1.4.0/24
|

Catalyst SD-WANコントローラでは、すべてがデフォルトに設定されていると仮定します。vEdgeデバイスは、ルーティング情報をCatalyst SD-WANコントローラと直接共有し、コントローラはすべてのvEdgeデバイスと共有します。次のトポロジは、すべてのルータのルーティングテーブルを示しています。

現在、すべてのBFDセッションがアップしています。
vEdge-DC1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1 1 up mpls mpls 60.1.1.1 20.1.1.1 12346 ipsec 7 1000 0:00:03:12 0
2.2.2.2 1 up mpls mpls 60.1.1.1 10.10.20.2 12406 ipsec 7 1000 0:06:28:51 0
4.4.4.4 2 up mpls mpls 60.1.1.1 30.1.1.1 12386 ipsec 7 1000 0:00:00:51 0
vEdge-DC1# show omp routes vpn 20 | t
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
20 10.1.1.0/24 2.2.2.2 43 1005 C,I,R installed 1.1.1.1 mpls ipsec -
2.2.2.2 37 1006 C,I,R installed 2.2.2.2 mpls ipsec -
20 10.1.3.0/24 0.0.0.0 66 1005 C,Red,R installed 3.3.3.3 mpls ipsec -
20 10.1.4.0/24 2.2.2.2 45 1006 C,I,R installed 4.4.4.4 mpls ipsec -
vEdge3とvEdge4の間の接続が無効になっている場合、トンネルがダウンすると、vEdge3とvEdge4の両方のBFDセッションもダウンします。これにより、それぞれのルートが「Invalid」および「TLOC Unresolved」としてマークされます。 次の出力でこれを確認できます。
vEdge3# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.1 1 up mpls mpls 60.1.1.1 20.1.1.1 12386 ipsec 7 1000 0:05:57:27
2.2.2.2 1 up mpls mpls 60.1.1.1 10.10.20.2 12426 ipsec 7 1000 0:05:57:27
4.4.4.4 4 down mpls mpls 60.1.1.1 30.1.1.1 12406 ipsec 7 1000 NA
vEdge3# show omp routes vpn 20 | t
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
IA -> On-demand inactive
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 10.1.1.0/24 2.2.2.2 43 1005 C,I,R installed 1.1.1.1 mpls ipsec -
2.2.2.2 37 1006 C,I,R installed 2.2.2.2 mpls ipsec -
1 10.1.3.0/24 0.0.0.0 66 1005 C,Red,R installed 3.3.3.3 mpls ipsec -
1 10.1.4.0/24 2.2.2.2 45 1006 Inv,U installed 4.4.4.4 mpls ipsec -
間接的な障害
「間接障害」を理解するために、制御ポリシーがvEdge2経由のルート10.1.4.0/24に対するvEdge3のネクストホップを変更するように定義され、vEdge4では10.1.3.0/24のネクストホップがvEdge1に変更されると仮定します。つまり、vEdge 3と4の間のトラフィックの場合、vEdge 2と1は中間ホップとして挿入されました。次の図で確認できます。

T2-T4間のオーバーレイトンネルがダウンしている間に、vEdge2とvEdge4の間で接続損失を引き起こすネットワーク障害がある場合、vEdge3には引き続きT2を経由する10.1.4.0の有効なルートがあります。したがって、トラフィックをvEdge2に送信します。vEdge2にはvEdge4との有効なトンネルがないため、ルートがアクティブではなくなるため、トラフィックがドロップされます。

前述のログとテストから、次のように結論付けられます。
- OMPでは、ルーティングピアとネクストホップの自動検出はありません
- トンネルがダウンしても、トポロジの再計算は行われません
- トンネルがダウンしても、宛先プレフィクスへのOMPルートは変わりません。発生する唯一の変更は、ネクストホップ、つまりTLOCへの到達可能性です。
- 直接オーバーレイ障害の場合は、同じ宛先への複数のトンネルによるトンネルの冗長性を提供する必要があります。
- オーバーレイパスに中間ホップ/ホップを導入する際には特別な注意を払う必要があり、トラフィックの不足ホールを回避するためにトンネルの冗長性を確保する必要があります。
これで、OMPはデフォルトでオーバーレイの障害時に再計算や再ルーティングを行わないことがわかりました。この問題を解決するには、コントロールポリシーを使用して「TLOC-Action」と呼ばれる機能を有効にします。
TLOCアクション
- Cisco SD-WANでは、制御ポリシー内の「TLOCアクション」により、送信元から宛先までの完全なパスに対する可視性を維持しながら、トラフィック転送に使用される中間ホップ(TLOC)を挿入できます。つまり、TLOCアクションオプションを設定することで、Cisco Catalyst SD-WANコントローラは、最終的な宛先デバイスへのパスのエンドツーエンドのトラッキングを実行できます。そのパスがダウンすると、コントローラはこのOMPルートを受信したWANエッジルータに通知します。
- プライマリリンクに障害が発生した場合にバックアップパスを提供するため、SD-WANオーバーレイネットワーク内のネットワークの復元力と耐障害性が向上します。これは、宛先に到達するために使用されるTLOCを操作することにより、トラフィックがネットワークを通じてどのようにルーティングされるかを制御する方法です。
- ポリシーにTLOCアクションが定義されている場合、SD-WANコントローラに対して、ルート計算に中間TLOCを挿入するよう指示します。つまり、必要に応じて、トラフィックは最終的な宛先に到達する前に、最初に指定された「バックアップ」場所に到達します。
- これは、プライマリリンクがダウンした場合でもトラフィックを別のパス経由で(指定されたTLOC経由で)自動的に再ルーティングして接続を保証する必要があるシナリオで特に役立ちます。
次のトポロジでは、vEdge2、vEdge3、vEdge4に焦点を当て、より理解を深めましょう。現在、ポリシーは定義されておらず、vEdge3の10.1.4.0/24のデータトラフィックは、T3とT4の間の直接トンネルを通過しています。

耐障害性とネットワークの復元力を提供するために、制御ポリシーは、(指定されたTLOCを介して)別のパスを介してトラフィックを再ルーティングするように設定されます。

- vEdge4は、直接接続されたネットワーク10.1.4.0/24のOMPアップデートを、ネクストホップT4を使用して「T4経由で10.1.4.0/24」としてCatalyst SD-WANコントローラに送信します。
- このルートは、SD-WANコントローラで設定されている制御ポリシーと一致し、それに定義されているポリシーに従って新しいTLOCおよびTLOC-Actionsを設定します。つまり、新しい「中間TLOC」を挿入します。
- コントローラは、2つのネクストホップ(中間TLOC(T3、3.3.3.3)と最終的なTLOC(元のルートのネクストホップT4))を使用して、OMPルートをvEdge1にアドバタイズします。 これにより、vEdge1には、宛先プレフィックス10.1.4.0/24がT2およびT4経由で到達可能であるという情報が提供されます。
TLOC-Actionで定義されたvEdge1に基づいて、10.1.4.0/24のトラフィックを転送します。したがって、コントロールプレーンポリシーで次の4種類のTLOCアクションを定義できます。
- Strict(デフォルト):「TLOC-Action strict」では、vEdge1とvEdge4の間のトラフィックはT3(中間ホップ)を経由する必要があり、vEdge1とvEdge4の間のトンネルがダウンした場合にトラフィックはドロップする必要があると定義します。
- プライマリ:「TLOC-Action primary」は、vEdge1とvEdge4の間のトラフィックが中間ホップT3(3.3.3.3)を通過し、このオーバーレイトンネルがダウンした場合に、SD-WANコントローラはvEdge1に通知し、トラフィックは直接トンネルを介してT4にルーティングされるように定義します。
- バックアップ:「TLOC-Action backup」は、vEdge1とvEdge4の間のトラフィックが最終的なLOC(元のルートのネクストホップ – T4)に直接送られ、vEdge1とvEdge4の間の直接オーバーレイトンネルがダウンした場合に、SD-WANコントローラがvEdge1に通知を行い、トラフィックが中間ホップT3を通るように定義します。
- Equal-Cost Multi-Path(ECMP):「TLOC-Action ECMP」では、通常の状況では、vEdge1とvEdge4の間の通信は、中間ホップT3および最終ホップT4を介してロードバランシングされます。