Configure interface topology settings

[Simon_Macpherso]

Hello,

Using API v1.8.1

The following command is not being accepted. 

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.name 'eth1' interfaces.topology-settings.ip-address-behind-this-interface 'specific' interfaces.topology-settings.specific-network 'network01'

Does anyone see an issue with this syntax? 

Regards,

Simon

[Chris_Atkinson]

Away from my lab currently but just quickly is "demo01" a gateway or cluster object?

[Simon_Macpherso]

Gateway object

[Bob_Zimmerman]

Looks fine to me, though you may also need to specify the interfaces.topology, depending on whether it's already set to the right value or not. For example, on an External interface, the ip-address-behind-this-interface property doesn't exist, so trying to set it may fail.

Try adding "interfaces.topology internal" to the call to see if it helps.

If it doesn't, try one call with only "interfaces.topology internal", then a second call with your topology-settings options.

[Simon_Macpherso]

Hi @Bob_Zimmerman 

I've tried both as follow and both are failing.

e.g.

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.topology internal 

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.topology internal  interfaces.name 'eth1' interfaces.topology-settings.ip-address-behind-this-interface 'specific' interfaces.topology-settings.specific-network 'dummy_VPN_domain'

code: "generic_err_invalid_parameter"

message: "Parameter [interfaces] value is not valid

Executed command failed. Changes are discarded. 

[Bob_Zimmerman]

You would need to specify the interface name in the first call, otherwise it doesn't know which interface it's working on.

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.name eth1 interfaces.topology internal

[Jim_Oqvist]

Hi Simon, interfaces is a JSON list. 

Note according to the documentation:  
https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/set-simple-gateway~v1.9%20
Network interfaces. When a gateway is updated with a new interfaces, the existing interfaces are removed.

Please try this:

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.1.topology 'internal' interfaces.1.name 'eth1' interfaces.1.ipv4-address '192.168.1.1' interfaces.1.ipv4-mask-length '24' interfaces.1.topology-settings.ip-address-behind-this-interface 'specific' interfaces.1.topology-settings.specific-network 'dummy_VPN_domain'

[Bob_Zimmerman]

Whoops. I missed the "List:" in front of the Object in the API documentation. Yes, it will need numbers.

[Simon_Macpherso]

I also missed it

[Simon_Macpherso]

Hi @Jim_Oqvist 

The note 'When a gateway is updated with a new interfaces, the existing interfaces are removed' is not clear. I wanted to update the properties of an existing interface. I didn't realize in order to do this the existing interface needs to be removed and re-added. Which explains why the below syntax  is required.

Also it seems ALL interfaces are removed even though I'm specifying eth1.  

To add both eth0 and eth1 I need to do it in one command, meaning it's declarative. 

The following command works 

mgmt_cli -r true set simple-gateway name 'demo01' interfaces.1.topology 'internal' interfaces.1.name 'eth1' interfaces.1.ipv4-address '192.168.1.1' interfaces.1.ipv4-mask-length '24' interfaces.1.topology-settings.ip-address-behind-this-interface 'specific' interfaces.1.topology-settings.specific-network 'dummy_VPN_domain'

Regards,

Simon

[Bob_Zimmerman]

---

@Simon_Macpherso wrote:

Also it seems ALL interfaces are removed even though I'm specifying eth1.

---

That's what the "When a gateway is updated with a new interfaces, the existing interfaces are removed" message means. To manipulate any interface via the API, you must provide all the information for all interfaces. Any interfaces which you don't provide in that API call are removed from the object.

[JozkoMrkvicka]

Such a API logic is perfect for automation of adding 1 VLAN on cluster with 500 VLANs ... 

[Bob_Zimmerman]

It's the closest API call I've seen to core REST functionality, where you download a whole record, manipulate it locally, then upload the whole record when you're done. The big difference still remaining is all other APIs I've used which claim to be RESTful use different HTTP verbs rather than different URLs for CRUD operations:

• Create - POST a whole object
• Read - GET a URL
• Update - PUT with a whole object to fully overwrite the server-side object, or PATCH with only part of the object to update only those fields
• Delete - DELETE a URL with the object identifier

Almost all the other APIs I've used which claim to be RESTful put the object identifier in the path of the URL. To operate on object 1cab76a9-261d-4add-b988-5856c4c5a909, you would make calls with those verbs to <server>/objects/1cab76a9-261d-4add-b988-5856c4c5a909. It separates structure of data from operations on the contents of that structure.

Check Point's management API uses POST for everything. Just about everywhere else, it feels more like remote procedure calls rather than state transfers.

This is the closest to a RESTful update call, where you tell the server "Make the object assume this state."