After being exposed to a couple of VSX deployments with 41000 chassis, I have to share with you some important points.
Deployment of 61000 or 41000 based firewalls is quite different from the regular Gaia appliances. The CPU blades called SGMs (Security Gateway Module) are acting as a single gateway. They load-share the traffic, they have a single GW configuration, including topology, IP addresses and even SIC. To achieve that, you need that, you need to define so-called Security Group and populate it with SGM blades. The first SGM added to the group becomes SMO - Single Management Object. It will perform SIC communications with Management and will maintain later on control connections on behalf of the Security Group. If it fails, another SGM takes over the function of SMO, maintaining logical GW functionality intact. It will take me just a moment to explain, why mentioning SMO is so important while talking about.
If you are deploying 61/41K as a regular GW without virtualization, there are virtually no pitfalls. That is not exactly the case with VSX.
The main VSX object provisioning can only be properly done if you have just a single SGM in the Security Group. Although this requirement is mentioned in the Administration guide, you can easily miss it. It is also not clear at the first sight, why this is so important.
If you ever deployed VSX on a regular appliance or or an open server with R75 and up, the process is quite complex. MGMT server pushes a provisioning scripts to the GW just after establishing SIC, forcing GW machine to reboot and come up as VSX GW.
The situation with 61/41K is not different, except that on those chassis it is a group of SGMs. Each SGM is in fact a Gaia machine.
So imagine we have a couple of SGMs in the security group before starting VSX provisioning. It is only SMO talking to your management server and then rebooting after establishing SIC. The second SGM blade will not do so, but will assume a role of SMO, considering the first blade in fault. The last known configuration pulled from the original SMO does not have any mentioning of VSX. On this point the provisioning will fail.
There are also some other potential issues with VSX provisioning. I will address them in a separate post.
-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets
Deployment of 61000 or 41000 based firewalls is quite different from the regular Gaia appliances. The CPU blades called SGMs (Security Gateway Module) are acting as a single gateway. They load-share the traffic, they have a single GW configuration, including topology, IP addresses and even SIC. To achieve that, you need that, you need to define so-called Security Group and populate it with SGM blades. The first SGM added to the group becomes SMO - Single Management Object. It will perform SIC communications with Management and will maintain later on control connections on behalf of the Security Group. If it fails, another SGM takes over the function of SMO, maintaining logical GW functionality intact. It will take me just a moment to explain, why mentioning SMO is so important while talking about.
If you are deploying 61/41K as a regular GW without virtualization, there are virtually no pitfalls. That is not exactly the case with VSX.
The main VSX object provisioning can only be properly done if you have just a single SGM in the Security Group. Although this requirement is mentioned in the Administration guide, you can easily miss it. It is also not clear at the first sight, why this is so important.
If you ever deployed VSX on a regular appliance or or an open server with R75 and up, the process is quite complex. MGMT server pushes a provisioning scripts to the GW just after establishing SIC, forcing GW machine to reboot and come up as VSX GW.
The situation with 61/41K is not different, except that on those chassis it is a group of SGMs. Each SGM is in fact a Gaia machine.
So imagine we have a couple of SGMs in the security group before starting VSX provisioning. It is only SMO talking to your management server and then rebooting after establishing SIC. The second SGM blade will not do so, but will assume a role of SMO, considering the first blade in fault. The last known configuration pulled from the original SMO does not have any mentioning of VSX. On this point the provisioning will fail.
There are also some other potential issues with VSX provisioning. I will address them in a separate post.
-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets
No comments:
Post a Comment