DMVPN WANフェイルオーバー：ルートポリシーか、トンネル停止か

二つのWANを持つDMVPNハブのフェイルオーバーには二通りあり、違いは見た目より大きい。一つはルートポリシーが選ぶ次ホップを変えるもので、パケットは流れ続け、変わるのは出口だけです。もう一つはトンネルを管理上停止するもので、そのインターフェース上のすべてのサービスを道連れにします。どちらも正解になり得ます。答える問いが違うからです。

決断は設定より先に来る

三つの条件がこれを決めます。トンネルインターフェースが上がっていることに他が依存していないか。たとえば二つ目のDMVPNプロファイルや、その状態を読む監視です。また、フェイルオーバーすべきトラフィック が独自のポリシーを持つのか、それともグローバルなルーティングテーブルに頼るのか。そして運用者に紛れのない状態変化が必要か、静かな経路切替で足りるか。この三つに答えると、選択はおおむね自ずと決まります。

停止が動いているサービスを巻き込むなら、ルートポリシーのほうが小さな操作です。プライマリWANが落ちている間はトンネルが存在してはならない、という要件なら、ポリシーの項目では表現できません。

答えを書き留めてください。設定は簡単な部分です。

ルートポリシーが実際に変えるもの

ポリシーベースルーティングでは、追跡対象オブジェクトが次ホップを制御できます。ルートマップの項目は候補の次ホップと、それを使うために上がっている必要がある追跡対象オブジェクトを指定し、その追跡状態はIP SLAプローブから来ます。オブジェクトがダウンすると項目は一致しなくなり、パケットは次の項目または通常のルーティングテーブルで評価されます。

最後のこの点は人を驚かせます。次ホップの選択をやめるポリシーは通常、トラフィックを遮断するのではなく、通常のルーティングを許可します。もし 障害時のブラックホール が必要なら、自分で書く必要があります。

構文はプラットフォームとリリースで異なるので、実際に動かしているバージョンのガイドを確認してください。

トンネル停止が変えるもの

インターフェースを停止すると管理状態が変わります。それに依存するすべてのトンネル、ルート、セッションが一斉にダウンし、トンネルこそ消えるべきものなら、まさに望む結果です。EEMアプレットがWANの問題を、無関係なサービスまで含む障害に変えてしまうのも同じ仕組みです。

この道を選ぶなら、アプレットを一つのインターフェースと一つのトリガーに限り、以前の管理状態を保存し、復旧アクションを定義し、繰り返しのフラップがループに陥らないようにしてください。

ハードコードされた復旧コマンドは、他の人が行った保守停止を上書きすることもあります。

プローブを思った経路に通す

現在の最良ルートに従うプローブは、他のすべてと一緒にバックアップWANへ移り、もうそれを使っていないという理由でプライマリを正常と報告します。

プローブは、テストする経路のインターフェースか送信元アドレスに固定します。何を狙っているかも確認してください。ISPの次ホップに届くことは、トンネルの存在理由であるサービスに届くことより弱い証拠です。アップとダウンの遅延は意図的に設定します。短いダウン遅延は素早く反応してフラップし、長い遅延は小さな揺らぎをやり過ごして本当の障害を隠します。Ciscoの IOS XEにおける追跡とポリシールーティングのガイド が対応する組み合わせを記載しており、お使いのプラットフォームの機能セットがそのどれを使えるかを決めます。

両方の遅延値を追跡対象オブジェクトの横に記録してください。そうでなければ、なぜそう振る舞ったのか誰にも分かりません。

復旧を決め、それから検証する

復旧には独自の決断が必要です。しきい値を何度も跨ぐリンクは、明らかに失敗したリンクより頻繁にセッションを移すことがあり、移動のたびに鍵の再交渉とアプリケーションの再試行が発生します。安定性の要件を選び、遅延にそれを表現させてください。そのうえで変更ウィンドウ中に、プローブの経路を見える状態で検証します。選択されたルート、外側のピア経路、そしてアプリケーションが実際に何をしたかです。

フェイルオーバーが機能してもアプリケーションが壊れるなら、問題はルーティング層より上にあり、どれだけ追跡しても直りません。

そのウィンドウの証拠を保存してください。次の変更はそれと比較されます。