clf - crx

client (ctl-provider)

To specify clients allowed to connect to the Certificate Trust List provider, or to specify a username and password for client authentication, use the client command in ctl provider configuration mode. To remove the configuration, use the no form of this command.

client { [ interface if_name ] ipv4_addr | username user_name password password [ encrypted ] }

no client { [ interface if_name ] ipv4_addr | username user_name password password [ encrypted ] }

Syntax Description

encrypted

Specifies encryption for the password.

interface if_name

Specifies the interface allowed to connect.

ipv4_addr

Specifies the IP address of the client.

password password

Specifies the password for client authentication.

username user_name

Specifies the username for client authentication.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl provider configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

8.0(2)

This command was added.

Usage Guidelines

Use the client command in ctl provider configuration mode to specify the clients allowed to connect to the CTL provider, and to set the username and password for client authentication. More than one command may be issued to define multiple clients. The username and password must match the CCM Administrator's username and password for the CallManager cluster.

Examples

The following example shows how to create a CTL provider instance:


ciscoasa(config)# ctl-provider my_ctl
 
ciscoasa(config-ctl-provider)# client interface inside 172.23.45.1
 
ciscoasa(config-ctl-provider)# client username CCMAdministrator password XXXXXX encrypted
 
ciscoasa(config-ctl-provider)# export certificate ccm_proxy
 
ciscoasa(config-ctl-provider)# ctl install

client (tls-proxy)

To configure trustpoints, keypairs, and cipher suites for a TLS proxy, use the client command in tls proxy configuration mode. To remove the configuration, use the no form of this command.

client { cipher-suite cipher_list | ldc { issuer ca_tp_name | key-pair key_label } | trust-point proxy_trustpoint | clear-text }

no client { cipher-suite cipher_list | ldc { issuer ca_tp_name | key-pair key_label } | trust-point proxy_trustpoint | clear-text }

Syntax Description

cipher-suite cipher_list

Specifies the cipher suite. To see the available options for your platform, enter ? for the cipher list.

clear-text

Specifies that communication between the ASA and the TLS server should be in clear text (not encrypted).

ldc issuer ca_tp_name

Specifies the local CA trustpoint to issue client local dynamic certificates.

ldc keypair key_label

Specifies the RSA keypair to be used by client local dynamic certificates.

trust-point proxy_trustpoint

Specifies a trustpoint that uses a static certificate as opposed to issuing local dynamic certificates.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Tls proxy configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

8.0(2)

This command was added.

8.0(4)

The trust-point keyword was added.

9.6(1)

The clear-text keyword was added.

Usage Guidelines

TLS proxy is used by some protocol inspection engines to decrypt encrypted traffic so that it can be inspected. After inspection, the proxy re-encrypts the traffic and sends it to the destination.

Use the client command in tls proxy configuration mode to control the TLS handshake parameters for the ASA when it acts in the TLS client role in TLS proxy.

You have the following options for the client trustpoint:

  • Use the client ldc commands to identify a local dynamic certificate issuer. Use this option when you need unique certificates per client. For example, for Cisco IP phones in SIP/SCCP inspection. Use the ldc issuer command to identify the local CA that issues client dynamic certificates (defined by the crypto ca trustpoint command). The trustpoint must have the proxy-ldc-issuer command configured, or be the default local CA server (LOCAL-CA-SERVER).

Use the ldc key-pair command to identify the keypair generated with the crypto key generate command.

  • Use the client trust-point command to identify a trustpoint that uses a static certificate. For example, for Cisco Unified Presence Server (CUPS) in SIP/SCCP inspection, The certificate must be owned by the ASA (identity certificate). The certificate can be self-signed, enrolled with a certificate authority, or from an imported credential.

  • Use the client clear-text command to use unencrypted communication with the TLS server. You can use this option if the ASA and TLS server are in the same data center and you can be certain the communication is secure. This configuration is intended for Diameter inspection.

You can also set a different cipher suite for the TLS proxy using client cipher-suite . If you do not define the ciphers the TLS proxy can use, the proxy uses the cipher suite defined by the ssl encryption command. If that command is not defined, all available ciphers are used. Specify this command only if you want to use a different suite than the one generally available on the ASA. You can use this command to achieve different ciphers between the two TLS sessions. You should use AES ciphers with the CallManager server.

Examples

The following example shows how to create a TLS proxy using a local dynamic certificate issuer:


ciscoasa(config)# tls-proxy my_proxy
ciscoasa(config-tlsp)# server trust-point ccm_proxy
ciscoasa(config-tlsp)# client ldc issuer ldc_server
ciscoasa(config-tlsp)# client ldc keypair phone_common

The following example shows how to create a TLS proxy using a trustpoint with a static certificate.


ciscoasa(config)# tls-proxy my_proxy
ciscoasa(config-tlsp)# server trust-point ccm_proxy
ciscoasa(config-tlsp)# client trust-point ent_y_proxy

The following example shows how to create a TLS proxy for Diameter inspection that uses clear text communication between the ASA and Diameter server.


ciscoasa(config)# tls-proxy diameter-tls-offload-proxy
 
ciscoasa(config-tlsp)# server trust-point tls-proxy-server-tp
 
ciscoasa(config-tlsp)# client clear-text

client-access-rule

To configure rules that limit the remote access client types and versions that can connect via IPsec through the ASA, use the client-access-rule command in group-policy configuration mode. To delete a rule, use the no form of this command.

client-access-rule e priority { permit | deny } type type version version | none

no client-access-rule e priority [ { permit | deny } type type version version ]

Syntax Description

deny

Denies connections for devices of a particular type and/or version.

none

Allows no client access rules. Sets client-access-rule to a null value, thereby allowing no restriction. Prevents inheriting a value from a default or specified group policy.

permit

Permits connections for devices of a particular type and/or version.

priority

Determines the priority of the rule. The rule with the lowest integer has the highest priority. Therefore, the rule with the lowest integer that matches a client type and/or version is the rule that applies. If a lower priority rule contradicts, the ASA ignores it.

type type

Identifies device types via free-form strings, for example VPN 3002. A string must match exactly its appearance in the show vpn-sessiondb remote command output, except that you can use the * character as a wildcard.

version version

Identifies the device version via free-form strings, for example 7.0. A string must match exactly its appearance in the show vpn-sessiondb remote command output, except that you can use the * character as a wildcard.

Command Default

By default, there are no access rules.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group-policy configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

To delete all rules, use the no client-access-rule command with only the priority argument. This deletes all configured rules, including a null rule created by issuing the client-access-rule none command.

When there are no client access rules, users inherit any rules that exist in the default group policy. To prevent users from inheriting client access rules, use the client-access-rule none command. The result of doing so is that all client types and versions can connect.

Construct rules according to these caveats:

  • If you do not define any rules, the ASA permits all connection types.

  • When a client matches none of the rules, the ASA denies the connection. This means that if you define a deny rule, you must also define at least one permit rule, or the ASA denies all connections.

  • For both software and hardware clients, type and version must match exactly their appearance in the show vpn-sessiondb remote command output.

  • The * character is a wildcard, which you can use multiple times in each rule. For example, client-access-rul e 3 deny type * version 3.* creates a priority 3 client access rule that denies all client types running release versions 3.x software.

  • You can construct a maximum of 25 rules per group policy.

  • There is a limit of 255 characters for an entire set of rules.

  • You can use n/a for clients that do not send client type and/or version.

Examples

The following example shows how to create client access rules for the group policy named FirstGroup. These rules permit VPN Clients running software version 4.1, while denying all VPN 3002 hardware clients:


ciscoasa(config)# group-policy FirstGroup attributes
ciscoasa(config-group-policy)# client-access-rule 1 d t VPN3002 v *
ciscoasa(config-group-policy)# client-access-rule 2 p * v 4.1

client-bypass-protocol

To configure how the ASA manages IPv4 traffic when it is expecting only IPv6 traffic or how it manages IPv6 traffic when it is expecting only IPv4 traffic, use the client-bypass-protocol command in group-policy configuration mode. To clear the client bypass protocol setting, use the no form of this command.

client-bypass-protocol { enable | disable }

no client-bypass-protocol { enable | disable }

Syntax Description

enable

If Client Bypass Protocol is enabled, the IP traffic for which the ASA did not assign an IP address type is sent from the client in the clear through the client's normal, non-VPN gateway.

disable

If Client Bypass Protocol is disabled, the IPv6 traffic for which the ASA did not assign an IP address type is dropped.

Command Default

Client Bypass Protocol is disabled by default in the DfltGrpPolicy.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group-policy configuration

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

The Client Bypass Protocol feature allows you to configure how the ASA manages IPv4 traffic when it is expecting only IPv6 traffic or how it manages IPv6 traffic when it is expecting only IPv4 traffic.

When the Secure Client makes a VPN connection to the ASA, the ASA could assign it an IPv4, IPv6, or both an IPv4 and IPv6 address. If the ASA assigns the Secure Client connection only an IPv4 address or only an IPv6 address, you can now configure the Client Bypass Protocol to drop network traffic for which the ASA did not assign an IP address, or allow that traffic to bypass the ASA and be sent from the client unencrypted or “in the clear.”

For example, assume that the ASA assigns only an IPv4 address to an Secure Client connection and the endpoint is dual stacked. When the endpoint attempts to reach an IPv6 address, if Client Bypass Protocol is disabled, the IPv6 traffic is dropped; however, if Client Bypass Protocol is enabled, the IPv6 traffic is sent from the client in the clear.

Examples

The following example enables client bypass protocol:


hostname(config-group-policy)# client-bypass-protocol enable
hostname(config-group-policy)# 

The following example disables client bypass protocol:


hostname(config-group-policy)# client-bypass-protocol disable
hostname(config-group-policy)# 

The following example clears the client bypass protocol setting:


hostname(config-group-policy)# no client-bypass-protocol enable
hostname(config-group-policy)# 

client-firewall

To set personal firewall policies that the ASA pushes to the VPN client during IKE tunnel negotiation, use the client-firewall command in group-policy configuration mode. To delete a firewall policy, use the no form of this command.

client-firewall none

no client-firewall { opt req } custom vendor-id num product-id num policy { AYT | CPP acl-in acl acl-out acl ] [ description string ]

client-firewall { opt | req } zonelabs-integrity


Note


When the firewall type is zonelabs-integrity , do not include arguments. The Zone Labs Integrity Server determines the policies.

client-firewall { opt | req } zonelabs-zonealarm policy { AYT | CPP acl-in acl acl-out acl }

client-firewall { opt | req } zonelabs-zonealarmorpro policy { AYT | CPP acl-in acl acl-out acl }

client-firewall { opt | req } zonelabs-zonealarmpro policy { AYT | CPP acl-in acl acl-out acl }

client-firewall { opt | req } cisco-integrated acl-in acl acl-out acl }

client-firewall { opt | req } sygate-personal

client-firewall { opt | req } sygate-personal-pro

client-firewall { opt | req } sygate-personal-agent

client-firewall { opt | req } networkice-blackice

client-firewall { opt | req } cisco-security-agent

Syntax Description

acl-in acl

Provides the policy the client uses for inbound traffic.

acl-out acl

Provides the policy the client uses for outbound traffic.

AYT

Specifies that the client PC firewall application controls the firewall policy. The ASA checks to make sure the firewall is running. It asks, “Are You There?” If there is no response, the ASA tears down the tunnel.

cisco-integrated

Specifies the Cisco Integrated firewall type.

cisco-security-agent

Specifies the Cisco Intrusion Prevention Security Agent firewall type.

CPP

Specifies Policy Pushed as source of the VPN Client firewall policy.

custom

Specifies the Custom firewall type.

description string

Describes the firewall.

networkice-blackice

Specifies the Network ICE Black ICE firewall type.

none

Indicates that there is no client firewall policy. Sets a firewall policy with a null value, thereby disallowing one. Prevents inheriting a firewall policy from a default or specified group policy.

opt

Indicates an optional firewall type.

product-id

Identifies the firewall product.

req

Indicates a required firewall type.

sygate-personal

Specifies the Sygate Personal firewall type.

sygate-personal-pro

Specifies the Sygate Personal Pro firewall type.

sygate-security-agent

Specifies the Sygate Security Agent firewall type.

vendor-id

Identifies the firewall vendor.

zonelabs-integrity

Specifies the Zone Labs Integrity Server firewall type.

zonelabs-zonealarm

Specifies the Zone Labs Zone Alarm firewall type.

zonelabs-zonealarmorpro policy

Specifies the Zone Labs Zone Alarm or Pro firewall type.

zonelabs-zonealarmpro policy

Specifies the Zone Labs Zone Alarm Pro firewall type.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Group policy configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

7.2(1)

The zonelabs-integrity firewall type was added.

Usage Guidelines

Only one instance of this command can be configured.

To delete all firewall policies, use the no client-firewall command without arguments. This command deletes all configured firewall policies, including a null policy created by issuing the client-firewall none command.

When there are no firewall policies, users inherit any that exist in the default or other group policy. To prevent users from inheriting such firewall policies, use the client-firewall none command.

Examples

The following example shows how to set a client firewall policy that requires Cisco Intrusion Prevention Security Agent for the group policy named FirstGroup:


ciscoasa(config)# group-policy FirstGroup attributes
ciscoasa(config-group-policy)# client-firewall
             req cisco-security-agent
         

client-types (crypto ca trustpoint)

To specify the client connection types for which this trustpoint can be used to validate the certificates associated with a user connection, use the client-types command in crypto ca trustpoint configuration mode.

[ no ] client-types { ssl | ipsec }

Syntax Description

ipsec

Specifies that the Certificate Authority (CA) certificate and policy associated with the trustpoint can be used to validate IPsec connections.

ssl

Specifies that the Certificate Authority (CA) certificate and policy associated with the trustpoint can be used to validate SSL connections.

Command Default

No default value or behavior.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Crypto ca trustpoint configuration

Command History

Release

Modification

8.0(2)

This command was added.

9.0(1)

Support for multiple context mode was added.

Usage Guidelines

When there are multiple trustpoints associated with the same CA certificate, only one of the trustpoints can be configured for a specific client type. However one of the trustpoints can be configured for one client type and the other trustpoint with another client-type.

If there is a trustpoint associated with the same CA certificate that is already configured with a client type, the new trustpoint is not allowed to be configured with the same client-type setting. The no form of the command clears the setting so that trustpoint cannot be used for any client validation.

Remote-access VPNs can use Secure Sockets Layer (SSL) VPN, IP Security (IPsec), or both, depending on deployment requirements, to permit access to virtually any network application or resource.

Examples

The following example enters crypto ca trustpoint configuration mode for trustpoint, central, and designates it an SSL trustpoint:


hostname(config)# crypto ca trustpoint central
hostname(config-ca-trustpoint)# client-types ssl
hostname(config-ca-trustpoint)#

The following example enters crypto ca trustpoint configuration mode for trustpoint, checkin 1, and designated it as an IPsec trustpoint.


hostname(config)# crypto ca trustpoint checkin1
hostname(config-ca-trustpoint)# client-types ipsec
hostname(config-ca-trustpoint)#

client-update

To issue a client-update for all active remote VPN software and hardware clients and ASAs configured as Auto Update clients, on all tunnel-groups or for a particular tunnel group, use the client-update command in privileged EXEC mode.

To configure and change client-update parameters at the global level, including VPN software and hardware clients and ASAs configured as Auto Update clients, use the client-update command in global configuration mode.

To configure and change client-update tunnel-group IPsec-attributes parameters for VPN software and hardware clients, use the client-update command in tunnel-group ipsec-attributes configuration mode.

To disable a client update, use the no form of this command.

Global configuration mode command:

client-update { enable | component { asdm | image } | device_id dev_string | family family_name | type type } url url-string rev-nums rev-nums }

no client-update { enable | component { asdm | image } | device_id dev_string | family family_name | type type } url url-string rev-nums rev-nums }

Tunnel-group ipsec-attributes configuration mode command:

client-update type type url url-string rev-nums rev-nums

no client-update type type url url-string rev-nums rev-nums

Privileged EXEC mode command:

client-update { all | tunnel-group }

no client-update tunnel-group

Syntax Description

all

(Available only in privileged EXEC mode.) Applies the action to all active remote clients in all tunnel groups. You cannot use the keyword all with the no form of the command.

component {asdm | image }

The software component for ASAs configured as Auto Update clients.

device-id dev_string

If the Auto Update client is configured to identify itself with a unique string, specify the same string that the client uses. The maximum length is 63 characters.

enable

(Available only in global configuration mode). Enables remote client software updates.

family family_name

If the Auto Update client is configured to identify itself by device family, specify the same device family that the client uses. It can be asa, pix, or a text string with a maximum length of 7 characters.

rev-nums rev-nums

(Not available in privileged EXEC mode.) Specifies the software or firmware images for this client. For Windows, WIN9X, WinNT, and VPN3002 clients, enter up to 4, in any order, separated by commas. For ASAs, only one is allowed. The maximum length of the string is 127 characters.

tunnel-group

(Available only in privileged EXEC mode.) Specifies the name of a valid tunnel-group for remote client update.

type type

(Not available in privileged EXEC mode.) Specifies the operating systems of remote PCs or the type of ASAs (configured as Auto Update clients) to notify of a client update. The list is the following:

  • asa5505: Cisco 5505 Adaptive Security Appliance

  • asa5510: Cisco 5510 Adaptive Security Appliance

  • asa5520: Cisco 5520 Adaptive Security Appliance

  • asa5540: Cisco 5540 Adaptive Security Appliance

  • linux: A Linux client

  • mac: MAC OS X client

  • pix-515: Cisco PIX 515 Firewall

  • pix-515e: Cisco PIX 515E Firewall

  • pix-525: Cisco PIX 525 Firewall

  • pix-535: Cisco PIX 535 Firewall

  • Windows: all windows-based platforms

  • WIN9X: Windows 95, Windows 98, and Windows ME platforms

  • WinNT: Windows NT 4.0, Windows 2000, and Windows XP platforms

  • vpn3002: VPN 3002 hardware client

  • A text string of up to 15 characters

url url-string

(Not available in privileged EXEC mode.) Specifies the URL for the software/firmware image. This URL must point to a file appropriate for this client. The maximum string length is 255 characters.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Privileged EXEC

  • Yes

  • Yes

Global configuration

  • Yes

  • Yes

Tunnel-group ipsec-attributes configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

7.1(1)

The tunnel-group ipsec-attributes configuration mode was added.

7.2(1)

The component , device-id , and family keywords and their arguments were added to support the ASA configured as an Auto Update Server.

9.0(1)

Support for multiple context mode was added.

Usage Guidelines

In tunnel-group ipsec-attributes configuration mode, you can apply this attribute only to the IPsec remote-access tunnel-group type.

The client-update command lets you enable the update; specify the types and revision numbers of clients to which the update applies; provide a URL or IP address from which to get the update; and, in the case of Windows clients, optionally notify users that they should update their VPN client version. If the client is already running a software version on the list of revision numbers, it does not need to update its software. If the client is not running a software version on the list, it should update.

For Windows clients, you can provide a mechanism for users to accomplish that update. For VPN 3002 hardware client users, the update occurs automatically, with no notification. When the client type is another ASA, this ASA acts as an Auto Update server.


Note


For all Windows clients and Auto Update clients, you must use the protocol “http://” or “https://” as the prefix for the URL. For the VPN 3002 hardware client, you must specify protocol “tftp://” instead.

Alternatively, for Windows clients and VPN 3002 hardware clients, you can configure client update just for individual tunnel-groups, rather than for all clients of a particular type.


Note


You can have the browser automatically start an application by including the application name at the end of the URL; for example: https://support/updates/vpnclient.exe.

After you have enabled client update, you can define a set of client-update parameters for a particular IPsec- remote access tunnel group. To do this, in tunnel-group ipsec-attributes mode, specify the tunnel-group name and its type, and the URL or IP address from which to get the updated image. In addition, you must specify a revision number. If the user client revision number matches one of the specified revision numbers, there is no need to update the client; for example, to issue a client update for all Windows clients.

Optionally, you can send a notice to active users with outdated Windows clients that their VPN client needs updating. For these users, a dialog box appears, offering the opportunity to launch a browser and download the updated software from the site specified in the URL. The only part of this message that you can configure is the URL. Users who are not active get a notification message the next time they log in. You can send this notice to all active clients on all tunnel groups, or you can send it to clients on a particular tunnel group.

If the user client revision number matches one of the specified revision numbers, there is no need to update the client, and users receive no notification message. VPN 3002 clients update without user intervention, and users receive no notification message.


Note


If you specify the client-update type as windows (specifying all Windows-based platforms) and later want to enter a client-update type of win9x or winnt for the same entity, you must first remove the windows client type with the no form of the command, then use new client-update commands to specify the new client types.

Examples

The following example, entered in global configuration mode, enables client update for all active remote clients on all tunnel groups:


ciscoasa(config)# client-update enable
ciscoasa# 

The following example applies only to Windows (Win9x, WinNT). Entered in global configuration mode, it configures client update parameters for all Windows-based clients, including the revision number, 4.7 and the URL for retrieving the update, https://support/updates.


ciscoasa(config)# client-update type windows url https://support/updates/ rev-nums 4.7
ciscoasa(config)# 

The following example applies only to VPN 3002 hardware clients. Entered in tunnel-group ipsec-attributes configuration mode, it configures client update parameters for the IPsec remote-access tunnel-group “salesgrp”. It designates the revision number, 4.7 and uses the TFTP protocol for retrieving the updated software from the site with the IP address 192.168.1.1:


ciscoasa(config)# tunnel-group salesgrp type ipsec-ra
ciscoasa(config)# tunnel-group salesgrp ipsec-attributes
ciscoasa(config-tunnel-ipsec)# client-update type vpn3002 
url tftp:192.168.1.1 rev-nums 4.7
ciscoasa(config-tunnel-ipsec)# 

The following example shows how to issue a client update for clients that are Cisco 5520 ASAs configured as Auto Update clients:


ciscoasa(config)# client-update type asa5520 component asdm url
http://192.168.1.114/aus/asdm501.bin rev-nums 7.2(1)

The following example, entered in privileged EXEC mode, sends a client-update notification to all connected remote clients in the tunnel group named “remotegrp” that need to update their client software. Clients in other groups do not get an update notification.


ciscoasa# client-update remotegrp
ciscoasa# 
The following example, entered in privileged EXEC mode, notifies all active clients on all tunnel groups:
ciscoasa# client-update all
ciscoasa# 

clock set

To manually set the clock on the ASA, use the clock set command in privileged EXEC mode.

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

Syntax Description

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.

hh : mm : ss

Sets the hour, minutes, and seconds in 24-hour time. For example, set 20:54:00 for 8:54 pm.

month

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

year

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

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Privileged EXEC

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

If you have not entered any clock configuration commands, the default time zone for the clock set command 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. However, if you enter the clock set command after you establish the time zone with the clock timezone command, then enter the time appropriate for the new time zone and not for UTC. Similarly, if you enter the clock summer-time command after the clock set command, the time adjusts for daylight saving. If you enter the clock set command after the clock summer-time command, enter the correct time for daylight saving.

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 for the clock set command.

Examples

The following example sets the time zone to MST, the daylight saving time to the default period in the U.S., and the current time for MDT to 1:15 p.m. on July 27, 2004:


ciscoasa(config)# clock timezone MST -7
ciscoasa(config)# clock summer-time MDT recurring
ciscoasa(config)# exit
ciscoasa# clock set 13:15:0 jul 27 2004
ciscoasa# show clock
13:15:00.652 MDT Tue Jul 27 2004

The following example sets the clock to 8:15 on July 27, 2004 in the UTC time zone, and then sets the time zone to MST and the daylight saving time to the default period in the U.S. The end time (1:15 in MDT) is the same as the previous example.


ciscoasa# clock set 20:15:0 jul 27 2004
ciscoasa# configure terminal
ciscoasa(config)# clock timezone MST -7
ciscoasa(config)# clock summer-time MDT recurring
ciscoasa# show clock
13:15:00.652 MDT Tue Jul 27 2004

clock summer-time

To set the date range for daylight saving time for the display of the ASA time, use the clock summer-time command in global configuration mode. To disable the daylight saving time dates, use the no form of this command.

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

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

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

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


Note


This command is not supported on the Firepower 1000 or Firepower 2100 in Appliance mode.

Syntax Description

date

Specifies the start and end dates for daylight saving time as a specific date in a specific year. If you use this keyword, you need to reset the dates each year.

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.

hh:mm

Sets the hour and minutes in 24-hour time.

month

Sets the month as a string. For the date command, you can enter the day and month as April 1 or as 1 April , for example, depending on your standard date format.

offset

(Optional) Sets the number of minutes to change the time for daylight saving time. By default, the value is 60 minutes.

recurring

Specifies 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 keyword lets you set a recurring date range that you do not need to alter yearly. If you do not specify any dates, the ASA uses the default date range for the United States: from 2:00 a.m. on the second Sunday in March to 2:00 a.m. on the first Sunday in November.

week

(Optional) 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

(Optional) Specifies the day of the week: Monday , Tuesday , Wednesday , and so on.

year

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

zone

Specifies the time zone as a string, for example, PDT for Pacific Daylight Time. When the ASA shows the daylight saving time according to the date range you set with this command, the time zone changes to the value you set here. See the clock timezone command to set the base time zone to a zone other than UTC.

Command Default

The default offset is 60 minutes.

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.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

8.0(2)

The default recurring date range was changed to 2:00 a.m. on the second Sunday in March to 2:00 a.m. on the first Sunday in November.

Usage Guidelines

For the Southern Hemisphere, the ASA accepts the start month to be later in the year than the end month, for example, from October to March.

Examples

The following example sets the daylight saving date range for Australia:


ciscoasa(config)# clock summer-time PDT recurring last Sunday October 2:00 last Sunday March 2:00

Some countries start daylight saving on a specific date. In the following example, daylight saving time is configured to start on April 1, 2008, at 3 a.m. and end on October 1, 2008, at 4 a.m.


ciscoasa(config)# clock summer-time UTC date 1 April 2008 3:00 1 October 2008 4:00

clock timezone

To set the time zone for the ASA clock, use the clock timezone command in global configuration mode. To set the time zone back to the default of UTC, use the no form of this command.

For Firepower 1000 and 2100 in Appliance mode:

clock timezone zone

no clock timezone [ zone ]

For all other models:

clock timezone zone [ - ] hours [ minutes ]

no clock timezone [ zone [ - ] hours [ minutes ] ]

Syntax Description

[- ]hours

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

minutes

(Optional) Sets the number of minutes of offset from UTC.

zone

Specifies the time zone as a string, for example, PST for Pacific Standard Time. For the Firepower 1000 and 2100 in Appliance mode, Enter the clock timezone ? command to see a list of acceptable time zone names.

Command Default

The default time zone is UTC.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

9.13(1)

This command was updated for the Firepower 1000 and 2100 in Appliance mode.

Usage Guidelines

To set daylight saving time, see the clock summer-time command (not supported for the Firepower 1000 or 2100).

The clock set command or the time derived from an NTP server sets the time in UTC. You must set the time zone as an offset of UTC using this command.

Examples

For the Firepower 1000 and 2100 in Appliance mode, the following example sets the time zone to Mountain Standard Time:


ciscoasa(config)# clock timezone ?
Available timezones:
CET
CST6CDT
Cuba
EET
Egypt
Eire
EST
EST5EDT
Factory
GB
GB-Eire
GMT
GMT0
GMT-0
GMT+0
Greenwich
Hongkong
HST
Iceland
Iran
Israel
Jamaica
Japan
[...]
ciscoasa(config)# clock timezone US/?
 
configure mode commands/options:
  US/Alaska          US/Aleutian    US/Arizona    US/Central
  US/East-Indiana    US/Eastern     US/Hawaii     US/Indiana-Starke
  US/Michigan        US/Mountain    US/Pacific 
ciscoasa(config)# clock timezone US/Mountain

The following example sets the time zone to Pacific Standard Time, which is -8 hours from UTC:


ciscoasa(config)# clock timezone PST -8

clu-keepalive-interval

To set the keepalive interval for flow state refresh messages (clu_keepalive and clu_update messages) from the flow owner to the director and backup owner, use the clu-keepalive-interval command in cluster group configuration mode. To use the default setting, use the no form of this command.

clu-keepalive-interval seconds

no clu-keepalive-interval

Syntax Description

seconds

15 to 55. The default is 15.

Command Default

The default is 15 seconds.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Cluster group configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.20(1)

This command was added.

Usage Guidelines

The flow owner sends keepalives (clu_keepalive messages) and updates (clu_update messages) to the director and backup owner to refresh the flow state. You can now set the keepalive interval. The default is 15 seconds, and you can set the interval between 15 and 55 seconds. You may want to set the interval to be longer to reduce the amount of traffic on the cluster control link.

This command is not part of the bootstrap configuration, and is replicated from the control node to the data nodes.

Examples

The following example sets the keepalive interval to 30 seconds:


ciscoasa(config)# cluster group cluster1
ciscoasa(cfg-cluster)# clu-keepalive-interval 30

cluster-ctl-file (Deprecated)

To use trustpoints that are already created from an existing CTL file stored in flash memory, use the cluster-ctl-file command in ctl file configuration mode. To remove the CTL file configuration so that you can create a new CTL file, use the no form of this command.

cluster-ctl-filefilename_path

no cluster-ctl-file filename_path

Syntax Description

filename_path

Specifies the path and filename of the CTL file stored on disk or stored in flash memory.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl-file configuration

  • Yes

  • Yes

Command History

Release

Modification

8.0(4)

The command was added.

9.4(1)

This command was deprecated along with all phone-proxy mode commands.

Usage Guidelines

When this command is configured, the Phone Proxy parses the CTL file stored in flash memory and installs the trustpoints from that CTL file, then uses that file from flash in the creation of the new CTL file.

Examples

The following example parses the CTL file stored in flash memory to install the trustpoints from that file:


ciscoasa(config-ctl-file)# cluster-ctl-file disk0:/old_ctlfile.tlv

cluster encryption

To enable encryption for messages exchanged on the virtual load-balancing cluster, use the cluster encryption command in vpn load-balancing configuration mode. To disable encryption, use the no form of this command.

clusterencryption

noclusterencryption


Note


VPN load balancing requires an active 3DES/AES license. The ASA checks for the existence of this crypto license before enabling load balancing. If it does not detect an active 3DES or AES license, the ASA prevents the enabling of load balancing and prevents internal configuration of 3DES by the load balancing system, unless the license permits this usage.

Syntax Description

This command has no arguments or keywords.

Command Default

Encryption is disabled by default.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Vpn load-balancing configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

This command turns encryption on or off for messages exchanged on the virtual load-balancing cluster.

Before configuring the cluster encryption command, you must have first used the vpn load-balancing command to enter vpn load-balancing configuration mode. You must also use the cluster key command to configure the cluster shared secret key before enabling cluster encryption.


Note


When using encryption, you must first configure the command isakmp enable inside , where inside designates the load-balancing inside interface. If ISAKMP is not enabled on the load-balancing inside interface, an error message appears when you try to configure cluster encryption.

Examples

The following is an example of a VPN load-balancing command sequence that includes a cluster encryption command to enable encryption for the virtual load-balancing cluster:


ciscoasa(config)# interface GigabitEthernet 0/1
ciscoasa(config-if)# ip address 209.165.202.159 255.255.255.0
ciscoasa(config)# nameif test
ciscoasa(config)# interface GigabitEthernet 0/2
ciscoasa(config-if)# ip address 209.165.201.30 255.255.255.0
ciscoasa(config)# nameif foo
ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic test
ciscoasa(config-load-balancing)# interface lbprivate foo
ciscoasa(config-load-balancing)# cluster ip address 209.165.202.224
ciscoasa(config-load-balancing)# cluster key 123456789
ciscoasa(config-load-balancing)# cluster encryption
ciscoasa(config-load-balancing)# participate

cluster exec

To execute a command on all units in the cluster, or on a specific member, use the cluster exec command in privileged EXEC mode.

cluster exec [ unit unit_name ] command

Syntax Description

unit unit_name

(Optional) Performs the command on a specific unit. To view member names, enter cluster exec unit ? (to see all names except the current unit), or enter the show cluster info command.

command

Specifies the command you want to execute.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

Sending a show command to all members collects all output and displays it on the console of the current unit. Other commands, such as capture and copy , can also take advantage of cluster-wide execution.

Examples

To copy the same capture file from all units in the cluster at the same time to a TFTP server, enter the following command on the master unit:


ciscoasa# cluster exec copy /pcap capture: tftp://10.1.1.56/capture1.pcap

Multiple PCAP files, one from each unit, are copied to the TFTP server. The destination capture file name is automatically attached with the unit name, such as capture1_asa1.pcap, capture1_asa2.pcap, and so on. In this example, asa1 and asa2 are cluster unit names.

The following sample output for the cluster exec show port-channel summary command shows EtherChannel information for each member in the cluster:


ciscoasa# cluster exec show port-channel summary
primary(LOCAL):***********************************************************
 Number of channel-groups in use: 2
Group  Port-channel  Protocol  Span-cluster  Ports
------+-------------+-----------+-----------------------------------------------
1         Po1              LACP      	Yes  Gi0/0(P)
2         Po2              LACP      	Yes  Gi0/1(P)
 secondary:******************************************************************
 Number of channel-groups in use: 2
Group  Port-channel  Protocol  Span-cluster   Ports
------+-------------+-----------+-----------------------------------------------
1         Po1              LACP      	Yes   Gi0/0(P)
2         Po2              LACP      	Yes   Gi0/1(P)

cluster flow-mobility lisp

To enable flow mobility for a traffic class, use the cluster flow-mobility lisp command in class configuration mode. You can access the class configuration mode by first entering the policy-map command. To disable flow mobility, use the no form of this command.

cluster flow-mobility lisp

no cluster flow-mobility lisp

Syntax Description

This command has no arguments or keywords.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Class configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.5(2)

This command was added.

Usage Guidelines

You should enable flow mobility on business-critical traffic. For example, you can limit flow mobility to only HTTPS traffic, and/or to traffic to specific servers.

About LISP Inspection for Cluster Flow Mobility

The ASA inspects LISP traffic for location changes and then uses this information for seamless clustering operation. With LISP integration, the ASA cluster members can inspect LISP traffic passing between the first hop router and the ETR or ITR, and can then change the flow owner to be at the new site.

Cluster flow mobility includes several inter-related configurations:

  1. (Optional) Limit inspected EIDs based on the host or server IP address—The first hop router might send EID-notify messages for hosts or networks the ASA cluster is not involved with, so you can limit the EIDs to only those servers or networks relevant to your cluster. For example, if the cluster is only involved with 2 sites, but LISP is running on 3 sites, you should only include EIDs for the 2 sites involved with the cluster. See the policy-map type inspect lisp , allowed-eid, and validate-key commands.

  2. LISP traffic inspection—The ASA inspects LISP traffic for the EID-notify message sent between the first hop router and the ITR or ETR. The ASA maintains an EID table that correlates the EID and the site ID. For example, you should inspect LISP traffic with a source IP address of the first hop router and a destination address of the ITR or ETR. See the inspect lisp command.

  3. Service Policy to enable flow mobility on specified traffic—You should enable flow mobility on business-critical traffic. For example, you can limit flow mobility to only HTTPS traffic, and/or to traffic to specific servers. See the cluster flow-mobility lisp command.

  4. Site IDs—The ASA uses the site ID for each cluster unit to determine the new owner. See the site-id command.

  5. Cluster-level configuration to enable flow mobility—You must also enable flow mobility at the cluster level. This on/off toggle lets you easily enable or disable flow mobility for a particular class of traffic or applications. See the flow-mobility lisp command.

Examples

The following example enables flow mobility for all inside traffic going to a server on 10.10.10.0/24 using HTTPS:


ciscoasa(config)# access-list IMPORTANT-FLOWS extended permit tcp any 10.10.10.0 255.255.255.0 eq https
ciscoasa(config)# class-map IMPORTANT-FLOWS-MAP
ciscoasa(config)# match access-list IMPORTANT-FLOWS
ciscoasa(config-cmap)# policy-map INSIDE_POLICY
ciscoasa(config-pmap)# class IMPORTANT-FLOWS-MAP
ciscoasa(config-pmap-c)# cluster flow-mobility lisp

cluster group

To configure the cluster bootstrap parameters and other cluster settings, use the cluster group command in global configuration mode. To clear the cluster configuration, use the no form of this command.

cluster group name

no cluster group name

Syntax Description

name

Specifies the cluster name as an ASCII string from 1 to 38 characters. You can only configure one cluster group per unit. All members of the cluster must use the same name.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

Each unit in the cluster requires a bootstrap configuration to join the cluster. Typically, the first unit you configure to join the cluster will be the master unit. After you enable clustering, after an election period, the cluster elects a master unit. With only one unit in the cluster initially, that unit will become the master unit. Subsequent units that you add to the cluster will be slave units.

Before you configure clustering, you need to set the cluster interface mode using the cluster interface-mode command.

You must use the console port or ASDM to enable or disable clustering. You cannot use Telnet or SSH.

Examples

The following example configures a management interface, configures a device-local EtherChannel for the cluster control link, disables the health check (temporarily), and then enables clustering for the ASA called “unit1,” which will become the master unit because it is added to the cluster first:


ip local pool mgmt 10.1.1.2-10.1.1.9
ipv6 local pool mgmtipv6 2001:DB8::1002/32 8
interface management 0/0
nameif management
ip address 10.1.1.1 255.255.255.0 cluster-pool mgmt
ipv6 address 2001:DB8::1001/32 cluster-pool mgmtipv6
security-level 100
management-only
no shutdown
interface tengigabitethernet 0/6
channel-group 1 mode active
no shutdown
interface tengigabitethernet 0/7
channel-group 1 mode active
no shutdown
cluster group pod1
local-unit unit1
cluster-interface port-channel1 ip 192.168.1.1 255.255.255.0
priority 1
key chuntheunavoidable
no health-check
enable noconfirm

The following example includes the configuration for a slave unit, unit2:


interface tengigabitethernet 0/6
channel-group 1 mode active
no shutdown
interface tengigabitethernet 0/7
channel-group 1 mode active
no shutdown
cluster group pod1
local-unit unit2
cluster-interface port-channel1 ip 192.168.1.2 255.255.255.0
priority 2
key chuntheunavoidable
no health-check
enable as-slave

cluster-interface

To specify the cluster control link physical interface and IP address, use the cluster-interface command in cluster group configuration mode. To remove the cluster interface, use the no form of this command.

cluster-interfaceinterface_idipip_addressmask

no cluster-interface [ interface_id ip ip_address mask ]

Syntax Description

interface_id

For hardware platforms: Specifies a physical interface, an EtherChannel, or a redundant interface. Subinterfaces and Management interfaces are not allowed.

For the ASA virtual: Specify a VNI interface.

This interface cannot have a nameif configured. For the ASA 5585-X with an IPS module, you cannot use the IPS module interfaces for the cluster control link.

ip ip_address mask

Specify an IPv4 address for the IP address; IPv6 is not supported for this interface. For each unit, specify a different IP address on the same network.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Cluster group configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

9.17(1)

We added support for VNI interfaces for the ASA virtual.

Usage Guidelines

You need to enable the cluster control link interface before you join the cluster.

For the ASA virtual: Each unit must dedicate one interface as a VXLAN (VTEP) interface for the cluster control link.

For hardware platforms: We recommend that you combine multiple cluster control link interfaces into an EtherChannel if you have enough interfaces. The EtherChannel is local to the ASA, and is not a spanned EtherChannel. We recommend that you use a Ten Gigabit Ethernet interface for the cluster control link. We recommend using the On mode for EtherChannel member interfaces to reduce unnecessary traffic on the cluster control link. The cluster control link does not need the overhead of LACP traffic because it is an isolated, stable network.

The cluster control link interface configuration is not replicated from the control node to data nodes; however, you must use the same configuration on each node. Because this configuration is not replicated, you must configure the cluster control link interfaces separately on each node.

See the configuration guide for more information about the cluster control link.

Examples

The following example creates an EtherChannel, Port-channel 2, for TenGigabitEthernet 0/6 and TenGigabitEthernet 0/7, and then assigns the port channel as the cluster control link. The port-channel interface is created automatically when you assign an interface to the channel group.


interface tengigabitethernet 0/6
channel-group 2 mode on
no shutdown
interface tengigabitethernet 0/7
channel-group 2 mode on
no shutdown
cluster group cluster1
cluster-interface port-channel2 ip 10.1.1.1 255.255.255.0

cluster interface-mode

To specify the cluster interface mode on each cluster unit, use the cluster interface-mode command in global configuration mode.To disable cluster interface mode, enter the no form of this command.

cluster interface-mode { individual | spanned } [ check-details | force ]

no cluster-interface [ interface_id ip ip_address mask ]

Syntax Description

individual

Sets the mode to Individual interface mode (routed mode; ASA hardware models only).

spanned

Sets the mode to Spanned EtherChannel mode.

check-details

Shows any incompatible configuration so that you can force the interface mode and fix your configuration later; the mode is not changed with this command.

force

Changes the mode without checking your configuration for incompatible settings. You need to manually fix any configuration issues after you change the mode. Because any interface configuration can only be fixed after you set the mode, we recommend using the force option so that you can at least start from the existing configuration. You can re-run the check-details option after you set the mode for more guidance.

Without the force option, if there is any incompatible configuration, you are prompted to clear your configuration and reload, thus requiring you to connect to the console port to reconfigure your management access. If your configuration is compatible (rare), the mode is changed and the configuration is preserved. If you do not want to clear your configuration, you can exit the command by typing n .

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

You can only configure one type of interface for clustering: Spanned EtherChannels or Individual interfaces; you cannot mix interface types in a cluster. If you have not set the mode, you cannot enable clustering. After you set the mode, even if you have not enabled clustering, your interfaces must comply with clustering interface requirements.

See the following guidelines:

  • You must set the mode separately on each ASA that you want to add to the cluster.

  • You can always configure the management-only interface as an Individual interface (recommended), even in Spanned EtherChannel mode. The management interface can be an Individual interface even in transparent firewall mode.

  • In Spanned EtherChannel mode, if you configure the management interface as an Individual interface, you cannot enable dynamic routing for the management interface. You must use a static route.

  • In multiple context mode, you must choose one interface type for all contexts. For example, if you have a mix of transparent and routed mode contexts, you must use Spanned EtherChannel mode for all contexts because that is the only interface type allowed for transparent mode.

Examples

The following example checks the current interface compatibility for Spanned EtherChannel mode:


ciscoasa(config)# cluster interface-mode spanned check-details
ERROR: Please modify the following configuration elements that are incompatible with 'spanned' interface-mode.
 - Interface vni1 is not a span-cluster port-channel interface, vni1(vni1) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/0 is not a span-cluster port-channel interface, Gi0/0(inside) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/1 is not a span-cluster port-channel interface, Gi0/1(test) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/1 is not a span-cluster port-channel interface, Gi0/1.1(vlan100) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/2 is not a span-cluster port-channel interface, Gi0/2(outside) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/5 is not a span-cluster port-channel interface, Gi0/5(bgmember1) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface Gi0/5 is not a span-cluster port-channel interface, Gi0/5.2(vlan200) cannot be used as data interface when cluster interface-mode is 'spanned'.
 - Interface BV1 is not a span-cluster port-channel interface, BV1(bvi1) cannot be used as data interface when cluster interface-mode is 'spanned'.
ciscoasa(config)# 

The following example sets the mode to Spanned EtherChannel mode and does not clear the incompatible configuration:

ciscoasa(config)# cluster interface-mode spanned force

cluster ip address

To set the IP address of the virtual load-balancing cluster, use the cluster ip address command in vpn load-balancing configuration mode. To remove the IP address specification, use the no form of this command.

cluster ip address ip-address

no cluster ip address [ ip-address ]

Syntax Description

ip-address

The IP address that you want to assign to the virtual load-balancing cluster.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Vpn load-balancing configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

You must first use the vpn load-balancing command to enter vpn load-balancing configuration mode and configure the interface to which the virtual cluster IP address refers.

The cluster IP address must be on the same subnet as the interface for which you are configuring the virtual cluster.

In the no form of the command, if you specify the optional ip-address value, it must match the existing cluster IP address before the no cluster ip address command can be completed.

Examples

The following example shows a VPN load-balancing command sequence that includes a cluster ip address command that sets the IP address of the virtual load-balancing cluster to 209.165.202.224:


ciscoasa(config)# interface GigabitEthernet 0/1
ciscoasa(config-if)# ip address 209.165.202.159 255.255.255.0
ciscoasa(config)# nameif test
ciscoasa(config)# interface GigabitEthernet 0/2
ciscoasa(config-if)# ip address 209.165.201.30 255.255.255.0
ciscoasa(config)# nameif foo
ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic test
ciscoasa(config-load-balancing)# interface lbprivate foo
ciscoasa(config-load-balancing)# cluster ip address 209.165.202.224
ciscoasa(config-load-balancing)# participate

cluster key

To set the shared secret for IPsec site-to-site tunnel exchanges on the virtual load-balancing cluster, use the cluster key command in vpn load-balancing configuration mode. To remove this specification, use the no form of this command.

cluster key [ 0 | 8 ] shared-secret

no cluster key [ 0 | 8 ] [ shared-secret ]

Syntax Description

[ 0 | 8]

Specify 0 if the password is unencrypted, or 8 if the password is already encrypted (for example, you copied it from another unit's configuration).

shared-secret

A 3- through 17-character string that defines the shared secret for the VPN load-balancing cluster. Special characters can appear in the string, but not spaces.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Vpn load-balancing configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

8.3(1)

We added support for encrypted passwords with the 0 and 8 keywords.

Usage Guidelines

You must first use the vpn load-balancing command to enter vpn load-balancing configuration mode. The shared secret defined in the cluster key command is also used for cluster encryption.

You must use the cluster key command to configure the shared secret before enabling cluster encryption.

If you specify a value for shared-secret in the no cluster key form of the command, the shared secret value must match the existing configuration.

Examples

The following example shows a VPN load-balancing command sequence that includes a cluster key command to set the shared secret of the virtual load-balancing cluster to 123456789:


ciscoasa(config)# interface GigabitEthernet 0/1
ciscoasa(config-if)# ip address 209.165.202.159 255.255.255.0
ciscoasa(config)# nameif test
ciscoasa(config)# interface GigabitEthernet 0/2
ciscoasa(config-if)# ip address 209.165.201.30 255.255.255.0
ciscoasa(config)# nameif foo
ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic test
ciscoasa(config-load-balancing)# interface lbprivate foo
ciscoasa(config-load-balancing)# cluster ip address 209.165.202.224
ciscoasa(config-load-balancing)# cluster key 123456789
ciscoasa(config-load-balancing)# cluster encryption
ciscoasa(config-load-balancing)# participate

cluster control-node

To make the current node the control node of a cluster, or to set another node as the control node, use the cluster control-node command in privileged EXEC mode.

cluster control-node [ unit unit_name ]


Caution


The best method to change the control node is to disable clustering on the control node (see the no enable (cluster group) command), waiting for a new control node election, and then re-enabling clustering. If you must specify the exact unit you want to become the control node, use the cluster control-node unit command. Note, however, that for centralized features, if you force a control node change using this command, then all connections are dropped, and you have to re-establish the connections on the new control node.

Syntax Description

unit unit_name

(Optional) Specifies the local unit name to be the new control node. To view node names, enter cluster control-node unit ? (to see all names except the current unit), or enter the show cluster info command.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Privileged EXEC

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

9.19(1)

This command was changed from cluster master to cluster control-node.

Usage Guidelines

You will need to reconnect to the main cluster IP address.

Examples

The following example sets asa2 as the control node:


ciscoasa# cluster control-node unit asa2

cluster-member-limit

To configure the maximum number of cluster members, use the cluster-member-limit command in cluster group configuration mode. To restore the default, use the no form of this command.

cluster-member-limit number

no cluster-member-limit

Syntax Description

number

Sets the maximum number of cluster members between 2 and 16. The default is 16

Command Default

The default is 16 members.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.16(1)

This command was added.

Usage Guidelines

If you know that your cluster will be fewer than the maximum of 16 units, then we recommend that you set the actual planned number of units. Setting the maximum units lets the cluster manage resources better. For example, if you use port address translation (PAT), then the control unit can allocate port blocks to the planned number of members, and it will not have to reserve ports for extra units you don't plan to use.

Examples

The following example sets the maximum cluster members to 6:


ciscoasa(config)# cluster group pod1
ciscoasa(cfg-cluster)# cluster-member-limit 6

cluster-mode (Deprecated)

To specify the security mode of the cluster, use the cluster-mode command in phone-proxy configuration mode. To set the security mode of the cluster to the default mode, use the no form of this command.

cluster-mode [ mixed | nonsecure ]

no cluster-mode [ mixed | nonsecure ]

Syntax Description

mixed

Specifies the cluster mode to be in mixed mode when configuring the Phone Proxy feature.

nonsecure

Specifies the cluster mode to be in nonsecure mode when configuring the Phone Proxy feature.

Command Default

The default cluster mode is nonsecure.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Phone-proxy configuration

  • Yes

  • Yes

Command History

Release

Modification

8.0(4)

The command was added.

9.4(1)

This command was deprecated along with all phone-proxy mode commands.

Usage Guidelines

When you are configuring the Phone Proxy to run in mixed-mode clusters (both secure and nonsecure modes), you must also configure the LDC issuer in case some phones are configured to be in authenticated or encrypted mode:


hostname(config)# crypto key generate rsa label ldc_signer_key modulus 1024
hostname(config)# crypto key generate rsa label phone_common modulus 1024
hostname(config)# tls-proxy my_proxy
hostname(config-tlsp)# server trust-point internal_PP_myctl
hostname(config-tlsp)# client ldc issuer ldc_server
hostname(config-tlsp)# client ldc keypair phone_common

Examples

The following example sets the security mode of the Phone Proxy to mixed (the IP phones will operate in secure and nonsecure modes):


ciscoasa
(config-phone-proxy)# cluster-mode mixed

cluster port

To set the UDP port for the virtual load-balancing cluster, use the cluster port command in vpn load-balancing configuration mode. To remove the port specification, use the no form of this command.

cluster port port

no cluster port [ port ]

Syntax Description

port

The UDP port that you want to assign to the virtual load-balancing cluster.

Command Default

The default cluster port is 9023.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Vpn load-balancing configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

You must first use the vpn load-balancing command to enter vpn load-balancing configuration mode.

You can specify any valid UDP port number. The range is 1-65535.

If you specify a value for port in the no cluster port form of the command, the port number specified must match the existing configured port number.

Examples

The following example sets the UDP port for the virtual load-balancing cluster to 9023:


ciscoasa(config)# interface GigabitEthernet 0/1
ciscoasa(config-if)# ip address 209.165.202.159 255.255.255.0
ciscoasa(config)# nameif test
ciscoasa(config)# interface GigabitEthernet 0/2
ciscoasa(config-if)# ip address 209.165.201.30 255.255.255.0
ciscoasa(config)# nameif foo
ciscoasa(config)# vpn load-balancing
ciscoasa(config-load-balancing)# interface lbpublic test
ciscoasa(config-load-balancing)# interface lbprivate foo
ciscoasa(config-load-balancing)# cluster ip address 209.165.202.224
ciscoasa(config-load-balancing)# cluster port 9023
ciscoasa(config-load-balancing)# participate

cluster redistribute vpn-sessiondb

To re-balance active sessions on a Distributed VPN cluster, use this command in privileged EXEC mode.

cluster redistribute vpn-sessiondb

Syntax Description

This command has no arguments.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl provider configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.9(1)

Command added.

Usage Guidelines

This command executes in the background and will return to the CLI, no console message will be displayed to the user when the operation is complete.

To monitor progress, use the show cluster vpn-sessiondb distribution command, or enable syslogs

The ASR operation must be performed on the master node, the orchestrator of the VPN sessions. The orchestrator is responsible for calculating which sessions will move and where. The orchestrator itself can move active sessions from itself to other nodes as well.

To reduce load on the cluster during this operation and to ensure a timely response time, a maximum of 100 sessions to be moved will be requested at any one time. If the calculated move was 1000 for one node, there would be 10 separate requests for that calculation.

The orchestrator will consider a move request complete for a node when all of the sessions have been moved, or if the owner member cannot move the requested number of sessions.

There are ways a redistribution operation will abort including if a node is unable to respond to the move request or there is a cluster topology change (member join/leave).

This is a best-effort operation. There is no guarantee that after the operation is complete that there will be a perfect distribution. Some nodes may have as much as 20% more/less sessions than average.

Examples

For example, if you have the following results from the show cluster vpn-sessiondb distribution:


Member 0 (unit-1-1): active: 229; backups at: 1(120), 2(109)
Member 1 (unit-1-3): active: 224; backups at: 0(117), 2(107)
Member 2 (unit-1-2): active: 0
After the ASR operation, the result looks like:
Member 0 (unit-1-1): active: 151; backups at: 1(120), 2(31)
Member 1 (unit-1-3): active: 151; backups at: 0(117), 2(34)
Member 2 (unit-1-2): active: 151; backups at: 0(72), 1(79)

Example of a successful initiation: 
ciscoasa/master# cluster redistribute vpn-sessiondb
Session redistribution initiated.
Use 'show cluster vpn-sessiondb distribution' to view distribution.
Initiation when redistribution is already in progress: 
ciscoasa/master# cluster redistribute vpn-sessiondb 
Redistribution already in progress
Use 'show cluster vpn-sessiondb distribution' to view distribution.
When executed on a slave node
 
ciscoasa/slave# cluster redistribute vpn-sessiondb 
ERROR: This command is only allowed on the cluster master

cluster remove unit

To remove the unit from the ASA cluster, use the cluster remove unit command in privileged EXEC mode.

cluster remove unit unit_name

Syntax Description

unit_name

Specifies the local unit name to removes from the cluster. To view member names, enter cluster remove unit ? , or enter the show cluster info command.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Privileged EXEC

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.0(1)

This command was added.

Usage Guidelines

The bootstrap configuration remains intact, as well as the last configuration synced from the master unit, so you can later re-add the unit without losing your configuration. If you enter this command on a slave unit to remove the master unit, a new master unit is elected.

Examples

The following example checks for unit names, and then removes asa2 from the cluster:


ciscoasa(config)# cluster remove unit ?
Current active units in the cluster:
asa2
ciscoasa(config)# cluster remove unit asa2
WARNING: Clustering will be disabled on unit asa2. To bring it back
to the cluster please logon to that unit and re-enable clustering

cluster replication delay

To enable the cluster replication delay for TCP connections, use the cluster replication delay command in cluster group configuration mode. To disable the delay, use the no form of this command.

cluster replication delay seconds { http | match tcp { host ip_address | ip_address mask | any | any4 | any6 } [ { eq | lt | gt } port ] { host ip_address | ip_address mask | any | any4 | any6 } [ { eq | lt | gt } port ] }

no cluster replication delay seconds { http | match tcp { host ip_address | ip_address mask | any | any4 | any6 } [ { eq | lt | gt } port ] { host ip_address | ip_address mask | any | any4 | any6 } [ { eq | lt | gt } port ] }

Syntax Description

seconds

Sets the delay between 1 and 15 seconds.

http

Sets the delay for all HTTP traffic. The http delay is enabled by default for 5 seconds.

Command Default

The http delay is enabled by default for 5 seconds.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.4(1.152)

This command was added.

Usage Guidelines

This feature helps eliminate the “unnecessary work” related to short-lived flows by delaying the director/backup flow creation.

Examples

The following example sets the FTP delay to 15 seconds, and the HTTP delay to 15 seconds:


ciscoasa(config)# cluster replication delay 15 match tcp any any eq ftp
ciscoasa(config)# cluster replication delay 15 http

cn-id

To configure a cn-id in a reference-identity object, use the cn-id command in ca-reference-identity mode. To delete a cn-id, use the no form of this command. You can access the ca-reference-identity mode by first entering the crypto ca reference-identity command to configure a reference-identity object..

cn-idvalue

no cn-id value

Syntax Description

value

Value of each reference-id.

cn-id

Common Name (CN), where the value matches the overall form of a domain name. The CN value cannot be free text. A CN-ID reference identifier does not identify an application service.

Command Default

No default behavior or values.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

ca-reference-identity

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.6(2)

We introduced this command.

Usage Guidelines

Once a reference identity has been created, the four identifier types and their associated values can be added or deleted from the reference identity.

The reference identifiers cn-id and dns-id MAY NOT contain information identifying the application service and MUST contain information identifying the DNS domain name.

Examples

The following example creates a reference-identity for a syslog server:


ciscoasa(config)# crypto ca reference-identity syslogServer
ciscoasa(config-ca-ref-identity)# dns-id syslog1-bxb.cisco.com
ciscoasa(config-ca-ref-identity)# cn-id syslog1-bxb.cisco.com

command-alias

To create an alias for a command, use the command-alias command in global configuration mode. To remove the alias, use the no form of this command.

command-alias mode command_alias original_command

no command-alias mode command_alias original_command

Syntax Description

command_alias

Specifies the new name for an existing command.

mode

Specifies the command mode in which you want to create the command alias, for example exec (for user and privileged EXEC modes), configure , or interface .

original_command

Specifies the existing command or command with its keywords for which you want to create the command alias.

Command Default

By default, the following user EXEC mode aliases are configured:

  • h for help

  • lo for logout

  • p for ping

  • s for show

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

When you enter the command alias, the original command is invoked. You might want to create command aliases to provide shortcuts for long commands, for example.

You can create an alias for the first part of any command and still enter the additional keywords and arguments as normal.

When you use CLI help, command aliases are indicated by an asterisk (*), and displayed in the following format:


*command-alias=original-command

For example, the lo command alias displays along with other privileged EXEC mode commands that start with “lo,” as follows:


ciscoasa# lo?
*lo=logout login  logout 

You can use the same alias in different modes. For example, you can use “happy” in privileged EXEC mode and configuration mode to alias different commands, as follows:


ciscoasa(config)# happy?
configure mode commands/options:
*happy="username employee1 password test"
exec mode commands/options:
*happy=enable

To list only commands and omit aliases, begin your input line with a space. Also, to circumvent command aliases, use a space before entering the command. In the following example, the alias named “happy” is not shown, because there is a space before the happy? command.


ciscoasa(config)# alias exec test enable
ciscoasa(config)# exit
ciscoasa#   happy?
ERROR: % Unrecognized command

As with commands, you can use CLI help to display the arguments and keywords that can follow a command alias.

You must enter the complete command alias. Shortened aliases are not accepted. In the following example, the parser does not recognize the hap command as indicating the alias named “happy”:


ciscoasa# hap
% Ambiguous command: "hap"

Examples

The following example shows how to create a command alias named “save ” for the copy running-config startup-config command:


ciscoasa(config)# command-alias exec save copy running-config startup-config
ciscoasa(config)# exit
ciscoasa# save
Source filename [running-config]?
Cryptochecksum: 50d131d9 8626c515 0c698f7f 613ae54e
2209 bytes copied in 0.210 secs
ciscoasa#

command-queue

To specify the maximum number of MGCP commands that are queued while waiting for a response, use the command-queue command in mgcp-map configuration mode. To remove the configuration, use the no form of this command.

command-queuelimit

no command-queue limit

Syntax Description

limit

Specifies the maximum number of commands to queue, from 1 to 2147483647.

Command Default

This command is disabled by default.

The default for the MGCP command queue is 200.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Mgcp-map configuration

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

Use the command-queue command to specify the maximum number of MGCP commands that are queued while waiting for a response. The range of allowed values is from 1 to 4294967295. The default is 200. When the limit has been reached and a new command arrives, the command that has been in the queue for the longest time is removed.

Examples

The following example limits the MGCP command queue to 150 commands:


ciscoasa(config)# mgcp-map mgcp_policy
ciscoasa(config-mgcp-map)#command-queue 150

commercial-security

To define an action when the Commercial Security (CIPSO) option occurs in a packet header with IP Options inspection, use the commercial-security command in parameters configuration mode. To disable this feature, use the no form of this command.

commercial-security action { allow | clear }

no commercial-security action { allow clear }

Syntax Description

allow

Allow packets containing the Commercial Security IP option.

clear

Remove the Commercial Security option from packet headers and then allow the packets.

Command Default

By default, IP Options inspection drops packets containing the Commercial Security IP option.

You can change the default using the default command in the IP Options inspection policy map.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Parameters configuration

  • Yes

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.5(1)

This command was added.

Usage Guidelines

This command can be configured in an IP Options inspection policy map.

You can configure IP Options inspection to control which IP packets with specific IP options are allowed through the ASA. You can allow a packet to pass without change or clear the specified IP options and then allow the packet to pass.

Examples

The following example shows how to set up an action for IP Options inspection in a policy map:


ciscoasa(config)# policy-map type inspect ip-options ip-options_map
ciscoasa(config-pmap)# parameters
ciscoasa(config-pmap-p)# commercial-security action allow
ciscoasa(config-pmap-p)# router-alert action allow

community-list

To create or configure a Border Gateway Protocol (BGP) community list and to control access to it, use the community-list command in global configuration command. To delete the community list, use the no form of this command

StandardCommunityLists

community-list { standard | standard list-name } { deny | permit } [ community-number ] [ AA:NN ] [ internet ] [ local-AS ] [ no-advertise ] [ no-export ]

no community-list { standard | standard list-name }

ExpandedCommunityLists

community-list { expanded | expanded list-name } { deny | permit } regexp

no community-list { expanded | expanded list-name }

Syntax Description

standard

Configures a standard community list using a number from 1 to 99 to identify one or more permit or deny groups of communities.

standard list-name

Configures a named standard community list.

permit

Permits access for a matching condition.

deny

Denies access for a matching condition.

community-number

(Optional) Specifies a community as a 32-bit number from 1 to 4294967200. A single community can be entered or multiple communities can be entered, each separated by a space.

AA:NN

(Optional) Autonomous system number and network number entered in the 4-byte new community format. This value is configured with with two 2-byte numbers separated by a colon. A number from 1 to 65535 can be entered each 2-byte number. A single community can be entered or multiple communities can be entered, each separated by a space.

internet

(Optional) Specifies the Internet community. Routes with this community are advertised to all peers (internal and external).

no-export

(Optional) Specifies the no-export community. Routes with this community are advertised to only peers in the same autonomous system or to only other subautonomous systems within a confederation. These routes are not advertised to external peers.

local-AS

(Optional) Specifies the local-as community. Routes with community are advertised to only peers that are part of the local autonomous system or to only peers within a subautonomous system of a confederation. These routes are not advertised to external peers or to other subautonomous systems within a confederation.

no-advertise

(Optional) Specifies the no-advertise community. Routes with this community are not advertised to any peer (internal or external).

Expanded

Configures an expanded community list number from 100 to 500 to identify one or more permit or deny groups of communities.

expanded list-name

Configures a named expanded community list.

regexp

Configures a regular expression that is used to specify a pattern to match against an input string.

Note

 
Regular expressions can be used only with expanded community lists.

Command Default

BGP community exchange is not enabled by default.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global Configuration

  • Yes

  • Yes

  • Yes

Command History

Release

Modification

9.2(1)

This command was added.

Usage Guidelines

The community-list command is used to configure BGP community filtering. BGP community values are configured as a 32-bit number (old format) or as a 4-byte number (new format). The new community format is enabled when the bgp-community new-format command is entered in global configuration mode. The new community format consists of a 4-byte value.

The first two bytes represent the autonomous system number, and the trailing two bytes represent a user-defined network number. Named and numbered community lists are supported. BGP community attribute exchange between BGP peers is enabled when the neighbor send-community command is configured for the specified neighbor. The BGP community attribute is defined in RFC 1997and RFC 1998.

BGP community exchange is not enabled by default. It is enabled on a per-neighbor basis with the neighbor send-community command. The Internet community is applied to all routes or prefixes by default, until any other community value is configured with this command or the set community command.

Once a permit value has been configured to match a given set of communities, the community list defaults to an implicit deny for all other community values.

Standard Community Lists

Standard community lists are used to configure well-known communities and specific community numbers. A maximum of 16 communities can be configured in a standard community list. If you attempt to configure more than 16 communities, the trailing communities that exceed the limit are not processed or saved to the running configuration file.

Expanded Community Lists

Expanded community lists are used to filter communities using a regular expression. Regular expressions are used to configure patterns to match community attributes. The order for matching using the * or + character is longest construct first. Nested constructs are matched from the outside in. Concatenated constructs are matched beginning at the left side. If a regular expression can match two different parts of an input string, it will match the earliest part first. For more information about configuring regular expressions, see the "Regular Expressions" appendix of theCisco IOS Terminal Services Configuration Guide.

Community List Processing

When multiple values are configured in the same community list statement, a logical AND condition is created. All community values must match to satisfy an AND condition. When multiple values are configured in separate community list statements, a logical OR condition is created. The first list that matches a condition is processed.

Examples

In the following example, a standard community list is configured that permits routes that from network 10 in autonomous system 50000:


ciscoasa(config)#  community-list 1 permit 50000:10 

In the following example, a standard community list is configured that permits only routes from peers in the same autonomous system or from subautonomous system peers in the same confederation:


ciscoasa(config)#  community-list 1 permit no-export 

In the following example, a standard community list is configured to deny routes that carry communities from network 40 in autonomous system 65534 and from network 60 in autonomous system 65412. This example shows a logical AND condition; all community values must match in order for the list to be processed.


ciscoasa(config)#  community-list 2 deny 65534:40 65412:60 

In the following example, a named standard community list is configured that permits all routes within the local autonomous system or permits routes from network 20 in autonomous system 40000. This example shows a logical OR condition; the first match is processed.


ciscoasa(config)#  community-list standard RED permit local-AS 
ciscoasa(config)#  community-list standard RED permit 40000:20 

In the following example, an expanded community list is configured that will deny routes that carry communities from any private autonomous system:


ciscoasa(config)#  community-list 500 deny _64[6-9][0-9][0-9]_|_65[0-9][0-9][0-9]_ 

In the following example, a named expanded community list configured that denies routes from network 1 through 99 in autonomous system 50000:


ciscoasa(config)#  community-list expanded BLUE deny 50000:[0-9][0-9]_ 

compatible rfc1583

To restore the method that is used to calculate the summary route costs per RFC 1583, use the compatible rfc1583 command in router configuration mode. To disable RFC 1583 compatibility, use the no form of this command.

compatible rfc1583

no compatible rfc1583

Syntax Description

This command has no arguments or keywords.

Command Default

This command is enabled by default.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl provider configuration

  • Yes

  • Yes

Command History

Release

Modification

7.0(1)

This command was added.

Usage Guidelines

Only the no form of this command appears in the configuration.

Examples

The following example shows how to disable an RFC 1583-compatible route summary cost calculation:


ciscoasa(config-router)# no compatible rfc1583
ciscoasa(config-router)#

compression

To enable compression for anyconnect-ssl connections and WebVPN connections, use the compression command in global configuration mode. To remove the command from the configuration, use the no form of the command.

compression { all | anyconnect-ssl | http-comp }

no compression { all | anyconnect-ssl | http-comp }

all

Specifies enabling all available compression techniques.

anyconnect-ssl

Specifies compression for anyconnect-ssl connections.

http-comp

Specifies compression for WebVPN connections.

Command Default

The default is all . All available box-wide compression techniques are enabled.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Global configuration

  • Yes

  • Yes

Command History

Release

Modification

7.1(1)

This command was added.

9.0(1)

Support for multiple context mode was added.

Usage Guidelines

The compression command configured in global configuration mode overrides the compression anyconnect-ssl command configured in group policy webvpn and username webvpn configuration modes.

For example, if you enter the anyconnect-ssl compression command for a certain group in group policy webvpn configuration mode, and then you enter the no compression command in global configuration mode, you override the anyconnect-ssl compression command settings that you have configured for the group.

Conversely, if you turn compression back on with the compression command in global configuration mode, any group settings take effect, and those settings ultimately determine the compression behavior.

If you disable compression with the no compression command, only new connections are affected. Active connections remain unaffected.

Examples

In the following example, compression is turned on for anyconnect-ssl connections:


hostname(config)# compression anyconnect-ssl

In the following example, compression is disabled for anyconnect-ssl and WebVPN connections:


hostname(config)# no
 compression anyconnect-ssl http-comp

config-register

To set the configuration register value that is used the next time you reload the ASA, use the config-register command in global configuration mode. To set the value back to the default, use the no form of this command.

config-register hex_value

no config-register

Syntax Description

hex_value

Sets the configuration register value as a hexadecimal number from 0x0 to 0xFFFFFFFF. This number represents 32 bits and each hexadecimal character represents 4 bits. Each bit controls a different characteristic. However, bits 32 through 20 are either reserved for future use, cannot be set by the user, or are not currently used by the ASA; therefore, you can ignore the three characters that represent those bits, because they are always set to 0. The relevent bits are represented by 5 hexadecimal characters: 0xnnnnn .

You do not need to include preceding 0s. You do need to include trailing 0s. For example, 0x2001 is equivalent to 0x02001; but 0x10000 requires all the zeros. See <xref> for more information about available values for the relevant bits.

Command Default

The default value is 0x1, which boots from the local image and startup configuration.

Command Modes


The following table shows the modes in which you can enter the command:

Command Mode

Firewall Mode

Security Context

Routed

Transparent

Single

Multiple

Context

System

Ctl provider configuration