Fortinet black logo

SD-WAN / SD-Branch Architecture for MSSPs

Home FortiGate / FortiOS 7.2.0 SD-WAN / SD-Branch Architecture for MSSPs
7.2.0
7.2.0
7.0.0
6.4.0

Planning guidelines

Planning guidelines

The most important question is how to assign VRF IDs to the Customer segments. Let us start by listing all the constraints that we have:

  • Avoid using VRF=0 for PE/CE. Due to its special role in FortiOS architecture, there are good reasons not to use VRF=0 in the multi-VRF SD-WAN overlay network. One such reason is explained in the next section, where we discuss the Internet access.

    To be clear: it is perfectly fine to use VRF=0 for other local purposes, without making it part of the SD-WAN overlay network. (Think of an out-of-band management, for example.) These use cases are valid.

    Note

    Not all FortiGate features can work in VRFs other than 0. One good example is multicast: at the moment of this writing, FortiOS supports it only in VRF=0. Therefore, if the customer needs multicast in one of their segments, then VRF=0 must be used. A tailored solution for this use case is outside the scope of this document.

  • Use the same VRF IDs everywhere. The VRF IDs have global significance in our solution. All the SD-WAN nodes (Hubs and Spokes!) must use the same CE/PE VRF IDs!

    This means that a particular segment (for example, Finance) must be attached to the same CE VRF across the entire SD-WAN network.

    This also means that the PE VRF must be the same across the entire SD-WAN network.

  • Use PE VRF for Internet access (and for all WAN underlays). In theory, we could talk about a separate WAN VRF to which the WAN-facing underlay interfaces are assigned. Apart from terminating the IPsec overlays, it would have another very important duty of providing Internet access to the CE VRFs. But we recommend using the PE VRF for this purpose, unless you have a very good reason to do it otherwise.

    In other words, our recommendation is that the PE VRF includes all the WAN-facing interfaces (underlays and overlays). Simply put: PE VRF = WAN VRF = Internet VRF.

    Note

    See also Providing Internet access, where we discuss Internet access in multi-VRF deployments in more detail.

With these constraints in mind, we recommend the following VRF allocation:

VRF ID

Role

0

Preferably not part of the SD-WAN overlay network (for example, OOB management)

1

PE VRF

2-251

CE VRFs

The next question is how to assign the RD/RT values to the CE VRFs:

  • Both RD and RT values have the following format: <ASN>:<int>. Recall that their exact values do not matter, as long as they are consistent on all the SD-WAN nodes. Hence, for simplicity, we recommend selecting a single Autonomous System number (such as 65000) and using a convention 65000:<vrf_id> for all CE VRFs, both for RDs and for RTs.

    In other words: RD = RT = 65000:<vrf_id>.

  • Note that if you extend the solution to multiple regions, the VPNv4 routes will be exchanged also between the regions (including their RDs and RTs). Recall that each region has its own AS number. However, the RD/RT must be configured consistently on all the SD-WAN nodes across the entire network!

    Hence, when selecting the AS number for your RD/RT, it is recommended NOT to use your region's AS! Do not confuse the AS number used for BGP operation with the "dummy" AS number used for the RD/RT values. They do not have to (and should not) be the same. For example, you can use the value 65000 for RTs/RDs (as shown earlier), while your regions will use AS numbers 65001, 65002 and so on for BGP operation.

Previous
Next

Planning guidelines

The most important question is how to assign VRF IDs to the Customer segments. Let us start by listing all the constraints that we have:

  • Avoid using VRF=0 for PE/CE. Due to its special role in FortiOS architecture, there are good reasons not to use VRF=0 in the multi-VRF SD-WAN overlay network. One such reason is explained in the next section, where we discuss the Internet access.

    To be clear: it is perfectly fine to use VRF=0 for other local purposes, without making it part of the SD-WAN overlay network. (Think of an out-of-band management, for example.) These use cases are valid.

    Note

    Not all FortiGate features can work in VRFs other than 0. One good example is multicast: at the moment of this writing, FortiOS supports it only in VRF=0. Therefore, if the customer needs multicast in one of their segments, then VRF=0 must be used. A tailored solution for this use case is outside the scope of this document.

  • Use the same VRF IDs everywhere. The VRF IDs have global significance in our solution. All the SD-WAN nodes (Hubs and Spokes!) must use the same CE/PE VRF IDs!

    This means that a particular segment (for example, Finance) must be attached to the same CE VRF across the entire SD-WAN network.

    This also means that the PE VRF must be the same across the entire SD-WAN network.

  • Use PE VRF for Internet access (and for all WAN underlays). In theory, we could talk about a separate WAN VRF to which the WAN-facing underlay interfaces are assigned. Apart from terminating the IPsec overlays, it would have another very important duty of providing Internet access to the CE VRFs. But we recommend using the PE VRF for this purpose, unless you have a very good reason to do it otherwise.

    In other words, our recommendation is that the PE VRF includes all the WAN-facing interfaces (underlays and overlays). Simply put: PE VRF = WAN VRF = Internet VRF.

    Note

    See also Providing Internet access, where we discuss Internet access in multi-VRF deployments in more detail.

With these constraints in mind, we recommend the following VRF allocation:

VRF ID

Role

0

Preferably not part of the SD-WAN overlay network (for example, OOB management)

1

PE VRF

2-251

CE VRFs

The next question is how to assign the RD/RT values to the CE VRFs:

  • Both RD and RT values have the following format: <ASN>:<int>. Recall that their exact values do not matter, as long as they are consistent on all the SD-WAN nodes. Hence, for simplicity, we recommend selecting a single Autonomous System number (such as 65000) and using a convention 65000:<vrf_id> for all CE VRFs, both for RDs and for RTs.

    In other words: RD = RT = 65000:<vrf_id>.

  • Note that if you extend the solution to multiple regions, the VPNv4 routes will be exchanged also between the regions (including their RDs and RTs). Recall that each region has its own AS number. However, the RD/RT must be configured consistently on all the SD-WAN nodes across the entire network!

    Hence, when selecting the AS number for your RD/RT, it is recommended NOT to use your region's AS! Do not confuse the AS number used for BGP operation with the "dummy" AS number used for the RD/RT values. They do not have to (and should not) be the same. For example, you can use the value 65000 for RTs/RDs (as shown earlier), while your regions will use AS numbers 65001, 65002 and so on for BGP operation.

Previous
Next