EIGRP 隣接か DMVPN トランジットか。まず役割を確認する

隣接が欠けていて、真ん中のルーターが明らかな容疑者に見える。だが無実かもしれない。外側のトンネルパケットを転送することと、オーバーレイのルーティングプロトコルに参加することは別の仕事であり、機器は後者をせずに前者だけをこなせる。以下の五つの確認を順に行い、最初に失敗したところで止める。

ステップ 1: 二つの役割を描く

想定している EIGRP 隣接を 二台のルーター間の論理接続として描き、次にそのトンネルパケットを運ぶアンダーレイのルーターを描く。同じ機器が両方の一覧に載る必要はなく、この一覧を混同することが、健全なトランジットルーターが隣接を壊したと疑われる最大の原因である。

トランジットルーターは通常の IP ルーティングとポリシーで外側のパケットを転送する。保護されたトンネルの中で運ばれるプロトコルを動かす必要はなく、そのパケットを通過させるのに EIGRP プロセスも要らない。

ステップ 2: 中央の機器が何を終端するか確認する

中央のルーターがトンネルを終端し、スポークとの EIGRP 隣接を形成する立場なら、答えはまったく変わる。その機器にはサポートされたオーバーレイルーティングの動作が必要であり、トランジットと呼んでも隣接の要件は消えない。ルーティング設定より先にトンネル設定を読む。その答えが以降のすべての確認を決める。

つまり最初の本当の問いは、どのプロトコルを調整するかではない。その箱がハブか、スポークか、単なるアンダーレイのホップか、端点間でフレームを運ぶ Layer 2 サービスか、という問いである。

ステップ 3: 隣接のコントロールプレーンを確認する

隣接すべき各機器で 四点を確認する。EIGRP インスタンスと自律システム番号、認証パラメーター、プロセスに参加するインターフェース、そのインターフェースをカバーするネットワーク文である。どれか一つでも食い違えば、インターフェースは上がり ping も通ったまま、隣接はダウンしたままになる。

RFC 7868 は EIGRP をマルチキャストの制御交換を伴う IP プロトコルとして記述している。だからこそ隣接関係は、中間ルーターがパケットを宛先へルーティングすることで代理できるものではない。制御交換がピアに届くか、隣接が形成されないかのどちらかである。

ステップ 4: 制御交換が伝達されることを確認する

次に、オーバーレイが想定した端点間で制御トラフィックを実際に運んでいるかを確認する。ピアの NHRP マッピングとそこへ到達する外側ルートを調べ、トンネルインターフェースが上がっていてトラフィックが通ることを確かめる。アンダーレイの ping が通ることは外側の経路の存在を示すだけで、オーバーレイの制御交換が届いたことは示さない。

透過的な Layer 2 サービス、ポイントツーポイントのトンネル、マルチポイントの DMVPN クラウドでは、マルチキャストの伝達方法が異なる。どれも同じように振る舞うと決めつけず、実際に導入した方式のサポートされたインターフェース、NHRP、マルチキャストのモデルに従う。

ステップ 5: 参加できないなら境界を再設計する

必要なオーバーレイ機器がプロトコルを動かせないなら、設計を明示的に変える。その境界でサポートされたプロトコルや交換モデルを使うか、隣接する機器どうしが実際に話す端点になるよう適切なエンドツーエンドのトンネルを用意する。スタティックルートが、不参加の機器をすべての制御パケットの中継役に変えると決めつけてはいけない。

図に各機器の役割を記し、設定と一緒に保管する。RFC 7868 が定めるプロトコル交換の定義が、トランジット転送で隣接関係を模擬できない理由の拠りどころである。

五つの確認をすべて終えても隣接しない場合、残る容疑者はトンネルインターフェースでのマルチキャスト処理やプロトコル 88 をフィルタするポリシーといったプラットフォーム機能である。これらは具体的で検証できる原因であり、真ん中のルーターを責めるもう一巡より価値がある。