This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Create a Post
Help
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Are you a member of CheckMates?

×
Sign in with your Check Point UserCenter/PartnerMap account to access more great content and get a chance to win some Apple AirPods! If you don't have an account, create one now for free!
RKinsp
Contributor
‎2021-04-23 09:49 AM
Jump to solution

Management API adding multiple cluster interfaces different subnets issue

Hey everyone,

We are prepping for a large edit involving around 350 VLAN interfaces on a cluster on R81. These interfaces are using different subnets then the cluster address that will be used.

 

The interfaces have already been discovered and added, but not the cluster addresses. We are are facing an issue with the management api where if we edit more then one interface, when publishing we get the error "The interfaces of all the members in this network must be under the same subnet".

If we publish one interface change at a time it works...

Any ideas on how to A) push this change regardles of the error? or B) Create a script that publishes after every change?

 

Below is the example test in lab, you can see that the exact same commands will not work if you try to publish two changes, but if you publish in between them it works fine...

Thanks in advance,

RK

 

EXAMPLE - Multiple edits, one publish not working:

 

[Expert@SMS:0]# mgmt_cli set simple-cluster name ClusterXL-Lab interfaces.update.name eth2.2009 interfaces.update.ip-address 192.168.224.38 interfaces.update.ipv4-mask-length 30 interfaces.update.interface-type cluster interfaces.update.topology INTERNAL interfaces.update.anti-spoofing False interfaces.update.topology-settings.ip-address-behind-this-interface SPECIFIC interfaces.update.topology-settings.specific-network VLAN-2009-group -s id.txt


---------------------------------------------
Time: [12:28:11] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)

---------------------------------------------
Time: [12:28:41] 23/4/2021
---------------------------------------------
"set simple-cluster" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-a6df-896461f5c74e"
task-name: "set simple-cluster"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- message: "Successfully finished"

[Expert@SMS:0]# mgmt_cli set simple-cluster name ClusterXL-Lab interfaces.update.name eth2.2010 interfaces.update.ip-address 192.168.224.42 interfaces.update.ipv4-mask-length 30 interfaces.update.interface-type cluster interfaces.update.topology INTERNAL interfaces.update.anti-spoofing False interfaces.update.topology-settings.ip-address-behind-this-interface SPECIFIC interfaces.update.topology-settings.specific-network VLAN-2010-group -s id.txt


---------------------------------------------
Time: [12:29:47] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)


---------------------------------------------
Time: [12:30:27] 23/4/2021
---------------------------------------------
"set simple-cluster" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-9336-357fb2189bca"
task-name: "set simple-cluster"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- message: "Successfully finished"

[Expert@SMS:0]# mgmt_cli publish -s id.txt


---------------------------------------------
Time: [12:31:44] 23/4/2021
---------------------------------------------
"Publish operation" in progress (10%)


---------------------------------------------
Time: [12:31:54] 23/4/2021
---------------------------------------------
"Publish operation" failed (100%)
tasks:
- task-id: "01234567-89ab-cdef-9cc7-b22834c9b3c1"
task-name: "Publish operation"
status: "failed"
progress-percentage: 100
suppressed: false
task-details:
- fault-message: "The interfaces of all the members in this network must be under the same subnet"

 

 

EXAMPLE - One at a time - works:

 

[Expert@SMS:0]# mgmt_cli set simple-cluster name ClusterXL-Lab interfaces.update.name eth2.2009 interfaces.update.ip-address 192.168.224.38 interfaces.update.ipv4-mask-length 30 interfaces.update.interface-type cluster interfaces.update.topology INTERNAL interfaces.update.anti-spoofing False interfaces.update.topology-settings.ip-address-behind-this-interface SPECIFIC interfaces.update.topology-settings.specific-network VLAN-2009-group -s id.txt


---------------------------------------------
Time: [12:32:49] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)


---------------------------------------------
Time: [12:32:59] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)


---------------------------------------------
Time: [12:33:09] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)


---------------------------------------------
Time: [12:33:19] 23/4/2021
---------------------------------------------
"set simple-cluster" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-9080-c941abe633c1"
task-name: "set simple-cluster"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- message: "Successfully finished"

[Expert@SMS:0]# mgmt_cli publish -s id.txt


---------------------------------------------
Time: [12:34:03] 23/4/2021
---------------------------------------------
"Publish operation" in progress (10%)


---------------------------------------------
Time: [12:34:13] 23/4/2021
---------------------------------------------
"Publish operation" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-9c4a-324faa169269"
task-name: "Publish operation"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- publishResponse:
numberOfPublishedChanges: 4
mode: "async"
revision: "de41ea20-2755-4659-99c3-618eca664f46"

[Expert@SMS:0]# mgmt_cli set simple-cluster name ClusterXL-Lab interfaces.update.name eth2.2010 interfaces.update.ip-address 192.168.224.42 interfaces.update.ipv4-mask-length 30 interfaces.update.interface-type cluster interfaces.update.topology INTERNAL interfaces.update.anti-spoofing False interfaces.update.topology-settings.ip-address-behind-this-interface SPECIFIC interfaces.update.topology-settings.specific-network VLAN-2010-group -s id.txt


---------------------------------------------
Time: [12:34:28] 23/4/2021
---------------------------------------------
"set simple-cluster" in progress (0%)

 


---------------------------------------------
Time: [12:35:08] 23/4/2021
---------------------------------------------
"set simple-cluster" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-9eb5-91432a7fe863"
task-name: "set simple-cluster"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- message: "Successfully finished"

[Expert@SMS:0]# mgmt_cli publish -s id.txt


---------------------------------------------
Time: [12:35:15] 23/4/2021
---------------------------------------------
"Publish operation" in progress (10%)


---------------------------------------------
Time: [12:35:25] 23/4/2021
---------------------------------------------
"Publish operation" succeeded (100%)
tasks:
- task-id: "01234567-89ab-cdef-83d6-dcfe4270d043"
task-name: "Publish operation"
status: "succeeded"
progress-percentage: 100
suppressed: false
task-details:
- publishResponse:
numberOfPublishedChanges: 4
mode: "async"
revision: "9d421d71-21f4-40ee-81c6-4527786ae93e"

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin
‎2021-04-23 02:47 PM
Jump to solution

Sounds like it might be a bug in the validation logic.
Paging @Omer_Kleinstern.

I suppose you could also just make each mgmt_cli call with -r true, which actually does a login as root before each command and a publish/logout after.
Generally not the most efficient approach but in this case, it might be a necessary workaround.

View solution in original post

5 Replies
PhoneBoy
Admin
Admin
‎2021-04-23 02:47 PM
Jump to solution

Sounds like it might be a bug in the validation logic.
Paging @Omer_Kleinstern.

I suppose you could also just make each mgmt_cli call with -r true, which actually does a login as root before each command and a publish/logout after.
Generally not the most efficient approach but in this case, it might be a necessary workaround.

RKinsp
Contributor
‎2021-04-25 10:28 AM
In response to PhoneBoy
Jump to solution

Thanks PhoneBoy! I thought -r was only for login.

In the lab I ended using the script reference below to have it wait out the commands...

https://community.checkpoint.com/t5/API-CLI-Discussion/Using-a-synchronous-commands-e-g-publish-inst...

 

On a side note, I also tried using --batch and that totally messed up all the ClusterXl Interfaces...

 

 

 

0 Kudos
PhoneBoy
Admin
Admin
‎2021-04-25 10:44 AM
In response to RKinsp
Jump to solution

You can use -r true for single commands (in addition to creating a session for reuse).
I did get some confirmation from R&D this is a known bug (PMTR-68323) which currently doesn’t have a fix.
Current plan is to fix in R81.20 and backport to the various JHF.

RKinsp
Contributor
‎2021-04-29 05:54 PM
In response to PhoneBoy
Jump to solution

So, I've used the -r option and a script to add 350+ cluster interfaces. Took upwards of 5 hours, after already having discovered and published the interfaces without a cluster IP.

Any ideas on how I could speed the process up? Have another cluster to configure tonight....

0 Kudos
PhoneBoy
Admin
Admin
‎2021-04-29 06:39 PM
In response to RKinsp
Jump to solution

You could recover some time by publishing after each change instead of using -r true for each change (i.e. reusing the same session instead of creating a new one).
That's probably it, at least while this bug still exists.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

View All ≫
Upcoming Events

    CheckMates Events