Skip to main content
Versa Networks

Hub-and-Spoke Topology Overview

Versa-logo-release-icon.png For supported software information, click here.

You use a hub-and-spoke topology to connect multiple spoke devices at branch sites to at least one hub device. The hubs are typically located in a data center or in a customer point of presence (PoP). The spoke devices are branch devices which usually have LAN ports that provide network connectivity for endpoint devices. Like all Versa Operating System™ (VOS™) devices, hub devices can also be used as gateway devices that forward Layer 3 traffic and provide access to a larger network.

Hub-and-spoke topologies offer advantages over other network topologies, including:

  • Cost—Hub-and-spoke topologies are generally less expensive than other networking topologies.
  • Scalability and agility—You can quickly and easily add or remove spoke devices from a hub-and-spoke topology as your networking needs evolve.

All hub and spoke devices connect to an SD-WAN Controller through a transport network—either an MPLS network or the internet, or both. The SD-WAN Controller is a component of the Versa Networks headend, which also includes Versa Director and Versa Analytics. You typically install the headend components in a data center or in the cloud. For more information, see the headend deployment articles.

To configure hubs, spokes, and hub controller nodes (HCNs), you use workflow templates. Templates are baseline configurations that you can deploy to multiple devices, thus saving time and effort when you configuring and deploying similar services on the devices in a network. Workflows provide an intuitive graphical user interface that allows you to build templates. Hub-and-spoke topologies consist of three separate templates—one for the hub devices, one for the spoke devices, and one for spoke groups. In the spoke group template, you configure the type of hub-and-spoke topology to use. You access workflow templates from the Workflows tab in Versa Director.

The following section describes the types of hub-and-spoke topologies that you can configure.

There are several types of topologies that you can configure to implement a hub-and-spoke technology, depending on your business needs, and you can change the network topology on demand using Workflows templates. The topologies allow you to choose whether spokes can communicate with each other and, if so, how they communicate. You can place spoke devices in spoke groups so that a hub can limit its route advertisements to only the branches within the spoke group.

This article discusses the following common types of hub-and-spoke topology:

  • Spoke to hub only
  • Spoke to spoke through a hub
  • Spoke to spoke direct
  • Spoke-hub-hub-spoke

Spoke to Hub Only

In a spoke-to-hub-only topology, spoke devices can send traffic only to networks located behind a hub. The spokes are not aware of any other spokes and cannot communicate with them either directly or through their hub. However, the hub can communicate directly with all spokes to which it is connected. A spoke-to-hub-only topology is useful when spokes need to communicate outwardly from the hub only—for example, to access central services—and do not need to communicate with other spokes.

The figure below shows an example of a spoke-to-hub-only topology. In this figure, traffic from both Spoke 4 and Spoke 6 is routed only to the hub.

spoke-to-hub-only-2.png

Spoke to Spoke Through a Hub

In a spoke to spoke through a hub topology, spokes can send traffic to other spokes, but all traffic must first pass through the hub. This topology is useful for deployments with more than 100 sites in a given tenant, and for performing functions like central filtering.

In the figure below, traffic from Spoke 4 is sent to Spoke 6 through the hub (blue arrows). Likewise, traffic from Spoke 1 is sent to Spoke 3 through the hub (green arrows).

spoke-spoke-through-hub-2-3.png

Spoke to Spoke Direct

In a spoke-to-spoke direct topology, you create spoke groups in which the member spokes are connected in a full-mesh topology so that they can communicate directly with each other. The spokes also have connectivity to other spoke groups through the hub.

In the figure below, the hub, Spoke 1, and Spoke 4 are members of Spoke Group A, and the hub, Spoke 3, Spoke 5, and Spoke 6 are members of Spoke Group B. Spoke 4 can communicate directly with Spoke 1 because they belong to the same spoke group (blue arrow), and Spoke 6 can communicate directly with Spoke 3 (green arrow). However, when Spoke 4 wants to communicate with Spoke 6, Spoke 4 must send the traffic through the hub, which forwards it to Spoke 6 (red arrows).

spoke-to-spoke-direct-9.png

The figure belows shows a alternate spoke-to-spoke direct topology. This topology comprises a hub and three spokes (Spoke 1, Spoke 2, and Spoke 3) and two transport networks, the internet and MPLS. In this topology:

  • Hub—Connects to both the internet and MPLS transports
  • Spoke 1—Connects only to the internet
  • Spoke 2—Connects only to the MPLS transport
  • Spoke 3—Connects to both the internet and MPLS tranports

All devices are part of the same spoke group, Spoke Group A.

When Spoke 1 wants to communicate with Spoke 3, its traffic goes directly to Spoke 3, because they are both connected to the internet (blue arrow).

Similarly, when Spoke 2 wants to communicate with Spoke 3, its traffic goes directly to Spoke 3, because they are both connected to the MPLS transport (red arrow).

However, when Spoke 1 wants to communicate with Spoke 2, its traffic must go through the hub, because Spoke 1 and Spoke 2 are not connected to a common WAN transport network (green arrow).

spoke-to-spoke-direct-scenario2-2.png

This topology provides a backup path in case one of the paths fails. For example, if Spoke 3 loses its connection to the internet, the direct connection with Spoke 1 is lost. Here, Spoke 1 has a backup route through the hub to reach Spoke 3, as shown by the blue arrows in the figure below.

spoke-to-spoke-direct-scenario3.png

Spoke-Hub-Hub-Spoke

A spoke-hub-hub-spoke (SHHS) topology consists of islands of spoke devices that are interconnected using hubs. You can group hubs and spokes into regions. This topology is useful in large SD-WAN networks that have a large number of geographically dispersed devices. In these types of networks, segmenting the network into multiple regions provides better scalability. Two or more hubs are deployed in each region, and they serve the spokes in the region. Within a region, you can create any of the hub-and-spoke topologies discussed previously. The hubs and spokes in each region tag the routes that they advertise with the special BGP community string 8011:x, where x is the ID of the region. Spokes in a region accept only routes that contain their region's community string. Hubs in a region accept routes from the spokes in its own region and from hubs in other regions.

As with all VOS SD-WAN devices, hubs are interconnected by Controller nodes that provide the control plane entry point. In a service provider environment, hubs are typically multitenant and are shared by multiple customers, which is similar to regular Controller nodes. You can onboard additional customer tenants by updating the workflow templates.

The following figure shows an SHHS topology. The topology consists of two regions: Region A comprises Hub 1, Spoke 1, and Spoke 2, and Region B comprises Hub 2, Spoke 3, and Spoke 4. Spoke 2 can communicate directly with Spoke 1 because they are in the same region (blue arrow). When Spoke 2 wants to communicate with Spoke 4, in Region B, the traffic is sent to Hub 1, which forwards the traffic to Hub 2 in Region B (purple arrow). Hub 2 then forwards the traffic to the destination, Spoke 4. Likewise, in Region B, Spoke 4 can send traffic directly to Spoke 3 because they are in the same region (green arrow). However, for Spoke 3 to send traffic to Spoke 1 in Region A, the traffic is sent to Hub 2, which forwards the traffic to Hub 1 in Region A, which then delivers the traffic to Spoke 1 (red arrows).

SHHS-3.png

You can create multiple spoke groups in a region. For more information, see Configure Regional Hub-and-Controller Nodes for SHHS Topologies.

Note that you can create a similar topology using hub and controller nodes (HCNs) instead of an SHHS topology.

Supported Software Information

Releases 20.2 and later support all content described in this article, except:

  • For Releases 20.2.1 and later, you can create multiple spoke groups in a region.
  • Was this article helpful?