1) Why would anyone use `redistribute connected`?
Is there any scenario that `eigrp network` can't achieve the same (better) results?
2) Does `eigrp network` always take precedence over `redistribute connected`?
I noticed with both `eigrp network` and `redistribute connected`, only interfaces not covered by `eigrp network` has a route source from Rconnected. For interfaces covered by both `eigrp network` and `redistribute connected` has a route source from Connected.
3) If EIGRP default-metric is not set, what metric is used? I thought the routes wouldn't be visible until default-metric is set (not the case here), that's probably the OSPF behavior.
"eigrp network ..." enables EIGRP on that interface, so it could talk to other EIGRP devices. While "redistributed connected ..." adds the routes for those interfaces without enabling EIGRP on them.
Consider a router terminating lots of VPN connections (and using dynamically created Virtual-Access interfaces) or maybe terminating lots of customer connections. You might not want to expose your EIGRP process to customers that should not be talking to it.
Isn't that what `passive-interface default`is for?
Not quite. That just stops it "sending", but it still listens - and perhaps you don't want to listen to what clients might be sending.
Probably not the case with EIGRP. But thanks for pointing it out. I did not know passive-interface normally does not suppress incoming routing traffic.
With EIGRP running on a network, the passive-interface command stops both outgoing and incoming routing updates
http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13675-16.html
Hello,
Please allow me to join and add my two cents...
1) Why would anyone use `redistribute connected`?
You don't see this command used often, and you are right that the network command is usually better suited to inject directly connected networks into EIGRP. As Paul correctly pointed out, one of the crucial differences between a network command and a redistribute connected command is that networks added with a network command are treated as EIGRP internal routes and EIGRP will try to establish adjacencies over the respective interfaces by sending and receiving EIGRP messages, while networks injected using the redistribute connected command are treated as EIGRP external routes and EIGRP will never send or receive its messages over such interfaces.
The redistribute connected would be advantageous in the following scenarios (the list is not exhaustive at all):
2) Does `eigrp network` always take precedence over `redistribute connected`?
To my knowledge, it does, and there is a good reason for it: In EIGRP path selection logic, internal routes are preferred to external routes (why would you go to a destination network over some foreign network topology if you have an internal path to it already?). So if you have covered a single directly connected network both with a network command and a redistribute connected command, then EIGRP will prefer the "internal point of view".
3) If EIGRP default-metric is not set, what metric is used?
For redistribute connected, EIGRP will have a look at the component metrics (bandwidth, delay, optionally reliability and load) of the interfaces where these networks are connected, and will compute the resulting metric out of these values. This is, by the way, precisely the same thing EIGRP would do if you had the networks added by a network command.
The default-metric is required specifically for redistributing routes from other routing protocols. Neither redistribute static nor redistribute connected in EIGRP require an explicit redistribution metric to be specified.
One last comment about passive-interface command: In fact, a passive interface neither sends nor receives routing protocol messages. This is true for EIGRP, OSPF, and IS-IS. RIP is the only exception - with RIP, passive interfaces do not send updates but they still listen for them.
Best regards,
Peter
Great Explanation! You nailed it