cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
914
Views
6
Helpful
15
Replies

EIGRP 64bit metrics on IOS-XE not behaving with SVI

nick-rock-city
Level 1
Level 1

Can anyone get SVI's to behave when using 64bit EIGRP metrics?  I see this behavior on IOS-XE 16.9.5 and 17.9.5

What I mean by this is, if you have a L2 port-channel, with 2 x 40g members this will "lose" in EIGRP delay calculation to a single routed 10g port. 

 

Setting the minimum delay (1) , or a max bandwidth the platform supports (in my case 200 Gigs) does not lower the picosecond delay below that of a 1 g link when looking at the topology table.

 

the show interface | include DLY command, shows the DLY that would be used in a 32bit EIGRP calculation, so is not helpful.

 

When using a L3 port-channel - With an IP address on the interface, the picosecond delay is calculated correctly.

Does anyone know

(1) of a way to manually set picosecond delay ?

(2) a show command that shows the 64bit picosecond delay of interfaces (outside of figuring it out from the topology table)

 

Thanks,

Nick

15 Replies 15

This feature called wide metric and it use only for eigrp named mode 

MHM

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello @nick-rock-city ,

>> What I mean by this is, if you have a L2 port-channel, with 2 x 40g members this will "lose" in EIGRP delay calculation to a single routed 10g port. 

This is normal because EIGRP cannot be aware of a L2 port channel and it should not take it in account in its calculations. As you have noted the calculation is correct on a L3 port-channel.

Be also aware that 64 bit EIGRP metric is scaled down to 32 bit before entering the routing table, because the IP routing table daemon works on 32 bits wide metric values for all protocols.

Hope to help

Giuseppe

 

nick-rock-city
Level 1
Level 1

Thank you.

Yes I understand the scaling as it enters the routing table.  What is the SVI configurable solution to this issue though - Is there no option to manipulate the delay below the minimum enterable of "1" - which is tens of microseconds?  I guess I do not understand the point of creating a 64bit metric that understands faster links that only supports routed physical interfaces.   32bit EIGRP was very easy to do route steering.

 

I also do not know why both additional show commands, and extra ways to configure delay were not added.  There are a few platforms running XE, with very limited 40/100g interfaces and you may need L2 between cores to service HSRP etc, without adding extra links (which we have done) there must be a configurable solution to this issue?  Something like "delay pico 10000". 

 

 

 

We have a TAC case open, we are not getting much traction - and any requests for decent documentation are non-existent.  EIGRP in 2024 seems to be a dead end.

 

 

Can I see the eigrp config?

MHM

nick-rock-city
Level 1
Level 1

The config is not really relevant, its simply 64bit named mode.  Here is an example of what we want to achieve in a diagram:

nickrockcity_0-1723041203214.png

Try to get to the loopback on A switch, via VLAN100 from the B side when using EIGRP 64 bit metrics.  You will always go via the IDF, not VLAN100 - even though VLAN100 uses an 80g L2 port-channel for physical transport.  Manipulating BW or DLY on vlan100 will not help, as the 10g links are physically to fast to "beat" via dated commands.

Hello @nick-rock-city ,

as a creative workaround named EIGRP mode still supports offset lists you can add "delay " on the links you would like to be less preferred and you can do this even in a selective way for some IP prefixes.

I know it is not so handy but if there is a lack of commands you can try this.

Hope to help

Giuseppe

 

yes this is what TAC also suggested, I want to steer away from this as we have a huge and complex EIGRP network, that we eventually want to move to BGP. I want deterministic, simple EIGRP before migrating sites.

ip delay eigrp AS1 250000 picoseconds <<- example how you can use wide metric and again this use only if you use eigrp named mode 

MHM

This seems to work on Nexus, do you have an equivalent for IOS?  I looked under af-interface under named mode, but could not find command

 

Friend this command config under interface but the eigrp must be named mode.

MHM

Can you show me the section of the IOS-XE command guide that mentions delay and picoseconds?  I am using named mode, and the "ip delay eigrp" command is not available as an interface level command.  This works fine on NXOS, but not on IOS or IOS-XE.   If possible can you show me the platform and code version you are getting this from - as for me it only works on NXOS.

 

Screenshot (813).pngScreenshot (814).pngScreenshot (815).pngScreenshot (816).pngScreenshot (817).png

When I run 

Router eigrp as 

The delay appear in microsecond 

Rourer eigrp named 

The delay appear in picosecond 

In both case the delay command under interface is work but the delay calculation is different.

MHM

nick-rock-city
Level 1
Level 1

The delay command is set in tens of microseconds, and cannot go below 10 microseconds (1 being the lowest value that can be entered), irrespective of how it is displayed.  Whether in named mode (displayed in pico) or original 32 bit mode (shown in micro). 

 

Now the "ip delay eigrp 1 xx picoseconds" can set much lower values than 10 microseconds, however I can only find this command on the cisco Nexus operating system.

 

Nexus:

nickrockcity_0-1723057305546.png

IOS-XE:

nickrockcity_1-1723057408089.png

 

Hello


@nick-rock-city wrote:
pauldriver_0-1723190266143.png.The options you ave

Apart from offsetting the metric, which you do not wish to use, another option which is possible but i guess not viable because you say you have a large eigrp topology would have been to NOT use bandwidth in the composite metric calculation and just use delay, would would mean changing the eigrp K values on all rtrs.

However looking at that topology above, at present i assume the next hop for routes from Sw A-B shows an IDF address? however SW A-B share the same subnet, so you could try negating the next-hop-self on the IDF, this is on by default as apposed to bgp which is turned off, which should change the next-hop for either SW A/B to be direct.

Example: IDF
router eigrp xxx
address-family ipv4 unicast autonomous-system x
af-interface xxxxx
no next-hop-self

 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking for a $25 gift card