VSX on 41/61K chassis, some reading materials

[varera]

Hi all,

I would like to share some info about VSX deployment on high-end chassis.

Part one:
http://checkpoint-master-architect.b...ssis-part.html

Part two:
http://checkpoint-master-architect.b...s-part_13.html

Part three:
http://checkpoint-master-architect.b...s-part_18.html

[abusharif]

Currently I've done four 61k and 41k vsx deployments, but I am not much of a blog person, so its good that you have taken the initiative and share with community :)
It will be followed with great interest!

[PhoneBoy]

I had never done a VSX + 61k deployment, good to see some real-world experience with it.

[varera]

All, thanks.

Part two link is now added above.

[varera]

Part three link is added above

[jonta]

Great articles! That really made it easier for me to understand the 61k at least.
Maybe you can add something about how SSMs are coming into all of this? I think I have a pretty good grasp on the SGMs, since they are basicly just internally clustered into a security group and acting as one big gateway. But what about the SSMs?
They are some sorts of switching module, right? Do they also cluster independently? They seem to have their own IP address.

[varera]

Great articles! That really made it easier for me to understand the 61k at least.
Maybe you can add something about how SSMs are coming into all of this? I think I have a pretty good grasp on the SGMs, since they are basicly just internally clustered into a security group and acting as one big gateway. But what about the SSMs?
They are some sorts of switching module, right? Do they also cluster independently? They seem to have their own IP address.

Generally speaking, SGMs are not "clustered". They do not exchange sync or heartbeat. They are also sharing the same kernel tables, although load balancing is done by as SSM level.

Now, SSMs are not clustered either. Best you can do is configuring LACP bonds in case you have multiple SSMs in your chassis.

Actual clustering in a classic sense of the word is done on chassis level.

As for internal IP addressing, SMMs need to monitor and maintain the whole hive, so each element has its own IP address for this purpose only.

Hope this makes it a bit more clear.

[jonta]

Thanks for a very quick reply!

However I feel that I still cannot grasp the concepts here and apply them to my previous knowledge.

In the article its explained that SGMs are clustered into a security group which has one IP address (the one on SMO) which is presented to the world, and the management server establishes SIC with this IP address.
This concept seems easy. Several blades acting as one gateway, which then runs for example virtual hosts on it.

But where do the SSMs come into this concept? They are switching modules, right? If they have their own IP addressses (one for each SSM) do that mean that the management server also establishes SIC with them? Or why would something need to connect to them on a IP level?
Is it just to be able to SSH into them and run packet dumps and such?

Another thing I do not fully grasp is how to for example reset SIC between SGM (or SMO) and the management server. Do I need to find which blade is SMO, SSH into it and run cpconfig sic ?

A third thing seem to pop up. When doing the initial setup phase, your can select which SGMs you want to include in the security group. Here I can select SGM blades from chassis 2 as well, but will that automatically make the first chassis communicate this to the blades of the second chassis?

[varera]

In the article its explained that SGMs are clustered into a security group which has one IP address (the one on SMO) which is presented to the world, and the management server establishes SIC with this IP address.
This concept seems easy. Several blades acting as one gateway, which then runs for example virtual hosts on it.

Correct. For Check Point security management server chassis looks like a single physical appliance. SMO is in charge of maintaining communications with the management server and only it.

But where do the SSMs come into this concept?

Absolutely nowhere. Security Management server does not know of their existence. SSM network ports are part of topology of single logical gateway, that's it.

They are switching modules, right? If they have their own IP addressses (one for each SSM) do that mean that the management server also establishes SIC with them? Or why would something need to connect to them on a IP level?
Is it just to be able to SSH into them and run packet dumps and such?

No, you will not be able to SSH to them directly. You only SSH to chassis / SGMs. No SIC either, as mentioned before, SSMs do not exist from security management perspective.

Chassis itself is using internal addressing for each piece of its hardware. This is internal mechanism that should not concern you at all, unless you are a chassis developer or debugger.

When you are running a packet dump, you are still using SGM OS, which is slightly modified version of Gaia. Although every blade on a chassis (other than SGMs) has its own platform, linux-based, but for all needs and purposes you may just consider it a black box.

Another thing I do not fully grasp is how to for example reset SIC between SGM (or SMO) and the management server. Do I need to find which blade is SMO, SSH into it and run cpconfig sic ?

SMO is always answering to GW management IP address. Every time you are connecting to chassis by SSH, you land on SMO, unless some other IP address used. If current SMO dies, new one is promoted. Once connected to SMO, you can then jump between the blades with CLI commands.

A third thing seem to pop up. When doing the initial setup phase, your can select which SGMs you want to include in the security group. Here I can select SGM blades from chassis 2 as well, but will that automatically make the first chassis communicate this to the blades of the second chassis?

If you follow the install guide, this question is mute. You might but you do not want to. Technically, first SGM on the first chassis is always SMO. If you change that, you will get into trouble.

[jonta]

Thanks for some great replies! How the 61k works is getting clearer all the time.

I have one more thing that interests me. When the administrator logs into the first blade in the first chassis and creates a security group with members: chassis 1: 1,2 chassis 2: 1,2
How exactly does the blade1 from chassis1 communicate to the other blades, that are separate machines, to reboot and install themselves into the security group? Is this done over some internal interface?
The reason I ask is because I have some trouble where another blade does not reboot and install after I have, in the installation of blade 1, said that it should be member of the security group.
So I wanted to know if I could verify that this communication channel is working.

[varera]

Thanks for some great replies! How the 61k works is getting clearer all the time.

I have one more thing that interests me. When the administrator logs into the first blade in the first chassis and creates a security group with members: chassis 1: 1,2 chassis 2: 1,2

Firstly, it is not how it is done, in case of VSX. You make a security group with SMO blade only, define VSX object, establish SIC and only then add other blades to the same group.[/QUOTE]

How exactly does the blade1 from chassis1 communicate to the other blades, that are separate machines, to reboot and install themselves into the security group? Is this done over some internal interface?

Yes, it is done through internal communication network. Each blade has internal IP address, as said above already. When you add a new blade to the security group, it pools all config files from SMO and reboots when done, to join the group after boot

The reason I ask is because I have some trouble where another blade does not reboot and install after I have, in the installation of blade 1, said that it should be member of the security group.
So I wanted to know if I could verify that this communication channel is working.

Remove the group from security group, shut it down, power on again and add to the group. If this does not work, open a support call. generally speaking, if it is done by the book, 99% chances are it will join the group without a problem.

[jonta]

Thanks again vareva!

Since this thread is about VSX on 61k I might try to ask another question here.
Have any of you ever had issues with making a blade into VSX?
Here is the log from my attempt

Installing default Policy - chkp_61k_sg2_vsx_VSX on chkp_61k_sg2_vsx...
Successfully installed default policy chkp_61k_sg2_vsx_VSX on chkp_61k_sg2_vsx
Generating VSX Configuration for chkp_61k_sg2_vsx.
Pushing VSX Configuration to chkp_61k_sg2_vsx.
chkp_61k_sg2_vsx...: VSX configuration was applied successfully.
VSX Processing Completed Successfully
Creating Virtual Switch...
Initializing SIC of - chkp_61k_sg2_vsx_VSW ...
SIC of chkp_61k_sg2_vsx_VSW has been initialized
Generating VSX Configuration for chkp_61k_sg2_vsx_VSW on chkp_61k_sg2_vsx.
Pushing VSX Configuration to chkp_61k_sg2_vsx.
Failed to configure chkp_61k_sg2_vsx with the following errors:
chkp_61k_sg2_vsx... error :VSX internal error 
Virtual Switch Processing Completed with Errors
Pushing network configuration to chkp_61k_sg2_vsx operation has finished with errors.
Refer to the messages retrieved during the VSX push configuration stage
and make sure that the configuration you are trying to push is legal.
If the problem persists contact Check Point Technical Support.
Operation has failed.

The problem seem to be about the virtual switch. When checking with "vsx stat -l" after I can see a vsid: 0 but no virtual switch on vsid: 1
I can only assume it has to do with the SSM in some way, but not clear how.
If nobody have had this issue, maybe someone know from which logs I can find more information?

Thanks!

[varera]

Thanks again vareva!

Since this thread is about VSX on 61k I might try to ask another question here.
Have any of you ever had issues with making a blade into VSX?
Here is the log from my attempt

Installing default Policy - chkp_61k_sg2_vsx_VSX on chkp_61k_sg2_vsx...
Successfully installed default policy chkp_61k_sg2_vsx_VSX on chkp_61k_sg2_vsx
Generating VSX Configuration for chkp_61k_sg2_vsx.
Pushing VSX Configuration to chkp_61k_sg2_vsx.
chkp_61k_sg2_vsx...: VSX configuration was applied successfully.
VSX Processing Completed Successfully
Creating Virtual Switch...
Initializing SIC of - chkp_61k_sg2_vsx_VSW ...
SIC of chkp_61k_sg2_vsx_VSW has been initialized
Generating VSX Configuration for chkp_61k_sg2_vsx_VSW on chkp_61k_sg2_vsx.
Pushing VSX Configuration to chkp_61k_sg2_vsx.
Failed to configure chkp_61k_sg2_vsx with the following errors:
chkp_61k_sg2_vsx... error :VSX internal error 
Virtual Switch Processing Completed with Errors
Pushing network configuration to chkp_61k_sg2_vsx operation has finished with errors.
Refer to the messages retrieved during the VSX push configuration stage
and make sure that the configuration you are trying to push is legal.
If the problem persists contact Check Point Technical Support.
Operation has failed.

The problem seem to be about the virtual switch. When checking with "vsx stat -l" after I can see a vsid: 0 but no virtual switch on vsid: 1
I can only assume it has to do with the SSM in some way, but not clear how.
If nobody have had this issue, maybe someone know from which logs I can find more information?

Thanks!

It seems your VSX SMO cannot create a virtual switch. At this point, please contact support. Some extensive debug is required here, and this forum is not appropriate to provide you enough assistance.

Thanks
VL

[abusharif]

You are running version that supports virtual switches? IIRC R76SP.10 or later
How is your licensing? VSW won't consume a VS license, but maybe it causes issue with creation additional VS* besides vs0.
check with "g_cplic print" from expert mode and look for CPSG-VSX-XX part of the license