Fortinet black logo

SD-WAN / SD-Branch Architecture for MSSPs

7.2.0

Segmentation over single overlay

Segmentation over single overlay

We now turn to the topic of segmentation across the SD-WAN network. The use case can be summarized as follows:

  • Customer sites have multiple segments segregated from each other. Within each site, each segment may be connected to separate network equipment (such as separate switches and routers), but segments may also share the same equipment that supports multiple VRFs.

    For example, the Customer may want to segregate data and OAM traffic in the network. Another typical requirement is to segregate data traffic of different sensitivity (classification levels), such as Education and Finance, Guest and Corporate, and so on.

  • Not only traffic flow, but also route propagation is permitted only within a segment. In other words, segmentation means also control plane segregation. It also means, for example, that IP addressing overlap is possible between different segments!

    Note

    For this reason, segmentation cannot be implemented only using firewall policies! While they can provide granular segregation of traffic flows, they do not restrict route propagation and do not allow IP overlap. (In other words, they do not implement control plane segregation.)

  • The requirement is to preserve this segregation across the entire SD-WAN network, when we interconnect the sites. In other words, the different segments should not "mix" with each other. Their segment identity must be preserved end-to-end. IP addressing overlap must be supported and so on.

How is this implemented in our SD-WAN Solution?

  • FortiGate devices support multiple VRFs. Therefore, on each SD-WAN node, different Customer segments will be attached to different VRFs.

    Note

    Different VRFs effectively mean different routing tables.

  • On the control-plane, we use MP-BGP VPNv4 to advertise VRF information together with each LAN prefix over the entire SD-WAN overlay network.

  • On the data-plane, the traffic is "tagged" using a new vpn-id-ipip encapsulation, when it is forwarded between the SD-WAN nodes. This encapsulation is enabled on all the IPsec overlay tunnels (including ADVPN shortcuts).

    In other words, we send the traffic from multiple segments (VRFs) over the same IPsec tunnel, while "tagging" it with its VRF information, so that the receiving SD-WAN node can preserve the segregation. This is why we sometimes call this feature "VRF-Aware Overlays".

    Note

    The "vpn-id-ipip" encapsulation is a variation of IPIP. An extra IP header is added inside the ESP payload (encrypted), encoding the VRF ID into the IP address field.

    Note that all our current ASIC and SoC generations (NP6, NP7, SoC4, SoC5, and so on) support acceleration of IPIP. This was one of our main considerations when designing the new encapsulation.

Segmentation over single overlay

We now turn to the topic of segmentation across the SD-WAN network. The use case can be summarized as follows:

  • Customer sites have multiple segments segregated from each other. Within each site, each segment may be connected to separate network equipment (such as separate switches and routers), but segments may also share the same equipment that supports multiple VRFs.

    For example, the Customer may want to segregate data and OAM traffic in the network. Another typical requirement is to segregate data traffic of different sensitivity (classification levels), such as Education and Finance, Guest and Corporate, and so on.

  • Not only traffic flow, but also route propagation is permitted only within a segment. In other words, segmentation means also control plane segregation. It also means, for example, that IP addressing overlap is possible between different segments!

    Note

    For this reason, segmentation cannot be implemented only using firewall policies! While they can provide granular segregation of traffic flows, they do not restrict route propagation and do not allow IP overlap. (In other words, they do not implement control plane segregation.)

  • The requirement is to preserve this segregation across the entire SD-WAN network, when we interconnect the sites. In other words, the different segments should not "mix" with each other. Their segment identity must be preserved end-to-end. IP addressing overlap must be supported and so on.

How is this implemented in our SD-WAN Solution?

  • FortiGate devices support multiple VRFs. Therefore, on each SD-WAN node, different Customer segments will be attached to different VRFs.

    Note

    Different VRFs effectively mean different routing tables.

  • On the control-plane, we use MP-BGP VPNv4 to advertise VRF information together with each LAN prefix over the entire SD-WAN overlay network.

  • On the data-plane, the traffic is "tagged" using a new vpn-id-ipip encapsulation, when it is forwarded between the SD-WAN nodes. This encapsulation is enabled on all the IPsec overlay tunnels (including ADVPN shortcuts).

    In other words, we send the traffic from multiple segments (VRFs) over the same IPsec tunnel, while "tagging" it with its VRF information, so that the receiving SD-WAN node can preserve the segregation. This is why we sometimes call this feature "VRF-Aware Overlays".

    Note

    The "vpn-id-ipip" encapsulation is a variation of IPIP. An extra IP header is added inside the ESP payload (encrypted), encoding the VRF ID into the IP address field.

    Note that all our current ASIC and SoC generations (NP6, NP7, SoC4, SoC5, and so on) support acceleration of IPIP. This was one of our main considerations when designing the new encapsulation.