Interface names

Referring to physical interface names directly is not ideal, because it makes your templates specific to the device model. Different models may have different interface names.

Let us find such references in our project foundation:

1. Device profiles in our Project Template, for example:

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

   In this case, the interface names are specific to the FortiGate-VM. As a result, every FortiGate model may need to have a separate device profile. Since a typical Managed Offering includes multiple device models, the number of profiles will quickly become excessive.

2. Other Provisioning Templates, mainly the SD-WAN Templates:

   

   Note that the overlay members are generic, thanks to the naming conventions followed by the Jinja Orchestrator. However, the underlay members suffer from the same problem as the device profiles: they explicitly refer to the physical interface names. As a result, every FortiGate model may need to have a separate SD-WAN Template.

Luckily, both these problems have an already familiar solution with per-device variables.

We can rewrite the above profile as follows:

'Branch': {
  'interfaces': [
    {
      'name': isp1_wan_interface,
      'role': 'wan',
      'ol_type': 'ISP1',
      'ip': 'dhcp'
    },
    {
      'name': isp2_wan_interface,
      'role': 'wan',
      'ol_type': 'ISP2',
      'ip': 'dhcp'
    },
    {
      'name': mpls_wan_interface,
      'role': 'wan',
      'ol_type': 'MPLS',
      'ip': mpls_wan_ip
    },
    {
      'name': lan_interface,
      'role': 'lan',
      'ip': lan_ip
    }
  ]
}

The new variables (isp1_wan_interface, isp2_wan_interface, mpls_wan_interface and lan_interface) must be defined on FortiManager, and their values must be set per-device. This introduces extra work during site staging because of more variables to set, but it easily pays off, making the device profiles reusable.

Note that the recommended way of setting the variables is either using the CSV file or using the API. Hence, adding more variables should not increase the burden significantly.

Another important advantage of this method is that the Jinja Orchestrator automatically skips the interfaces without a name. For example, if the value of isp2_wan_interface is not set, this interface is simply skipped! Looking carefully at the rewritten profile, we can see that now it can easily replace both the "Silver" and the "Gold" profiles from the previous chapters:

• For the "Silver" devices (such as "site1-1"), the isp2_wan_interface variable will be left unset
• For the "Gold" devices (such as "site1-2"), it will be set to the correct ISP2 interface.

Our device profile is now truly generic. A single profile can cover not only different hardware models, but even SD-WAN nodes with different number of links. And most likely, it can be reused between different projects.

The same variables will be reused in the SD-WAN Template for the underlay members:

And now, just like the device profile, this single SD-WAN Template can be reused on different hardware models. (It was already used by SD-WAN nodes with different number of links, thanks to the installation targets that we had set on its members in the previous chapters.)