Basic Settings

This chapter describes how to configure basic settings on the ASA that are typically required for a functioning configuration.

Set the Hostname, Domain Name, and the Enable and Telnet Passwords

To set the hostname, domain name, and the enable and Telnet passwords, perform the following steps.

Before you begin

Before you set the hostname, domain name, and the enable and Telnet passwords, check the following requirements:

  • In multiple context mode, you can configure the hostname and domain name in both the system and context execution spaces.

  • For the enable and Telnet passwords, set them in each context; they are not available in the system. When you session to the ASASM from the switch in multiple context mode, the ASASM uses the login password you set in the admin context.

  • To change from the system to a context configuration, enter the changeto context name command.

Procedure

Step 1

Specify the hostname for the ASA or for a context. The default hostname is “asa.”

hostname name

Example:


ciscoasa(config)# hostname myhostnamexample12345

This name can be up to 63 characters. The hostname must start and end with a letter or digit, and have only letters, digits, or a hyphen.

When you set a hostname for the ASA, that name appears in the command line prompt. If you establish sessions to multiple devices, the hostname helps you keep track of where you enter commands.

For multiple context mode, the hostname that you set in the system execution space appears in the command line prompt for all contexts. The hostname that you optionally set within a context does not appear in the command line, but can be used by the banner command $(hostname) token.

Step 2

Specify the domain name for the ASA. The default domain name is default.domain.invalid.

domain-name name

Example:


ciscoasa(config)# domain-name example.com

The ASA appends the domain name as a suffix to unqualified names. For example, if you set the domain name to “example.com” and specify a syslog server by the unqualified name of “jupiter,” then the ASA qualifies the name to “jupiter.example.com.”

Step 3

Change the enable password. By default, the enable password is blank.

enable password password

Example:


ciscoasa(config)# enable password Pa$$w0rd

The enable password lets you enter privileged EXEC mode if you do not configure enable authentication. The enable password also lets you log into ASDM with a blank username if you do not configure HTTP authentication.

The password argument is a case-sensitive password of 3 to 127 characters long, and can be any combination of ASCII printable characters (character codes 32-126), with the exception of spaces and the question mark.

This command changes the password for the highest privilege level (15). If you configure local command authorization, you can set enable passwords for each privilege level from 0 to 15 using the following syntax:

enable password password level number

The encrypted keyword (for passwords 32 characters and fewer) or the pbkdf2 keyword (for passwords longer than 32 characters) indicates that the password is encrypted (using an MD5-based hash or a PBKDF2 (Password-Based Key Derivation Function 2) hash using SHA-512). When you define a password in the enable password command, the ASA encrypts it when it saves it to the configuration for security purposes. When you enter the show running-config command, the enable password command does not show the actual password; it shows the encrypted password followed by the encrypted or pbkdf2 keyword. For example, if you enter the password “test,” the show running-config command output would appear as something similar to the following: 


username user1 password DLaUiAX3l78qgoB5c7iVNw== encrypted

The only time you would actually enter the encrypted or pbkdf2 keyword at the CLI is if you are cutting and pasting a configuration file for use in another ASA, and you are using the same password.

Enter the enable password command without a password to set the password to the default, which is blank.

Step 4

Set the login password for Telnet access. There is no default password.

The login password is used for Telnet access when you do not configure Telnet authentication. You also use this password when accessing the ASASM from the switch with the session command.

passwd password [encrypted]

Example:


ciscoasa(config)# passwd cisco12345

The password is a case-sensitive password of up to 16 alphanumeric and special characters. You can use any character in the password except a question mark or a space.

The password is saved in the configuration in encrypted form, so you cannot view the original password after you enter it. If for some reason you need to copy the password to another ASA but do not know the original password, you can enter the passwd command with the encrypted password and the encrypted keyword. Normally, you only see this keyword when you enter the show running-config passwd command.

Set the Date and Time


Note

Do not set the date and time for the ASASM or the Firepower 2100, 4100, or 9300; the ASA receives these settings from the chassis.

Set the Time Zone and Daylight Saving Dates

To set the time zone and daylight saving date range, perform the following steps.

Procedure

Step 1

Set the time zone. By default, the time zone is UTC.

  • clock timezone zone [-]hours [minutes]

    • zone —Specifies the time zone as a string, for example, PST for Pacific Standard Time.

    • [-]hours —Sets the number of hours of offset from UTC. For example, PST is -8 hours.

    • minutes —Sets the number of minutes of offset from UTC.

    Example:

    
ciscoasa(config)# clock timezone PST -8
Step 2

Enter one of the following commands to change the date range for daylight saving time from the default. The default recurring date range is from 2:00 a.m. on the second Sunday in March to 2:00 a.m. on the first Sunday in November.

  • Set the start and end dates for daylight saving time as a specific date in a specific year. If you use this command, you need to reset the dates every year.

    clock summer-time zone date {day month | month day } year hh:mm {day month | month day } year hh:mm [offset ]

    • zone —Specifies the time zone as a string, for example, PDT for Pacific Daylight Time.

    • day —Sets the day of the month, from 1 to 31. You can enter the day and month as April 1 or as 1 April, for example, depending on your standard date format.

    • month —Sets the month as a string. You can enter the day and month as April 1 or as 1 April, depending on your standard date format.

    • year —Sets the year using four digits, for example, 2004. The year range is 1993 to 2035.

    • hh:mm —Sets the hour and minutes in 24-hour time.

    • offset —Sets the number of minutes to change the time for daylight saving time. By default, the value is 60 minutes.

    Example: 

    
ciscoasa(config)# clock summer-time PDT 1 April 2010 2:00 60

  • Specify the start and end dates for daylight saving time, in the form of a day and time of the month, and not a specific date in a year. This command enables you to set a recurring date range that you do not need to change yearly.

    clock summer-time zone recurring [week weekday month hh:mm week weekday month hh:mm ] [offset ]

    • zone —Specifies the time zone as a string, for example, PDT for Pacific Daylight Time.

    • week —Specifies the week of the month as an integer between 1 and 4 or as the words first or last. For example, if the day might fall in the partial fifth week, then specify last.

    • weekday —Specifies the day of the week: Monday, Tuesday, Wednesday, and so on.

    • month —Sets the month as a string.

    • hh:mm —Sets the hour and minutes in 24-hour time.

    • offset —Sets the number of minutes to change the time for daylight savings time. By default, the value is 60 minutes.

    Example: 

    
ciscoasa(config)# clock summer-time PDT recurring first Monday April 2:00 60

Set the Date and Time Using an NTP Server

NTP is used to implement a hierarchical system of servers that provide a precisely synchronized time among network systems. This kind of accuracy is required for time-sensitive operations, such as validating CRLs, which include a precise time stamp. You can configure multiple NTP servers. The ASA chooses the server with the lowest stratum—a measure of how reliable the data is.

Time derived from an NTP server overrides any time set manually.

Before you begin

In multiple context mode, you can set the time in the system configuration only.

Procedure

Step 1

(Optional) Enable MD5 authentication with an NTP server.

  1. Enable authentication.

    ntp authenticate

    Example:

    
ciscoasa(config)# ntp authenticate

    When you enable NTP authentication, you must also specify a key ID in the ntp trusted-key command and associate that key with the server with the ntp server key command. Configure the actual key for the ID with the ntp authentication-key command. If you have multiple servers, configure a separate ID for each sever.

  2. Specify an authentication key ID to be a trusted key, which is required for authentication with an NTP server.

    ntp trusted-key key_id

    Example:

    
ciscoasa(config)# ntp trusted-key 1
ciscoasa(config)# ntp trusted-key 2
ciscoasa(config)# ntp trusted-key 3
ciscoasa(config)# ntp trusted-key 4

    The key_id argument is a value between 1 and 4294967295. You can enter multiple trusted keys for use with multiple servers.

  3. Set a key to authenticate with an NTP server.

    ntp authentication-key key_id md5 key

    Example:

    
ciscoasa(config)# ntp authentication-key 1 md5 aNiceKey1
ciscoasa(config)# ntp authentication-key 2 md5 aNiceKey2
ciscoasa(config)# ntp authentication-key 3 md5 aNiceKey3
ciscoasa(config)# ntp authentication-key 4 md5 aNiceKey4

    • key_id —Sets the ID that you set using the ntp trusted-key command.

    • md5 key —Sets the MD5 key as a string up to 32 characters long.

Step 2

Identify an NTP server.

ntp serveripv4_address [key key_id ] [source interface_name] [prefer ]

Example:


ciscoasa(config)# ntp server 10.1.1.1 key 1 prefer
ciscoasa(config)# ntp server 10.2.1.1 key 2

If you enabled NTP authentication (ntp authenticate ), you must specify the key key_id argument using the ID that you set using the ntp trusted-key command.

The source interface_name keyword-argument pair identifies the outgoing interface for NTP packets if you do not want to use the default interface in the routing table. Because the system does not include any interfaces in multiple context mode, specify an interface name defined in the admin context.

The prefer keyword sets this NTP server as the preferred server if multiple servers have similar accuracy. NTP uses an algorithm to determine which server is the most accurate and synchronizes to that one. If servers are of similar accuracy, then the prefer keyword specifies which of those servers to use. However, if a server is significantly more accurate than the preferred one, the ASA uses the more accurate one. For example, the ASA uses a server of stratum 2 over a server of stratum 3 that is preferred.

You can identify multiple servers; the ASA uses the most accurate server.

Set the Date and Time Manually

To set the date and time manually, perform the following steps:

Before you begin

In multiple context mode, you can set the time in the system configuration only.

Procedure

Set the date time manually.

clock set hh:mm:ss {month day | day month } year

Example:


ciscoasa# clock set 20:54:00 april 1 2004

The hh:mm:ss argument sets the hour, minutes, and seconds in 24-hour time. For example, enter 20:54:00 for 8:54 pm.

The day value sets the day of the month, from 1 to 31. You can enter the day and month as april 1 or as 1 april, for example, depending on your standard date format.

The month value sets the month. Depending on your standard date format, you can enter the day and month as april 1 or as 1 april.

The year value sets the year using four digits, for example, 2004. The year range is from 1993 to 2035.

The default time zone is UTC. If you change the time zone after you enter the clock set command using the clock timezone command, the time automatically adjusts to the new time zone.

This command sets the time in the hardware chip, and does not save the time in the configuration file. This time endures reboots. Unlike the other clock commands, this command is a privileged EXEC command. To reset the clock, you need to set a new time with the clock set command.

Configure the Master Passphrase

The master passphrase allows you to securely store plain text passwords in encrypted format and provides a key that is used to universally encrypt or mask all passwords, without changing any functionality. Features that use the master passphrase include the following:

  • OSPF

  • EIGRP

  • VPN load balancing

  • VPN (remote access and site-to-site)

  • Failover

  • AAA servers

  • Logging

  • Shared licenses

Add or Change the Master Passphrase

To add or change the master passphrase, perform the following steps.

Before you begin

  • This procedure will only be accepted in a secure session, for example by console, SSH, or ASDM via HTTPS.

  • If failover is enabled but no failover shared key is set, an error message appears if you change the master passphrase, informing you that you must enter a failover shared key to protect the master passphrase changes from being sent as plain text.

  • Enabling or changing password encryption in Active/Standby failover causes a write standby , which replicates the active configuration to the standby unit. Without this replication, the encrypted passwords on the standby unit will differ even though they use the same passphrase; configuration replication ensures that the configurations are the same. For Active/Active failover, you must manually enter write standby . A write standby can cause traffic interruption in Active/Active mode, because the configuration is cleared on the secondary unit before the new configuration is synced. You should make all contexts active on the primary ASA using the failover active group 1 and failover active group 2 commands, enter write standby , and then restore the group 2 contexts to the secondary unit using the no failover active group 2 command.

Procedure

Step 1

Set the passphrase used for generating the encryption key. The passphrase must be between 8 and 128 characters long. All characters except a backspace and double quotes are accepted for the passphrase. If you do not enter the new passphrase in the command, you are prompted for it. To change the passphrase, you must enter the old passphrase.

key config-key password-encryption [new_passphrase [old_passphrase]]

Example:


ciscoasa(config)# key config-key password-encryption
Old key: bumblebee
New key: haverford
Confirm key: haverford
Note 

Use the interactive prompts to enter passwords to avoid having the passwords logged in the command history buffer.

Use the no key config-key password-encrypt command with caution, because it changes the encrypted passwords into plain text passwords. You may use the no form of this command when downgrading to a software version that does not support password encryption.

Step 2

Enable password encryption.

password encryption aes

Example:


ciscoasa(config)# password encryption aes

As soon as password encryption is enabled and the master passphrase is available, all the user passwords will be encrypted. The running configuration will show the passwords in the encrypted format.

If the passphrase is not configured at the time that password encryption is enabled, the command will succeed in anticipation that the passphrase will be available in the future.

If you later disable password encryption using the no password encryption aes command, all existing encrypted passwords are left unchanged, and as long as the master passphrase exists, the encrypted passwords will be decrypted, as required by the application.

Step 3

Save the runtime value of the master passphrase and the resulting configuration.

write memory

Example:


ciscoasa(config)# write memory

If you do not enter this command, passwords in startup configuration may still be visible if they were not saved with encryption previously. In addition, in multiple context mode the master passphrase is changed in the system context configuration. As a result, the passwords in all contexts will be affected. If the write memory command is not entered in the system context mode, but not in all user contexts, then the encrypted passwords in user contexts may be stale. Alternatively, use the write memory all command in the system context to save all configurations.

Examples

The following example shows that no previous key was present: 


ciscoasa(config)# key config-key password-encryption 12345678

The following example shows that a key already exists: 


ciscoasa(config)# key config-key password-encryption 23456789
Old key: 12345678

In the following example, you enter the command without parameters so that you will be prompted for keys. Because a key already exists, you are prompted for it. 


ciscoasa(config)# key config-key password-encryption
Old key: 12345678
New key: 23456789
Confirm key: 23456789

In the following example, there is no existing key, so you are not prompted to supply it. 


ciscoasa(config)# key config-key password-encryption
New key: 12345678
Confirm key: 12345678

Disable the Master Passphrase

Disabling the master passphrase reverts encrypted passwords into plain text passwords. Removing the passphrase might be useful if you downgrade to a previous software version that does not support encrypted passwords.

Before you begin

  • You must know the current master passphrase to disable it. See Remove the Master Passphrase if you do not know the passphrase.

  • This procedure works only in a secure session; that is, by Telnet, SSH, or ASDM via HTTPS.

    To disable the master passphrase, perform the following steps:

Procedure

Step 1

Remove the master passphrase. If you do not enter the passphrase in the command, you are prompted for it.

no key config-key password-encryption [old_passphrase]]

Example:


ciscoasa(config)# no key config-key password-encryption

Warning! You have chosen to revert the encrypted passwords to plain text. 
This operation will expose passwords in the configuration and therefore 
exercise caution while viewing, storing, and copying configuration.

Old key: bumblebee
Step 2

Save the runtime value of the master passphrase and the resulting configuration.

write memory

Example:


ciscoasa(config)# write memory

The non-volatile memory containing the passphrase will be erased and overwritten with the 0xFF pattern.

In multiple mode, the master passphrase is changed in the system context configuration. As a result, the passwords in all contexts will be affected. If the write memory command is entered in the system context mode, but not in all user contexts, then the encrypted passwords in user contexts may be stale. Alternatively, use the write memory all command in the system context to save all configurations.

Remove the Master Passphrase

You cannot recover the master passphrase. If the master passphrase is lost or unknown, you can remove it.

To remove the master passphrase, perform the following steps:

Procedure

Step 1

Remove the master key and the configuration that includes the encrypted passwords.

write erase

Example:


ciscoasa(config)# write erase
Step 2

Reload the ASA with the startup configuration, without any master key or encrypted passwords.

reload

Example:


ciscoasa(config)# reload

Configure the DNS Server

You need to configure DNS servers so that the ASA can resolve host names to IP addresses. You also must configure DNS servers to use fully qualified domain names (FQDN) network objects in access rules.

Some ASA features require use of a DNS server to access external servers by domain name; for example, the Botnet Traffic Filter feature requires a DNS server to access the dynamic database server and to resolve entries in the static database. Other features, such as the ping or traceroute command, let you enter a name that you want to ping or traceroute, and the ASA can resolve the name by communicating with a DNS server. Many SSL VPN and certificate commands also support names.


Note

The ASA has limited support for using the DNS server, depending on the feature. For example, most commands require you to enter an IP address and can only use a name when you manually configure the name command to associate a name with an IP address and enable use of the names using the names command.

Before you begin

Make sure that you configure the appropriate routing and access rules for any interface on which you enable DNS domain lookup so you can reach the DNS server.

Procedure

Step 1

Enable the ASA to send DNS requests to a DNS server to perform a name lookup for supported commands.

dns domain-lookup interface_name

Example:


ciscoasa(config)# dns domain-lookup inside

If you do not enable DNS lookup on an interface, then the DNS server source interface or the interface found using the routing table cannot be used.

Step 2

Specify the DNS server group that the ASA uses for outgoing requests.

dns server-group DefaultDNS

Example:


ciscoasa(config)# dns server-group DefaultDNS

Other DNS server groups can be configured for VPN tunnel groups. See the tunnel-group command in the command reference for more information.

Step 3

Specify one or more DNS servers. You may enter all six IP addresses in the same command, separated by spaces, or you can enter each command separately. The ASA tries each DNS server in order until it receives a response.

name-server ip_address [ip_address2] [...] [ip_address6] [interface_name]

Example:


ciscoasa(config-dns-server-group)# name-server 10.1.1.5 192.168.1.67 209.165.201.6 dmz

(Optional) Specify the interface_name through which the ASA communicates with the server. If you do not specify the interface, the ASA checks the data routing table; if there are no matches, it then checks the management-only routing table.

Step 4

Configure the domain name appended to the hostname if it is not fully-qualified:

domain-name name

Example:


ciscoasa(config-dns-server-group)# domain-name example.com
Step 5

(Optional.) Configure additional properties of the DNS server group.

Use the following commands to change the characteristics of the group, if the default settings are not appropriate for your network.

  • timeout seconds —The number of seconds, from 1 to 30, to wait before trying the next DNS server. The default is 2 seconds. Each time the ASA retries the list of servers, this timeout doubles.

  • retries number —The number of times, from 0 to 10, to retry the list of DNS servers when the ASA does not receive a response.

  • expire-entry-timer minutes number —The number of minutes after a DNS entry expires (that is, the TTL has passed) that the entry is removed from the DNS lookup table. Removing an entry requires that the table be recompiled, so frequent removals can increase the processing load on the device. Because some DNS entries can have very short TTL (as short as three seconds), you can use this setting to virtually extend the TTL. The default is 1 minute (that is, the entry is removed one minute after the TTL has passed). The range is 1 to 65535 minutes. This option is used when resolving FQDN network objects only.

  • poll-timer minutes number —The time, in minutes, of the polling cycle used to resolve FQDN network/host objects to IP addresses. FQDN objects are resolved only if they are used in a firewall policy. The timer determines the maximum time between resolutions; the DNS entry's time-to-live (TTL) value is also used to determine when to update to IP address resolution, so individual FQDNs might be resolved more frequently than the polling cycle. The default is 240 (four hours). The range is 1 to 65535 minutes.

Configure the Hardware Bypass and Dual Power Supply (Cisco ISA 3000)

You can enable the hardware bypass so that traffic continues to flow between an interface pair during a power outage. Supported interface pairs are copper GigabitEthernet 1/1 & 1/2; and GigabitEthernet 1/3 & 1/4. When the hardware bypass is active, no firewall functions are in place, so make sure you understand the risks of allowing traffic through. See the following hardware bypass guidelines:

  • This feature is only available on the Cisco ISA 3000 appliance.

  • If you have a fiber Ethernet model, only the copper Ethernet pair (GigabitEthernet 1/1 & 1/2) supports hardware bypass.

  • When the ISA 3000 loses power and goes into hardware bypass mode, only the supported interface pairs can communicate; when using the default configuration, inside1 <---> inside2, and outside1 <---> outside2 can no longer communicate. Any existing connections between these interfaces will be lost.

  • We suggest that you disable TCP sequence randomization (as described in this procedure). If randomization is enabled (the default), then when the hardware bypass is activated, TCP sessions will need to be re-established. By default, the ISA 3000 rewrites the initial sequence number (ISN) of TCP connections passing through it to a random number. When the hardware bypass is activated, the ISA 3000 is no longer in the data path and does not translate the sequence numbers; the receiving client receives an unexpected sequence number and drops the connection. Even with TCP sequence randomization disabled, some TCP connections will have to be re-established because of the link that is temporarily down during the switchover.

  • Cisco TrustSec connections on hardware bypass interfaces are dropped when hardware bypass is activated. When the ISA 3000 powers on and hardware bypass is deactivated, the connections are renegotiated.

  • When the hardware bypass is deactivated, and traffic resumes going through the ISA 3000 data path, some existing TCP sessions need to be re-established because of the link that is temporarily down during the switchover.

  • When hardware bypass is active, the Ethernet PHYs are disconnected, so the ASA is unable to determine the interface status. Interfaces may appear to be in a down state.

For dual power supplies in the ISA 3000, you can establish dual power supplies as the expected configuration in the ASA OS. If one power supply fails, the ASA issues an alarm. By default, the ASA expects a single power supply and won't issue an alarm as long as it includes one working power supply.

Before you begin

  • You must attach the hardware bypass interfaces to access ports on the switch. Do not attach them to trunk ports.

Procedure

Step 1

Configure the hardware bypass to activate during a power failure:

hardware-bypass GigabitEthernet {1/1-1/2 | 1/3-1/4} [sticky]

Example:


ciscoasa(config)# hardware-bypass GigabitEthernet 1/1-1/2
ciscoasa(config)# hardware-bypass GigabitEthernet 1/3-1/4

The sticky keyword keeps the appliance in hardware bypass mode after the power comes back and the appliance boots up. In this case, you need to manually turn off the hardware bypass when you are ready; this option lets you control when the brief interruption in traffic occurs.

Step 2

Manually activate or deactivate the hardware bypass:

[no] hardware-bypass manual GigabitEthernet {1/1-1/2 | 1/3-1/4}

Example:


ciscoasa# hardware-bypass manual GigabitEthernet 1/1-1/2
ciscoasa# no hardware-bypass manual GigabitEthernet 1/1-1/2
Step 3

(Optional) Configure the hardware bypass to remain active until after the ASA FirePOWER module boots up:

hardware-bypass boot-delay module-up sfr

You must enable hardware bypass without the sticky option for the boot delay to operate. Without the hardware-bypass boot-delay command, the hardware bypass is likely to become inactive before the ASA FirePOWER module finishes booting up. This scenario can cause traffic to be dropped if you configured the module to fail-close, for example.

Step 4

Disable TCP sequence randomization. This example shows how to disable randomization for all traffic by adding the setting to the default configuration.

policy-map global_policy

class sfrclass

set connection random-sequence-number disable

If you later decide to turn it back on, replace "disable" with enable .

Step 5

Establish dual power supplies as the expected configuration:

power-supply dual

Step 6

Save the configuration.

write memory

The behavior of hardware bypass after the system comes online is determined by the configuration setting in the startup configuration, so you must save your running configuration.

Adjust ASP (Accelerated Security Path) Performance and Behavior

The ASP is an implementation layer that puts your policies and configurations into action. It is not of direct interest except during troubleshooting with the Cisco Technical Assistance Center. However, there are a few behaviors related to performance and reliability that you can adjust.

Choose a Rule Engine Transactional Commit Model

By default, when you change a rule-based policy (such as access rules), the changes become effective immediately. However, this immediacy comes with a slight cost in performance. The performance cost is more noticeable for very large rule lists in a high connections-per-second environment, for example, when you change a policy with 25,000 rules while the ASA is handling 18,000 connections per second.

The performance is affected because the rule engine compiles rules to enable faster rule lookup. By default, the system also searches uncompiled rules when evaluating a connection attempt so that new rules can be applied; because the rules are not compiled, the search takes longer.

You can change this behavior so that the rule engine uses a transactional model when implementing rule changes, continuing to use the old rules until the new rules are compiled and ready for use. With the transactional model, performance should not drop during the rule compilation. The following table clarifies the behavioral difference.

Model

Before Compilation

During Compilation

After Compilation

Default

Matches old rules.

Match new rules.

(The rate for connections per second decreases.)

Matches new rules.

Transactional

Matches old rules.

Match old rules.

(The rate for connections per second is unaffected.)

Matches new rules.

An additional benefit of the transactional model is that, when replacing an ACL on an interface, there is no gap between deleting the old ACL and applying the new one. This feature reduces the chances that acceptable connections may be dropped during the operation.


Tip

If you enable the transactional model for a rule type, syslogs to mark the beginning and the end of the compilation are generated. These syslogs are numbered 780001 through 780004.

Use the following procedure to enable the transactional commit model for the rule engine.

Procedure

Enable the transactional commit model for the rule engine:

asp rule-engine transactional-commit option

Where the options are:

  • access-group—Access rules applied globally or to interfaces.

  • nat—Network Address Translation rules.

Example:


ciscoasa(config)# asp rule-engine transactional-commit access-group

Enable ASP Load Balancing

The ASP load balancing mechanism helps avoid the following issues:

  • Overruns caused by sporadic traffic spikes on flows

  • Overruns caused by bulk flows oversubscribing specific interface receive rings

  • Overruns caused by relatively heavily overloaded interface receive rings, in which a single core cannot sustain the load.

ASP load balancing allows multiple cores to work simultaneously on packets that were received from a single interface receive ring. If the system drops packets, and the show cpu command output is far less than 100%, then this feature may help your throughput if the packets belong to many unrelated connections.

Procedure

Step 1

Enable the automatic switching on and off of ASP load balancing:

asp load-balance per-packet auto

The auto keyword is not available on the ASAv; you must manually enable or disable ASP load balancing.

Step 2

Manually enable ASP load balancing:

asp load-balance per-packet

ASP load balancing is enabled until you manually disable it, even if you also have the auto command enabled.

Step 3

Manually disable ASP load balancing:

no asp load-balance per-packet

This command only applies if you manually enabled ASP load blancing. If you also enabled the auto command, then the system reverts to automatically enabling or disabling ASP load balancing.

Monitoring the DNS Cache

The ASA provides a local cache of DNS information from external DNS queries that are sent for certain clientless SSL VPN and certificate commands. Each DNS translation request is first looked for in the local cache. If the local cache has the information, the resulting IP address is returned. If the local cache can not resolve the request, a DNS query is sent to the various DNS servers that have been configured. If an external DNS server resolves the request, the resulting IP address is stored in the local cache with its corresponding hostname.

See the following command for monitoring the DNS cache:

  • show dns-hosts

    This command shows the DNS cache, which includes dynamically learned entries from a DNS server as well as manually entered name and IP addresses using the name command.

History for Basic Settings

Feature Name

Platform Releases

Description

Dual power supply support for the ISA 3000

9.6(1)

For dual power supplies in the ISA 3000, you can establish dual power supplies as the expected configuration in the ASA OS. If one power supply fails, the ASA issues an alarm. By default, the ASA expects a single power supply and won't issue an alarm as long as it includes one working power supply.

We introduced the following command: power-supply dual

Longer password support for local username and enable passwords (up to 127 characters)

9.6(1)

You can now create local username and enable passwords up to 127 characters (the former limit was 32). When you create a password longer than 32 characters, it is stored in the configuration using a PBKDF2 (Password-Based Key Derivation Function 2) hash. Shorter passwords continue to use the MD5-based hashing method.

We modified the following commands: enable, username

ISA 3000 hardware bypass

9.4(1.225)

The ISA 3000 supports a hardware bypass function to allow traffic to continue flowing through the appliance when there is a loss of power.

We introduced the following commands: hardware-bypass, hardware-bypass manual, hardware-bypass boot-delay, show hardware-bypass

This feature is not available in Version 9.5(1).

Automatic ASP Load Balancing

9.3(2)

You can now enable automatic switching on and off of the ASP load balancing feature.

Note 

The automatic feature is not supported on the ASAv; only manual enabling and disabling is supported.

We introduced the following command: asp load-balance per-packet auto.

Removal of the default Telnet password

9.0(2)/9.1(2)

To improve security for management access to the ASA, the default login password for Telnet was removed; you must manually set the password before you can log in using Telnet.

Note 

The login password is only used for Telnet if you do not configure Telnet user authentication (the aaa authentication telnet console command).

Previously, when you cleared the password, the ASA restored the default of “cisco.” Now when you clear the password, the password is removed.

The login password is also used for Telnet sessions from the switch to the ASASM (see the session command). For initial ASASM access, you must use the service-module session command, until you set a login password.

We modified the following command: password

Password Encryption Visibility

8.4(1)

We modified the show password encryption command.

Master Passphrase

8.3(1)

We introduced this feature. The master passphrase allows you to securely store plain text passwords in encrypted format and provides a key that is used to universally encrypt or mask all passwords, without changing any functionality.

We introduced the following commands: key config-key password-encryption, password encryption aes, clear configure password encryption aes, show running-config password encryption aes, show password encryption