Skip to content

04 Overlay Customization

Jump to bottom
Dmitry Perets edited this page Mar 27, 2024 · 22 revisions

Design Flavor

Dynamic BGP on Loopback (unified)

Jinja Orchestrator versions: 7.4

Basic Settings

The following two optional variables can be used to tweak this design flavor:

Variable Scope Description Values Default stateful
advpn2 project or profiles.options Config ready for ADVPN 2.0 true / false true yes
dynamic_bgp project or profiles.options Dynamic BGP (RR-less) true / false false yes

They can be configured as global variables, for example:

{% set advpn2 = true %}
{% set dynamic_bgp = true %}

The global values can be overriden on per-profile basis, for example:

{% set profiles = {
    'LegacySpoke': {
      'options': {
        'advpn2': false,
        'dynamic_bgp': false
      },
      'interfaces': [
        # ...
      ]
    }
  }
%}

When used for offline rendering, advpn2 = true generates the complete ADVPN 2.0 configuration (most of which is under SD-WAN section).
When used for FortiManager-based deployment, the SD-WAN configuration is handled by the FortiManager. But even in this case it is advised to configure advpn2 = true, in order to configure the best-practice foundation for ADVPN 2.0.

Mixed Deployment

Mixed RR-based/RR-less deployment is supported. In addition to configuring per-profile settings for the Spokes (with dynamic_bgp set to either false or true for different profiles), it is required to configure custom BGP peering on the Hubs. This is done in the Hubs definition, for example:

{% set hubs = {

    'site1-H1': {
      'peering': {
        'EDGE_RR': { 
          'dynamic_bgp': false,
          'lo_summary': '10.200.1.128/25'
        },
        'EDGE': {
          'dynamic_bgp': true,
          'lo_summary': lo_summary
        }
      },
      'overlays': {
         # ...
      },
      # ...
    }
  }
%}

Each peering must contain the dynamic_bgp value ("true" for RR-less, "false" for RR-based), as well as the respective loopback range for the Spokes.

Multi-VRF Support (Segmentation over Single Overlay)

Variable Scope Description Values Default stateful
pe_vrf project PE VRF for multi-VRF deployments <int> 1 yes
vrf_leak_summary project Internal subnet to use for inter-VRF links e.g. '10.200.255.0/24' 10.200.255.0/24 yes
vrf_rt_as project Base ASN to use for RD/RT values e.g. '65000' 65000 yes

This unified design flavor can be used both for single-VRF is multi-VRF deployments. Most of the necessary distinctions have been already mentioned on the previous pages. Here we summarize them for convenience. The table above also lists all the relevant optional variables that were not mentioned previously.

In order to prepare multi-VRF deployment, the following elements must be configured in the Project Template:

  • One or more VRFs must be defined in the region(s), as explained on this page. The VRFs listed under the region will be used to generate MP-BGP configuration for all devices.

    • The values of MP-BGP RD/RT are using ASN 65000 by default. This can be controlled by an optional global variable listed above.

  • PE VRF is set to 1 by default. This can be controlled by an optional global variable listed above.

  • CE VRFs must be assigned to the LAN interfaces in the device profiles, using the vrf parameter, as explained on this page. Any interface without an explicit VRF value will be assigned to the PE VRF.

    • CE VRFs for which Internet access is required must be configured with allow_dia parameter (in reality, the configuration is per interface, although the effect is for the entire CE VRF).

    • There is a default internal subnet which is used by default for all inter-VRF links. It can be overriden by an optional global variable listed above.

If a region does not contain any VRFs, it is considered to be a single-VRF deployment. As a result, multi-VRF encapsulation is not enabled on the IPSEC tunnels, MP-BGP configuration is not generated, inter-VRF links are not created and all the interfaces without an explicit VRF value are assigned to VRF=0.

Note that reconfiguration between single-VRF and multi-VRF deployment cannot be fully supported at the moment, if Internet access is provided to CE VRFs. This is because the Jinja Orchestrator currently cannot delete the inter-VRF links (note that the allow_dia parameter is not stateful, as shown on this page).

Topology Options

Overlay Mapping and Naming Convention

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
ol_type profiles.interfaces Overlay to connect to over this WAN interface <str> -(!) no
ul_name profiles.interfaces Local underlay name to add to the tunnel <str> - no

An overlay tunnel will be generated from each WAN-facing interface in the Edge (Spoke) device profile to each Hub serving the device region. The target overlay (to which the tunnel will connect) is defined by the ol_type parameter, which is mandatory for all WAN interfaces.

Therefore, it is expected that each of the Hubs is defined in the hubs structure, and each of them describes the overlay referred by the ol_type value.

The default naming convention for the generated tunnels on the Spoke is:

H<hub_index>_<ol_type>

Optionally, a local underlay transport name can be added. This happens automatically, if the ul_name parameter is defined. The naming convention then becomes:

<ul_name>-H<hub_index>_<ol_type>

On the Hub side, the Dial-Up IPSEC endpoints are generated for each WAN interface with the following naming convention:

EDGE_<ol_type>

For more advanced Spoke-to-Hub connectivity options, please refer to this page.

Multi-regional Support

Jinja Orchestrator versions: 7.2+

Hub-to-Hub tunnels between regions are automatically generated when more than one region is defined. Hub-to-Hub EBGP peering is generated as well. By default, the Hub-to-Hub tunnels are built over all available overlays, if they are matching on both Hubs.

Jinja Orchestrator versions: 7.4

Variable Scope Description Values Default stateful
hub2hub hubs.overlays Generate Hub-to-Hub tunnel true / false true no

Hub-to-Hub tunnels over certain overlays can be skipped, by adding hub2hub = false parameter, for example:

{% set hubs = {
    'site1-H1': {
      'overlays': {
        'INET': {
          'wan_ip': west_h1_isp1,
          'network_id': '11',
          'hub2hub': false
        },
        'MPLS': {
          'wan_ip': west_h1_mpls,
          'network_id': '13'
        }
      }
      # ...
    }
    # ...
  }
%}

ADVPN

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
intrareg_advpn project ADVPN within regions true / false true yes
multireg_advpn project ADVPN between regions true / false true (7.4+) yes

Hub-to-Hub Tunnels within the Region

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
intrareg_hub2hub project Hub-to-hub tunnels within regions true / false false no

Other Settings

IPSEC Authentication

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
cert_auth project Enable cert-based authentication (otherwise: PSK) true / false true yes
edge_cert_template project Certificate Template name for Spokes Edge yes
hub_cert_template project Certificate Template name for Hubs Hub yes
psk project pre-shared key (PSK), when cert_auth = false S3cr3t! yes

When certificate-based authentication is enabled, the Certificate Template name is used as the certicicate name in the IPSEC configuration.

Redundant IPSEC Tunnels ("monitor" feature)

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
backup_group profiles.interfaces Backup Group ID - yes
backup profiles.interfaces Interface is backup true / false false yes

We introduce a new abstract concept: a backup group.

The most general definition is as follows. A backup group contains several WAN interfaces, some of which are designated as "backup". Those designated as "backup" are backing up the rest of the group members. In practice, it means that the overlay tunnels over them will be up only when the rest of the group members (non-backup ones) are down. However, as we explain below, there are certain limitations to this general definition, imposed by the FOS capabilities.

The concept is implemented using the IPSEC "monitor" feature available in FOS, also known as "redundant VPN" (see here).

In FOS 7.2, a backup tunnel can monitor only a single "main" tunnel. Therefore, the backup group must currently include only one non-backup interface and one or more backup interfaces. The tunnels over each backup interface will monitor the tunnel over the non-backup interface within the same backup group. Note that in the future FOS releases we will be able to lift this limitation.

Let's consider the most common example:

{% set profiles = {
    'INET_LTE': {
      'interfaces': [
        {
          'name': 'wan1',
          'role': 'wan',
          'ol_type': 'INET',
          'ip': 'dhcp',
          'backup_group': 1,
          'dia': true
        },
        {
          'name': 'wan2',
          'role': 'wan',
          'ol_type': 'LTE',
          'ip': 'dhcp',
          'backup_group': 1,
          'backup': true,
          'dia': true
        },
        {
          'name': 'internal5',
          'role': 'lan',
          'ip': lan_ip
        }
      ]
    } 
  }
%}

There are two optional parameters added to the device profiles on per-interface level:

  • backup_group defines the ID of the backup group
  • backup (true/false) defines whether an interface is designated as backup or not

In the above example, "wan1" and "wan2" belong to the same backup group, in which "wan2" is designated as backup.

Let's assume that we have a Dual-Hub region, so that this example profile is expected to generate four overlay tunnels: H1_INET, H1_LTE, H2_INET and H2_LTE. The configuration above will result in the following redundant VPN configuration:

  • H1_LTE tunnel will monitor H1_INET
  • H2_LTE tunnel will monitor H2_INET

As can be seen, the IPSEC "monitor" feature is applied on per-Hub basis, within the configured backup group.

Overlay Stickiness

Jinja Orchestrator versions: 7.2+

Variable Scope Description Values Default stateful
overlay_stickiness project Enable overlay stickiness (legacy in 7.4+) true / false false (7.4+) yes

Clone this wiki locally