ClusterXL - adding interface via CLI not working

[RKinsp]

Good morning everyone!

I am trying to add a vlan interface to a Cluster via API / CLI on R81 (open server). The interfaces were configured on the individual gateways via CLI and they are up, but when I try the below command for creating the interface at the cluster level, it gives me the folowwing error: CLINFR0711 Command insecure

I think I might be missing somthing on the command itself but the error does not give me much to go on. What I am doing is SSHing into the SMS and trying the CLI from there:

mgmt login user admin

mgmt set simple-cluster name "ClusterXL" interfaces.add.name "eth1.100" interfaces.add.ip-address "10.1.1.100" interfaces.add.ipv4-mask-length "30" interfaces.add.interface-type "cluster" interfaces.add.topology "INTERNAL" interfaces.add.anti-spoofing "false" interface.add.topology-settings.ip-address-behind-this-interface "SPECIFIC" interface.add.topology-settings.specific-network " ClusterXL-Subnet-1" members.update.1.name "ClusterXL-1" members.update.1.interfaces.name "eth1.100" members.update.1.interfaces.ipv4-address "172.32.0.1" members.update.1.interfaces.ipv4-network-mask "255.255.255.252" members.update.2.name "ClusterXL-2" members.update.2.interfaces.name "eth1.100" members.update.2.interfaces.ipv4-address "172.32.0.2" members.update.2.interfaces.ipv4-network-mask "255.255.255.252" --format json

Reference:

https://sc1.checkpoint.com/documents/latest/APIs/index.html?#clish/set-simple-cluster~v1.7%20

Any thoughts

Output from show-api-versions

mgmt show-api-versions
current-version: "1.7"
supported-versions:
- "1"
- "1.1"
- "1.6.1"
- "1.2"
- "1.3"
- "1.4"
- "1.5"
- "1.6"
- "1.7"

Thanks!

RK

[Timothy_Hall]

Perhaps this is just an artifact of copy/pasting into your post, but you have a leading space for an object name here, which is not allowed:

" ClusterXL-Subnet-1" 

[RKinsp]

I think that was just a posting issue. I tried copying the exact example on the API page and only changing the object names and still no go. "Command Insecure".

I wonder if naming my cluster ClusterXL might be the issue...

mgmt set simple-cluster name "ClusterXL" interfaces.add.name "eth3" interfaces.add.ip-address "10.10.10.1" interfaces.add.ipv4-mask-length "24" interfaces.add.interface-type "cluster" interfaces.add.topology "INTERNAL" interfaces.add.anti-spoofing "true" members.update.1.name "ClusterXL-1" members.update.1.interfaces.name "eth3" members.update.1.interfaces.ipv4-address "10.10.10.2" members.update.1.interfaces.ipv4-network-mask "255.255.255.0" members.update.2.name "ClusterXL-2" members.update.2.interfaces.name "eth3" members.update.2.interfaces.ipv4-address "10.10.10.3" members.update.2.interfaces.ipv4-network-mask "255.255.255.0" --format json

[Timothy_Hall]

Very possible that "ClusterXL" is a reserved word when it comes to object naming.

[RKinsp]

Ok, so I figured it out. It seems there is a command length limit when using SSH into the system. When using partial commands it works, but whenever I go beyond a certain count it gives me the insecure error.

Confirmed by typing in the same command into SmartConsole CLI and it works fine.

Any ideas on turning off this lenght limit?

Example below works in Gaia CLI:

mgmt set simple-cluster name "ClusterXL" interfaces.add.name "eth4.100" interfaces.add.ip-address "10.1.1.100" interfaces.add.ipv4-mask-length "24" interfaces.add.interface-type "cluster" interfaces.add.topology "INTERNAL" interfaces.add.anti-spoofing "false" interfaces.add.topology-settings.ip-address-behind-this-interface "SPECIFIC" interfaces.add.topology-settings.specific-network "VLAN-100-Interface"

Example below works in SmartConsole CLI

set simple-cluster name "ClusterXL" interfaces.add.name "eth4.100" interfaces.add.ip-address "10.1.1.100" interfaces.add.ipv4-mask-length "24" interfaces.add.interface-type "cluster" interfaces.add.topology "INTERNAL" interfaces.add.anti-spoofing "false" interfaces.add.topology-settings.ip-address-behind-this-interface "SPECIFIC" interfaces.add.topology-settings.specific-network "VLAN-100-Interface" members.update.1.name "ClusterXL-1" members.update.1.interfaces.name "eth4.100" members.update.1.interfaces.ipv4-address "172.32.0.1" members.update.1.interfaces.ipv4-mask-length "30" members.update.2.name "ClusterXL-2" members.update.2.interfaces.name "eth4.100" members.update.2.interfaces.ip-address "172.32.0.2" members.update.2.interfaces.ipv4-mask-length "30" --format json

[PhoneBoy · Accepted solution]

Use expert mode?

[RKinsp]

Thanks Phoneboy.

Expert mode works, but still did not find a way to do it straight in Gaia. It is just an extra step we were trying to avoid, but it solves to problem.

[PhoneBoy]

Is it possible to break that up into multiple commands?
I think the issue is the command line is longer than clish allows.

[genisis__]

Query Guys,

If I have an existing cluster and a number of interfaces how do I set anti-spoofing to detect on each of these interfaces using the mgmt_cli?  

If I can prep this in advanced it would save me time later.

[RKinsp]

Hello,

I think the following would set it to detect, but I have not tested it

mgmt_cli set simple-cluster name "cluster1" interfaces.update.name "eth-1" interfaces.update.anti-spoofing-settings.action "detect" --format json

You would need a line per interface. You would probably use the login method so you wouldnt need to user and password per line.

ex.

mgmt_cli login user admin password adminpass > id.txt

mgmt_cli set simple-cluster name "cluster1" interfaces.update.name "eth-1" interfaces.update.anti-spoofing-settings.action "detect" -s id.txt

mgmt_cli set simple-cluster name "cluster1" interfaces.update.name "eth-2" interfaces.update.anti-spoofing-settings.action "detect" -s id.txt

etc...

mgmt_cli publish -s id.txt

[genisis__]

Thanks - I'll give it a go.

[genisis__]

I assume if I did this through the smartconsole command prompt I would need a username/password.

[genisis__]

Just tried it but it did not work:

set simple-cluster name "CLUSTER1" interfaces.update.name "bond5" interfaces.update.anti-spoofing-settings.action "detect"

code: "generic_err_invalid_parameter"
message: "Invalid parameter for [interface-type]. Mandatory to specify interface type

The found "interface-type" here:

https://sc1.checkpoint.com/documents/latest/APIs/?#cli/set-simple-cluster~v1.7%20

 and then tried this:

set simple-cluster name "CLUSTER1" interfaces.update.name "bond5" interfaces.update.anti-spoofing-settings.action "detect" interfaces.update.interface-type "cluster"

and then got this:

code: "generic_err_missing_required_parameters"
message: "Missing parameter: [ip-address or ipv4-address or ipv6-address]"

Its looking like a number of mandatory fields are required.

[RKinsp]

I assumed if you were editing a current interface you could just use a single value...  Try the example below just adding the anti-spoofing section.  Please note this does not work for adding an interface, there is another example for that.

https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/set-simple-cluster~v1.7%20

mgmt_cli set simple-cluster name "cluster1" interfaces.update.name "eth-1" interfaces.update.ip-address "1.2.2.203" interfaces.update.network-mask "255.255.255.0" interfaces.update.interface-type "cluster" interfaces.update.topology "INTERNAL" interfaces.update.topology-settings.ip-address-behind-this-interface "network defined by the interface ip and net mask" interfaces.update.topology-settings.interface-leads-to-dmz false --format json

[genisis__]

The challenge here is I only want to update the Anti-Spoofing part, and leave everything else untouched.

[PhoneBoy]

Unfortunately, there are some API calls that require multiple things to be specified even though it may not seem...necessary.
Not exactly sure if this is a bug or not.
@Omer_Kleinstern any thoughts?

[genisis__]

Thanks, in this case its just quickier and safer to do it the old fashion way 😉

[PhoneBoy]

Apparently, the need for the parameters via the API is by design (not a bug, exactly).
We'll work to improve this in an upcoming release.

[genisis__]

Thanks.

b.t.w is it possible to failover gateways using API?