前の話で、距離だけで測る世界と、全員で地図を共有する世界の間に立つ第三の道に出会った。
EIGRP は、隣の話だけで地図を描く設計だった。
隣の話だけで地図を描く EIGRP なら、その隣との関係そのものが成立条件になるはずだ。どうやって始まり、どうやって「いま生きている」と分かるのか。
OSPF で身につけた neighbor を読む目は、ここでも役に立つ。Hello を交わして相手を見つけ、Hello が止まれば関係が失われる。そこまでは同じだ。
R1 と R2 は直結のセグメントで Hello も届いているのに、show ip eigrp neighbors に R2 の行が現れない場面がある。
「Hello が届いているなら neighbor になるはず」と考えていると、手が止まる。
EIGRP neighbor adjacency は、Hello を送り合った両側で、AS 番号と K 値が一致したときに、お互いを隣として登録する関係だ。


考えてみよう
本話に入る前に、5 秒だけ自分の頭で先に置いてみてほしい。OSPF で身につけた「Hello で隣を見つける」感覚は、EIGRP でもそのまま使えるだろうか。もし違いがあるとしたら、何が違うだろうか。
「Hello の間隔が違うくらいだろう」と予想したなら、その予想を持ったまま読み進めてほしい。EIGRP では、Hello が届いていても、お互いを隣として登録しない場面がある。
隣の話だけで動くなら、隣との関係を先に見る
EIGRP を読む入口は、前の話で見た「隣の話だけで地図を描く」という一文にある。
全員が同じ地図を持つ OSPF の世界では、Hello が往復して相手を見つけ、Hello が来なくなれば一定時間のあとで相手を失う。
EIGRP も、最初の見た目は似ている。R1 と R2 が直結のセグメントでつながり、お互いに Hello packet を出して、相手の存在を知る。ここまでは OSPF の記憶と重なる。
違いは、そのあとにある。
EIGRP は隣から「あなたから見た距離はこれだけ」という情報を受け取り、その距離に自分から隣への距離を足して経路を選ぶ。隣の計算結果をそのまま自分の判断に使う設計だから、ただ相手がそこにいるだけでは足りない。相手と自分が同じ EIGRP の世界で話しているか、同じ前提で距離を測っているか。そこまで揃って初めて、お互いを隣として登録する。
この違いを見落とすと、show ip eigrp neighbors に行がない場面で、見直す方向を間違える。
行がない場面では、「Hello は届いているのか」だけでは足りない。「Hello は届いているとして、AS 番号と K 値は両側で一致しているのか」まで見る必要がある。
Hello packet と Hold time は、隣の存在を生かし続ける
まず、EIGRP でも Hello packet が隣を見つける入口になる。
R1 が Hello packet を出し、R2 が受け取る。R2 も Hello packet を出し、R1 が受け取る。片側だけが相手を見つけた状態では、まだ安心できない。R1 から R2 へ届くだけでは、R2 から R1 へも届くとは限らないからだ。EIGRP は、両側で相手を確認できて初めて、その先に進む。
Hello packet は、最初に一度だけ投げる合図ではない。
Hello packet は 5 秒オーダーで短い間隔で届き続ける。Hold time は Hello の 3 倍、数十秒オーダーで、次の Hello が来なかったときに「もう隣として扱えない」と見切るまでの猶予になる (規格値としては、高速なリンクで Hello 5 秒、Hold time 15 秒)。覚えておきたいのは、この余白が、次の Hello を待つ猶予になることだ。
show ip eigrp neighbors の Hold 列は、この猶予の残りが見える場所だ。Hello packet が届けば残り時間は戻り、止まれば減っていく。切れれば、その相手は出力から消える。
ここまでは、OSPF で身につけた感覚に近い。Hello が届き続ける間だけ、隣として扱える。Hello が止まれば、関係は失われる。
けれど、EIGRP ではここで話が終わらない。
Hello packet が届いていても、AS 番号が違えば、EIGRP プロセスはその相手を同じ世界の相手として見ない。K 値が違えば、同じ宛先への距離を両側で違う物差しで測っていることになる。
だから、Hello packet と Hold time は neighbor adjacency の入口であって、条件のすべてではない。
AS 番号と K 値まで揃って、隣として登録する
EIGRP の neighbor adjacency が揃う条件を、1 つずつ場面として見ていく。
1 つ目は、AS 番号だ。
R1 で router eigrp 100 が動いている。R2 でも同じ AS 番号で EIGRP が動いている。このとき、Hello packet は同じ EIGRP の世界から来たものとして扱われる。反対に、R2 が別の AS 番号で動いていれば、R1 から見た R2 は「そこにいる機器」ではあっても、同じ neighbor adjacency の相手ではない。Hello packet がケーブルを越えて届いても、AS 番号 (autonomous system number) が違えば、同じ世界の相手としては扱わない。
2 つ目は、K 値だ。
EIGRP は、経路を見るときに距離を計算する。その距離の見方を決める係数の組が、K 値 (K1-K6 の組) だ。標準の組は、規格値として K1=K3=1 / K2=K4=K5=0 と覚えておけば、Essential の入口としては十分だ。
この K 値が両側で違うと、同じ宛先を見ていても、両側で違う物差しを使うことになる。隣の計算結果をそのまま採用する EIGRP では、物差しがずれた相手を隣にするのは土台として危うい。だから EIGRP は、Hello packet の中で K 値を相手に伝える。R1 と R2 の K 値が一致しているときだけ、お互いを隣として登録する。
3 つ目は、Hello packet が届くことだ。
AS 番号と K 値が合っていても、Hello packet が届かなければ相手を見つけられない。届き続けなければ、Hold time が切れて出力から消える。show ip eigrp neighbors に行があるかどうかは、この「いま届いているか」を映す窓になる。
4 つ目は、直結のセグメントで結ばれていることだ。
EIGRP の neighbor adjacency は、直結のセグメントにいる相手との関係として読む。R1 と R2 の間に L3 の別の経路を挟んで、どこか遠くの相手と自然に隣になる、という読み方ではない。Hello packet が届く範囲と、直結のセグメントを同じ場面で見る。
この 4 つは、順位ではない。
AS 番号が合う。K 値が合う。Hello packet が届く。直結のセグメントでつながっている。
どれか 1 つが欠ければ、show ip eigrp neighbors にその相手は現れない。


K 値が違うと、Hello は届いていても行が消える
直結のセグメントは見えている。AS 番号も同じに見える。Hello packet も届いているように見える。それなのに、show ip eigrp neighbors に R2 の行がない。
この場面で「Hello が届いていないのだろう」と早合点すると、原因を遠回りする。K 値が違うと、Hello は届いているのに、EIGRP はお互いを隣として登録しないからだ。
ここで手がかりになるのがログだ。K-value mismatch と分かる行が残っていることがある。
このログは、K 値が違うと関係を続けない、という判断が起きた跡だ。show ip eigrp neighbors の出力からは R2 の行が消える。けれど、だからといって、Hello packet が物理的に届いていないとは限らない。ここが、現場で気付きにくい落とし穴になる。
出力に行がない。直結のセグメントは生きている。相手も EIGRP を動かしている。Hello packet も届いているように見える。なのに、隣として登録されない。そのときは、ログを見る。
K-value mismatch が出ていれば、見るべき場所は Hello の到達性ではなく、両側の K 値の組だ。K 値の各成分が何を意味するかまで、この話で追う必要はない。まず必要なのは、K 値 (K1-K6 の組) が両側で一致しているかを確認することだ。


show ip eigrp neighbors は、いま登録されている隣を見る窓
EIGRP の neighbor adjacency を読むとき、最初に開く窓は show ip eigrp neighbors だ。
この出力に R2 の行があれば、R1 から見て R2 はいま隣として登録されている。行がなければ、まだ登録されていないか、以前は登録されていたが消えたか、どちらかだ。
まず見るのは、細かい列のすべてではない。H 列は、見つけた neighbor の並びを示す。Address には相手のアドレスが出る。Interface には、自分側のどのインターフェースで見えているかが出る。Uptime には、その関係がどれくらい続いているかが出る。
Essential の入口で特に見たいのは、行の有無と Hold 列だ。
行があるなら、いま隣として登録されている。Hold 列が動いているなら、Hello packet によって関係が生かされている。
行が消えたなら、そこで初めて 4 つの条件へ戻る。AS 番号は一致しているか。K 値は一致しているか。Hello packet は届いているか。直結のセグメントで結ばれているか。この順で見れば、「行がない」という症状を、ただの不安ではなく、確認できる問いに変えられる。
K 値が違う場面では、show ip eigrp neighbors からは相手が消える。だから、行がないだけを見て「Hello packet が届いていない」と決めつけない。ログを見て、K-value mismatch のような原因が残っていないかを確認する。
show ip eigrp neighbors は、EIGRP のすべてを説明する画面ではない。けれど、いま誰と neighbor adjacency を持っているかを読む入口としては、いちばん手前に置ける。
EIGRP の隣接関係は、AS 番号と K 値が一致したときに成立する
EIGRP の neighbor adjacency は、Hello packet を送り合うだけでは始まらない。Hello packet は入口で、相手がそこにいることを知り、Hold time によって、その相手がいまも見えているかを生かし続ける。けれど EIGRP は隣の話だけで動く設計だから、隣と自分が同じ前提で話しているかを確かめる。AS 番号 (autonomous system number) が一致し、K 値 (K1-K6 の組) が一致し、Hello packet が届き、直結のセグメントで結ばれている。この 4 つが揃ったときに、お互いを隣として登録する。
明日、show ip eigrp neighbors に行がない場面に出会ったら、最初にこの 4 つへ戻ればいい。直結のセグメントはあるか。Hello packet は届いているか。AS 番号は同じか。K 値は同じか。ログに K-value mismatch は出ていないか。行がないからといって、すぐに「Hello が届いていない」とは決めない。この順に見れば、EIGRP の neighbor adjacency は、ただの「隣接している機器」ではなく、条件を満たした相手を隣として登録する関係として読める。
隣との関係は成立した。けれど、その隣から受け取った複数の経路が、どう採用される側と予備の側に分かれるのかには、まだ踏み込んでいない。