Microsoft’s Route Server spoke-injection guidance warns that disabling Propagate gateway routes also stops spoke subnets from learning Route Server routes dynamically. For the documented hub-hosted Route Server pattern, spoke peering must use the remote gateway or Route Server. The document distinguishes that arrangement from a dual-homed design where the spoke has its own Route Server. Microsoft Learn.
\nUse this check before changing a spoke subnet’s route table. Identify where Route Server actually runs, which networks peer with it, and which application destinations rely on its learned routes. Do not infer route dependencies from the setting’s gateway-oriented name.
\nDSE recommends listing the dynamic prefixes expected to remain available before changing propagation. Have the routing owner compare the planned setting with the actual topology and any replacement routes. Preserve the current table, association and peering flags. Include a recovery action for loss of an approved dynamic route, rather than limiting rollback criteria to internet reachability.
\nCompare effective routes before and after an approved test change. Check representative Route Server-learned destinations separately from local and static-route destinations. Record next hops and application outcomes together. If a dynamic route disappears, verify the propagation and peering settings before changing the appliance’s BGP advertisements.
\n