SD-WAN: system-ip 付与における設計上の注意点

[Akira Iwamoto]

• はじめに
• 各コンポーネントの動作
• DNS Resolver の ip address をsystem-ip として付与できない
• default gateway のアドレスを system-ip として付与できない
• 事象からの回復方法

 

はじめに

Cisco SD-WANのソリューションは、Amazon AWS, Microsoft Azure などのPublic Cloudにコントローラを作成する場合と、自らが管理するデータセンタ内にある、オンプレミスのCloudに作成する場合があります。

いずれの場合においても system-ip を付与にするに当たり、重複などが無いよう、アドレス選択には注意が必要です。 

以前報告された、問題となったケースについて、例を提示しながら解説します。

各コンポーネントの動作

vManage/vSmart/vBond などのコントローラや、vEdge となる vEdge Cloud, vEdge ハードウェア機器、cEdge ハードウェア機器では、system-ip に指定された ip アドレスを /32 アドレスとして、自コンポーネント内のルーティングテーブルに connected (AD=1) としてインストールします。この prefixを omp を介して広報することで、system-ip アドレス宛に他のコンポーネントから接続することが出来るようになっています。

DNS Resolver の ip address をsystem-ip として付与できない

vManage における問題として、以下のような問題が報告されましたが、これは vSmart/vBond/vEdge 等他のコンポーネントにおいても重要です。

Ciscoが提供する AWS 上のSD-WANコントローラには、デフォルトで vManage には 1.1.1.1 という system-ip が設定されています。そのため、1.1.1.1 への接続は、ローカルホストへの接続となります。

一方、1.1.1.1 を DNS Resolver として設定した場合、その接続先はローカルアドレスとなるため、名前解決出来なくなり、種々の問題が発生します。Resolverに 1.1.1.1 を使用する場合は、vManage の system-ip を変更する必要があります。  

default gateway のアドレスを system-ip として付与できない

AWS 上に提供されるコントローラは、それらのインターフェースは private address 10.x.x.0/24 のIPアドレスセグメントに接続されています。また、vpn 0/vpn512 のそれぞれのデフォルトゲートウェイは、それぞれのセグメント上にあります。

報告された事象の中では、10.0.2.1 は、vSmart の vpn 0 のデフォルトゲートウェイとして使用されていました。vSmart がこのアドレスへ接続性を失うと、すべての vEdge への OMP 接続が影響を受けダウンします。

このとき、SD-WAN Overlayに接続された vEdge では、system-ip に 10.0.2.1 が使用されていたため、vEdge 内に 10.0.2.1/32 がインストールされ、また OMP によって vSmart へ広報されました。vSmart はそれを受信した結果、10.0.2.1/32 は 当該 vEdge へのトンネルの先にあるといった認識をし、ルーティングテーブルへインストールします。

vSmart は、10.0.2.1 へのデフォルトゲートウェイとしての接続性を失い、当該 vEdge へのセッションを含む、すべての OMP セッションがダウンします。またこれをトリガーとして、vSmart はルーティングテーブルから、10.0.2.1/32 のトンネル向き経路を削除します。

これによって、デフォルトゲートウェイへの接続性は回復し、OMP セッションの状態も回復します。しかしながら、OMPが動作することにより、再度 10.0.2.1/32 を受信し、同様の事象が発生します。

これを繰り返すことで、vEdge からは vSmart へのOMPセッションの Up/Down を繰り返し、不安定な状態が発生します。

事象からの回復方法

一度 vEdge から広報された system-ip について、vSmart 上ではそれを記憶しています。本事象が発生した場合は、vEdge の system-ip を変更し、vSmart の再起動を行い復旧を行ってください。