well the default-metric is set (not sure why) in the router eigrp config to:

default-metric 1500 1 255 1500

but i believe that is only for redistribution.

if i go to any other router on the same LAN and show the ip route for the WAN interface of this router the reliablility is 171/255

which just seems wacky to me. Other routes comming from this router show 255/255

"default-metric 1500 1 255 1500"

It's missing a number for the re-distrobution.

Should be

default-metric

Yes you are correct that when you re-distrobute into EIGRP from another routing protocol, you must use this command.

That's interesting. Is it calculating it from the realtime error rates? You you have a high number of errors or discards (drops) on that WAN link?

Kevin Dorrell

Luxembourg

That is the strange thing - I do not see any errors on either the WAN or LAN interface for that router. And the routes for the remotes off of that router all have 255 for reliability.

Here is the whole skinny on the issue (probably way too much info but what the heck):

This router (call it router A) is the gateway for a OC3 Sonet interface serving a number of remote sites. The router next to it (router B) is connected to a DS3 that is broken out into separate T1 P2P interfaces.

One of the sites off the OC3 on router A also has a backup router with a P2P to the DS3 on router B. Routers A and B are each connected to a pair of 6509s (A on one, B on the other) which are connected via a 4Gb channel.

If you go to router B and show the route for the WAN address on router A, it shows a host route (32 bit mask) as being advertised through the P2P interface to the backup router at the remote site with reliability of 253, instead of the gig LAN interface where it should be. I filtered the WAN address of router A from coming in the P2P link on router B with an incoming dist-list. Showing the route for router A WAN now shows a host route (32 bit mask) with the same reliability, being advertised by another router (C) that provides backup Frame to ATM connections to a number of sites that also have primary connections to router A. Router C is at a backup site across town and is connected to the LAN for routers A and B via a 100Mb Metro Ethernet connection running to one of the 6509s. I configured the same inbound dist-list on router C and finally see a route for router A's 30 bit WAN subnet as advertised by router A with a reliability of 171.

Show route from router B before dist-list addition on router B:

Route metric is 2771976, traffic share count is 1

Total delay is 43520 microseconds, minimum bandwidth is 1544 Kbit

Reliability 253/255, minimum MTU 1500 bytes

Loading 1/255, Hops 3

Show route from router B after dist-list addition on router B:

Route metric is 3448224, traffic share count is 1

Total delay is 4496 microseconds, minimum bandwidth is 768 Kbit

Reliability 253/255, minimum MTU 1500 bytes

Loading 1/255, Hops 4

Show route from router B after dist-list addition on router C:

Route metric is 30720, traffic share count is 1

Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit

Reliability 171/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Are you re-distrobuting routing protocols at all?

Is the default metric set on each router?

If you are not re-distrobuting other routing profiles into EIGRO, consider removing the default metric command from your EIGRP statement and see what happens.

The only redistribution going on would be for statics which i don't believe we have on this router, so i can remove that default statement.

The OC3 is connected to a carrier router which i believe is redistributing our eigrp routes into their BGP net, then it is again redistributed back into our eigrp net at the remote end. They may be doing something whacky there. But all the WAN nets for the remote connections show up correctly.

This WAN interface is also a source for a tunnel interface that is not currently in use - that wouldn't have anything to do with it you think?

removed the default metric and the tunnel int config with no change.

Russ,

So effectively, if this interface started running EIGRP at boot time, you would probably expect it to contribute 255 to the reliability metric as it does not really have time to collect any metrics for the interface before the EIGRP starts.

His 171 must mean that of all the routers in the path to the prefix he is studying, one of them (and not necessarily this one) has an interface that was flaky at the time EIGRP was started on it. That could be either because EIGRP was configured after boot time, once the interface had accumulated some errors, or that the interface was flaky so someone shut it down and up again without clearing the flaky error count.

At boot time, how long does it take to establish an error count that would be worthwhile using innthe reliability metric, and would tere actually be an eror count available by the time EIGRP started on the interface. I suspect not.

Kevin Dorrell

Luxembourg

Not necessarily.... Lots of things are going on at boot, and the interface may come up long before EIGRP comes up in the boot cycle, and then it may be some short time before EIGRP actually reads the reliability off the interface. I consider the number EIGRP picks up pretty random, it's picked up too early in the process to be meaningful. If the router comes up, sends a couple of ethernet frames on the interface, and dumps one of them, then EIGRP comes up, then you're going to get some low reliability number on that interface. If you wait ten minutes, and then go check the reliability on all the interfaces on the network, you won't be able to find the one that gave you that low reliability number--because it's sent enough packets to move it higher now....

At some point, we'll make the reading of the metrics dynamic, and then they'll be useful again, but I don't really know where that is on the road map.

:-)

Russ

Thanks Russ, that's very helpful, and a good reason not to use the metric. Thanks.

BTW, looking forward to your talk on "New Developments in BGP" in Barcelona in January - that is you isn't it?

Kevin Dorrell

Luxembourg

Yep... I suppose I should go look at those slides, and get the up to date. :-) I'm also doing a techtorial with Alvaro and Ole this year.

:-)

Russ