BGPセッションは稼働、顧客経路は破断：DMVPN上のMPLS

ピアリングは何週間も上がったままで、プレフィックス数も正しく見えるのに、ある顧客のトラフィックはいまだに遠回りをするか、まったく届かない。同じ指標で二つの別のものを判定している。BGPセッションが示すのは、二つのピアがTCP接続でメッセージを交換できるということであり、オーバーレイがその特定の顧客向けのラベル付きパケットを運べるかどうかについては何も語らない。

この隙間はMPLS over DMVPNの設計で最も見えやすい。ハブ経路と直接のスポーク経路が、ピアリングとは無関係な理由で異なる挙動を示すことがあるからだ。

セッションが実際に証明するもの

BGPはTCP上で動くため、他の何かが起きる前に、各ピアは相手側端点のアドレスへの経路を必要とする。その端点にループバックを選べば、転送の保証ではなく到達性の要件を作ったことになる。セッションはその後も、顧客トラフィックが決して使わないインターフェースを通って上がったままでいられる。

結論を出す前に、両端で四つの事実を記録する。セッションの送信元アドレス、宛先アドレス、それが属するルーティングコンテキスト、そしてカーネルやルーターがその組に対して選ぶインターフェースだ。これらの事実はコントロールプレーンを記述している。顧客のパケットはその上にVRF、ラベルスタック、オーバーレイのマッピングを加える。

四つの仕組みであり、一つではない

MPLS over DMVPNに関するCiscoのドキュメントは、部品を明確に分けている。MP-BGPはプロバイダーエッジ装置間で顧客オーバーレイのラベルを配布する。MPLSはそのラベルを使ってパケットの転送コンテキストを選ぶ。NHRPはオーバーレイアドレスを、動的トンネルが必要とするトランスポート端点へ対応づける。IPsecは該当する場所でピア経路を保護する。

四つのうちどれかが正しく、別のものが誤っていることはあり得るし、トラフィックを運ぶのはその組み合わせだ。経路交換が完了していても、あるVRFのラベル束縛が欠けていたり、NHRPマッピングが古いトランスポートアドレスを指していたり、トンネルはあるが内部パケットを許可するポリシーがないことがある。これらのどれもセッションを落とさない。

ハブ経路と近道を比べる。一度に一つの変数だけ

送信元ホスト、宛先ホスト、VRFを固定し、同じフローを二度たどる。ハブ経路では、次のホップ、遠隔の顧客コンテキストを識別するサービスラベル、使用中のオーバーレイからトランスポートへのマッピングを記録する。意図した直接経路でも同じ三つを記録する。二つの一覧の差が障害であり、あるいは障害がないことの証拠だ。

比較の間はフローを一定に保つ。観測の合間に送信元ホスト、VRF、宛先を変えると、無関係な二つの物語ができあがる。この演習が失敗する最も一般的な理由がこれだ。

ループバック試験は別の区画に置く

ルーターのループバックを送信元とするpingは有用な試験であり、ホストからのフローとは別のケースを試す。送信元アドレスはルーターのもので、ルーティングコンテキストはVRFではなくグローバルかもしれず、戻りの経路も顧客プレフィックスがたどるものと異なり得る。だからループバックが応答することと、このアプリケーションが近道で動くことは別々の結果であり、顧客を記述するのは後者だけだ。

両方を試し、ノートでは別々に印を付ける。両者が食い違ったとき、設計がどこでずれているかについて具体的な何かを学んだことになる。緑のチェックマーク一つが教えてくれることより、はるかに多い。

バージョンと不具合の主張には、それぞれの証拠が要る

現場報告はときどきホストマスクやBGPの送信元アドレスを変えるよう勧めるが、そうした報告は、書かれた対象の不具合と影響を受けたリリースと併せて読んで初めて意味を持つ。一つのリリースの回避策は、アーキテクチャがどの/32プレフィックスも支援しないという主張ではない。

DMVPNのフェーズ、プラットフォーム、リリースに合ったドキュメントを使い、一つの章がFlexVPNを含む複数の構成を扱い得ることを覚えておく。ある構成の例が別の構成へ黙って移ることはない。本当に必要なコントロールプレーン設計に合わせてセッション端点を選び、それから顧客の転送経路を別に検証する。すべてのループバックマスクを書き換えることは、どの作業が失敗したかを見つける代わりにはならない。