Had an issue at work today I was wondering if I could bounce off you guys:
We run an EIGRP hub and spoke network with DMVPN tunnels for the WAN connectivity. At the spoke sites, we have redundant EIGRP routers controlled via HSRP. Active router goes to the primary hub, Standby router goes to the redundant hub. In our standardized router configurations we use eigrp stub connected on the primary spoke router only. Our lead architect stresses the importance of this, stating that neglecting to include it could cause major issues.
Well, today we fielded a new spoke site without the stub configuration, and it caused network wide routing issues, services drops, & latency. I don't quite understand how this happened though. To my knowledge, having EIGRP stub on the spoke router basically tells the hub-side not to query it for routing paths to lost successors to prevent query storms, SIA situations, etc....I get how that could cause a problem if ALL the spoke sites were missing the EIGRP stub command, but it was only this new site that was missing the information. If all the spoke sites were missing the stub config, then I could deduce that we probably received an alarm for a down branch, which means the EIGRP neighborship dropped & the hub queried every router on the network, but since the only router missing the stub config was this new one, I can't understand how 1 site out of 100 missing the stub command could cause such havoc.
Also, as an aside: Our standardized configurations do NOT require we configure eigrp stub on the HSRP standby routers at the spoke sites. However, all of the literature available recommends all spoke routers to be configured with the stub command. Does this not apply for the standby router in the HSRP pair?
I don't have any experience with DMPVN so i may be asking the wrong questions here.
If under normal operations a remote site fails the hub will not query any other remote sites with EIGRP stub configured.. But does it query the redundant hub ? If so what stops the redundant hub from sending queries to all the remote sites via the backup links as they are not configured with EIGRP stub ?
Do the HSRP routers see each other as EIGRP neighbors in each remote site ?
In addition to changing the behavior about query one thing that configuring an EIGRP router as stub will do is that a stub router can learn routes from multiple neighbors but will not advertise any of the dynamic routes that it has learned. Your new router that was not stub was learning routes from its neighbor at the site and then would probably have advertised those routes to its upstream neighbors. I wonder if this was part of the problem that it created.
I would think that it was highly advisable that both of the routers at the remote site should be configured as stub. We do not know anything about how they are configured and perhaps there is some summerization configured or some route filtering configured that results in stub not being important for them. But in general I would think that if one remote site router was stub then both of them should be.
Hi Richard / Jon,
That's exactly what my internal struggle is; If a branch goes down, what stops the hub from querying the standby routers without the stub connected command? And more interestingly, why does the network function perfectly fine with only the active router in the HSRP pair configured to be stub, but if 1 active router is missing the stub configuration, havoc ensues? Doesn't make any sense to me.
As far as configurations go: The most common site-type we field with this configuration is that the active HSRP router has two DMVPN tunnels built on it; One goes to a hub router in data center 1, and the other goes to a seperate hub router in data center 2. Service providers are broadband internet. EIGRP is the routing protocol, and the spoke LAN subnet, Tunnel subnet to DC-1 & Tunnel Subnet to DC-2 are advertised. As this is VPN, there is also a default route pointing to the next hop ISP address. This is the router that we issue EIGRP Stub connected on.
The Standby router at the spoke sites is a GRE Tunnel over MPLS via wireless 3G modem to a different hub router at data center 1. This is the one that does not require eigrp stub, and we never have issues.
Jon, to answer your question: Yes, the HSRP pair routers do see each other as EIGRP neighbors.
The only thing I can think of is that it has something to do with the standby router going over an MPLS network & the active router going over internet broadband.
One other question while were on the topic: When eigrp stub connected is issued on a spoke router and it advertises the connected routes back to the hub, how will the hub router claim it knows those routes? Will it say "known via connected" on the hub router, as it does on the spoke router?
There are lots of interesting parts to this discussion that we do not have enough information available to really understand and make suggestions about the hubs and spokes and failover.
But your last question is one that we can answer easily. If the spoke is configured as stub and it advertises its lan subnet to the hub (shows as connected on the spoke) then that route will be a normal EIGRP learned dynamic route on the hub. It will not show as connected on the hub.
Rick makes a good point about the new site advertising routes back to the hub.
So it sounds like there are 3 hub routers, 2 used for the primary links and one for the MPLS wireless backup link. How do these hub routers communicate amongst themselves ie. do they see each other as EIGRP neighbors ?
I was initially thinking that because the new site was not EIGRP stub a query was sent from the hub for a lost subnet and the new site active router then sent the query to the standby router which then queried the standby hub which then queried all the remote sites via the standby routers.
But this assumes that the MPLS wireless DMPVN tunnels are up which as i say i don't have any experience with DMPVN so i don't know whether that is the case.
Even if they are i can't see how this would affect your broadband network, only the MPLS wireless network.
Haven't forgot about you, I've just been too busy to visit the forums, but I do appreciate your help/suggestions. Will return when things slow down.
Dean, you could do this a number of ways:
2) Summary Route
I know you don't want to implement stub on your EIGRP spoke routers. But you can also stop queries with summary links. The query should be looking for an exact match.
RA queries for 10.10.10.0/24 but RB, RC, and RD have 10.0.0.0/8. They will not have an exact match, and will send a reply back, that says, I don't have any sorry.
Just a thought...