1 hour delay in the license expiration trap

This article describes the issue of a one hour delay in the license expiration trap.

  1. The date is set, as shown below, and the license expiration date is 2012-10-17 00:00:00 UTC:
  2. LICENSE_EXPIRED Messages are generated in log messages; but no trap is generated:
  3. Now, the license will still be used and installed; even though it has expired:
  4. The license expires and SNMPD generates the trap after an hour (Oct 17 00:59:13):

This issue is due to the signature base set containing only the most up-to-date and dangerous malware signatures (not full set due to memory limitations). Every update is formed dynamically and the number of signatures is always changing. The selection of signatures for each new base set is based on statistics and it dynamically changes. So, each set provides the same protection level.

The delay in the trap is due to the following reasons:

  • In 11.1R1, a change was made to the license expiration on SRX platforms, in which the license data will be written to the database, only at 1 hour intervals. This is the DB that alarmd reads to check if a license is about to expire.
  • So, this results in expiration alarms being triggered, only after an hour of license expiry. This was already discussed with the Branch SRX team, prior to implementation.

In 11.4R3 Optimized, the 1 hour database update logic is performed as follows:

For SRX platforms, the update interval of usage.db is:

  • 1 hour, if the remaining usage time of a feature is > 1 hour.
  • 30 minutes, if the remaining usage time of a feature is > 30 minutes.
  • 10 minutes, if the remaining usage time of a feature is > 10 minutes.
  • 1 min, if the remaining usage time of a feature is > 1 minute.
  • 10 seconds, if the remaining usage time of a feature is <= 1 minute.

So, from 11.4R3 or later, the delay in alarms for license expiry will not occur.

About the author

Prasanna

Leave a Comment