Information About Feature Licenses
A license specifies the options that are enabled on a given ASA. It is represented by an activation key that is a 160-bit (5 32-bit words or 20 bytes) value. This value encodes the serial number (an 11 character string) and the enabled features.
This section includes the following topics:
Preinstalled License
By default, your ASA ships with a license already installed. This license might be the Base License, to which you want to add more licenses, or it might already have all of your licenses installed, depending on what you ordered and what your vendor installed for you. See the “Monitoring Licenses” section section to determine which licenses you have installed.
Permanent License
You can have one permanent activation key installed. The permanent activation key includes all licensed features in a single key. If you also install time-based licenses, the ASA combines the permanent and time-based licenses into a running license. See the “How Permanent and Time-Based Licenses Combine” section for more information about how the ASA combines the licenses.
Time-Based Licenses
In addition to permanent licenses, you can purchase time-based licenses or receive an evaluation license that has a time-limit. For example, you might buy a time-based AnyConnect Premium license to handle short-term surges in the number of concurrent SSL VPN users, or you might order a Botnet Traffic Filter time-based license that is valid for 1 year.
This section includes the following topics:
Time-Based License Activation Guidelines
- You can install multiple time-based licenses, including multiple licenses for the same feature. However, only one time-based license per feature can be active at a time. The inactive license remains installed, and ready for use. For example, if you install a 1000-session AnyConnect Premium license, and a 2500-session AnyConnect Premium license, then only one of these licenses can be active.
- If you activate an evaluation license that has multiple features in the key, then you cannot also activate another time-based license for one of the included features. For example, if an evaluation license includes the Botnet Traffic Filter and a 1000-session AnyConnect Premium license, you cannot also activate a standalone time-based 2500-session AnyConnect Premium license.
How the Time-Based License Timer Works
- The timer for the time-based license starts counting down when you activate it on the ASA.
- If you stop using the time-based license before it times out, then the timer halts. The timer only starts again when you reactivate the time-based license.
- If the time-based license is active, and you shut down the ASA, then the timer continues to count down. If you intend to leave the ASA in a shut down state for an extended period of time, then you should deactivate the time-based license before you shut down.
Note We suggest you do not change the system clock after you install the time-based license. If you set the clock to be a later date, then if you reload, the ASA checks the system clock against the original installation time, and assumes that more time has passed than has actually been used. If you set the clock back, and the actual running time is greater than the time between the original installation time and the system clock, then the license immediately expires after a reload.
How Permanent and Time-Based Licenses Combine
When you activate a time-based license, then features from both permanent and time-based licenses combine to form the running license. How the permanent and time-based licenses combine depends on the type of license. Table 4-18 lists the combination rules for each feature license.
Note Even when the permanent license is used, if the time-based license is active, it continues to count down.
Table 4-18 Time-Based License Combination Rules
|
|
AnyConnect Premium Sessions |
The higher value is used, either time-based or permanent. For example, if the permanent license is 1000 sessions, and the time-based license is 2500 sessions, then 2500 sessions are enabled. Typically, you will not install a time-based license that has less capability than the permanent license, but if you do so, then the permanent license is used. |
Unified Communications Proxy Sessions |
The time-based license sessions are added to the permanent sessions, up to the platform limit. For example, if the permanent license is 2500 sessions, and the time-based license is 1000 sessions, then 3500 sessions are enabled for as long as the time-based license is active. |
Security Contexts |
The time-based license contexts are added to the permanent contexts, up to the platform limit. For example, if the permanent license is 10 contexts, and the time-based license is 20 contexts, then 30 contexts are enabled for as long as the time-based license is active. |
Botnet Traffic Filter |
There is no permanent Botnet Traffic Filter license available; the time-based license is used. |
All Others |
The higher value is used, either time-based or permanent. For licenses that have a status of enabled or disabled, then the license with the enabled status is used. For licenses with numerical tiers, the higher value is used. Typically, you will not install a time-based license that has less capability than the permanent license, but if you do so, then the permanent license is used. |
To view the combined license, see the “Monitoring Licenses” section.
Stacking Time-Based Licenses
In many cases, you might need to renew your time-based license and have a seamless transition from the old license to the new one. For features that are only available with a time-based license, it is especially important that the license not expire before you can apply the new license. The ASA allows you to stack time-based licenses so you do not have to worry about the license expiring or about losing time on your licenses because you installed the new one early.
When you install an identical time-based license as one already installed, then the licenses are combined, and the duration equals the combined duration.
For example:
1. You install a 52-week Botnet Traffic Filter license, and use the license for 25 weeks (27 weeks remain).
2. You then purchase another 52-week Botnet Traffic Filter license. When you install the second license, the licenses combine to have a duration of 79 weeks (52 weeks plus 27 weeks).
Similarly:
1. You install an 8-week 1000-session AnyConnect Premium license, and use it for 2 weeks (6 weeks remain).
2. You then install another 8-week 1000-session license, and the licenses combine to be 1000-sessions for 14 weeks (8 weeks plus 6 weeks).
If the licenses are not identical (for example, a 1000-session AnyConnect Premium license vs. a 2500-session license), then the licenses are not combined. Because only one time-based license per feature can be active, only one of the licenses can be active. See the “Activating or Deactivating Keys” section for more information about activating licenses.
Although non-identical licenses do not combine, when the current license expires, the ASA automatically activates an installed license of the same feature if available. See the “Time-Based License Expiration” section for more information.
Time-Based License Expiration
When the current license for a feature expires, the ASA automatically activates an installed license of the same feature if available. If there are no other time-based licenses available for the feature, then the permanent license is used.
If you have more than one additional time-based license installed for a feature, then the ASA uses the first license it finds; which license is used is not user-configurable and depends on internal operations. If you prefer to use a different time-based license than the one the ASA activated, then you must manually activate the license you prefer. See the “Activating or Deactivating Keys” section.
For example, you have a time-based 2500-session AnyConnect Premium license (active), a time-based 1000-session AnyConnect Premium license (inactive), and a permanent 500-session AnyConnect Premium license. While the 2500-session license expires, the ASA activates the 1000-session license. After the 1000-session license expires, the ASA uses the 500-session permanent license.
Shared AnyConnect Premium Licenses
A shared license lets you purchase a large number of AnyConnect Premium sessions and share the sessions as needed among a group of ASAs by configuring one of the ASAs as a shared licensing server, and the rest as shared licensing participants. This section describes how a shared license works and includes the following topics:
Information About the Shared Licensing Server and Participants
The following steps describe how shared licenses operate:
1. Decide which ASA should be the shared licensing server, and purchase the shared licensing server license using that device serial number.
2. Decide which ASAs should be shared licensing participants, including the shared licensing backup server, and obtain a shared licensing participant license for each device, using each device serial number.
3. (Optional) Designate a second ASA as a shared licensing backup server. You can only specify one backup server.
Note The shared licensing backup server only needs a participant license.
4. Configure a shared secret on the shared licensing server; any participants with the shared secret can use the shared license.
5. When you configure the ASA as a participant, it registers with the shared licensing server by sending information about itself, including the local license and model information.
Note The participant needs to be able to communicate with the server over the IP network; it does not have to be on the same subnet.
6. The shared licensing server responds with information about how often the participant should poll the server.
7. When a participant uses up the sessions of the local license, it sends a request to the shared licensing server for additional sessions in 50-session increments.
8. The shared licensing server responds with a shared license. The total sessions used by a participant cannot exceed the maximum sessions for the platform model.
Note The shared licensing server can also participate in the shared license pool. It does not need a participant license as well as the server license to participate.
a. If there are not enough sessions left in the shared license pool for the participant, then the server responds with as many sessions as available.
b. The participant continues to send refresh messages requesting more sessions until the server can adequately fulfill the request.
9. When the load is reduced on a participant, it sends a message to the server to release the shared sessions.
Note The ASA uses SSL between the server and participant to encrypt all communications.
Communication Issues Between Participant and Server
See the following guidelines for communication issues between the participant and server:
- If a participant fails to send a refresh after 3 times the refresh interval, then the server releases the sessions back into the shared license pool.
- If the participant cannot reach the license server to send the refresh, then the participant can continue to use the shared license it received from the server for up to 24 hours.
- If the participant is still not able to communicate with a license server after 24 hours, then the participant releases the shared license, even if it still needs the sessions. The participant leaves existing connections established, but cannot accept new connections beyond the license limit.
- If a participant reconnects with the server before 24 hours expires, but after the server expired the participant sessions, then the participant needs to send a new request for the sessions; the server responds with as many sessions as can be reassigned to that participant.
Information About the Shared Licensing Backup Server
The shared licensing backup server must register successfully with the main shared licensing server before it can take on the backup role. When it registers, the main shared licensing server syncs server settings as well as the shared license information with the backup, including a list of registered participants and the current license usage. The main server and backup server sync the data at 10 second intervals. After the initial sync, the backup server can successfully perform backup duties, even after a reload.
When the main server goes down, the backup server takes over server operation. The backup server can operate for up to 30 continuous days, after which the backup server stops issuing sessions to participants, and existing sessions time out. Be sure to reinstate the main server within that 30-day period. Critical-level syslog messages are sent at 15 days, and again at 30 days.
When the main server comes back up, it syncs with the backup server, and then takes over server operation.
When the backup server is not active, it acts as a regular participant of the main shared licensing server.
Note When you first launch the main shared licensing server, the backup server can only operate independently for 5 days. The operational limit increases day-by-day, until 30 days is reached. Also, if the main server later goes down for any length of time, the backup server operational limit decrements day-by-day. When the main server comes back up, the backup server starts to increment again day-by-day. For example, if the main server is down for 20 days, with the backup server active during that time, then the backup server will only have a 10-day limit left over. The backup server “recharges” up to the maximum 30 days after 20 more days as an inactive backup. This recharging function is implemented to discourage misuse of the shared license.
Failover and Shared Licenses
This section describes how shared licenses interact with failover and includes the following topics:
Failover and Shared License Servers
This section describes how the main server and backup server interact with failover. Because the shared licensing server is also performing normal duties as the ASA, including performing functions such as being a VPN gateway and firewall, then you might need to configure failover for the main and backup shared licensing servers for increased reliability.
Note The backup server mechanism is separate from, but compatible with, failover.
Shared licenses are supported only in single context mode, so Active/Active failover is not supported.
For Active/Standby failover, the primary unit acts as the main shared licensing server, and the standby unit acts as the main shared licensing server after failover. The standby unit does not act as the backup shared licensing server. Instead, you can have a second pair of units acting as the backup server, if desired.
For example, you have a network with 2 failover pairs. Pair #1 includes the main licensing server. Pair #2 includes the backup server. When the primary unit from Pair #1 goes down, the standby unit immediately becomes the new main licensing server. The backup server from Pair #2 never gets used. Only if both units in Pair #1 go down does the backup server in Pair #2 come into use as the shared licensing server. If Pair #1 remains down, and the primary unit in Pair #2 goes down, then the standby unit in Pair #2 comes into use as the shared licensing server.
The standby backup server shares the same operating limits as the primary backup server; if the standby unit becomes active, it continues counting down where the primary unit left off. See the “Information About the Shared Licensing Backup Server” section for more information.
Failover and Shared License Participants
For participant pairs, both units register with the shared licensing server using separate participant IDs. The active unit syncs its participant ID with the standby unit. The standby unit uses this ID to generate a transfer request when it switches to the active role. This transfer request is used to move the shared sessions from the previously active unit to the new active unit.
Maximum Number of Participants
The ASA does not limit the number of participants for the shared license; however, a very large shared network could potentially affect the performance on the licensing server. In this case, you can increase the delay between participant refreshes, or you can create two shared networks.
Failover or ASA Cluster Licenses
With some exceptions, failover and cluster units do not require the same license on each unit. For earlier versions, see the licensing document for your version.
This section includes the following topics:
Failover License Requirements and Exceptions
Failover units do not require the same license on each unit.
Older versions of ASA software required that the licenses match on each unit. Starting with Version 8.3(1), you no longer need to install identical licenses. Typically, you buy a license only for the primary unit; for Active/Standby failover, the secondary unit inherits the primary license when it becomes active. If you have licenses on both units, they combine into a single running failover cluster license.
The exceptions to this rule include:
- Security Plus license for the ASA 5505, 5510, and 5512-X—The Base license does not support failover, so you cannot enable failover on a standby unit that only has the Base license.
- Encryption license—Both units must have the same encryption license.
- IPS module license for the ASA 5512-X through ASA 5555-X—Both units require the IPS module license. You also need the IPS signature subscription on the IPS side for both units. See the following guidelines:
– To buy the IPS signature subscription you need to have the ASA with IPS pre-installed (the part number must include “IPS”, for example ASA5515-IPS-K9); you cannot buy the IPS signature subscription for a non-IPS part number ASA.
– You need the IPS signature subscription on both units; this subscription is not shared in failover, because it is not an ASA license.
– The IPS signature subscription requires a unique IPS module license per unit. Like other ASA licenses, the IPS module license is technically shared in the failover cluster license. However, because of the IPS signature subscription requirements, you must buy a separate IPS module license for each unit in.
Note A valid permanent key is required; in rare instances, your authentication key can be removed. If your key consists of all 0’s, then you need to reinstall a valid authentication key before failover can be enabled.
ASA Cluster License Requirements and Exceptions
Cluster units do not require the same license on each unit. Typically, you buy a license only for the master unit; slave units inherit the master license. If you have licenses on multiple units, they combine into a single running ASA cluster license.
The exceptions to this rule include:
- Clustering license—Each unit must have a clustering license.
- Encryption license—Each unit must have the same encryption license.
How Failover or ASA Cluster Licenses Combine
For failover pairs or ASA clusters, the licenses on each unit are combined into a single running cluster license. If you buy separate licenses for each unit, then the combined license uses the following rules:
- For licenses that have numerical tiers, such as the number of sessions, the values from each unit’s licenses are combined up to the platform limit. If all licenses in use are time-based, then the licenses count down simultaneously.
For example, for failover:
– You have two ASAs with 10 AnyConnect Premium sessions installed on each; the licenses will be combined for a total of 20 AnyConnect Premium sessions.
– You have two ASA 5520 ASAs with 500 AnyConnect Premium sessions each; because the platform limit is 750, the combined license allows 750 AnyConnect Premium sessions.
Note In the above example, if the AnyConnect Premium licenses are time-based, you might want to disable one of the licenses so you do not “waste” a 500 session license from which you can only use 250 sessions because of the platform limit.
– You have two ASA 5540 ASAs, one with 20 contexts and the other with 10 contexts; the combined license allows 30 contexts. For Active/Active failover, the contexts are divided between the two units. One unit can use 18 contexts and the other unit can use 12 contexts, for example, for a total of 30.
For example, for ASA clustering:
– You have four ASA 5585-X ASAs with SSP-10, three units with 50 contexts each, and one unit with the default 2 contexts. Because the platform limit is 100, the combined license allows a maximum of 100 contexts. Therefore, you can configure up to 100 contexts on the master unit; each slave unit will also have 100 contexts through configuration replication.
– You have four ASA 5585-X ASAs with SSP-60, three units with 50 contexts each, and one unit with the default 2 contexts. Because the platform limit is 250, the licenses will be combined for a total of 152 contexts. Therefore, you can configure up to 152 contexts on the master unit; each slave unit will also have 152 contexts through configuration replication.
- For licenses that have a status of enabled or disabled, then the license with the enabled status is used.
- For time-based licenses that are enabled or disabled (and do not have numerical tiers), the duration is the combined duration of all licenses. The primary/master unit counts down its license first, and when it expires, the secondary/slave unit(s) start counting down its license, and so on. This rule also applies to Active/Active failover and ASA clustering, even though all units are actively operating.
For example, if you have 48 weeks left on the Botnet Traffic Filter license on two units, then the combined duration is 96 weeks.
To view the combined license, see the “Monitoring Licenses” section.
Loss of Communication Between Failover or ASA Cluster Units
If the units lose communication for more than 30 days, then each unit reverts to the license installed locally. During the 30-day grace period, the combined running license continues to be used by all units.
If you restore communication during the 30-day grace period, then for time-based licenses, the time elapsed is subtracted from the primary/master license; if the primary/master license becomes expired, only then does the secondary/slave license start to count down.
If you do not restore communication during the 30-day period, then for time-based licenses, time is subtracted from all unit licenses, if installed. They are treated as separate licenses and do not benefit from the combined license. The time elapsed includes the 30-day grace period.
For example:
1. You have a 52-week Botnet Traffic Filter license installed on two units. The combined running license allows a total duration of 104 weeks.
2. The units operate as a failover unit/ASA cluster for 10 weeks, leaving 94 weeks on the combined license (42 weeks on the primary/master, and 52 weeks on the secondary/slave).
3. If the units lose communication (for example the primary/master unit fails), the secondary/slave unit continues to use the combined license, and continues to count down from 94 weeks.
4. The time-based license behavior depends on when communication is restored:
- Within 30 days—The time elapsed is subtracted from the primary/master unit license. In this case, communication is restored after 4 weeks. Therefore, 4 weeks are subtracted from the primary/master license leaving 90 weeks combined (38 weeks on the primary, and 52 weeks on the secondary).
- After 30 days—The time elapsed is subtracted from both units. In this case, communication is restored after 6 weeks. Therefore, 6 weeks are subtracted from both the primary/master and secondary/slave licenses, leaving 84 weeks combined (36 weeks on the primary/master, and 46 weeks on the secondary/slave).
Upgrading Failover Pairs
Because failover pairs do not require the same license on both units, you can apply new licenses to each unit without any downtime. If you apply a permanent license that requires a reload (see Table 4-19), then you can fail over to the other unit while you reload. If both units require reloading, then you can reload them separately so you have no downtime.
No Payload Encryption Models
You can purchase some models with No Payload Encryption. For export to some countries, payload encryption cannot be enabled on the Cisco ASA series. The ASA software senses a No Payload Encryption model, and disables the following features:
- Unified Communications
- VPN
You can still install the Strong Encryption (3DES/AES) license for use with management connections. For example, you can use ASDM HTTPS/SSL, SSHv2, Telnet and SNMPv3. You can also download the dynamic database for the Botnet Traffic Filter (which uses SSL).
When you view the license (see the “Monitoring Licenses” section), VPN and Unified Communications licenses will not be listed.
Licenses FAQ
Q. Can I activate multiple time-based licenses, for example, AnyConnect Premium and Botnet Traffic Filter?
Yes. You can use one time-based license per feature at a time.
Q. Can I “stack” time-based licenses so that when the time limit runs out, it will automatically use the next license?
Yes. For identical licenses, the time limit is combined when you install multiple time-based licenses. For non-identical licenses (for example, a 1000-session AnyConnect Premium license and a 2500-session license), the ASA automatically activates the next time-based license it finds for the feature.
Q. Can I install a new permanent license while maintaining an active time-based license?
Yes. Activating a permanent license does not affect time-based licenses.
Q. For failover, can I use a shared licensing server as the primary unit, and the shared licensing backup server as the secondary unit?
No. The secondary unit has the same running license as the primary unit; in the case of the shared licensing server, they require a server license. The backup server requires a participant license. The backup server can be in a separate failover pair of two backup servers.
Q. Do I need to buy the same licenses for the secondary unit in a failover pair?
No. Starting with Version 8.3(1), you do not have to have matching licenses on both units. Typically, you buy a license only for the primary unit; the secondary unit inherits the primary license when it becomes active. In the case where you also have a separate license on the secondary unit (for example, if you purchased matching licenses for pre-8.3 software), the licenses are combined into a running failover cluster license, up to the model limits.
Q. Can I use a time-based or permanent AnyConnect Premium license in addition to a shared AnyConnect Premium license?
Yes. The shared license is used only after the sessions from the locally installed license (time-based or permanent) are used up. Note : On the shared licensing server, the permanent AnyConnect Premium license is not used; you can however use a time-based license at the same time as the shared licensing server license. In this case, the time-based license sessions are available for local AnyConnect Premium sessions only; they cannot be added to the shared licensing pool for use by participants.
Configuring Licenses
This section includes the following topics:
Obtaining an Activation Key
To obtain an activation key, you need a Product Authorization Key, which you can purchase from your Cisco account representative. You need to purchase a separate Product Authorization Key for each feature license. For example, if you have the Base License, you can purchase separate keys for Advanced Endpoint Assessment and for additional AnyConnect Premium sessions.
After obtaining the Product Authorization Keys, register them on Cisco.com by performing the following steps.
Detailed Steps
Step 1 Obtain the serial number for your ASA by entering the following command.
ciscoasa# show version | grep Serial
Step 2 If you are not already registered with Cisco.com, create an account.
Step 3 Go to the following licensing website:
http://www.cisco.com/go/license
Step 4 Enter the following information, when prompted:
- Product Authorization Key (if you have multiple keys, enter one of the keys first. You have to enter each key as a separate process.)
- The serial number of your ASA
- Your e-mail address
An activation key is automatically generated and sent to the e-mail address that you provide. This key includes all features you have registered so far for permanent licenses. For time-based licenses, each license has a separate activation key.
Step 5 If you have additional Product Authorization Keys, repeat Step 4 for each Product Authorization Key. After you enter all of the Product Authorization Keys, the final activation key provided includes all of the permanent features you registered.
Activating or Deactivating Keys
This section describes how to enter a new activation key, and how to activate and deactivate time-based keys.
Prerequisites
- If you are already in multiple context mode, enter the activation key in the system execution space.
- Some permanent licenses require you to reload the ASA after you activate them. Table 4-19 lists the licenses that require reloading.
Table 4-19 Permanent License Reloading Requirements
|
License Action Requiring Reload
|
All models |
Downgrading the Encryption license. |
Limitations and Restrictions
Your activation key remains compatible if you upgrade to the latest version from any previous version. However, you might have issues if you want to maintain downgrade capability:
- Downgrading to Version 8.1 or earlier—After you upgrade, if you activate additional feature licenses that were introduced before 8.2 , then the activation key continues to be compatible with earlier versions if you downgrade. However if you activate feature licenses that were introduced in 8.2 or later , then the activation key is not backwards compatible. If you have an incompatible license key, then see the following guidelines:
– If you previously entered an activation key in an earlier version, then the ASA uses that key (without any of the new licenses you activated in Version 8.2 or later).
– If you have a new system and do not have an earlier activation key, then you need to request a new activation key compatible with the earlier version.
- Downgrading to Version 8.2 or earlier—Version 8.3 introduced more robust time-based key usage as well as failover license changes:
– If you have more than one time-based activation key active, when you downgrade, only the most recently activated time-based key can be active. Any other keys are made inactive.
– If you have mismatched licenses on a failover pair, then downgrading will disable failover. Even if the keys are matching, the license used will no longer be a combined license.
Detailed Steps
|
|
|
Step 1 |
activation-key key [ activate | deactivate ]
ciscoasa# activation-key 0xd11b3d48 0xa80a4c0a 0x48e0fd1c 0xb0443480 0x843fc490 |
Applies an activation key to the ASA. The key is a five-element hexadecimal string with one space between each element. The leading 0x specifier is optional; all values are assumed to be hexadecimal. You can install one permanent key, and multiple time-based keys. If you enter a new permanent key, it overwrites the already installed one. The activate and deactivate keywords are available for time-based keys only. If you do not enter any value, activate is the default. The last time-based key that you activate for a given feature is the active one. To deactivate any active time-based key, enter the deactivate keyword. If you enter a key for the first time, and specify deactivate , then the key is installed on the ASA in an inactive state. See the “Time-Based Licenses” section for more information. |
Step 2 |
(Might be required.) reload
ciscoasa# reload |
Reloads the ASA. Some permanent licenses require you to reload the ASA after entering the new activation key. See Table 4-19 for a list of licenses that need reloading. If you need to reload, you will see the following message:
WARNING: The running activation key was not updated with the requested key. The flash activation key was updated with the requested key, and will become active after the next reload.
|
Configuring a Shared License
This section describes how to configure the shared licensing server and participants. For more information about shared licenses, see the “Shared AnyConnect Premium Licenses” section.
This section includes the following topics:
Configuring the Shared Licensing Server
This section describes how to configure the ASA to be a shared licensing server.
Prerequisites
The server must have a shared licensing server key.
Detailed Steps
|
|
|
Step 1 |
license-server secret secret
ciscoasa(config)# license-server secret farscape |
Sets the shared secret, a string between 4 and 128 ASCII characters. Any participant with this secret can use the licensing server. |
Step 2 |
(Optional) license-server refresh-interval seconds
ciscoasa(config)# license-server refresh-interval 100 |
Sets the refresh interval between 10 and 300 seconds; this value is provided to participants to set how often they should communicate with the server. The default is 30 seconds. |
Step 3 |
(Optional) license-server port port
ciscoasa(config)# license-server port 40000 |
Sets the port on which the server listens for SSL connections from participants, between 1 and 65535. The default is TCP port 50554. |
Step 4 |
(Optional) license-server backup address backup-id serial_number [ ha-backup-id ha_serial_number ]
ciscoasa(config)# license-server backup 10.1.1.2 backup-id JMX0916L0Z4 ha-backup-id JMX1378N0W3 |
Identifies the backup server IP address and serial number. If the backup server is part of a failover pair, identify the standby unit serial number as well. You can only identify 1 backup server and its optional standby unit. |
Step 5 |
license-server enable interface_name
ciscoasa(config)# license-server enable inside |
Enables this unit to be the shared licensing server. Specify the interface on which participants contact the server. You can repeat this command for as many interfaces as desired. |
Examples
The following example sets the shared secret, changes the refresh interval and port, configures a backup server, and enables this unit as the shared licensing server on the inside interface and dmz interface:
ciscoasa(config)# license-server secret farscape
ciscoasa(config)# license-server refresh-interval 100
ciscoasa(config)# license-server port 40000
ciscoasa(config)# license-server backup 10.1.1.2 backup-id JMX0916L0Z4 ha-backup-id JMX1378N0W3
ciscoasa(config)# license-server enable inside
ciscoasa(config)# license-server enable dmz
Configuring the Shared Licensing Backup Server (Optional)
This section enables a shared license participant to act as the backup server if the main server goes down.
Prerequisites
The backup server must have a shared licensing participant key.
Detailed Steps
|
|
|
Step 1 |
license-server address address secret secret [ port port ]
ciscoasa(config)# license-server address 10.1.1.1 secret farscape |
Identifies the shared licensing server IP address and shared secret. If you changed the default port in the server configuration, set the port for the backup server to match. |
Step 2 |
license-server backup enable interface_name
ciscoasa(config)# license-server backup enable inside |
Enables this unit to be the shared licensing backup server. Specify the interface on which participants contact the server. You can repeat this command for as many interfaces as desired. |
Examples
The following example identifies the license server and shared secret, and enables this unit as the backup shared license server on the inside interface and dmz interface:
ciscoasa(config)# license-server address 10.1.1.1 secret farscape
ciscoasa(config)# license-server backup enable inside
ciscoasa(config)# license-server backup enable dmz
Configuring the Shared Licensing Participant
This section configures a shared licensing participant to communicate with the shared licensing server.
Prerequisites
The participant must have a shared licensing participant key.
Detailed Steps
|
|
|
Step 1 |
license-server address address secret secret [ port port ]
ciscoasa(config)# license-server address 10.1.1.1 secret farscape |
Identifies the shared licensing server IP address and shared secret. If you changed the default port in the server configuration, set the port for the participant to match. |
Step 2 |
(Optional) license-server backup address address
ciscoasa(config)# license-server backup address 10.1.1.2 |
If you configured a backup server, enter the backup server address. |
Examples
The following example sets the license server IP address and shared secret, as well as the backup license server IP address:
ciscoasa(config)# license-server address 10.1.1.1 secret farscape
ciscoasa(config)# license-server backup address 10.1.1.2