Hub-and-Spoke

Hub-and-spoke topology configuration refers to a simplified method for setting up a hub-and-spoke network, particularly within a Cisco Catalyst SD-WAN. This configuration approach streamlines the process by eliminating the need for complex centralized control policies, which were traditionally required and often lengthy.

Feature history for Hub-and-Spoke

This table describes the developments of this feature, by release.

Table 1. Feature history

Feature Name

Release Information

Description

Hub-and-Spoke configuration method

Cisco IOS XE Catalyst SD-WAN Release 17.12.1a

Cisco Catalyst SD-WAN Manager Release 20.12.1

Hub-and-spoke configuration simplifies the process of configuring a hub-and-spoke topology. This approach makes complex centralized control policy unnecessary. The configuration requires only a few simple configurations: a single command each on:

  • The Cisco Catalyst SD-WAN Controllers serving a network

  • A router that serves as a hub

  • The routers that operate as spokes.

Hub-and-Spoke configuration

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.

Hub-and-Spoke connectivity example

This section provides a detailed example demonstrating how network connectivity changes when a full-mesh network is converted to a hub-and-spoke topology.

The following table details the devices, their intended roles, IP addresses, interfaces, and prefixes used in this example, along with their corresponding color coding for illustrations.

Table 2. Devices, IP Addresses, Roles, Interfaces, and Prefixes

Device

Intended Role

Interfaces

Prefixes

Device0

172.16.255.15

Color in illustration: Purple

Hub

10.0.20.15 (3g)

10.1.15.15 (LTE)

None

Device1

172.16.255.35

Color in illustration: Green

Spoke1

10.5.1.35 (LTE)

10.20.35.0/24

Color in illustration: Green highlight

Device2

172.16.255.45

Color in illustration: Blue

Spoke2

10.0.6.45 (LTE)

10.20.45.0/24

Color in illustration: Blue highlight

SDWAN-Controller09

172.16.255.19

Color in illustration: Dark red

Cisco SD-WAN Controller

Not applicable

Not applicable

SDWAN-Controller10

172.16.255.20

Color in illustration: Red

Cisco SD-WAN Controller

Not applicable

Not applicable

The following figure shows the initial state of the network, with full-mesh connectivity before configuring hub-and-spoke.

Figure 1. Network Connectivity Before Hub-and-Spoke Configuration

The following figure shows the network connectivity after configuring hub-and-spoke.

Figure 2. Network Connectivity After Hub-and-Spoke Configuration

Device0 (Hub) connectivity before and after

This section details the observed connectivity for Device0, which functions as the hub, both before and after the hub-and-spoke configuration. It includes information regarding BFD sessions, OMP routes, and IP routes.

BFD Sessions on Device0 (Hub)

The following describes the state of BFD sessions on Device0.

  • Before Configuration: The show sdwan bfd sessions command shows that it has BFD sessions with both Device1 (Spoke1) and Device2 (Spoke1).

  • After configuration: Device0 retains the same BFD sessions with both Device1 (Spoke1) and Device2 (Spoke2).

Figure 3. Hub: BFD Sessions Before and After

OMP Routes on Device0 (Hub)

The following describes the state of OMP routes on Device0.

  • Before Configuration: The show sdwan omp route vpn 1 command shows that the prefixes advertised by Device1 (Spoke1) and Device2 (Spoke2) are reachable only through Device1 (Spoke1) and Device2 (Spoke2), respectively.

  • After configuration: The Device1 (Spoke1) prefix and the Device2 (Spoke2) prefix are reachable through the hub itself (indicated by 0.0.0.0 in the FROM PEER column).

Figure 4. Hub: OMP Routes Before and After

IP Routes on Device0 (Hub)

The following describes the state of IP routes on Device0.

  • Before Configuration: The show ip route vrf 1 command shows that the prefixes advertised by Device1 (Spoke1) and Device2 (Spoke2) are reachable through Device1 (Spoke1) and Device2 (Spoke2), respectively.

  • After configuration: This connectivity remains unchanged for Device0.

Figure 5. Hub: IP Routes Before and After

Device1 (Spoke1) connectivity before and after

This section details the observed connectivity for Device1, which functions as Spoke1, both before and after the hub-and-spoke configuration. It includes information regarding BFD sessions, OMP routes, and IP routes.

BFD Sessions on Device1 (Spoke1)

The following describes the state of BFD sessions on Device1.

  • Before Configuration: The show sdwan bfd sessions command shows BFD sessions with both Device0 (future hub) and Device2 (future Spoke2).

  • After configuration: Device1 only has BFD sessions with the hub; there are no BFD sessions with other spokes (for example, Spoke2).

Figure 6. Spoke1: BFD Sessions Before and After

OMP Routes on Device1 (Spoke1)

The following describes the state of OMP routes on Device1.

  • Before Configuration: The show sdwan omp route vpn 1 command shows that it can reach the Device2 (Spoke2) prefix directly through Device2. This is evident because the TLOC IP column shows the system IP of Device2.

  • After configuration: Device1 can reach the Device2 (Spoke2) prefix only through the hub.

Figure 7. Spoke1: OMP Routes Before and After

IP Routes on Device1 (Spoke1)

The following describes the state of IP routes on Device1.

  • Before Configuration: The show ip route vrf 1 command shows Device1 could reach the Device2 prefix directly through Device2.

  • After configuration: Device1 (Spoke1) can reach the Device2 (Spoke2) prefix only through the hub..

Figure 8. Spoke1: IP Routes Before and After

Device2 (Spoke2) connectivity before and after

This section details the observed connectivity for Device2, which functions as Spoke2, both before and after the hub-and-spoke configuration, mirroring the changes observed for Device1. It includes information regarding BFD sessions, OMP routes, and IP routes.

BFD Sessions on Device2 (Spoke2)

The following describes the state of BFD sessions on Device2.

  • Before Configuration: The show sdwan bfd sessions command shows Device2 had BFD sessions with both Device0 (future hub) and Device1 (future Spoke1).

  • After configuration: Device2 only has BFD sessions with the hub; there are no BFD sessions with other spokes (for example, Spoke1).

Figure 9. Spoke2: BFD Sessions Before and After

OMP Routes on Device2 (Spoke2)

The following describes the state of OMP routes on Device2.

  • Before Configuration: The show sdwan omp route vpn 1 command shows that Device2 could reach the Device1 (Spoke1) prefix directly through Device1 (TLOC IP column shows the system IP of Device1).

  • After configuration: Device2 can reach the Device1 (Spoke1) prefix only through the hub.

Figure 10. Spoke2: OMP Routes Before and After

IP Routes on Device2 (Spoke2)

The following describes the state of IP routes on Device2.

  • Before Configuration: The show ip route vrf 1 command shows that Device2 could reach the Device1 prefix directly through Device1.

  • After configuration: Device2 can reach the Device1 (Spoke1) prefix only through the hub.

Figure 11. Spoke2: IP Routes Before and After

Hub-and-Spoke use cases

Hub-and-spoke use cases describe practical scenarios where this network topology is effectively applied to meet specific organizational needs and leverage its benefits.

Example (Centralized Network Services)

Consider an organization's network with the following characteristics:

  • Headquarters Site: Features a single device designated as a hub, running numerous network services such as an enterprise firewall.

  • Branch Sites: Consists of three branch locations, each equipped with an edge router.

Network administrators choose to implement a hub-and-spoke topology to route all traffic between branch sites through the headquarters hub. This strategic decision allows for the consistent application of centralized network services to all inter-branch traffic, enhancing security and policy enforcement.

The following illustration depicts the configured hub-and-spoke topology for this use case.

Figure 12. Hub-and-Spoke Topology

Configure a Hub-and-Spoke topology

To provide a high-level overview and guide users through the complete process of setting up a hub-and-spoke topology using simplified configuration methods.

Before you begin

Follow these steps to configure a hub-and-spoke topology:

Procedure

Step 1

Configure a Cisco SD-WAN Controller to enable Hub-and-Spoke using Cisco SD-WAN Manager. For more information, see Configure a Cisco Catalyst SD-WAN Controller to enable Hub-and-Spoke using Cisco SD-WAN Manager.

Step 2

Configure a Cisco SD-WAN Controller to enable Hub-and-Spoke using a CLI Template. For more information, see Configure a Cisco SD-WAN Controller to enable Hub-and-Spoke using a CLI template.

Step 3

Configure a Router as a Transport Gateway, for Hub-and-Spoke. Hub-and-spoke configuration makes use of site types and transport gateways. See the following procedures in the transport gateway documentation:

Configure a router as a transport gateway using Cisco SD-WAN Manager.

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

Step 4

Configure the Site Type for a Router, for Hub-and-Spoke. Hub-and-spoke configuration makes use of site types and transport gateways. See the following procedures in the transport gateway documentation:

Configure the site type for a router using Cisco SD-WAN Manager.

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

Configure a Cisco Catalyst SD-WAN Controller to enable Hub-and-Spoke using Cisco SD-WAN Manager

Use this procedure to enable the simplified hub-and-spoke topology configuration method on your Cisco SD-WAN Controller via the Cisco SD-WAN Manager graphical user interface.

This configuration is a foundational step for implementing the simplified hub-and-spoke topology in your Cisco Catalyst SD-WAN environment. It prepares the controllers to filter and advertise TLOC and route information appropriately for hub and spoke devices.

Before you begin

Follow these steps to enable hub-and-spoke configuration on your Cisco SD-WAN Controller:

Procedure

Step 1

From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

Step 2

Click Feature Templates.

Step 3

Do one of the following:

  1. To create a new System template for Cisco SD-WAN Controllers, click Add Template, choose Controller, and click System.

  2. To edit an existing Cisco SD-WAN Controller System template, locate a template of type Controller System in the table of existing feature templates, click … adjacent to the template, and choose Edit.

Step 4

In the Topology field, choose Hub and Spoke.

Step 5

Click Save if creating a new template, or Update if editing an existing template.

The Cisco SD-WAN Controller is now configured to enable the hub-and-spoke topology, allowing for the simplified configuration of hub and spoke routers in the network.

Configure a Cisco SD-WAN Controller to enable Hub-and-Spoke using a CLI template

Use this procedure to enable the simplified hub-and-spoke topology configuration method on your Cisco SD-WAN Controllers by applying a CLI template.

This method provides an alternative to using Cisco SD-WAN Manager for enabling hub-and-spoke functionality on controllers. It is suitable for automated deployments or when direct CLI configuration is preferred. For more information about using CLI templates, see CLI Add-On Feature Templates and CLI Templates. By default, CLI templates execute commands in global configuration mode.

Before you begin

Follow these steps to enable hub-and-spoke configuration on your Cisco SD-WAN Controller using a CLI template:

Procedure

Step 1

Enter system configuration mode.

system

Step 2

Enable a hub-and-spoke topology.

topology hub-and-spoke enable

Note

 

To disable hub-and-spoke functionality, use the no form of the command.

Example

The following example shows how to enable the hub-and-spoke topology:

system
topology hub-and-spoke enable

The Cisco SD-WAN Controller is now configured to enable the hub-and-spoke topology via the CLI template, allowing for the simplified configuration of hub and spoke routers in the network.

Hub-and-Spoke configuration verification

Hub-and-spoke configuration verification involves confirming the correct setup and operational status of a hub-and-spoke topology within a Cisco Catalyst SD-WAN environment. This includes examining configurations on Cisco SD-WAN Controllers, individual hub and spoke routers, and observing expected network behavior.

Methods for Verifying Cisco SD-WAN Controller Configuration

Hub-and-spoke configuration makes use of transport gateways and the site type parameter, which are described in the transport gateway documentation. See Transport gateways for connecting networks in Cisco SD‑WAN.

To verify that a Cisco SD-WAN Controller configuration includes the topology hub-and-spoke enable command, use the show running-config command.

In the following example, the Cisco SD-WAN Controller is configured to enable a hub-and-spoke topology. 

sdwanController# show running-config
...
system
 topology hub-and-spoke
  enable

To verify that the topology hub-and-spoke enable command has taken effect, use the show omp summary command. The output indicates the topology. In the following example, the topology is hub-and-spoke.

sdwanController# show omp summary
per-state UP
admin-state UP
...
topology hub-and-spoke