Fortinet white logo
Fortinet white logo

SD-WAN Deployment for MSSPs

Overlay tunnels

Overlay tunnels

By default, overlay tunnels are generated on a Spoke from each WAN interface in the Spoke's profile to each Hub serving the Spoke's region. For each tunnel, the target overlay (to which the tunnel will connect) is defined by the ol_type parameter of the WAN interface.

For example, consider a Spoke "site1-1" in our example project. It belongs to the "Silver" profile, which is defined as follows:

'Silver': {
  'interfaces': [
    {
      'name': 'port1',
      'role': 'wan',
      'ol_type': 'ISP1',
      'ip': 'dhcp'
    },
    {
      'name': 'port4',
      'role': 'wan',
      'ol_type': 'MPLS',
      'ip': mpls_wan_ip
    },
    {
      'name': 'port5',
      'role': 'lan',
      'ip': lan_ip
    }
  ]
}

It also belongs to the West region, which is served by two Hubs ("site1-H1" and "site1-H2").

In accordance with our reference design, the Jinja Orchestrator will generate four tunnels in this case: one per Hub from each of the two WAN interfaces. The default naming convention will be:

H<hub_index>_<ol_type>

In other words, the following four tunnels will be generated on the Spoke:

  • H1_ISP1

  • H1_MPLS

  • H2_ISP1

  • H2_MPLS

Hence, these are the tunnel names that we will configure in the SD-WAN Template assigned to this Spoke!

Optionally, we can add a local underlay name to the naming convention. In some topologies, this might result in a more intuitive tunnel naming convention, which can simplify future troubleshooting. To achieve this, we must simply add a ul_name parameter to the interface. For example, consider the "Many-to-One" topology between Spoke and Hub (see Topologies with multiple Internet links section in the SD-WAN / SD-Branch Architecture for MSSPs guide), in which a Spoke has two Internet links, while a Hub has just one. This topology can be modeled as follows:

'ManyToOne': {
  'interfaces': [
    {
      'name': 'port1',
      'role': 'wan',
      'ol_type': 'INET',
      'ul_name': 'ISP1',
      'ip': 'dhcp'
    },
    {
      'name': 'port2',
      'role': 'wan',
      'ol_type': 'INET',
      'ul_name': 'ISP2',
      'ip': 'dhcp'
    }
  ]
}

The following tunnels will be generated on the Spoke (assuming a Dual-Hub region):

  • ISP1-H1_INET

  • ISP2-H1_INET

  • ISP1-H2_INET

  • ISP2-H2_INET

This tunnel naming helps to correctly identify both the local and the remote end of each tunnel.

Note

For more examples, see the Wiki page in the GitHub repository. See Appendix C - External resources.

Finally, on the Hubs the following naming convention is used, when generating the Dial-Up IPSEC endpoints:

EDGE_<ol_type>

For a Hub that belongs to the "Silver" profile (such as "site2-H1"), the Dial-Up endpoints will be EDGE_ISP1 and EDGE_MPLS.

Overlay tunnels

Overlay tunnels

By default, overlay tunnels are generated on a Spoke from each WAN interface in the Spoke's profile to each Hub serving the Spoke's region. For each tunnel, the target overlay (to which the tunnel will connect) is defined by the ol_type parameter of the WAN interface.

For example, consider a Spoke "site1-1" in our example project. It belongs to the "Silver" profile, which is defined as follows:

'Silver': {
  'interfaces': [
    {
      'name': 'port1',
      'role': 'wan',
      'ol_type': 'ISP1',
      'ip': 'dhcp'
    },
    {
      'name': 'port4',
      'role': 'wan',
      'ol_type': 'MPLS',
      'ip': mpls_wan_ip
    },
    {
      'name': 'port5',
      'role': 'lan',
      'ip': lan_ip
    }
  ]
}

It also belongs to the West region, which is served by two Hubs ("site1-H1" and "site1-H2").

In accordance with our reference design, the Jinja Orchestrator will generate four tunnels in this case: one per Hub from each of the two WAN interfaces. The default naming convention will be:

H<hub_index>_<ol_type>

In other words, the following four tunnels will be generated on the Spoke:

  • H1_ISP1

  • H1_MPLS

  • H2_ISP1

  • H2_MPLS

Hence, these are the tunnel names that we will configure in the SD-WAN Template assigned to this Spoke!

Optionally, we can add a local underlay name to the naming convention. In some topologies, this might result in a more intuitive tunnel naming convention, which can simplify future troubleshooting. To achieve this, we must simply add a ul_name parameter to the interface. For example, consider the "Many-to-One" topology between Spoke and Hub (see Topologies with multiple Internet links section in the SD-WAN / SD-Branch Architecture for MSSPs guide), in which a Spoke has two Internet links, while a Hub has just one. This topology can be modeled as follows:

'ManyToOne': {
  'interfaces': [
    {
      'name': 'port1',
      'role': 'wan',
      'ol_type': 'INET',
      'ul_name': 'ISP1',
      'ip': 'dhcp'
    },
    {
      'name': 'port2',
      'role': 'wan',
      'ol_type': 'INET',
      'ul_name': 'ISP2',
      'ip': 'dhcp'
    }
  ]
}

The following tunnels will be generated on the Spoke (assuming a Dual-Hub region):

  • ISP1-H1_INET

  • ISP2-H1_INET

  • ISP1-H2_INET

  • ISP2-H2_INET

This tunnel naming helps to correctly identify both the local and the remote end of each tunnel.

Note

For more examples, see the Wiki page in the GitHub repository. See Appendix C - External resources.

Finally, on the Hubs the following naming convention is used, when generating the Dial-Up IPSEC endpoints:

EDGE_<ol_type>

For a Hub that belongs to the "Silver" profile (such as "site2-H1"), the Dial-Up endpoints will be EDGE_ISP1 and EDGE_MPLS.