A transit authority places two DMVPN hubs on one shared mGRE cloud for hub redundancy across the county WAN. What trade-off does that dual-hub single-cloud design primarily involve?
Select an answer to reveal the explanation.
Short Explanation
Two hubs on one mGRE cloud is two mayors sharing one town square — simpler for spokes, but a square-wide problem hits both. You get hub redundancy without dual tunnel complexity, yet you do not isolate failure domains as cleanly as dual clouds. Know that trade-off going in.
Full Explanation
Dual-hub single-cloud DMVPN lets a transit authority place two hubs on one shared mGRE cloud so spokes use simpler configuration while still having hub redundancy. The trade-off is correlated exposure: an overlay or NHRP-plane issue in that shared cloud can affect both hubs together, unlike stricter dual-cloud isolation.
Spokes can register to more than one hub; redundancy is not merely configuration symmetry without registration. Single-cloud dual hubs do not require disabling NHRP. The design does not force Phase 1 only; Phase 3 shortcuts remain compatible with two hubs on one cloud.
Exam caveat: single-cloud dual hub trades simplicity for correlated failure risk—know that trade-off language on design questions.
Operational check: register spokes to both hubs on the shared cloud, fail one hub, confirm failover, and document residual risk if the shared NHRP/mGRE plane itself fails. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.