Tuning BGP Convergence in High-Availability Firewall Cluster Design
Two weeks ago Nicola Modena explained how to design BGP routing to implement resilient high-availability network services architecture. The next step to tackle was obvious: how do you fine-tune convergence times, and how does BGP convergence compare to the more traditional FHRP-based design.
Latest blog posts in BGP in Data Center Fabrics series
- BGP Unnumbered Duct Tape
- Modern IBGP Design with AddPath and ORR
- Mixed Feelings about BGP Route Reflector Cluster ID
- BGP Route Reflector Myths
- Three Dimensions of BGP Address Family Nerd Knobs
- Feedback: Recursive BGP Next Hop Resolution
- Highlights: Dynamic Negotiation of BGP Capabilities
- Building a BGP Anycast Lab
- Optimal BGP Path Selection with BGP Additional Paths
- Dynamic Negotiation of BGP Capabilities
Recent posts in the same categories
design
- EVPN Designs: EBGP Everywhere
- One-Arm Hub-and-Spoke VPN with MPLS/VPN
- EVPN Hub-and-Spoke Layer-3 VPN
- Hub-and-Spoke VPN on a Single PE-Router
- Hub-and-Spoke VPN Topology
- EVPN Designs: Scaling IBGP with Route Reflectors
firewall
- Stateful Firewall Cluster High Availability Theater
- IPv6 Security in Layer-2 Firewalls
- Worth Reading: Off-Path Firewall with Traffic Engineering
- Configuring NSX-T Firewall with a CI/CD Pipeline
- Automating NSX-T Firewall Configuration
- Considerations for Host-based Firewalls (Part 2)
The strategy I provide are the same as in the Petr article referring to BGP PIC: preparing a secondary path and minimizing the fault propagation delay. There are also other possibilities that fall into the "pe-ce link protection" category for the backbone side, that typically represents the most difficult element to optimize (this is very specific but can be the subject of a future post). However, the purpose of the article is broader because too often the only solution adopted for HA's firewall is Active/Standby with FHRP.
And yes, the solution is tested and sucessfully adopted with different vendor combinations.