URL Filter update - users not seeing changes?

[cenders]

1.  If a URL is incorrectly categorized, I submit a change to Brightcloud.

2. Brightcloud emails me the next day (or two) and says the change was accepted and is in the latest DB.

3. I confirm on Brightcloud's website that the URL is newly categorized and what version of the DB it is in.

4. I confirm that my PAN devices have that version of the URL DB (or later). If not, I perform a manual update (via CLI).

But when I try to browse the site, I'm still seeing the old classification for that site (which is blocked by policy).

Is there a delay from when the update occurs before the system sees the new category? Can I cycle a service on the box to make this quicker?

[scanlab.rgr · Accepted solution]

You must clear the URL-cache on the command line: clear url-cache

Regards,

Rainer

[cenders]

Awsome, thank you.

[dyang]

Just to elaborate a little more, URLs are cached on your device, so even if you see a category update via the BrightCloud website, you must wait for the device cache to expire before it can pick up the new categorization.  Clearing your entire cache will certainly force a cloud lookup since the URL in question would no longer be cached on your device, but do keep in mind that you would be clearing your entire cache.

[cmutchler]

How long does it take for a device cache to time out?

[dyang]

By default, the cache has a timeout value of 24 hrs.  We recently identified a bug recently where this variable was not getting configured properly, but this should be addressed in a future release (meaning you'll be able to configure this to a number of your choosing).

[Mitch_Williams]

Great post:smileylaugh:

[gafrol]

We are facing a problem with a lot of "unknown" URL's (Brightcloud DB) although the URLs in question are well known sites. We already filed a case but the problem could not get fixed until now. We are on 5.0.7.

After clearing the url-cache all works fine again for a unknown amount of time (days,weeks). But clearing the url-cache manually every now and then cannot be the solution.

Now I am reading about a bug in the cache timeout value.

dyang schrieb:

By default, the cache has a timeout value of 24 hrs.  We recently identified a bug recently where this variable was not getting configured properly, but this should be addressed in a future release (meaning you'll be able to configure this to a number of your choosing).

Can you give us some more info about this one ?

rgds Roland