- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: R80.x - Performance Tuning Tip - Management Da...
- 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
R80.x - Performance Tuning Tip - Management Data Plane Separation
Management Data Plane Separation allows a security gateway to have isolated management and data networks. The network system of each domain (plane) is independent and includes interfaces, routes, sockets, and processes. This has the performance advantage that some processes run separately from the firewall core daemon. Thus it reduces the load on the firewall processes, e.g. during the policy installation.
The management plane is a domain whose purpose is to access, provision, and monitor the gateway. This includes:
- Routing separation
- Resource Separation
- Access: SSH, FTP, and more
- Provisioning: Policy installation, GAIA Portal, RestAPI's, and more
- Monitoring: Logs, SNMP, and more
When resource separation is enabled, the security gateway will separat the management instance. Here is an example:
Mgmt |
SND |
SND |
CoreXL |
CoreXL |
CoreXL |
CoreXL |
CoreXL |
This feature can be enabled with the following minimum requirements:
- R80.30 kernel 3.10 and JHF 136 or higher
- R80.20SP JHF 194 or higher
- To enable this option, at least 4 cores and 3 CoreXL FW instances are required.
TIP 1
To configure Management Data Plane Separation or if you need more information take a look at this SK138672.
TIP 2
This can also help if a gateway or a ClusterXL member goes into CUL freeze mode (SK92723) during policy installation through high CPU load on cluster member or single gateway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this also possible with R80.10 or R80.20 and the latest JHF?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3.10 kernel is required for that functionality, so no
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We use this with R80.30 and kernel 3.10.
Since we have been using it we have no problems with high CPU usage when installing policies.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does this not reduce a core license?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One has to die one death
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In sk138672, we can found this :
Setting the 'sync' interface. When you use Routing Separation and ClusterXL, you must set the Sync interface on the Management Plane. The interface is used for ClusterXL synchronization between members.
and this :
The use of logical interfaces is not supported on management interface (Alias, Bridge, VPN Tunnel, 6in4 Tunnel, PPPoE, Bond, VLAN)
So, if I understand correctly,
- It's mandatory to put the sync interface in the management plane
- Management plane doesn't support bonding
So if my sync interface is a bond, I can't use management place, correct ?
- Tags:
- performance
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You need MGMT plane separation when your machine is extremely busy with FW operations. we are talking 90+% average CPU utilization. That is the only use case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the answer but if I understand correctly, this feature also allow "routing" and "ressources" separation, right ?
So I can put the management interface into a separate "VRF" and if I shoot myself in the foot with the routing, the management server will still be able to reach the gateways through the management interface.
Do I understand this correctly?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, that interpretation is not correct. Routing here means traffic filtering and forwarding. As kernel related CPU tasks usually have highest priority, MGMT plane allows taking one CPU for processes only hence allowing logging, admin processes and WebUI access unaffected, if FW tasks are taking too much CPU time
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry but I'm extremly confused now 😅
In sk138672, we can read this :
(a) Routing Separation
Routing Separation creates a routing domain (ID 1) that includes an interface that the Gateway uses to communicate with Management, and an interface used for the synchronization of cluster members (when using ClusterXL). This domain has its own routing table, in which routing decisions are made. It is not connected with the Data Plane via any virtual adapter. This means that any packet that is inbound to the Gateway, whether on the Management or on the Data Plane, cannot cross over to the other plane.
So if I'm reading this correctly, it's like a VRF, no ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, my bad, I misread your original comment.
Yes, there is a different routing domain for management only communications. I think VRF terms are no longer applicable on 3.10, but I cannot recall the new name other than routing domain, sorry 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay 🙂
So for my original question, if my sync interface is a bonding, I can't use the "routing separation", correct ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bonding is not supported with MGMT plane, you answered this yourself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I wanted to be sure 😞
I think it's a very big limitation and it's going to prevent the deployment of this feature where it's the most needed 😞 If Checkpoint could remove this limitation, it would be great !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are there plans for bonding to be supported in the future?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The support limitations are coming from RH side. It is not possible with 3.10 kernel to get bonding working on MGMT plane. Also, it kinda productive, as MGMT interface should not carry any production traffic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But it's a requirement to put the sync interface in the MGMT plane and bonding on the sync interace is a must for high availability. I realy hope checkpoint will remove this limitation one day
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I see your point.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue that we are having with this new feature is the way CP implemented it when it comes to SNMP. Switching the gateways to mplane was great for routing, but it had a side effect and broke a lot of out monitoring tools. Without going into too many details, in order to get all the monitoring data needed such as interfaces, cpu. memory, you have to use the context argument "-n dplane" for SNMPv3. Not all the tools support this. We expect when we connect to a device via SNMP we should get all the data; basically everything we need to monitor. I am not sure how all other Network Vendors are implementing their dedicated Mgmt interfaces, but I guess I really don't care, as long as it acts seemless to the user and all of our tools. It feels like CP did not put a lot of thought into the way this feature was implemented.