Routing Configuration Guide, Cisco Catalyst SD-WAN Releases 17.x

PDF

Hub-and-Spoke configuration

Updated: February 6, 2026

Overview

Explains the simplified method for building a centralized architecture using transport gateway functionality and site-type attributes. Understanding this mechanism allows you to implement a hub-and-spoke topology that automatically filters route information to spokes, ensuring all inter-spoke traffic flows through a designated hub.

Hub-and-spoke configuration is a method that simplifies the process of establishing a hub-and-spoke topology. Historically, this topology required complex expertise and lengthy centralized control policies in a Cisco Catalyst SD-WAN environment. This new configuration method, available from Cisco IOS XE Catalyst SD-WAN Release 17.12.1a, eliminates the need for complex control policy, making configuration faster.

This method involves configuring the Cisco Catalyst SD-WAN Controller that serve the network to enable hub-and-spoke and configuring transport gateway functionality on a router that will serve as a hub.

Note

The resulting hub-and-spoke topology applies to all VRFs.

Configuration overview

Hub-and-spoke configuration for Cisco Catalyst SD-WAN has three parts, as described in the following table:

Intent

Devices or Controllers to Configure

Configuration

1. Enable a hub-and-spoke topology in the network.

Cisco SD-WAN Controllers that serve the network

Enable hub-and-spoke configuration in the network.

See the following:

2. Configure a router as a transport gateway to function as a hub.

Router designated as hub

Enable transport gateway functionality on the router.

See Configure a router as a transport gateway using a CLI template

The CLI template method uses the transport-gateway enable command.

3. Configure routers to function as spokes.

Routers designated as spokes

Configure the device site type as spoke.

See Configure the site type for a router using a CLI template.

The CLI template method uses the site-type command.

Result of configuration

This configuration results in the following network behavior:

  • Cisco Catalyst SD-WAN Controllers in the network filter the TLOC and route information that they advertise to each router in the network.

    • Routers operating as hubs (transport gateways) receive all TLOC and route information.

    • Routers operating as spokes receive TLOC and route information for the hubs (transport gateways) in the network. They do not receive TLOCs or routes for other spokes. Consequently, there are no bidirectional forwarding detection (BFD) sessions between spoke devices.

  • All spoke-to-spoke traffic flows through the transport gateway, which re-originates routes for each spoke.

Taken together, the result is a hub-and-spoke topology. Routers operating as spokes receive TLOC and route information for the hubs (transport gateways) in the network. They do not receive TLOCs or routes for other spokes. Consequently, there are no bidirectional forwarding detection (BFD) sessions between spoke devices. `

If there are non-spoke sites in the network, spoke sites continue to receive TLOCs or routes from such sites and BFD is established from spoke sites to the non-spoke sites. In this case, it is not a true hub-and-spoke topology.

Benefits of Hub-and-Spoke

A hub-and-spoke topology offers several applications and benefits, including the following:

  • Operating each spoke network with a degree of isolation allows for applying different policies, transport mechanisms, and other configurations to each discrete spoke.

  • Decreasing the number of peers for the edge routers serving each spoke reduces the resource demands on those edge routers.

  • Routing all inter-spoke traffic through a hub enables the application of network services, such as firewall policy, to all inter-spoke traffic.

  • The described configuration process simplifies the setup of a hub-and-spoke topology, avoiding the need for complex centralized control policy.

Restrictions for Hub-and-Spoke

When implementing a hub-and-spoke topology, adhere to the following restrictions to ensure proper functionality and avoid misconfigurations.

Key restrictions for hub-and-spoke configurations include:

  • Transport gateway site type: When using a transport gateway as a hub, do not configure its site type as spoke.

  • On-demand tunnels: In a hub-and-spoke topology, on-demand tunnels are not supported. This is because spoke-to-spoke direct tunnels are not supported in the hub-and-spoke topology.

  • Migration: There is no automatic procedure for migrating from a hub-and-spoke topology defined by control policy to the hub-and-spoke configuration method described here.