- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Session table sync between different devices o...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Session table sync between different devices or clusters (not running ClusterXL...)
Hello guys,
I was wondering if there is a method which can be used to sync single security gateways or clusters that haven't been configured to operate in a cluster. To say it different; I want to sync the session tables of different devices, which have obsolutely nothing in common.
The case I am thinking about is the following:
Let's say you have to migrate an old IPSO gateway, running R77.30 to a newer R80.20 appliance. The downtime - obviously - should be as limited as possible. You are thinking about setting up the new firewall and also pre-push the configuration to it. The only thing which has to be done now in order to perform the firewall change is to turn down the switch ports which lead to the old fw and enable respective ports for the new device [of course the switch config needs to get adjusted in addition]. But where does that lead us? Well in a quite unstable state.
Once you open the "floodgates" and all the traffic is passing via the new device it is also getting immediantly blocked, as no state information is saved in the "new" state table. You see lots of errors and issues in the logging pane and can't be really sure whether the missing session information is the only issue. Some applications are maybe written in such a poor way that they need hours in order to function again and realize that a new session needs to be opened.
The current way to ommit this behavior is by disabling the "drop out of state tcp packets" option in the global properties. But this is - at least in my opinion - not a clever solution, as you need to disable a security feature just in order to migrate in a "softer" way.
I know that it is possible to see, or kinda export, the session table. But is there a way to manually import it? Maybe if the possibility itself exists it would be possible to script something like a manual failover, for such a specific case?
Let me hear your thoughts!
Regards,
Maik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Use the fcu tool to sync connections between old and new cluster gateways.
More read here:
R80.30 cheat sheet - ClusterXL
ClusterXL upgrade methods and paths
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maik,
I think there is no way doing this.
But I don‘t understand your need. If your gateway is important to have only such a short downtime you should use ClusterXL and not a standalone gateway. And with ClusterXL you can do Upgrade without connection loss.
Wolfgang
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello guys,
Thanks for your replies. I was thinking about a more "unusual" upgrade process, where the old hardware is getting swapped with new appliances (or virtual instances). Let's for example say you have the following scenario:
- Your current setup is an old IPSO cluster, running R77.30 and old hardware which is not under support anymore, nor is it able to to run R80+
- You have purchased a bunch of new appliances and installed R80x in VSX mode on top of it a year ago
- Now you want to migrate from the old IPSO cluster to a VS in the already existing VSX cluster
How would you migrate in such a scenario, in the softest way possible? I am not talking about a possible management migration and rulebase movement - I mainly am searching for an answer regarding the gateways themselves. Let's just assume the management site has already been migrated or that there is no need to migrate anything here. We "just" need to swap the physical old cluster with a VS on our new VSX cluster, with the least amount of downtime and/or drops.
Regards,
Maik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pretty sure the fcu process only works for clusters, not individual gateways also.
