- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Last week we tried to upgrade a gateway cluster member to version R81.10 from R80.40 which is using OSPF to propagate OSPF routes to neighbor devices. Using the MVC method after failover the routes are not propageted to the OSPF neighbors. Is this not supported anymore since using MVC?
Would the same occur with using BGP and what if the SMS is connected over BGP we will lock ourselves out completely? In other words a policy install would be impossible?
Could someone clarify how to deal with dynamic routing OSPF and/or BGP while upgrading to version R81.10 in a cluster using MVC?
If it's ClusterXL HA (not VRRP) and if you did not enable ospf graceful-restart
then we expect both members to hold OSPF neigborship in MVC state
Hi,
OSPF and BGP are supported with MVC, routes should completely synced from R80.40 and R81.10 members.
Were there routes came back after a while on the R81.10 member?
What Jumbo take do you have on the R80.40 member and what Jumbo did you use on the R81.10 member?
How do you propagate the OSPF routes? redistribution? routemaps? other?
Yair
so if I am correct you should enable mvc on the upgraded member only?
We came from R80.40 take take 139 > R81.10 JHF81
We redistribute the interfaces on the Check Point, all local connected network into OSPF, after failing over to R81.10 we found that no routes were advertised and everything became unavailable. Should TAC have a deeper look into this?
so the issue we have seen was more related to not advertising the routes vs not having the routes, the OSPF neighbors did not have any route from Check Point
we waited 2 minutes but needed to fail back due to major impact.
Happened to me that after upgrade to R81 OSPF didnt like the automatic router id.
Had to remove ospf config, set router id explicitly and add ospf config again.
we already have router-id explicitly configured
Any known such issue with BGP and local interface redistribution? I encountered a similar case during an R81 to R81.10 MVC upgrade but not much time to troubleshoot before having to fallback.
I am also curious about that one because i have similar upgrade planned with same setup in less then 2 weeks.
There were some known issues in the past related to BGP, hard to tell if those match what you experienced.
I can tell that latest jumbo hf of R81 and R81.10 include all relevant fixes to issues we were aware of (listed as resolved in jumbo hf SKs)
Yair
Hi
Update,
We update the FW both from R80.10 to R81.10 latest JHF.
Both FW is learning the ospf routes however, only active fw is showing the ospf neighbor.
Not sure where to go from here.
I believe that is normal neigborship is via the virtual IP on Check Point when you failover that one takes it over
Hi
We are facing the same issue.
Currently, we are running MVC, we raised this issue with TAC and they have advised that MVC does not support dynamic routing such as OSPF , BGP.
We manage to fix the failover to R81.10 by issue cpstop;cpstart to perform the Failover . We have been adivse to carry on the upgrade on the other FW, bring them to same version and we should see the OSPF routes populating. I hope so.
We are doing this tonight.
I ll update you how it goes.
If it's ClusterXL HA (not VRRP) and if you did not enable ospf graceful-restart
then we expect both members to hold OSPF neigborship in MVC state
Hi
We have graceful restart on on a active fw and off on standby fw.
If I need to switch off graceful restart on ospf do I need to do out of hours and will it cause any impact while doing so.
Thanks
OSPF graceful Restart was available for VRRP only in R81 and below
in R81.10 and up - OSPF graceful Restart is supported for ClusterXL as well (same command)
if you configure OSPF graceful Restart - it must be configured on both members.
you might want to consider this R81.10 Known issue
Hi Yair,
Thanks for the update.
Both FW are now configured with ospf graceful restart on.
I only see the OSPF neighbour on Active FW and No Neighbours found on standby.
This is expected with GR
since we do not sync neighbor state with GR but only ospf routes
upon failover routes are kept on new active member, meanwhile ospf neighbor state is re established
HI ,
Yes, i did a failover with GR enabled on both FW. neighbourship established on active member.
Thanks
Ronak
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
15 | |
9 | |
6 | |
5 | |
4 | |
4 | |
3 | |
3 | |
2 | |
2 |
Wed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (CEST)
Effortless Web Application & API Security with AI-Powered WAF, an intro to CloudGuard WAFWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksWed 03 Sep 2025 @ 11:00 AM (SGT)
Deep Dive APAC: Troubleshooting 101 for Quantum Security GatewaysThu 04 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: External Risk Management for DummiesWed 10 Sep 2025 @ 11:00 AM (EDT)
Quantum Spark Management Unleashed: Hands-On TechTalk for MSPs Managing SMB NetworksAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY