Fortinet white logo
Fortinet white logo

Design example - multi-regional design

Design example - multi-regional design

As your solution expands geographically and the number of sites grows, it becomes reasonable to define multiple regions. Each region would be comprised of a hub-and-spoke topology as described in one of the previous examples (either dual-hub or single-hub).

To achieve that, we define regional hubs in each geographical area, and let all other sites in the area connect only to these regional hubs. This includes both IPsec overlays and BGP sessions. As already discussed, this would be enough to provide connectivity within each region. In addition, all the regional hubs are interconnected between them, forming a full-mesh topology with BGP sessions exchanging the routes between all the regions.

The recommended approach is to use EBGP between the regional hubs so that each hub advertises a summary route of all regional prefixes to all remote regional hubs. Those will, in turn, advertise default routes to their spokes. A spoke willing to communicate to a remote region will always send traffic to its local, regional hub, which will use the correct summary route to forward the traffic to the remote regional hub. Note that ADVPN will be used only for spoke-to-spoke traffic within each region, while the traffic across the regions will always flow through the regional hubs.

Design example - multi-regional design

Design example - multi-regional design

As your solution expands geographically and the number of sites grows, it becomes reasonable to define multiple regions. Each region would be comprised of a hub-and-spoke topology as described in one of the previous examples (either dual-hub or single-hub).

To achieve that, we define regional hubs in each geographical area, and let all other sites in the area connect only to these regional hubs. This includes both IPsec overlays and BGP sessions. As already discussed, this would be enough to provide connectivity within each region. In addition, all the regional hubs are interconnected between them, forming a full-mesh topology with BGP sessions exchanging the routes between all the regions.

The recommended approach is to use EBGP between the regional hubs so that each hub advertises a summary route of all regional prefixes to all remote regional hubs. Those will, in turn, advertise default routes to their spokes. A spoke willing to communicate to a remote region will always send traffic to its local, regional hub, which will use the correct summary route to forward the traffic to the remote regional hub. Note that ADVPN will be used only for spoke-to-spoke traffic within each region, while the traffic across the regions will always flow through the regional hubs.