EIGRP stub & multi-access

[mflanigan]

There is a caveat in the eigrp doc, which says that in a multi-access network, all routers except the hub must be stubs, or else none should be, but it doesn't go into much detail. My questions are:

1.What exactly breaks if there is a mix of stub and non-stub spokes?

2.Can this be circumvented by using neighbor statements?

Specifically, my customer has a hub and 4 spoke routers all connected to a wide-area layer 2 ethernet service, with the spokes set as stub. One router now has an additional site chained to the back of it. They want to run eigrp throughout the network, so this router is no longer a stub on the Ethernet. I know I have other workarounds, like GRE, sub-interfaces, etc., but can stub routing still be used over the WAN if all the routers are configured with neighbor statements? This would be the customer's first choice. I should note that routing is working fine now, but I don't know what will happen if a link breaks.

Thanks

[Peter Paluch]

Hello Michael,

I haven't personally tried mixing EIGRP stub and non-stub routers on a common segment. But let's try to at least theoretically analyze what can go wrong.

First of all, we have to talk about what exactly is the EIGRP stub functionality about. The EIGRP Stub affects the way how spoke routers propagate queries, reply with answers and send updates:

1.) For any query received, a stub router replies immediately with "destination unreachable" without propagating the query further

2.) Any network that is learned via EIGRP a stub router is not advertised to any further neighbor

3.) Only a specific subset of locally generated or connected networks is advertised by a stub router to its neighbors (the options are connected, summary, static, any combination thereof, or none)

4.) Neighbors of stub routers do not send any queries to stub routers

However, by itself, an EIGRP Stub feature does not prevent the stub router itself to send queries. It is free to send queries and it accepts all answers and updates like a normal router does.

To answer your queries: what exactly breaks is very much dependent on your topology and the nature of the topology change. I can imagine routers not having identical knowledge of existing destination networks, routers failing to discover alternate paths though they may exist, and so on. It all stems from the Stub properties - do not propagate queries, do not propagate EIGRP-learned routes, answer to any query with unreachable metric.

This problem cannot be circumvented using neighbor statements. The neighbor statement is used to set up adjacencies between routers but it does not affect the way the EIGRP Stub works. You can have a Frame Relay network without any 'broadcast' flags in your IP/DLCI mappings. In this case, you will need to use the neighbors commands but still you can designate spoke routers as EIGRP Stub.

I suggest going over this presentation, it also helps a bit. Note also that the presentation talks about mixing stub and non-stub neighbors but that was only a feature enhancement request and I am not aware whether this has been successfully implemented yet.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/ps6630/prod_presentation0900aecd80310eff.pdf

Best regards,

Peter

[Laurent Aubert]

Hi,

if a hub detects there is one non-stub router on a shared interface (Ethernet, FR,..), it will disable the stub routing feature for this interface. It could lead to Query storm and network instability on this media if you have many spokes (like in DMVPN for ex)

This restriction had been removed starting 12.4(7) and 12.4(9)T (nothing to configure to activate it)

If you have cascaded router behind a stub router, you may need to configure both summary (for updates sent to the hub) and stub leaking for updates sent to the cascaded router:

http://www.cisco.com/en/US/docs/ios/iproute_eigrp/command/reference/ire_a1.html#wp1023086

HTH

Laurent.

[mflanigan]

To Peter and Laurent,

Thank you both for your replies. I believe the customer is at the level for this config to work, per Laurent. This should address the problem. Laurent, the router with the cascaded site was taken out of stub status - I didn't like trying to keep it as stub and still propagate the cascaded subnets. I did check the release notes for both 12.4(7), and 12.4(9)T, and didn't anything about that. Can we confirm that those releases incoporated the upgrade?

Thanks.

Regards,

Mike Flanigan

[Laurent Aubert]

Hi Mike,

I double checked and the fix is in the releases I told you. Of course, every release after those ones will also have this fix.

As it's seen an internal enhancement, it may be not documented but I agree the caveat should be updated.

Laurent.

[mflanigan]

Laurent,

Thank you. I think this issue is resolved.

[Peter Paluch]

Hello Laurent,

Thank you for your answer here - you have been very helpful.

Best regards,

Peter