02 Regions and Hubs Customization - fortinet-solutions-cse/sdwan-advpn-reference GitHub Wiki

Regions

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
as regions AS number of the region e.g. '65001' -(!) yes
lan_summary regions Regional LAN summary e.g. '10.0.0.0/16' - yes
lo_summary regions Regional loopback summary e.g. '10.200.1.0/24' - yes
pe_vrf regions PE VRF for multi-VRF deployment (up to 7.2) <int> 1 yes
Variable Scope Description Values Default stateful
id regions.vrfs VRF ID e.g. '11' -(!) yes
lan_summary regions.vrfs Regional LAN summary per VRF e.g. '10.0.0.0/16' - yes

The regions structure describes all the regions in the project:

{% set regions = {
    'Region1': {
      {# Region1 parameters #}
    },
    'Region2': {
      {# Region2 parameters #}
    }
    {# ... #}
  }
%}

At the very minimum, a region must include an AS number and a list of Hubs serving it (usually one or two):

{% set regions = {
    'SuperWAN': {
      'as': '65001',
      'hubs': [ 'site1-H1', 'site1-H2' ]
    }
  }
%}

In a multi-VRF deployment, one or more VRFs must be specified in the vrfs list, for example:

{% set regions = {
    'SuperWAN': {
      'as': '65001',
      'vrfs': [
        {
          'id': 11
        },
        {
          'id': 12
        }
      ],
      'hubs': [ 'site1-H1', 'site1-H2' ]
    }
  }
%}

In a multi-regional deployment, the regional loopback and LAN summaries (lan_summary, lo_summary) must also be specified. If the deployment is both multi-regional and multi-VRF, the regional LAN summary must be specified per VRF.

For more information about advertisement of LAN and loopback summaries, see this page.

Hubs

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
lo_bgp hubs Loopback IP used for BGP termination e.g. '10.200.1.253' -(!) yes
Variable Scope Description Values Default stateful
wan_ip hubs.overlays Endpoint IP for the IPSEC tunnel e.g. '100.64.1.1' -(!) yes
network_id hubs.overlays IKEv2 Network ID for the IPSEC tunnel e.g. '21' -(!) yes
hub2hub hubs.overlays Allow Hub-to-Hub tunnels over this overlay (7.4+) true / false true no

The hubs structure describes all the Hubs serving the project:

{% set hubs = {
    'hub1': {
      {# hub1 parameters #}
      'overlays': {
        'ol_type_1': {
          {# ol_type_1 parameters #}
        },
        'ol_type_2': {
          {# ol_type_2 parameters #}        
        }
        {# ... #}
      }
    },
    'hub2': {
      {# hub2 parameters #}
      'overlays': {
        'ol_type_1': {
          {# ol_type_1 parameters #}
        },
        'ol_type_2': {
          {# ol_type_2 parameters #}        
        }
        {# ... #}
      }
    }
    {# ... #}    
  }
%}

Every Hub listed inside the regions definition must be described here.

At the very minimum, each Hub must have its loopback value (lo_bgp) and the list of overlays (describing the overlays terminated on it):

{% set hubs = {
    'site1-H1': {
      'lo_bgp': '10.200.1.253',
      'overlays': {
        'ISP1': {
          'wan_ip': '100.64.1.1',
          'network_id': '11'
        },
        'MPLS': {
          'wan_ip': `172.16.1.5`,
          'network_id': '13'
        }
      }
    }
  }
%}

The overlays are those referred using the ol_type parameter in the device profiles. The Spokes will build IPSEC tunnels to them, using the information defined here.

Jinja Orchestrator versions: 7.4+

Variable Scope Description Values Default stateful
dynamic_bgp hubs.peering Dynamic BGP (RR-less) true / false false yes
lo_summary hubs.peering Loopback range for this peering e.g. '10.200.1.128/25' -(!) yes

By default, a single BGP peering is created on each Hub, to accomodate all the Spokes, in accordance with the selected routing design. Optionally, you can customize BGP peering using peering structure, to support mixed deployments. For more information, check this section.

⚠️ **GitHub.com Fallback** ⚠️