Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
bebertjack
Contributor
Jump to solution

Web API timeout

Hello,

We use Skybox with our Checkpoint environment but we face an issue in R80.20 in management server with a lot of Gateway.

Skybox try to use the Web API on a management server in R80.20 (HFA10 - API 1.3) with a script via the URL https://127.0.0.1/web_api/run-script.

The script is to catch the routing table of the Gateway the Management server administrate.

The problem occur if the task took more than 300 seconds, the client receive an error code "HTTP/1.1 502 Proxy Error" even if the task continue, I can see it if I'm connected to the console. There is no difference in the log file api.elg if the task is successful or unsuccessful

I already try some test

  1. With curl from skybox server
  2. With curl_cli directly on the management server
  3. to increase the session timeout during the login process but unsuccessfully

curl_cli -vvvv -H "Content-Type: application/json" -X POST -d '{"session-timeout":"1800","user":"XXXXXX","password":"YYYYYYYYY"}' https://127.0.0.1/web_api/login --insecure

Do someone know how to increase the timeout ?

 

Thanks

Bebertjack

0 Kudos
1 Solution

Accepted Solutions
Joshua_Hatter
Employee
Employee

The timeout you are experiencing is not controllable via the API login parameters. The timeout, at 300 seconds you are running into is an apache default configuration. That if any POST command is received and data is not transferred over this connection for 300 seconds, apache will close this connection.

 

We do not recommend modifying this timeout as it effects several services. I would go the route phone boy is recommending, and try to understand why in the world a show route or similar command would take 5 minutes.

 

If you are querying hundreds of devices at a time, with run script targets. You might reduce to only a handful of devices at a time. As run-script will not pass any data over the API command until all scripts report there status.

 

View solution in original post

0 Kudos
8 Replies
PhoneBoy
Admin
Admin
What command specifically are you sending via run-script to get the routing table?
Note the command sent must be executable in expert mode.
Regardless of how you're doing it, I can't think of a reason it should take more than 300 seconds (5 minutes) to return a result for the routing table.
0 Kudos
Miroslav_Guoth
Participant
Hi PhoneBoy,
I got similar problem. I want to install policy, but due to number of GWs connected to management and lack of resources of SMS it just takes up to 15 minutes. Currently upgrade of SMS for more powerful or, reducing number of GWs is not the way.
I'm getting timeout message after 10 mins, so I expect that it's because of default session-timeout: 600
I increased General session timeout in Gaia - but no affect to WEB_API timeout.
Is there any possibility to increase session time-out from 600 to 1200?

Thanks a lot for any advice
0 Kudos
PhoneBoy
Admin
Admin
You have to specify the longer timeout as part of the login call that creates the session.
Also, are you trying to install policy to multiple gateways at once?
Try installing to fewer gateways.
Either that or try polling the task-id more frequently, which should also refresh the timer on the session.
0 Kudos
Tamir_Goren
Employee
Employee

Hi Miroslav,

My name is Tamir Goren from Checkpoint RnD. I might be able to help you with better policy load performance time. I recently committed some performance enhancements  in context of PMTR-62864 issue. You can open an SR with Checkpoint TAC and add this information. I will try to provide you with it.

Regards -Tamir

0 Kudos
Adam_Forester
Ambassador
Ambassador

On mgmt_cli you can increase the timeout by using '--conn-timeout'

0 Kudos
Joshua_Hatter
Employee
Employee

The timeout you are experiencing is not controllable via the API login parameters. The timeout, at 300 seconds you are running into is an apache default configuration. That if any POST command is received and data is not transferred over this connection for 300 seconds, apache will close this connection.

 

We do not recommend modifying this timeout as it effects several services. I would go the route phone boy is recommending, and try to understand why in the world a show route or similar command would take 5 minutes.

 

If you are querying hundreds of devices at a time, with run script targets. You might reduce to only a handful of devices at a time. As run-script will not pass any data over the API command until all scripts report there status.

 

0 Kudos
bebertjack
Contributor

Thanks for the answer

I use the command below
curl_cli -v -H "Content-Type: application/json" -H "X-chkp-sid: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -X POST -d '{"script":"netstat -rne","script-name":"Get routing rules","targets":["GW Target"]}' https://127.0.0.1/web_api/run-script --insecure

I think I find why we issue a timeout. Skybox put all the object tagged Firewall GW even the Cluster object itself in the GW target part of the command. The problem is that Cluster object do not respond to the request and then it took some time before CKPT put this task in error.

I confirm it with two tests:
- With all the target the task is complete in 18 mn en 14 sec
- With only the cluster member in the target part the task end in 4 mn 37 sec

0 Kudos
bebertjack
Contributor

Tanks for the answer

I use the command below
curl_cli -v -H "Content-Type: application/json" -H "X-chkp-sid: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -X POST -d '{"script":"netstat -rne","script-name":"Get routing rules","targets":["GW Target"]}' https://127.0.0.1/web_api/run-script --insecure

I think I find why we issue a timeout. Skybox put all the object tagged Firewall GW even the Cluster object itself in the GW target part of the command. The problem is that Cluster object do not respond to the request and then it took some time before CKPT put this task in error.

I confirm it with two tests:
- With all the target the task is complete in 18 mn en 14 sec
- With only the cluster member in the target part the task end in 4 mn 37 sec

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events