Statict routes Redistributed in EIGRP

[mahesh18]

Hi,

I was reading this statement

EIGRP does not add static routes to the EIGRP topology table unless that routes are

redistributed.

Say Router A  has direct connection to Router B.

And Router A   fa int IP is 192.168.50.2

Router B  has int IP  192.168.50.3

So this mean that if router A  has default route  like 0.0.0.0 0.0.0.0.0 192.168.50.3

and if i do the sh ip eigrp  topology on the router A

it still shows route to

192.168.50.0 subnet?

Can someone please explain me why this happened?

thanks

mahesh

[mahesh18]

Hi Peter,

Many thanks for explaining me in great detail.

Sorry for causing confusion to eveyone.

I will spent some time in going through your replies and  studying  more about EIGRP redistribution before i ask

further questions

Best regards

MAhesh

[Reza Sharifi]

Hi Mahesh,

In addition to explanation by Peter. Looking at the config in your post, you have this command:

no passive-interface Serial0/0

That means interface s0/0 is part of EIGRP network and that is why you see 192.168.50.x in the EIGRP topology.

Or did I misundestand your question?

Reza

[Peter Paluch]

Hi Reza,

That means interface s0/0 is part of EIGRP network and that is why you see 192.168.50.x in the EIGRP topology.

Hmmm... Mahesh said that there is no network 192.168.50.0 command configured on either of his routers which makes me suspicious about what's going on. To my best knowledge, setting the S0/0 interface as "no passive" without specifying it via a network command is not sufficient to have it advertised.

Best regards,

Peter

[Reza Sharifi]

Hi Peter,

So, than what is the purpose of this command under EIGRP process?

Mahesh,

Can you post "sh run" from both routers?

Thanks,

Reza

[Peter Paluch]

Hi Reza,

So, than what is the purpose of this command under EIGRP process?

The snippets of Mahesh's configuration show that he has passive-interface default and no passive-interface S0/0 configured, thereby allowing EIGRP communication only via S0/0 interface even if other interfaces are included into EIGRP using appropriate network commands.

Having an interface declared as passive or "non-passive" does not automatically mean that it is going to be advertised by EIGRP. An interface must first be included into EIGRP by a network command to be advertised. Configuring it as passive merely prevents EIGRP from sending and receiving EIGRP packets over it - if and only if it is covered by a network command. If an interface is not covered by a network command, declaring it explicitly as passive or "non-passive" has no effect.

There is an exception to this rule: In IS-IS, declaring an interface passive will automatically cause it to be advertised (as if you configured the ip router isis on this interface) but prevents IS-IS from forming adjacencies over that interface. The same is valid if running EIGRP for IPv6.

I am not sure if I answered your question - please do ask further.

Best regards,

Peter

[Reza Sharifi]

Hi Peter,

Thanks for the excellent explanation.  I thought, the purpose of this command was that you did not have to explicitly add the network command since you add the physical or logical interface to the process, but apparently my thought was wrong.   Just adding the interface is not enough, you still have to apply the network command, which seems to be redundant.  To me, it would make sense to just add the network command or the interface.  Maybe I am looking at this, because of the way other vender's deploy protocols.  For example, on a Juniper router, you create the process and add the physical or logical interface to it.  You don't need any network command.  I thought, Cisco is going down the same path.

Best Regards,

Reza

[Peter Paluch]

Hello Reza,

I thought, the purpose of this command was that you did not have to  explicitly add the network command since you add the physical or logical  interface to the process

That's the gotcha Cisco's legacy style of configuring routing protocols is to add interfaces using the network command only. Declaring an interface as passive/non-passive is only an additional tweaking of the protocol's operation on an interface once it has been added via the network command, but it is not considered as adding the interface to the routing protocol per se. Needless to say, it is strongly confusing.

The IS-IS has been the only routing protocol in IOS that, to my best knowledge, never used the network command and instead added interfaces directly. Since IOS 12.3, also OSPF can be configured directly on an interface using the command ip ospf area. Things are different with IPv6 routing protocols: neither of them uses the network command and all are configured directly on interfaces.

Just adding the interface is not enough, you still have to apply the network command, which seems to be redundant.

Exactly. But as I indicated - declaring the interface as passive/non-passive is not considered as adding the interface to the routing protocol (save IS-IS and EIGRP for IPv6).

For example, on a Juniper router, you create the process and add the  physical or logical interface to it.  You don't need any network  command.  I thought, Cisco is going down the same path. 

With IS-IS, it has always been this way. OSPFv2 supports this approach since IOS 12.3. Other IPv4 routing protocols have only the network command available. IPv6 protocols are a different beast here... fortunately

Best regards,

Peter

[Reza Sharifi]

Hi Peter,

Thank you so much for clarification. I guess Cisco does a good job of keeping as confused by deploying one protocol one way and another protocol in a different way.  I always ask our SEs the question of why can it all be done the same way?

If other venders can do it, Cisco can certailly do the same.  And the answer is, we are moving that way with IOS XE, Nexus -OS, etc.... hmmm

So, the conclusion is that this command under the EIGRP process is not necessary, since the network command does the job anyway.

Thanks again

Reza

[mahesh18]

Hi Reza,

Do you still need config of Routers ?

LEt me know

thanks

MAhesh

[Reza Sharifi]

Mahesh,

No need.  It is clear now.

Thanks,

Reza