EIGRP METRIC CALCULATION

[Barikuma]

I have tunnel 100 and 200 running across Site A and B, with EIGRP configured on both tunnels. Tunnel 100 is sourced from e1/0 and tunnel 200 e1/1 on both sites. The bandwidth and delay of tunnel 100 has been configured to make sure that EIGRP calculates a lower metric and chooses tunnel 100 as its best path; variance has also been configured to ensure Unequal Cost Multipath.
My question is if the e1/0 link between site A and the service provider is degraded (say delay and jitter across the link increases), will this cause EIGRP to recalculate its metric? Given that EIGRP is configured only on the tunnel and not the physical interfaces.

[MHM Cisco World]

As I know it will not effect the EIGRP metric of tunnel' this change happened to underlying network.

MHM

[Jens Albrecht · Accepted solution]

Hello @Barikuma,

EIGRP calculates its metric using the parameters (bandwidth and delay) explicitly configured on the tunnel interface itself, not the underlying physical interface. This means that EIGRP does not look at the physical interface (e1/0, e1/1) performance for paths where only the tunnel interface is in the EIGRP process.

So increasing delay/jitter or reducing bandwidth on e1/0 will NOT trigger EIGRP to recalculate its metric.

HTH!

[David Ruess · Accepted solution]

Hello,

To add to this thread the delay I believe is a static value. I dont think it changes and can be configured manually on an interface. It wouldn't really be beneficial to recalculate an EIGRP path every time the delay changed. You would almost ALWAYS have reconvergence.

Secondly EIGRP uses only the LOWEST Bandwidth along the entire path in its metric. So changing the BW may not even make EIGRP recalculate in that aspect.

-David

[Barikuma]

Hi @David Ruess,

I beg to differ. While it may not always be advisable, it is indeed possible to configure (or modify) the delay and bandwidth on an interface. I tested this in a lab environment, where Tunnel 100 was configured with a bandwidth of 1000 and a delay of 4000 to influence the metric calculation.

That said, I stand to be corrected.

Cheers!

[Giuseppe Larosa · Accepted solution]

Hello @Barikuma ,

what David @David Ruess  has pointed out is that EIGRP use the configured values of bandwidth and delay and not values of delay experienced on the interface.

This is true also of other optional components of EIGRP composite metric like load if enabled the load level on the interface when EIGRP is started is taken in account but this does not mean recalculations when load on interface changes over time.

This aspect of EIGRP implementation has been first described by Russ White here in the forums.

And it is also the main reason why no production network enables additional metrics fields in EIGRP metric because there is no real advantage in doing it.

Hope to help

Giuseppe

[Barikuma]

Thank you! @Giuseppe Larosa, this clarifies it. 

[MHM Cisco World]

I modify the interface f0/0 in R1 and R2 and tunnel between R1 and R3 never effect by this change 

NOTE:- only MTU maybe effect if you use PDMTU

[David Ruess]

Yes as @Giuseppe Larosa elaborated on my thread I meant it doesn't change dynamically with the actual link congestion. I should have been more clear in that aspect.

[MHM Cisco World]

If I have time I will run lab and check 

MHM

[MHM Cisco World]

Friend your Q is simple  are overlying tunnel inherit from underlying or not.

That it' let me run lab and check

Update you tonight 

MHM