Affect of stub in a fully-meshed Metro E environment

[akrauska]

Our 150 remote routers were all stubbed in our FR hub/spoke network. Now we've migrated 16 over to Metro E/fully meshed network and they are still stubbed. We've kept the FR connections for a backup to the Metro E. The Cisco document "EIGRP Stub Routing" lists the following under Restrictions: "A stub router should not have any EIGRP neighbors other than distribution routers. Ignoring this restriction will cause undesirable behavior." Can someone elaborate on the "undersirable behavior" and whether routers in a fully-meshed Metro E should be stubbed. ATT says they should not. I haven't able to find anything in writing to really define the best practice in this mixed environment.

[Richard Burts]

Andrew

I think I agree with ATT on this, while it was beneficial to configure them as subs when they were spokes in a hub and spoke network it is not appropriate when they are in a full mesh.

One aspect of configuring a router as stub is that it will advertise its own routes (connected, static, or perhaps redistributed) but it will not advertise routes that it has learned from a neighbor. That is good for hub and spoke but not so good for full mesh. Another important aspect of stub routers in EIGRP is that routers do not send query packets to stub neighbors. While that is good in hub and spoke networks it probably has negative impact on convergence in full mesh networks.

HTH

Rick

[akrauska]

Rick,

Thanks for the input. What do you make of this explanation I got today about why these routers have remained stubbed in the Metro E environment: "It isn't just about topology but also traffic flow for our applications. Additionally as we move forward, many of these routers will converted to the OSPF core and this has potential impacts on how we handle this." This makes no sense at all to me in relation to the purpose of stubbing. Any thoughts?

Andy

[Richard Burts]

Andy

It seems to me to be a bunch of fancy verbiage which dances around the question without really saying much. I do have a couple of thoughts about both of the points in their response.

So what is the traffic flow? I am assuming that the original setup created a group of remote routers which provide access for groups of remote users and a hub router which provides connectivity to corporate resources and connectivity between the remotes. If those relationships remain the same (essentially only the transport changes), one could argue that maintaining the stub configuration does not hurt anything. In my mind it means that you lose some of the advantage of full mesh Ethernet connectivity. But maybe the applications do not care.

Part of what I think I perceive in the second point is that someone plans to change the routing protocol for these routers and believes that it is not worth the effort to clean them up in EIGRP since they will convert to OSPF at some point (and I gather that the stub configuration on the Ethernet has not yet caused much pain - so maybe they are right).

As an abstract issue or as a design question I still believe that for full mesh Ethernet (Metro or otherwise) EIGRP routers should not be stub. But in your particular situation I am not sure that retaining the stub does any damage.

HTH

Rick