This article describes the issue of a one hour delay in the license expiration trap.
- The date is set, as shown below, and the license expiration date is 2012-10-17 00:00:00 UTC:
root> set date 201210162359.30 Tue Oct 16 23:59:30 UTC 2012 root> show system license License usage: Licenses Licenses Licenses Expiry Feature name used installed needed av_key_kaspersky_engine 1 1 0 2012-10-17 00:00:00 UTC wf_key_surfcontrol_cpa 1 0 1 29 days dynamic-vpn 0 2 0 permanent ax411-wlan-ap 0 2 0 permanent
- LICENSE_EXPIRED Messages are generated in log messages; but no trap is generated:
root> root> monitor list root> monitor start all_logs | match LIC root> monitor start all_logs | match | LIC root> clear log all_logs *** all_logs *** Oct 17 00:02:55 utmd[1141]: LICENSE_EXPIRED_KEY_DELETED: License key "JUNOS386449" has expired.
- Now, the license will still be used and installed; even though it has expired:
root> show system uptime Current time: 2012-10-17 00:39:25 UTC System booted: 2012-10-16 19:18:55 UTC (05:20:30 ago) Protocols started: 2012-10-16 19:20:42 UTC (05:18:43 ago) Last configured: 2012-10-17 00:24:40 UTC (00:14:45 ago) by root 12:39AM up 5:21, 1 user, load averages: 0.02, 0.05, 0.03 root> show system license License usage: Licenses Licenses Licenses Expiry Feature name used installed needed av_key_kaspersky_engine 1 1 0 2012-10-17 00:00:00 UTC wf_key_surfcontrol_cpa 1 0 1 29 days dynamic-vpn 0 2 0 permanent ax411-wlan-ap 0 2 0 permanent
- The license expires and SNMPD generates the trap after an hour (Oct 17 00:59:13):
[edit] root# run show system license usage ? Possible completions: <[Enter]> Execute this command | Pipe through a command [edit] root# run show system license usage Licenses Licenses Licenses Expiry Feature name used installed needed av_key_kaspersky_engine 1 0 1 27 days wf_key_surfcontrol_cpa 1 0 1 27 days dynamic-vpn 0 2 0 permanent ax411-wlan-ap 0 2 0 permanent
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.