Fortinet white logo
Fortinet docs logo DOCUMENT LIBRARY
Fortinet white logo
Fortinet docs logo DOCUMENT LIBRARY
Products Best Practices Hardware Guides Products A-Z
Summary
By Solution
By 4D Pillars
By Cloud
Secure Networking
Unified SASE
Security Operations
Secure SD-WAN
Secure Access Service Edge (SASE)
ZTNA
LAN Edge
Identity and Access Management
Next Generation Firewall
Public Cloud
Private Cloud
FortiCloud
Secure Networking
  • Hybrid Mesh Firewall
  • NOC Management
  • LAN
  • WAN
    • More >>
    Unified SASE
  • Single Vendor SASE
  • Cloud Network Security
  • Secure Endpoint Connectivity
  • Web Application / API Protection
    • More >>
    Security Operations
  • Security Operations Automation
  • Identity
  • Early Detection & Prevention
    • More >>
    Secure Networking
  • Hybrid Mesh Firewall
  • NOC Management
  • LAN
  • WAN
  • Communication & Surveillance
    • Unified SASE
  • Single Vendor SASE
  • Secure Endpoint Connectivity
  • Cloud Network Security
  • Cloud-Native Security
  • Web Application / API Protection
    • Security Operations
  • Security Operations Automation
  • Endpoint
  • Data Protection
  • Identity
  • Email
  • Early Detection & Prevention
  • Expert Services
  • Edge Firewall
  • Orchestration & management
  • SD Branch
  • Application Delivery
  • Single Vendor SASE
  • Secure Endpoint Connectivity
  • Secure Private Access
  • Thin Edge
  • Identity
  • Application Gateway
  • Enterprise Asset Management
  • Endpoint Agent
  • Agentless Security Posture
  • Identity
  • Wireless
  • Switching
  • Identity
  • Privilege Acccess Management
  • Next Generation Firewall
  • Orchestration & management
  • Expert Services
  • All
  • All
  • Account Management
  • SAAS Management
  • SAAS Application Security
  • Managed Services
  • Platform as a service (PAAS)
  • Other SAAS Services
    • 4D Resources
    Solution Hubs
  • 4D Pillars
  • Cloud
  • Popular Solutions

    • SD-WAN / SD-Branch Architecture for MSSPs

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

    BGP on loopback

    BGP on loopback

    Starting from FOS 7.0.4, we support a new routing design called "BGP on Loopback". It simplifies the configuration significantly and greatly reduces the number of routes advertised throughout the network.

    • Every Spoke establishes a single IBGP session towards each of the Hubs.

    • This IBGP session is terminated on the loopback interface, which uniquely identifies each SD-WAN node (Hub and Spoke).

    • The Spoke advertises its LAN prefix(es) over this single IBGP session per Hub.

    The following diagram depicts the same Single-Hub SD-WAN/ADVPN region as in the previous section and illustrates a LAN prefix 10.0.2.0/24, which is advertised by "site1-2" and is propagated to "site1-1":

    As can be seen, for each LAN prefix, a single BGP route is generated, with a copy sent to each of the Hubs:

    • BGP next-hop (NH) is the loopback IP of the originating Spoke.

    • The Hubs still act as BGP RRs, but they need to reflect a smaller number of routes. Furthermore, BGP ADD-PATH is no longer required, because there is just a single BGP NH for each prefix in the network.

    • Besides reflecting the routes, the Hubs also advertise a loopback summary to the Spokes. It summarizes all the loopback addresses in the overlay network (10.200.0.0/14 in our example). BGP NH of this summary route is the loopback of the Hub itself.

    • On the receiving Spokes, the BGP NH of the LAN prefix is recursively resolved through the loopback summary, which in turn is resolved through a static /32 route towards the Hub loopback, and injected by an extension to the IKE protocol (exchange-ip-addrv4 feature). See the Example of route resolution with BGP on loopback.

    The following diagram shows the same region with an active ADVPN shortcut between "site1-1" and "site1-2":

    As can be seen when ADVPN shortcut is established, it injects a /32 route towards the loopback IP of the remote Spoke. This allows to recursively resolve the earlier learned BGP route through the shortcut. At the same time, an extension to the BGP resolution algorithm (called "Tag-based Recursive Resolution" and covered in BGP extension: tag-based recursive resolution) ensures that alternative paths (through the other available overlays) are still included in the resolution results. (See the Example of route resolution with BGP on loopback.)

    Before seeing an example of route resolution, we must elaborate on the two proprietary extensions that have been implemented to support this design:

    Previous
    Next

    BGP on loopback

    BGP on loopback

    Starting from FOS 7.0.4, we support a new routing design called "BGP on Loopback". It simplifies the configuration significantly and greatly reduces the number of routes advertised throughout the network.

    • Every Spoke establishes a single IBGP session towards each of the Hubs.

    • This IBGP session is terminated on the loopback interface, which uniquely identifies each SD-WAN node (Hub and Spoke).

    • The Spoke advertises its LAN prefix(es) over this single IBGP session per Hub.

    The following diagram depicts the same Single-Hub SD-WAN/ADVPN region as in the previous section and illustrates a LAN prefix 10.0.2.0/24, which is advertised by "site1-2" and is propagated to "site1-1":

    As can be seen, for each LAN prefix, a single BGP route is generated, with a copy sent to each of the Hubs:

    • BGP next-hop (NH) is the loopback IP of the originating Spoke.

    • The Hubs still act as BGP RRs, but they need to reflect a smaller number of routes. Furthermore, BGP ADD-PATH is no longer required, because there is just a single BGP NH for each prefix in the network.

    • Besides reflecting the routes, the Hubs also advertise a loopback summary to the Spokes. It summarizes all the loopback addresses in the overlay network (10.200.0.0/14 in our example). BGP NH of this summary route is the loopback of the Hub itself.

    • On the receiving Spokes, the BGP NH of the LAN prefix is recursively resolved through the loopback summary, which in turn is resolved through a static /32 route towards the Hub loopback, and injected by an extension to the IKE protocol (exchange-ip-addrv4 feature). See the Example of route resolution with BGP on loopback.

    The following diagram shows the same region with an active ADVPN shortcut between "site1-1" and "site1-2":

    As can be seen when ADVPN shortcut is established, it injects a /32 route towards the loopback IP of the remote Spoke. This allows to recursively resolve the earlier learned BGP route through the shortcut. At the same time, an extension to the BGP resolution algorithm (called "Tag-based Recursive Resolution" and covered in BGP extension: tag-based recursive resolution) ensures that alternative paths (through the other available overlays) are still included in the resolution results. (See the Example of route resolution with BGP on loopback.)

    Before seeing an example of route resolution, we must elaborate on the two proprietary extensions that have been implemented to support this design:

    Previous
    Next