番外編:EIGRPから学ぶ、ネットワークエンジニアとして一皮むけるための観点

2024年12月28日 23:29

だらだら寝転がりながらINEの動画みてたら面白いのがあったので紹介

※ジュニアエンジニアが感動しただけなのでそんなん当たり前だが？？？という先輩エンジニアの方々は暖かい目で見守ってください。

普通にEIGRP組んだトポロジがあります。

投入config

RT1
hostname RT1

interface Loopback0
ip address 1.1.1.1 255.255.255.0
!
interface GigabitEthernet0/0
ip address 10.10.10.1 255.255.255.0
!
router eigrp 1
network 0.0.0.0

RT2
hostname RT2

interface Loopback0
ip address 2.2.2.2 255.255.255.0
!
interface GigabitEthernet0/0
ip address 10.10.10.2 255.255.255.0
!
router eigrp 1
network 0.0.0.0

普通の挙動

普通にEIGRPが組めれば以下のようになるはずです。

これは普通の動作。

いじわるした挙動

これをちょっとコネコネして動作を変えます。もちろん設定は消してない。

neighbor組めて問題なさそうに見えるが実は右から2つ目のQcntが上がってる

QcntはルータがEIGRPパケットを送信しようとしてるが、ネイバーから確認応答がないことを示している。

トラブルシューティング

これは一体何が起きているのか。

ここでEIGRPの基本的な挙動をざっくりおさらいしておくと
helloでネイバーを確立。
updateでお互いのルート情報を通知し合う。
query,ack,replyとかでルート情報に変更があった場合にコネコネする（ここは今回割愛）
これを頭に入れておくことで、どこのプロセスで問題があるのか切り分けができるのです。

access-list 100 permit eigrp any any
debug ip packet 100
debug ip eigrp 1
とかでdebug取ったり、キャプチャ取ったりしてみる。

*Dec 28 13:40:33.381: IP: s=10.10.10.1 (local), d=224.0.0.10 (GigabitEthernet0/0), len 70, sending broad/multicast
*Dec 28 13:40:33.382: IP: s=10.10.10.1 (local), d=224.0.0.10 (GigabitEthernet0/0), len 70, sending full packet

*Dec 28 13:40:42.162: IP: s=10.10.10.2 (GigabitEthernet0/0), d=224.0.0.10, len 60, rcvd 0

helloは出てる

ログの細かいことは知らんが、224.0.0.10宛のマルチキャスト宛に出るhelloパケットは問題なさそう。なのでneighbor自体は組めてそう。

*Dec 28 13:40:30.021: IP: s=10.10.10.1 (local), d=10.10.10.2 (GigabitEthernet0/0), len 40, sending
*Dec 28 13:40:30.022: IP: s=10.10.10.1 (local), d=10.10.10.2 (GigabitEthernet0/0), len 40, sending full packet
*Dec 28 13:40:30.025: IP: s=10.10.10.2 (GigabitEthernet0/0), d=10.10.10.1, len 40, access denied
*Dec 28 13:40:30.026: IP: tableid=0, s=10.10.10.2 (GigabitEthernet0/0), d=10.10.10.1 (GigabitEthernet0/0), routed via RIB

updateはなんかダメそうだね

updateに何かしらの異常がありそう。

updateに異常があったのでルート情報がお互いに交換できず、Qcntが上がったり、RT1→RT2のlo0の2.2.2.2に疎通できなかったわけです。

これいれてたからね

答えを言うとアクセスリストでいじわるしたのでこの挙動になってます。

結論

プロトコルのシーケンスをしっかり覚えておくのが、中級者（もはや上級者な気もしてしまうが…）の一歩だな思いました。

しっかりというのは、例えばDHCPで言うとDiscover→offer→request→ackの順番とか、Discoverがブロードキャスト,offerがユニキャストとか、もっと深く覚えてもいいかも。

今回の例では、helloは問題なく、updateに問題があったのです。原因の切り分けですね。

実務でもトラブルが発生した際に、プロトコルのシーケンスの中のこっちのブロードキャストは問題なかったけどこっちのユニキャストは問題あるね。ユニキャストで問題があるから…みたいなことがありました。

現場でよく使う技術のシーケンスと、各シーケンスでやってる内容やそのパケットがユニキャストなのか、ブロードキャストなのか等知っておくとエンジニアレベルが上がりそうですね。CCOにはこういった挙動までは書いてないことが多い気がするので、RFCも読まなきゃだめな理由はこのせいだなと思いました…