EIGRP metrics on manually summarized route

pblower · ‎07-09-2009

I'm having trouble identifying where and how certain metrics are arrived at on my network and was hoping someone may have some insight. I was unable to get to the bottom of it with TAC.

I've got a L3 MAN environment with 3 WAN aggregation routers spread throughout the MAN. My remote sites typically have two circuits; one each to two of the three WAN aggregation routers. I'm either using EIGRP stub routing on the remote site router or have a distribution list allowing only the default route to reach the remote sites.

The WAN aggregation routers know all the remote site subnets. I manually summarize the remote site subnets on the WAN aggregation routers into the MAN. Since the MAN does not learn the specific remote site subnets (due to the summarization), I have GRE tunnels that connect each of the WAN aggregation routers to each other (through the MAN) so that should one of the WAN links to a remote site go down, the other WAN aggregation routers learns about it over the GRE tunnel.

So any device in the MAN trying to reach a remote site goes to the primary WAN aggregation router and then over a WAN circuit to the remote site router. If that WAN circuit is down, the path would still be to the same WAN aggregation router but then it would go over the GRE tunnel to one of the other WAN aggregation routers and over the secondary WAN circuit. No need for the MAN to know that one of the WAN circuits was down and no routing updates are propogated in MAN. All of this works.

The weird metrics I'm seeing is that on my MAN device (a Catalyst 6500) that is directly connected to a WAN aggregration router that is doing the manual summarization, the hop count is reported as 7 (I know that hop count is not used in EIGRP metrics) It also reports a delay of 450 microseconds though it is across a gig interface (10 microseconds default) and has a minimum bandwidth of 44247 Kbps. I am stumped as to where it is getting these metrics.

I do have other summarized routes in the environment (different routers involved) that have metrics as I'd expect). Anyone have any suggestions as to where they could be coming from? Below is some the output:

MAN switch:

C-6513: sho ip eigrp top 10.32.0.0/12

EIGRP-IPv4 (AS 142): Topology Default-IP-Routing-Table(0) entry for 10.32.0.0/12

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

Routing Descriptor Blocks:

10.56.27.50 (GigabitEthernet11/30), from 10.56.27.50, Send flag is 0x0

Composite metric is (69376/69120), Route is Internal

Vector metric:

Minimum bandwidth is 44247 Kbit

Total delay is 450 microseconds

Reliability is 255/255

Load is 32/255

Minimum MTU is 1500

Hop count is 7

WAN router:

sho ip eigrp top 10.32.0.0/12

IP-EIGRP (AS 142): Topology entry for 10.32.0.0/12

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

Routing Descriptor Blocks:

0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0

Composite metric is (69120/0), Route is Internal

Vector metric:

Minimum bandwidth is 44247 Kbit

Total delay is 440 microseconds

Reliability is 255/255

Load is 32/255

Minimum MTU is 1500

Hop count is 6

As you can see, even the WAN aggregation router has a hop count of 6 when it is the device doing the summarization (the default administrative distance is 5). It also has a delay of 440 microseconds.

Giuseppe Larosa · ‎07-10-2009

Hello Phil,

EIGRP data structures for routes contain several separate fields, all the ones that can be considered by EIGRP composite metric and minimum MTU on path and router hops on path.

Some parameters like BW and MTU record the minimum values on the path so are left unchanged if the downstream routers are interconnected with faster links with same or greater MTU.

Other parameters like delay and hop count are cumulative:

at each EIGRP router hop the field is updated.

For this reason you see total delay 450 microseconds on MAN switch.

total delay = local_node_link_delay + received delay = 10 + 440

The router hop count is incremented by one.

Minimum BW is that of a DS3.

As you can see min BW and min MTU are left unchanged and are equal on both devices.

So these values are correct and the changes on the two nodes reflect the different type of parameters: minimal tpye versus cumulative type.

Hope to help

Giuseppe

Richard Burts · ‎07-10-2009

Giuseppe

I believe that Phil is asking where these values come from -for example where is the delay of 440 coming from. It is not explicit in his question but I get the feeling that Phil expects that since the WAN router is doing the summarization that it would generate some local metric.

What we were told in an EIGRP session at the recent Cisco Live conference is that in generating a summary route that EIGRP takes the metric from the most attractive detailed route being summarized and uses that as the metric for the summary route. So if Phil were to do show ip eigrp topology on all of the more detailed routes being summarized I believe that he will find that there is a route with a delay of 440 and a hop count of 6.

HTH

Rick

HTH

Rick

Giuseppe Larosa · ‎07-10-2009

Hello Rick,

I've probably lost myself in the details I was analyzing!

I agree that at least a component route within the summary route in the EIGRP topology should have those values of total delay and router hop count.

ps.

by the way, have you enjoyed the Cisco Live event?

Hope to help

Giuseppe

pblower · ‎07-10-2009

Hi Rick.

You nailed it!

I was able to find a specific route with that delay, bandwidth, and hop count. It is coming from yet another WAN aggregation router that was deployed without the summarization (which I'm trying to correct) and therefore was leaned by all my routers. The WAN router doing the summarization was learning the specific route and using it because it still had the best metrics (lots of hops across the MAN but when they are 10 gig not too much delay involved).

Anyway, armed with this info I should be able to get the traffic flowing the way I want.

Thanks a bunch.

Richard Burts · ‎07-10-2009

Phil

I am glad that my response was helpful in solving your issue. Thank you for posting back to the forum and indicating that you had found the route that is the source of the metric. It makes the forum more useful when the person who initiated a discussion does post back and indicate how the issue was resolved.

HTH

Rick

HTH

Rick