# Account for Route Server when disabling gateway-route propagation on a spoke

> Review the dynamic routes affected by a subnet route-table setting.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-072-account-for-route-server-when-disabling-gateway-route-propagation-on-a-spoke/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:33:48+00:00
- Modified: 2026-09-17T16:38:45+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 1 minutes

## What you need to know

Review the dynamic routes affected by a subnet route-table setting.

## Potentially affected

Use 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.

## DSE recommendation

DSE recommends listing the dynamic prefixes expected to remain available before changing propagation.

## Article

## Source facts

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](https://learn.microsoft.com/en-us/azure/route-server/route-injection-in-spokes).

## Applicability

Use 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.

## DSE recommendation

DSE 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.

## Verification

Compare 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.

## Official references

[Microsoft Learn: Route injection in spoke virtual networks](https://learn.microsoft.com/en-us/azure/route-server/route-injection-in-spokes).

## Primary reference

- Name: Route injection in spoke virtual networks - Azure Route Server | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/route-server/route-injection-in-spokes
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Account for Route Server when disabling gateway-route propagation on a spoke,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-072-account-for-route-server-when-disabling-gateway-route-propagation-on-a-spoke/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.