Fortinet black logo

SD-WAN Deployment for MSSPs

7.2.0

Deployment overview

Deployment overview

We will follow the recommended deployment workflow, as described in the Provisioning and management section of the SD-WAN / SD-Branch Architecture for MSSPs guide. To recap, this workflow consists of the following stages:

  • Creating model devices and templates

  • Staging sites

  • Onboarding devices

Before we begin, let us highlight several important guidelines about the workflow:

  1. Device Discovery is discouraged. FortiManager (FMG) allows you to onboard devices in multiple ways. One option is to manually deploy and partially configure a new FortiGate device, then onboard it using the Device Discovery method, which is initiated from the FMG side. While this method works well in some environments, we discourage you from using it. We recommend using Model Devices, as instructed by the deployment workflow.

    The Model Device approach turns FMG into a "Source of Truth" for the entire SD-WAN node configuration. It suits multiple ZTP (and LTP) methods, and it is safer. An interim configuration will not cause service disruption, since only the final configuration is pushed to the "real" FortiGate (FGT) device at the very last stage.

  2. Per-device configuration is discouraged. FMG allows you to configure FGT devices directly in the Device Manager module on a per-device basis. This method works both for the Model Devices and for the onboarded "real" devices. However, we strongly discourage you from using this method when configuring your Secure SD-WAN Solution. Interactive per-device configuration using Device Manager quickly becomes unacceptable as the number of sites grows. It cannot be easily tracked and/or replicated to other devices or to other environments.

    As instructed by the deployment workflow, the entire SD-WAN node configuration should be carefully templated! The amount of per-device configuration should be reduced to the minimum: it should be limited mainly to assigning the device to the right Device Blueprint and setting per-device variables.

    These steps will then automatically lead to device assignment to the right Device Group, rendering of the right set of the Provisioning Templates, and installation of the right Policy Package.

    Note

    We would like to highlight that the use of Device Blueprints, Device Groups, Provisioning Templates and Policy Packages is always encouraged, whether you are planning to use Zero-Touch Provisioning or not. Good reusable templates are the key for a successful large-scale Secure SD-WAN deployment!

  3. Automation is encouraged. FMG provides comprehensive JSON API support that allows complete automation of the deployment. Every action described in this document can be automated with an API call made using an automation framework of your choice, such as Ansible, Python, and so on. As a result, it is possible to deploy the entire Secure SD-WAN Solution in a fully automated, unattended manner, and there is not need log in to FMG interactively.

    This is strongly encouraged, as it provides multiple benefits:

    • Automation is consistent. Interactive actions are often inconsistent. It may take longer to make the automation work for the first time. But once it is ready, it will produce predictable results every time, without missing a step or mistyping a value.

    • Automation is traceable. Interactive actions are usually not traceable. When the automation is done correctly, it gives you the ability to have a clear trace of all performed actions.

    • Infrastructure as Code (IaC). All templates and other FMG objects can be imported from an external repository using automation. This allows you to quickly replicate the environment from scratch to maintain consistency between staging and production environments for example.

    • For MSSPs, custom Management Portals provide a valuable opportunity to speak their Customer's language: the UI of those Portals can be designed with consideration to a particular Customer's business, using the relevant language, rather than generic SD-WAN terminology. Customer's operators can connect to such a custom Portal, request the necessary action in the language they understand, and trigger API calls from the Portal to FMG (for example, creating a Model Device during site onboarding).

    • Needless to say, automation saves time, minimizes human mistakes, and becomes indispensable in large-scale deployments.

    • See also the External orchestration section in the SD-WAN / SD-Branch Architecture for MSSPs guide.

Deployment overview

We will follow the recommended deployment workflow, as described in the Provisioning and management section of the SD-WAN / SD-Branch Architecture for MSSPs guide. To recap, this workflow consists of the following stages:

  • Creating model devices and templates

  • Staging sites

  • Onboarding devices

Before we begin, let us highlight several important guidelines about the workflow:

  1. Device Discovery is discouraged. FortiManager (FMG) allows you to onboard devices in multiple ways. One option is to manually deploy and partially configure a new FortiGate device, then onboard it using the Device Discovery method, which is initiated from the FMG side. While this method works well in some environments, we discourage you from using it. We recommend using Model Devices, as instructed by the deployment workflow.

    The Model Device approach turns FMG into a "Source of Truth" for the entire SD-WAN node configuration. It suits multiple ZTP (and LTP) methods, and it is safer. An interim configuration will not cause service disruption, since only the final configuration is pushed to the "real" FortiGate (FGT) device at the very last stage.

  2. Per-device configuration is discouraged. FMG allows you to configure FGT devices directly in the Device Manager module on a per-device basis. This method works both for the Model Devices and for the onboarded "real" devices. However, we strongly discourage you from using this method when configuring your Secure SD-WAN Solution. Interactive per-device configuration using Device Manager quickly becomes unacceptable as the number of sites grows. It cannot be easily tracked and/or replicated to other devices or to other environments.

    As instructed by the deployment workflow, the entire SD-WAN node configuration should be carefully templated! The amount of per-device configuration should be reduced to the minimum: it should be limited mainly to assigning the device to the right Device Blueprint and setting per-device variables.

    These steps will then automatically lead to device assignment to the right Device Group, rendering of the right set of the Provisioning Templates, and installation of the right Policy Package.

    Note

    We would like to highlight that the use of Device Blueprints, Device Groups, Provisioning Templates and Policy Packages is always encouraged, whether you are planning to use Zero-Touch Provisioning or not. Good reusable templates are the key for a successful large-scale Secure SD-WAN deployment!

  3. Automation is encouraged. FMG provides comprehensive JSON API support that allows complete automation of the deployment. Every action described in this document can be automated with an API call made using an automation framework of your choice, such as Ansible, Python, and so on. As a result, it is possible to deploy the entire Secure SD-WAN Solution in a fully automated, unattended manner, and there is not need log in to FMG interactively.

    This is strongly encouraged, as it provides multiple benefits:

    • Automation is consistent. Interactive actions are often inconsistent. It may take longer to make the automation work for the first time. But once it is ready, it will produce predictable results every time, without missing a step or mistyping a value.

    • Automation is traceable. Interactive actions are usually not traceable. When the automation is done correctly, it gives you the ability to have a clear trace of all performed actions.

    • Infrastructure as Code (IaC). All templates and other FMG objects can be imported from an external repository using automation. This allows you to quickly replicate the environment from scratch to maintain consistency between staging and production environments for example.

    • For MSSPs, custom Management Portals provide a valuable opportunity to speak their Customer's language: the UI of those Portals can be designed with consideration to a particular Customer's business, using the relevant language, rather than generic SD-WAN terminology. Customer's operators can connect to such a custom Portal, request the necessary action in the language they understand, and trigger API calls from the Portal to FMG (for example, creating a Model Device during site onboarding).

    • Needless to say, automation saves time, minimizes human mistakes, and becomes indispensable in large-scale deployments.

    • See also the External orchestration section in the SD-WAN / SD-Branch Architecture for MSSPs guide.