eigrp metrics for Rstatic

[da_heizhu]

Hi,

I found sth strange on some of the EIGRP routes in one of the core router. Refer to the attached configuration of the router.

For example there are two static routes being defined:

ip route 192.168.100.6 255.255.255.255 172.25.56.254

ip route 192.168.100.40 255.255.255.255 172.25.56.254

and they are redistributed into EIGRP without any default metric set. When I check these two routes in eigrp topology table, they give different metrics, which is deduced from different reference bandwidth they use. See the output below:

HQ_21_7206-1# sh ip eig to 192.168.100.6/32

IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 40512000

Routing Descriptor Blocks:

172.25.56.254, from Rstatic, Send flag is 0x0

Composite metric is (40512000/0), Route is External

Vector metric:

Minimum bandwidth is 64 Kbit

Total delay is 20000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

External data:

Originating router is 172.25.159.25 (this system)

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

IP-EIGRP (AS 1): Topology entry for 192.168.100.40/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160

Routing Descriptor Blocks:

172.25.56.254, from Rstatic, Send flag is 0x0

Composite metric is (28160/0), Route is External

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 100 microseconds

Reliability is 255/255

Load is 26/255

Minimum MTU is 1500

Hop count is 0

External data:

Originating router is 172.25.159.25 (this system)

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

As you can see one is using 64k as mininum bandwidth and one is using 100000 k. I try to add new static routes and they all use 100000k as mininum bandwidth upon redistribution (which make sense as the next hop is a FE interface). But how does the 64k minimum bandwidth come into picture for 192.168.100.6/32? In fact, most of the previously configured static routes on this router are experiencing the same as 192.168.100.6/32. Such behavior is not found on other routers..

[ankbhasi]

Hi Friend,

Can you confirm to reach destination 192.168.100.6/32 there is no link on way where you have 64k mandwidth configured?

For eigrp it does not matter what is the bandwidth for next hop but it takes the minimum bandwidth link upto the destination into account for calculating the metric.

HTH

Ankur

[da_heizhu]

well, the next hop for 192.168.100.6 is 172.25.56.254, a firewall connected on the fa1/0 segment. Certainly no 64k bandwidth configured on firewall. core router is not running eigrp with the firewall either.

[ankbhasi]

Hi Xiao,

Can you update how many hops are there in between router HQ_21_7206-1 and 192.168.100.6 and is any link in between these have 64k configuration?

Regards,

Ankur

[Richard Burts]

Xiao

This is quite strange. Both static routes use the same next hop address and are redistributed in the same EIGRP process. From this I would certainly expect them to have the same metric. I wonder if they were configured at different times and at the time the route to 192.168.100.6 defined the interface leading to the next hop any differently? Can you say whether this router has rebooted since the static routes were configured? Is it possible to reboot the router and see if that causes the metric to be the same on both routes? Or if reboot is not feasible is it possible to do clear ip eigrp 1?

Ankur

Your questions about bandwidth in the network would be logical and appropriate if we were talking about dynamically advertised routes. But this question is about redistributed static. For redistributed static routes the only things that matter are whether a default metric is configured or the bandwidth of the interface used to get to the next hop.

HTH

Rick

[Kevin Dorrell]

"I wonder if they were configured at different times and at the time the route to 192.168.100.6 defined the interface leading to the next hop any differently?"

Or perhaps at the time they were redistributed, the default-metric was different, or even set by a route-map? I got caught out recently by some unexpected behavior applying and/or removing a route-map, cos I didn't know to do a clear ip route *. And that was also all about metrics and where they got set (and whether the routes got redistributed at all).

It may not be necessary to clear the EIGRP process - maybe clear ip route * will do the trick.

Kevin Dorrell

Luxembourg

[Richard Burts · Accepted solution]

Kevin

I thought about the possibility of clear ip route. I decided that it was not likely to change things if the EIGRP topology table shows different values for the bandwidth then clearing the IP routing table will just recalculate with the same inputs and why would it come up with different results in the routing table. I believe that we need something that will force it to relearn the topology table. I am not sure what does that other than reboot or clear ip eigrp.

Certainly there is no harm to trying clear ip route first - since it is clearly less disruptive than either suggestion that I made. But I have no confidence that clear ip route will change the metrics.

HTH

Rick

[da_heizhu]

Hi guys,

Surprisingly cle ip route does the job.. now the metric back to normal.

HQ_21_7206-1#sh ip eig to 192.168.1.16/32

IP-EIGRP (AS 1): Topology entry for 192.168.1.16/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 40512000

Routing Descriptor Blocks:

172.25.56.254, from Rstatic, Send flag is 0x0

Composite metric is (40512000/0), Route is External

Vector metric:

Minimum bandwidth is 64 Kbit

Total delay is 20000 microseconds

Reliability is 255/255

Load is 1/255

Minimum MTU is 1500

Hop count is 0

HQ_21_7206-1#cle ip route 192.168.1.16

HQ_21_7206-1#sh ip eigrp to 192.168.1.16/32

IP-EIGRP (AS 1): Topology entry for 192.168.1.16/32

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160

Routing Descriptor Blocks:

172.25.56.254, from Rstatic, Send flag is 0x0

Composite metric is (28160/0), Route is External

Vector metric:

Minimum bandwidth is 100000 Kbit

Total delay is 100 microseconds

Reliability is 255/255

Load is 9/255

Minimum MTU is 1500

Hop count is 0

External data:

Originating router is 172.25.159.25 (this system)

AS number of route is 0

External protocol is Static, external metric is 0

Administrator tag is 0 (0x00000000)

Thank all especially Rick and kevin for the valuable suggestion and comments.

But what puzzles me still is that what condition could cause the 64k bandwidth thing.. i will try playing arround with routemap as kevin suggested in a lab..

[Richard Burts]

Xiao

Thanks for posting back to the thread and indicating that you had solved the problem. Thanks for using the rating system to indicate that your problem had been solved (and thanks for the rating). It makes the forum more useful when people can read about a problem and can know that they will read a solution to the problem.

I am glad to know that clear ip route did fix it. And I am surprised that clear ip route fixed it. As I commented to Kevin I thought that since it was in the topology table with different delays it would take something that clears the topology table to fix it. I do not see how the clear ip route clears the topology table. But your evidence is clear that clear ip route did fix it.

The very fine thing about the forum is the variety of opinion from different people. And the chance to learn from each other.

I encourage you to continue your participation in the forum.

HTH

Rick