Cisco IOS-XEにおいてEIGRPの対向に設定されたk-value(metric weights)を知る2つの方法

結論: `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](https://datatracker.ietf.org/doc/html/rfc7868#section-6.7.1)によれば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.](https://ine.com/blog/2009-11-20-what-you-wont-tell-me-the-k-values-no-problem) がよく知られたよりrawなk-valueのリバースエンジニアリング手法です。この記事では以下のコマンドによりpacket dumpをできると記載してあります。
```
debug ip packet 100 detail dump
```
このコマンドは最近のアーキテクチャで上手く動かないようなので[ソフトウェアでの組み込みパケットの設定およびキャプチャ](https://www.cisco.com/c/ja_jp/support/docs/ios-nx-os-software/ios-embedded-packet-capture/116045-productconfig-epc-00.html)を参照します。
```
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をおすすめします。