結論: debug eigrp packets hello detailでtype 1の最初の5byteを見る
はじめに
トラブルシュート中に対向に設定されたEIGRPのmetricを知りたいことがあります。ドキュメントを見たり、検索をしても「対向の値に合わせる」しか書いていないことが多いです。
私はこのケースではpacket dumpのhexをみてk値を調べてきました。しかし、より簡単な方法(方法1)がありました。
構成
RT1(E0/1) -- (E0/1) RT2
Cisco CML2.8 FreeTier上のIOSXEVersion 17.15.1, RELEASE SOFTWARE (fc4)
RT1:
interface Ethernet0/1
ip address 192.168.1.1 255.255.255.0
router eigrp 55
metric weights 0 1 2 3 4 5
network 192.168.1.0
RT2:
interface Ethernet0/1
ip address 192.168.1.2 255.255.255.0
router eigrp 55
metric weights 0 6 7 8 9 10
network 192.168.1.0
この状態ではk-valueが不一致なので以下のメッセージが出てneighborは確立できません。
RT2において:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 55: Neighbor 192.168.1.1 (Ethernet0/1) is down: K-value mismatch
方法1: debug eigrp packets hello detail
debug eigrp packets hello detail
とします。以下のように出力されます。RFC: 7868 EIGRP - EIGRP Packet Formats- 0x0001 - PARAMETER_TYPEによればtype==1がk-valueのパラメータです。type1が含まれるメッセージに注目します。
RT2の出力
*Jan 26 13:19:49.753: EIGRP: Received HELLO on Et0/1 - paklen 20 nbr 192.168.1.1
*Jan 26 13:19:49.753: AS 55, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0
*Jan 26 13:19:49.753: {type = 1, length = 12}
*Jan 26 13:19:49.753: {vector = {
*Jan 26 13:19:49.753: {01020304 0500000F}
*Jan 26 13:19:49.753: }
*Jan 26 13:19:49.753: K-value mismatch
---
*Jan 26 13:19:54.157: EIGRP: Sending HELLO on Et0/1 - paklen 30
*Jan 26 13:19:54.157: AS 55, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Jan 26 13:19:54.157: {type = 1, length = 12}
*Jan 26 13:19:54.157: {vector = {
*Jan 26 13:19:54.157: {06070809 0A00000F}
*Jan 26 13:19:54.157: }
これにより、-> Eth0/1からのinのweightは1/2/3/4/5であり、Eth0/1へのinのweightは6/7/8/9/10(0x0a)であることが分かりました。今回はRT2側でとったので例えばRT2のweightを1/2/3/4/5に会わせれば良いです。
方法2: hex packet dump (INE)
INE: What? You won't tell me the K values? No problem. がよく知られたよりrawなk-valueのリバースエンジニアリング手法です。この記事では以下のコマンドによりpacket dumpをできると記載してあります。
debug ip packet 100 detail dump
このコマンドは最近のアーキテクチャで上手く動かないようなのでソフトウェアでの組み込みパケットの設定およびキャプチャを参照します。
conf t
access-list 100 permit ip any host 224.0.0.10
end
monitor capture buffer mycap
monitor capture buffer mycap size 2048 max-size 1518 linear
monitor capture buffer mycap filter access-list 100
! これではとれない
! monitor capture point ip cef mypoint ethernet 0/1 both
! CPUまで上がったものをとる
monitor capture point ip process-switched mypoint2 both
monitor capture point associate mypoint2 mycap
monitor capture buffer mycap clear
monitor capture point start mypoint2
! 適当にまつ
monitor capture point stop mypoint2
! みる
show monitor capture buffer mycap dump
この時の注意は、物理インタフェースでなくCPUのパケットをキャプチャポイントとすることです。以下のように表示できます。
RT2の出力
13:09:09.771 UTC Jan 26 2025 : IPv4 Process : Et0/1 None
799CD5F8D600: 01005E00 000AAABB ..^...*;
799CD5F8D610: CC001810 080045C0 003C0216 00000158 L.....E@.<.....X
799CD5F8D620: 14E1C0A8 0101E000 000A0205 D6950000 .a@(..`.....V...
799CD5F8D630: 00000000 00000000 00000000 00370001 .............7..
799CD5F8D640: 000C0102 03040500 000F0004 00081C00 ................
799CD5F8D650: 020000
-> Eth0/1からのinのweightは1/2/3/4/5
13:09:27.713 UTC Jan 26 2025 : IPv4 Process : None Et0/1
799CD5F8D600: 01005E00 000AAABB ..^...*;
799CD5F8D610: CC001910 080045C0 00460216 00000158 L.....E@.F.....X
799CD5F8D620: 14D6C0A8 0102E000 000A0205 C68A0000 .V@(..`.....F...
799CD5F8D630: 00000000 00000000 00000000 00370001 .............7..
799CD5F8D640: 000C0607 08090A00 000F0004 00081C00 ................
799CD5F8D650: 020000F5 000A0000 00020000 00 ...u.........
-> Eth0/1へののinのweightは6/7/8/9/10(0x0a)
rawのhex dumpを見るのは辛いので
monitor capture buffer mycap export unix:mycap.pcap
とするとmypcap.pcapにpcap形式で保存できます。しかし、IOS-XE自身にはwiresharkが搭載されていないのでIOS-XE内でpcapを解析する方法がありません。方法1をおすすめします。