Data Center Objects not updating - force refresh?

[Nicholas_Sherid]

Hi Forum

VSEC blade seems to have stopped scanning.  Tags and other metadata from Azure is no longer being updated.  Need to troubleshoot - cant seem to find verification scripts or documentation on specific subject.

Azure Server shows connected , when I click on "Test Connection" it shows connected.  Anyone give me a steer on this?

Thanks!

[Matthias_Haas]

Hi Nicholas,

If you click on Datacenter Objects, do you have a yellow bar at the top with something like "Object is missing/no longer available" ? We had similar problems that after some time, the content of the Datacenter Objects (the IPs) "disappeared/was no longer updated", so the rulebase was more or less empty. I checked sk131932 (too many requests by the Mng Server) but I did find only a couple of "HTTP status code 429 Too many requests" error" log entries.

Matthias

[Nicholas_Sherid]

Not sure that is my problem - but that log file is excellent - many thanks

I am going through this now and I'll post up the outcome 

[Nicholas_Sherid]

this was my logfile if any one has the same issue on r80.10:

/var/log/opt/CPsuite-R80/fw1/log/cloud_proxy.elg

and ref sk131932 - @Matthias Haas - good steer mate thanks

RequestException: HTTP/1.1 502 Bad Gateway
{"error":{"code":"BadGatewayConnection","message":"The network connectivity issue encountered for 'Microsoft.Network'; cannot fulfill the request."}}

[Nicholas_Sherid]

This was a major fail on my part: There seems to be a difference between a full system restart and a cprestart, one reboots the box and the other seems to fully start the process again (I can only assume some form of state is written to disk and therefore persists at reboot whilst a cprestart starts from scratch).  There is a properties file where you can make the debugging more verbose:

Edit:

vi $VSECDIR/lib/log4j.properties 

Add entries

log4j.logger.com.cp.dcrepository = TRACE 
log4j.logger.com.cp.cms_proxydcrepository=TRACE 
log4j.logger.com.cp.cms=TRACE 

Restart vsec controller:

vsec_controller_stop 

Then you can tail the cloud_proxy.elg file i.e. (I like to follow the file in real time):

tail -f /var/log/opt/CPsuite-R80/fw1/log/cloud_proxy.elg

If you are lookng for something specific, then pipe the tail into grep of something useful (obviously replace some_useful_object with whatever is of interest to you)

tail -f /var/log/opt/CPsuite-R80/fw1/log/cloud_proxy.elg | grep some_useful_object

Loving the gaia linux effect (yeah I know the kernel is different), but this is handy for a less seasoned checkpoint debugger like me .  Interesting mash up to java, bash and python going on in R80.x

This is verbose - therefore consumes disk space - don't forget to remove the entries in the properties file and restart the controller when you are done!!

[KostasGR]

Hello

For code 429 the explanation is that there is a rate limiting configuration  for API calls on destination server in order to protect it from DoS.

BR,

Kostas

[John_Parnell]

Hey Nicholas,

I hope you have your issue resolved. If you need to update a Data center object on a gateway for any of the cloud providers. You can use vsec_controller_cli There will be an option to resend enforcement data. Then you chose your cluster. This usually resolves data center objects not updating. If that fails some other possible solutions are as follows. vsec off vsec on, for which you will need to wait up to 10 minutes for all gateways to update. This greatly depends on the number of clusters you have. Also I have found that in some cases where the same policy is used with multiple clusters, I need to install policy to all of the clusters at once in order to resolve the issue. 

[Nicholas_Sherid]

thanks john!