DMVPNオーバーレイでEIGRPネイバーが上がらない

トンネルは上がっていて、一方のスポークから他方へpingは通るのに、ハブ側ではEIGRPのネイバーが一つも表示されない。この組み合わせは謎ではなく正常です。pingが証明するのはNHRP経由のユニキャスト到達性であり、EIGRPのhelloはマルチキャストだからです。DMVPNオーバーレイでは、ルーティングプロトコルの配送モデルが二つ目の設定面になります。そして人々が飛ばしがちなのはまさにこの面で、一つ目の面がすでに健全に見えるからです。以下の各層はそれぞれ専用のコマンドで確認するので、一つの層で失敗しても一覧の先頭に戻ることはありません。

期待する隣接関係を書き出す

showコマンドを打つ前に、短い一覧を作ります。どのスポークがどのハブと、どのトンネルインターフェース経由で、どのEIGRP自律システムにおいてピアになるべきか。 マルチハブ構成はハブ間の隙間で壊れる。そして一覧があれば「EIGRPが壊れた」ではなく「スポーク3がハブ2に登録していない」と言えます。各リンクで期待するトンネルサブネットも書き添えてください。両端のアドレス不一致は、プロトコル障害とまったく同じに見えるからです。一覧はチケットに書いておき、次のシフトが直前のスクリーンショットではなく設計と比較できるようにします。

NHRPを確認し、次にマルチキャスト経路を確認する

まず登録状態と、ハブが実際に保持しているマッピングを見ます。ハブに動的エントリがないスポークは登録できておらず、ルーティングプロトコルでは直りません。次に、スポークがハブのNBMAアドレスからのマルチキャストを受け入れているか確認します。これはNHSエントリとは別の行です。

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

ip nhrp map multicast の行が、スポークのhelloをオーバーレイ上の複製マルチキャストとしてハブへ送れるようにし、ハブのマルチキャストを登録済みのスポークへ届かせます。これがなければNHRP経由のユニキャストは通り、マルチキャストは通りません。pingが証拠に見えるのは、まさにこの分断のためです。Ciscoの IOS XE DMVPNガイド はフェーズごとのハブとスポークのマルチキャスト動作を記述しているので、別トポロジから断片をコピーするのではなく、実際に展開したフェーズに設定を合わせてください。

EIGRP自身のインターフェースポリシーを確認する

EIGRPプロセスに入っていない、あるいはpassiveになっているトンネルは、オーバーレイがどれほど健全でも隣接を形成しません。インターフェースの参加状態とネイバーテーブルを併せて読みます。前者が後者を説明するからです。

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

認証とメトリックの重みは両端で一致している必要があります。モードの違うキーチェーンやK値の不一致は、受信側に目立つsyslog行を残さずにhelloを落とします。設計が明示的に設定したユニキャストネイバーを使うなら、マルチキャスト設定の上に重ねるのではなく、そのモデルに完全に従ってください。

GREの運搬とIPsecの保護を分けて考える

DMVPNはマルチキャストをGREの内側で運び、IPsecは内側のマルチキャストを直接守るのではなくGREパケットを保護します。だからこそ「IPsecはマルチキャストを運べない」という一般論は、この設計では誤りであり、診断としても役に立ちません。トンネルのIPsecプロファイル、各ピアのセキュリティアソシエーション、トンネルインターフェースの状態を、三つの別々の事実として確認します。

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

SAが上がっていてカウンタが動いているのにEIGRPが下がったままなら、調査はスタックの上へ戻ります。パケットは保護され配送されているので、問題はプロトコルがどのパケットを送ると決めているかです。

ネイバー数だけでなく経路を検証する

隣接ができたら、何を広告し、何をインストールしているかを読みます。マルチポイントトンネルでは、スプリットホライズンとネクストホップの挙動が、スポークがハブ経由で別のスポークに届くかを決めます。また集約は、ネイバー関係が完璧でもプレフィックスを隠すことがあります。

最後に、二つのサイト間で許可されたアプリケーションを通し、その経路を確認します。スポーク間の直接ショートカットは、独自のNHRPとセキュリティ状態を持つ転送要件であり、ネイバー数を良く見せるために追加すると、たいてい二つ目の問題を生みます。

フェーズ設計、マルチキャストマッピング、EIGRPポリシーを一か所に記録してください。次のエンジニアが必要とするのは設計であり、記録の写しではありません。