- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Cluster member A with physical IP 192.168.1.1/24
Cluster member B with physical IP 192.168.1.2/24
Member A with the following for export
set routemap default id 100 on
set routemap default id 100 allow
set routemap default id 100 match network 0.0.0.0/0 exact
set routemap default id 100 match protocol static
set routemap default id 100 action nexthop ip 192.168.1.1
Member B with the following for export
set routemap default id 100 on
set routemap default id 100 allow
set routemap default id 100 match network 0.0.0.0/0 exact
set routemap default id 100 match protocol static
set routemap default id 100 action nexthop ip 192.168.1.2
When Cluster fails over, a blackhold will occur, right ?
Reason:
Before failover, member B does not have BGP peering, just synced with Member A for all the routes which points 192.168.1.1 as next-hop. When failover occurs and before member B establishes BGP relationship and advertises new next-hop (192.168.1.2), a blackhold occurs.
Am I right ??
When setting up dynamic routing on a CP cluster, all peers must use the cluster interface VIP to peer with and route to. Routing/peering to individual gateway IPs is not supported. Hence the configuration on each cluster member must be identical.
Tip: configure the router-id to a cluster VIP before configuring BGP, again identical across the cluster.
When setting up dynamic routing on a CP cluster, all peers must use the cluster interface VIP to peer with and route to. Routing/peering to individual gateway IPs is not supported. Hence the configuration on each cluster member must be identical.
Tip: configure the router-id to a cluster VIP before configuring BGP, again identical across the cluster.
thanks so much for clarification !!
Yes, without BGP Graceful Restart and/or BFD features enabled, once failover occurs, there is short outage for BGP during re-establishment of peering from new member. It is described within sk175923.
Best practise is to enable BGP Graceful Restart (sk100499) and/or Bidirectional Forwarding Detection (BFD) with cBIT detection (sk175923) to mitigate this problem.
I think it will be blackheld even with Graceful Restart enabled.
Graceful Restart only helps when next-hop points to the VIP. This is the way we are doing.
But if standby node uses its own physical IP, a blackhold will occur during the failover.
Right ?
BGP should be configured to use VIP in cluster. You should also use the same VIP as router-id. Config for BGP within all cluster members should be the same.
I also dont get what is the goal here. You want to propagate only default IPv4 static route ? What is config for BGP peers (show configuration bgp) ?
You should use preference statement within routemaps to specify where to use routemap with "default" name.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 14 | |
| 10 | |
| 9 | |
| 7 | |
| 6 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY