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.
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.
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:
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?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...