Redistributing Static Routes to EIGRP

[jpl861]

Hi,

I read here in Cisco website that in order to redistribute routes from one protocol to EIGRP, it should have a default-metric set or a metric set for the routing protocol. If there's no metric set then the route will not be redistributed.

Im wondering why our MSFC2 is redistributing static routes without metric.

Here's the configuration:

--------------------------------------

router eigrp 30

redistribute static route-map redist

redistribute bgp 25612 metric 1536 2000 255 1 1500 (I changed the AS#)

network 10.0.0.0

network 192.168.254.0

no auto-summary

eigrp log-neighbor-changes

ip route 10.199.180.0 255.255.255.0 10.199.56.51

ip route 10.199.238.0 255.255.255.0 10.199.56.51

ip route 10.200.20.178 255.255.255.255 10.199.56.115

ip route 10.200.20.189 255.255.255.255 10.199.56.115

ip route 10.200.20.190 255.255.255.255 10.199.56.115

access-list 5 permit 10.200.20.182

access-list 5 permit 10.200.20.178

access-list 5 permit 10.200.20.190

access-list 5 permit 10.200.20.189

access-list 5 permit 10.199.238.0 0.0.0.255

access-list 5 permit 10.199.180.0 0.0.0.255

route-map redist permit 10

match ip address 5

--------------------------------------

When I checked the routing table of the other routers, it can still see the redistributed routes from the MSFC2 and flagged as an external EIGRP (170).

Im wondering why this redistribution happened.

Please help. I'm confused. =(

[royalblues]

Hi

I did a Lab simulation and found that the router redistributing the static route actually assigns a FD of 1 to the route

(shows as Rstatic in topology)

The other routers upstream/downstream add up the normal metric to this (bandwidth+delay)

HTH, rate if it does

Narayan

[ruwhite]

I've not followed the thread, and I don't claim to be an expert, but... :-) I saw this one question and thought I'd at least give it a shot!

I just checked in the lab, and EIGRP will redistribute a static without a metric. I had realized this for statics to connected next hops and to interfaces, but not for those with next hops learned through another protocol (this is the one I wanted to check in the lab). In effect, what EIGRP does is to take the metrics from the interface through which the static points, or through which the next hop for the static is reachable.

HTH.

:-)

Russ

[rtanner]

now all we need is the CCO reference stating that is indeed the case !

In theory, practice and theory operate the same. In practice, they don't.

[sundar.palaniappan]

I remember reading a document on CCO a few days ago that did state static/connected route redistribution into EIGRP doesn't need explicit metric association or default metric configuration. That was the first time I realized that. I can't seem to find the document now.

I don't understand the inconsistency in metric requirement between static/connected routes versus routes learned via other sources during redistribution. Static/connected routes using the interface attributes for metric calculation implies the source network is directly connected to that interface and that's not always the case.

Just my 2 cents.

HTH

Sundar

[Alan Ng'ethe]

---

@sundar.palaniappan wrote:

I remember reading a document on CCO a few days ago that did state static/connected route redistribution into EIGRP doesn't need explicit metric association or default metric configuration. That was the first time I realized that. I can't seem to find the document now.

I don't understand the inconsistency in metric requirement between static/connected routes versus routes learned via other sources during redistribution. Static/connected routes using the interface attributes for metric calculation implies the source network is directly connected to that interface and that's not always the case.

Just my 2 cents.

HTH

Sundar

---

Interesting discussion. I always added metric to such static routes when redistributing.