- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Blades URL Filtering and Application Control "...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Blades URL Filtering and Application Control "Not Responding" ?!...
Hello all,
Blades "URL Filtering" and "Application Control" are seen as "Not Responding" from our SmartConsole.
However, these two Blades have their Licenses active and not expired.
Could it be a cosmetic display issue? How can I be sure that the Blades continue to work?
Thanks a lot.
_____________
Technical infos :
Product version Check Point Gaia R81.10
OS build 335
OS kernel version 3.10.0-957.21.3cpx86_64
OS edition 64-bit
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With reference to sk111944 has the machine been restarted recently?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, one week ago.
The solution could be in the SK111944 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Check the file contents as listed in the SK. If it looks ok and the problem persists with the latest JHF installed please contact TAC to investigate further.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Indeed we already provided to our Support-Registred the content of this file and we are waiting for a feedback...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
(
:status (0)
:status_short_desc ()
:status_long_desc ()
:app_update_status (up-to-date)
:app_update_description ("Gateway is up to date. Database version: 31012201.")
:app_next_update_description ("The next update will be run as scheduled.")
:app_db_version (31012201)
:urlf_status_code (0)
:urlf_status_short_description ()
:urlf_status_long_description ()
:appi_rad_status_code (0)
:appi_rad_status_description ("Application Control Engine is up and running")
:urlf_rad_status_code (0)
:urlf_rad_status_description ("URL Filtering engine is up and running")
:app_subscription_expiration_date ("Sun Dec 31 00:00:00 2023")
:app_subscription_status (valid)
:app_subscription_description ("Contract is up to date.")
:urlf_subscription_expiration_date ("Sun Dec 31 00:00:00 2023")
:urlf_subscription_status (valid)
:urlf_subscription_description ("Contract is up to date.")
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it a positive false ?...
The Blades continue to work despite of the warning on the SmartConsole ??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah mate it keeps working.
Just check the logs:
blade:"URL Filtering" or blade:"Application Control"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It could be false positive, but I would do what was suggested by @Chris_Atkinson and @Juan_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Probably just a cosmetic issue, but restarting all services as it says in sk111944 to resolve it is a bit of a blunt force instrument.
Generally when you are retrieving status from a gateway, the updates are provided by the cpd daemon on the gateway. If that daemon is having issues it may log something into $CPDIR/log/cpd.elg that is helpful. However I have seen restarting just the cpd daemon on the gateway clear a number of status issues (and doing so will not cause an outage). Obviously this is not a long-term solution but can help identify where the problem is located.
There is also a daemon called cpstat_monitor but I believe that one is just for the advanced Traffic/System Counters reports provided by the monitoring blade and not for general status.
Finally there are a number of status databases maintained by cpd that can get corrupted in various ways (such as the SMS running out of disk space) causing strange status behavior. The primary indicator of this condition is high CPU utilization by cpd or it occasionally crashing. See these SKs:
sk101484: CPD is consuming high CPU utilization (>90%) or CPD is terminated on the Security Gateway
sk109940: CPD daemon consumes CPU at high level and exits periodically.
now available at maxpowerfirewalls.com