02-02-2007 03:59 AM - edited 03-03-2019 03:36 PM
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. =(
02-06-2007 07:31 AM
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
02-06-2007 04:13 PM
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
02-06-2007 04:24 PM
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.
02-06-2007 04:48 PM
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
07-31-2019 07:14 PM
@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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: