Support Center > Search Results > SecureKnowledge Details
Management Data Plane Separation Technical Level


Table of contents:

  1. Introduction
  2. Minimum Requirements
  3. How it works
    1. Routing Separation
    2. Resource Separation
  4. Configuration
  5. Best Practice
  6. Limitations

Important: This feature is new in R80.30. If you need it for R80.20, please submit a Request for Enhancement.

(1) Introduction

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. The Management Plane is a domain whose purpose is to access, provision, and monitor the Gateway. This includes:

  • Access: SSH, FTP, and more
  • Provisioning: Policy installation, GAiA Portal, RestAPI's, and more
  • Monitoring: Logs, SNMP, and more

Any Service, Process or Port used by the above is considered a part of the Management Plane. Everything else is considered a part of the Data Plane.

(2) Minimum Requirements

This feature must be enabled with the following:
For R80.30 kernel 3.10, Jumbo Hotfix Take 136 or higher must be installed.
For R80.20SP, Jumbo Hotfix Take 194 or higher must be installed.

Important: Management Data Plane Separation is not support on Maestro systems

(3) How it works

The solution is implemented via software and can be used on a physical or virtual appliance. It includes the following capabilities that can be used independently:

  • Routing Separation
  • Resource Separation

(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. All non-Management related operations should not use the Management Plane network, for example: DNS, Proxy, DHCP, and Software blade portals.

In order to switch the context to either Management Plane or Data Plane in bash, use the following commands:

  • 'dplane' will switch the network context to the data plane (id 0).
  • 'mplane' will switch the network context to the Management Plane (id 1)

For more information about the relevant Check Point processes and ports, refer to sk97638 and sk52421.

(b) Resource Separation

With Resource Separation, a dedicated CPU will be allocated for joint use by the Management NIC and a CoreXL FW-Instance (2 if Hyper-Threading is enabled). The CoreXL FW-Instance will not receive any traffic by SND except for packets that are inbound or outbound to the Management NIC. Usually, the number of connections is small, which practically ensures that regardless of how busy the other CoreXL FW-instances and NICs are, the Gateway will remain accessible via the Management NIC.

Consider a Security Gateway with 8 cores and a 2-6 split. (SND-CoreXL)

When Resource Separation is enabled, the Security Gateway will look like this:

For more information about CoreXL, refer to sk98737.


  • To enable this option, at least 4 Cores and 3 CoreXL FW-Instances are required.
  • When using Routing and Resource separation, the affinity for the Management Plane processes is not automatically set to a dedicated CPU.
  • As the feature uses a dedicated CPU, there are fewer CPU core(s) for Data Plane inspection.

(4) Configuration

All configurations are done on 'clish', however, if you're on Scalable Platforms all configurations must be done via Gclish.

Important: Management Data Plane Separation is not support on Maestro systems

Commands are 'set/add/delete/show mdps …'

  • Enable/disable routing separation:

    clish> set mdps mgmt plane <on|off>


    • It is recommended that the enable/disable routing separation be done during a Maintenance window. The procedure needs to be done via a serial port, as connectivity through the Management interface will be lost. A reboot is required to complete the operation.
    • In Scalable platforms, please follow the following steps after enabling/disabling MDPS.
      • Reboot Standby Chassis
      • Fail-over to Standby Chassis
      • Reboot Standby Chassis.
  • Changing clish context: To view or edit clish options in a similar way to bash mplane or dplane commands.
clish> set mdps environment <mplane|dplane>
  • Enable/disable resource separation:

    clish> set mdps mgmt resource <on|off>


    • It is recommended that enable/disable resource separation be done during a Maintenance window. The procedure needs to be done via a serial port, as connectivity through the Management interface will be lost for a short time. A reboot is required to complete the operation.
    • First, you need to configure the network interface, then enable the MDPS.
  • Controlling amount of CPU's for Resource separation:
         clish> set mdps resource cpu 1..4
  • Setting the 'Management' interface. When you use either the Routing or the Resource Separation, you must define the Management interface. The interface will be used for communication with the Management Server and to access the Gateway.

    clish> set mdps interface <NAME> management <on|off>

  • 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.

    clish> set mdps interface <NAME> sync <on|off>

    • Setting sync interface is not supported on Scalable Platforms.
  • Adding or deleting routes on the Management Plane

clish> add/delete mdps route <ADDRESS> nexthop <ADDRESS>

    • This option is no longer available starting R81. Switch to relevant 'clish' context and use routing commands in order to set, modify or display.
  • Adding or deleting tasks from the Management Plane.
With this option, It is possible to choose where to place tasks that the Gateway is running, either on the Management Plane or on the Data Plane context. "Task" can be from the following:
    • Port, Protocol: A specific port and protocol from any process will be bound to the Management Plane; The process itself will remain in the Data Plane context. This option works only for Check Point known ports.
    • Process: A specific process name will be bound to the Management Plane, Including all ports that the process opens.
    • Service: OS service may include several processes, All of which will be bound to the Management Plane.

When enabling Routing separation, A set of default tasks will bound to Management plane, All others will remain on Data plane. A task cannot be bound to both planes.

clish> add/delete mdps task <OPTIONS>


    • Added/Deleted tasks applied upon the following restart of the task.

(5) Best Practices

When using Routing Separation

  • Do not include Management Plane subnets on any Software blade portal.
  • Connectivity to the LDAP and similar servers from the Gateway should be done via the Data Plane.
  • All commands in expert mode or clish should be executed in the context of the Data Plane (ID 0) except commands which are network dependent, such as 'ip ...', 'ifconfig', 'netstat', etc.
  • SNMP queries:
    • When using v2/v2c: In order to query Gateway Data plane OID's, Add to the community name suffix _dplane. For example, if the community name is "test," then the data plane community name is "test_dplane".
    • When using v3: In order to query Gateway Data plane OID's, Context argument should be added, the context name is "dplane".
  • When using a local license, the IP address should be the same as the Management interface IP address.

When using Management Resource

  • Do not set CPU affinity (manually or via the 'sim affinity') for the Management interface.

(6) Known Limitations

Issue ID Description
PMTR-25365 IPv6 is not supported on the Management interface when using Resource Separation.
PMTR-25369 Configuration of Routing or Resource Separation can be done only via clish.
PMTR-29698 The use of logical interfaces is not supported on management interface (Alias, Bridge, VPN Tunnel, 6in4 Tunnel, PPPoE, Bond, VLAN)
When using ClusterXL and Routing separation, Same subnet for Management and data interface is not supported.
On SmartDashboard, "Get interface with topology" fetches data plane interfaces topology only.
When using Routing separation, Backup/Snapshot to remote host on Management plane only
On Scalable Platforms:
  • Sync & Chassis Internal Network (CIN) interfaces are not considered part of the Management Plane.
  • All SGMs in the Security Group must be up and ACTIVE when enabling/disabling MDPS.
  • Configuration of Routing Separation can be done only via gclish.
  • Only Management interfaces and magg can be used as a Management interface in MDPS.
  • When configuring syslog, syslog server must be in the Management interface's subnet.
  • Fetch topology in SmartConsole is not supported, therefore, any topology modifications must be done manually in SGW and SmartConsole.
This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Give us Feedback
Please rate this document