Hello Justin
Thanks for sharing your experience and the results of your investigations of the split horizon and stub features of EIGRP. This behavior that you observed in the R3 router is indeed based on how EIGRP operates. The behavior centers on the fact that R3 is configured as a stub even though it has more than one connection to the rest of the EIGRP topology.
The term “stub” typically denotes an endpoint or a router at the edge, and in the common EIGRP use case, it’s often a router with a single connection to the rest of the network. Such routers are ideal candidates for the stub feature because they don’t need to handle or propagate EIGRP queries. Their sole path into the EIGRP domain is via that one connection.
However, the EIGRP stub feature, in its pure technical definition, does not prohibit a router from having multiple connections. It’s more about the behavior of the router in the EIGRP topology than its connection count, and this is the behavior you observed. When you make an EIGRP router a stub, it signals its neighbors to not send it queries.
By default, a stub router will only advertise connected and summary routes. As a result, a stub router will not advertise routes it has learned from other EIGRP neighbors. This means the router upstream will not have knowledge of any downstream routes beyond the stub router.
You are indeed correct that stub leak maps do resolve these issues. Personally, the reason I believe that you haven’t seen this documented anywhere is the fact that a router with multiple connections to an EIGRP topology is not typically configured as a stub, and thus its behavior can be unexpected and not immediately understandable.
I hope this has been helpful!
Laz