Topology Hub Spoke Policy

Configure hub-and-spoke topology policies to define traffic flow between hub and spoke sites through target VPNs.

spoke_groups[].spoke_sites also accepts network hierarchy groups and regions via the paired spoke_site_groups key - a group name expands to every site nested under it, unioned with any sites listed directly. Hub sites (selected_hub_sites, hub_preferences[].hub_sites) do not have a group option: the hub set is meant to be small and explicit, so it is always a literal site list. See Example-3 and the version note below.

Diagram

Classes

topology_profiles (sdwan.feature_profiles)

Name	Type	Constraint	Mandatory	Default Value
hub_spoke_policies	List	[hub_spoke_policies]	No

hub_spoke_policies (sdwan.feature_profiles.topology_profiles)

Name	Type	Constraint	Mandatory	Default Value
name	String	Regex: ^[^&<>! "]{1,128}$	Yes
lan_vpn_names	List	String[Regex: ^[^&<>! "]{1,128}$]	Yes
selected_hub_sites	List	String	Yes
spoke_groups	List	[spoke_groups]	Yes

spoke_groups (sdwan.feature_profiles.topology_profiles.hub_spoke_policies)

Name	Type	Constraint	Mandatory	Default Value
name	String	Regex: ^[^&<>! "]{1,128}$	Yes
spoke_sites	List	String	No
spoke_site_groups	List	String	No
hub_preferences	List	[hub_preferences]	Yes

hub_preferences (sdwan.feature_profiles.topology_profiles.hub_spoke_policies.spoke_groups)

Name	Type	Constraint	Mandatory	Default Value
hub_sites	List	String	Yes
preference	Choice	10, 20, 30, 40, 50, 60, 70, 80, 90, 100	Yes

Examples

Example-1: This example demonstrates a basic hub-and-spoke topology with a single spoke group. SITE_100 is the hub, SITE_200 is the spoke, and traffic flows through service_lan_vpn1.

sdwan:
  feature_profiles:
    topology_profiles:
      - name: topology_profile_1
        description: hub spoke topology
        hub_spoke_policies:
          - name: hub_spoke_basic
            lan_vpn_names:
              - service_lan_vpn1
            selected_hub_sites:
              - SITE_100
            spoke_groups:
              - name: spoke_group_1
                spoke_sites:
                  - SITE_200
                hub_preferences:
                  - hub_sites:
                      - SITE_100
                    preference: 10

Example-2: This example demonstrates a hub-and-spoke topology with multiple spoke groups and hub preference for failover. Two spoke groups use different hubs with priority preferences.

sdwan:
  feature_profiles:
    topology_profiles:
      - name: topology_profile_2
        description: multi spoke hub spoke topology
        hub_spoke_policies:
          - name: hub_spoke_multi
            lan_vpn_names:
              - service_lan_vpn1
              - service_lan_vpn2
            selected_hub_sites:
              - SITE_100
              - SITE_101
            spoke_groups:
              - name: spoke_group_east
                spoke_sites:
                  - SITE_200
                  - SITE_201
                hub_preferences:
                  - hub_sites:
                      - SITE_100
                    preference: 10
                  - hub_sites:
                      - SITE_101
                    preference: 20
              - name: spoke_group_west
                spoke_sites:
                  - SITE_300
                hub_preferences:
                  - hub_sites:
                      - SITE_101
                    preference: 10

Note:

• lan_vpn_names references service LAN VPN feature names (not VPN IDs). If a VPN needs renumbering, create a new LAN VPN feature with the desired VPN ID rather than modifying the existing one in-place.
• preference values must be consecutive multiples of 10, starting from 10. Example preference values: hub1 - 10, hub2 - 10 when both hubs are primary and hub1 - 10, hub2 - 20 for primary/secondary hubs
• All sites listed in hub_preferences[].hub_sites must also appear in selected_hub_sites.

Example-3: This example demonstrates targeting spoke sites by network hierarchy group instead of listing them individually. BRANCHES is a group declared under sdwan.network_hierarchy that expands to every site nested under it. The hub itself, SITE_100, is still listed explicitly - hub sites are never group-expanded.

sdwan:
  manager_version: "20.18.4"
  network_hierarchy:
    sites:
      - name: SITE_100
        site_id: 100
    groups:
      - name: BRANCHES
        sites:
          - name: SITE_200
            site_id: 200
          - name: SITE_201
            site_id: 201
  feature_profiles:
    topology_profiles:
      - name: topology_profile_3
        description: group-targeted hub spoke topology
        hub_spoke_policies:
          - name: hub_spoke_by_group
            lan_vpn_names:
              - service_lan_vpn1
            selected_hub_sites:
              - SITE_100
            spoke_groups:
              - name: spoke_group_branches
                spoke_site_groups:
                  - BRANCHES
                hub_preferences:
                  - hub_sites:
                      - SITE_100
                    preference: 10

Note: site targeting and Manager version

• A group name in spoke_site_groups must be declared as a group or region under sdwan.network_hierarchy, and every site name here (hub or spoke) must be declared as a site there too - directly, or nested under any group/region. An undeclared name fails validation.
• When sdwan.network_hierarchy is declared, every resolved site is sent as a network hierarchy UUID on Manager 20.18.1 and later. An unset manager_version is treated as 20.18.1+.
• Set manager_version below 20.18 (e.g. "20.15") to send plain site names on the wire instead, for Managers that predate hierarchy UUIDs. manager_version is required whenever sdwan.network_hierarchy is declared - validation rejects the combination of a declared hierarchy and an unset version.
• A spoke_site_groups entry that expands to no sites (an empty group) fails the plan - selected_hub_sites, each spoke group’s sites, and each hub_preferences entry all require at least one site.