Advanced LSVPN configuration workflow using iBGP to securely connect up to 500
distributed office locations with primary and disaster recovery data centers.
| Where Can I Use This? | What Do I Need? |
|
|
- No separate license required for LSVPN when using NGFWs
|
This use case illustrates how GlobalProtect LSVPN securely connects distributed office locations
with primary and disaster recovery data centers that house critical applications for
users and how an internal border gateway protocol (iBGP) eases deployment and
upkeep. Using this method, you can extend up to 500 satellite offices connecting to
a single gateway.
BGP is a highly scalable, dynamic routing protocol that is ideal for hub-and-spoke deployments
such as LSVPN. As a dynamic routing protocol, it eliminates much of the overhead
associated with access routes (static routes) by making it relatively easy to deploy
additional satellite firewalls. Due to its route filtering capabilities and features
such as multiple tunable timers, route dampening, and route refresh, BGP scales to a
higher number of routing prefixes with greater stability than other routing
protocols like RIP and OSPF. In the case of iBGP, a peer group, which includes all
the satellites and gateways in the LSVPN deployment, establishes adjacencies over
the tunnel endpoints. The protocol then implicitly takes control of route
advertisements, updates, and convergence.
In this example configuration, an
active/passive HA pair of PA-5200 firewalls is deployed in the primary
(active) data center and acts as the portal and primary gateway.
The disaster recovery data center also has two PA-5200s in an active/passive
HA pair acting as the backup LSVPN gateway. The portal and gateways
serve 500 PA-220s deployed as LSVPN satellites in branch offices.
Both
data center sites advertise routes but with different metrics. As
a result, the satellites prefer and install the active data center’s
routes. However, the backup routes also exist in the local routing
information base (RIB). If the active data center fails, the routes
advertised by that data center are removed and replaced with routes
from the disaster recovery data center’s routes. The failover time
depends on selection of iBGP times and routing convergence associated
with iBGP.
The
following workflow shows the steps for configuring this deployment: