eigrp named mode config shows delay in micro instead of pico

balireddi

HI All,
Need some help in figuring out what am i doing wrong with EIGRP named mode lab.I'm on Version 15.1(4)M7. I have enabled eigrp named mode and trying to figure out why the delay is in microseconds instead of pico


R1#show run | s eigrp
router eigrp MULTI-AF
!
address-family ipv4 unicast autonomous-system 100
!
topology base
exit-af-topology
network 150.1.0.0
network 155.1.0.0
exit-address-family


R1#show eigrp address-family ipv4 100 topology 150.1.2.2/32
EIGRP-IPv4 VR(MULTI-AF) Topology Entry for AS(100)/ID(150.1.1.1) for 150.1.2.2/32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 27264000
Descriptor Blocks:
155.1.0.5 (Tunnel0), from 155.1.0.5, Send flag is 0x0
Composite metric is (27264000/25984000), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 65000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1400
Hop count is 2
Originating router is 150.1.2.2
155.1.13.3 (FastEthernet0/1.13), from 155.1.13.3, Send flag is 0x0
Composite metric is (27266560/27264000), route is Internal
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 65100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1400
Hop count is 3
Originating router is 150.1.2.2

OctalDump

I'm about 60% certain this was introduced in ios 15.4, but I can't find a source. I think it is related to "wide metrics" which use 64bit calculations - which gives either bigger numbers or greater precisions, hence ability to do picoseconds.

Anyway, it seems to be EIGRP release 8 or later. I think a show eigrp plugins gives this info.

rtid

Perhaps you're adjacent to an EIGRP router running Classic mode, which will enforce using a 32-bit metric.

rtid

Correction: The IOS version you're utilizing doesn't support EIGRP Wide Metrics. It was introduced in 15.2(4)M, as it would pertain to your post. Additionally, my previous response was misleading in that you either have support for the Wide Metric TLV or you do not - all permutations will should interoperate as protocols with TLVs tend to.

I would have just edited my first post, but I'm not certain this forum (or my account) has that capacity.