-
null
- packet-tracer
- pager
- page style
- parameters
- participate
- passive-interface (ipv6 router ospf)
- passive-interface (isis)
- passive-interface (router eigrp)
- passive-interface (router rip)
- passwd
- password (crypto ca trustpoint)
- password encryption aes
- password-history
- password-management
- password-parameter
- password-policy authenticate enable
- password-policy lifetime
- password-policy minimum-changes
- password-policy minimum-length
- password-policy minimum-lowercase
- password-policy minimum-numeric
- password-policy minimum-special
- password-policy minimum-uppercase
- password-policy reuse-interval
- password-policy username-check
- password-prompt
- password-storage
- peer-id-validate
- peer ip
- perfmon
- periodic
- periodic-authentication certificate
- permit-errors
- permit-response
- pfs
- phone-proxy (Deprecated)
- pim
- pim accept-register
- pim bidir-neighbor-filter
- pim bsr-border
- pim bsr-candidate
- pim dr-priority
- pim hello-interval
- pim join-prune-interval
- pim neighbor-filter
- pim old-register-checksum
- pim rp-address
- pim spt-threshold infinity
- ping
packet-tracer through ping Commands
packet-tracer
The packet-tracer command can be used in privileged EXEC mode to generate a 5-to-6 tuple packet against a firewall’s current configurations. For clarity, the packet-tracer syntax is shown separately for ICMP, TCP/UDP/SCTP, and IP packet modeling.
packet-tracer input ifc_name [vlan-id vlan_id ] icmp [inline-tag tag ]
{ sip | user username | security-group {name name | tag tag } | fqdn fqdn_string }
icmp_value [ icmp_code ] [ dmac ] { dst_ip | security-group {name name | tag tag } | fqdn fqdn_string } [detailed] [xml]
packet-tracer input ifc_name [vlan-id vlan_id ] rawip [inline-tag tag ]
{ sip | user username | security-group {name name | tag tag } | fqdn fqdn_string }
protocol [ dmac ] { dst_ip | security-group {name name | tag tag } | fqdn fqdn_strin g}
[detailed] [xml]
packet-tracer input ifc_name [vlan-id vlan_id] { tcp | udp | sctp } [inline-tag tag]
{ sip | user username | security-group { name name | tag tag } | fqdn fqdn_string } src_port [ dmac ] { dst_ip | security-group { name name | tag tag } | fqdn fqdn_string } dst_port [{ vxlan-inner vxlan_inner_tag icmp inner_src_ip inner_icmp_type inner_icmp_code [ inner_icmp_id ] inner_dst_ip inner_src_mac inner_dst_mac } | { vxlan-inner vxlan_inner_tag rawip inner_src_ip inner_protocol inner_dst_ip inner_src_mac inner_dst_mac } | { vxlan-inner vxlan_inner_tag { tcp | udp | sctp } inner_src_ip inner_src_port inner_dst_ip inner_dst_port inner_src_mac inner_dst_mac }] [detailed] [xml]
Syntax Description
Command Default
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
Usage Guidelines
In addition to capturing packets with the capture command, it is possible to trace the lifespan of a packet through the ASA to see if it is behaving as expected. The packet-tracer command enables you to do the following:
- Debug all packet drops in a production network.
- Verify the configuration is working as intended.
- Show all rules applicable to a packet along with the CLI lines that caused the rule addition.
- Show a timeline of packet changes in a datapath.
- Inject tracer packets into the datapath.
- Search for an IPv4 or IPv6 address based on the user identity and the FQDN.
- Debug packets across cluster nodes.
The packet-tracer command provides detailed information about the packets and how they are processed by the ASA. packet-tracer allows a firewall administrator to inject a virtual packet into the security appliance and track the flow from ingress to egress. Along the way, the packet is evaluated against flow and route lookups, ACLs, protocol inspection, and NAT. The power of the utility comes from the ability to simulate real-world traffic by specifying source and destination addresses with protocol and port information.
The optional vlan-id keyword allows packet tracer to enter a parent interface, which is later redirected to a subinterface that matches the VLAN identity. The VLAN identity is an optional entry only for non-sub-interfaces. Management interface is an exception, where a parent management-only interface can only have the management-only sub-interfaces.
The destination MAC address lookup is available.
In transparent firewall mode, when the input interface is VTEP, Destination MAC address is optionally enabled if you enter a value in VLAN. Whereas in the bridge group member interface, Destination MAC address is a mandatory field but is optional if you enter the vlan-id keyword.
In routed firewall mode, when the input interface is bridge group member interface, The vlan-id keyword and dmac argument are optional.
The following tables provide full information pertaining to the interface-dependent behavior of VLAN identity and Destination MAC address in transparent and routed firewall modes respectively.
|
|
|
---|---|---|
When you run the packet-tracer command using the input ingress interface and if the packet does not get dropped, the packet traverses through different phases like UN-NAT, ACLs, NAT, IP-OPTIONS, and FLOW-CREATION. The resultant message is displayed: “ALLOW”.
In a scenario where the firewall configurations could cause live traffic to be dropped, the simulated tracer packet will also be dropped. In some instances, a specific drop reason will be provided. For example, if a packet was dropped because of an invalid header validation, the following message appears: “packet dropped due to bad ip header (reason).” The packet gets dropped in a switching sequence if the Destination MAC address is unknown. It initiates the ASA to search for the Destination MAC address. packet-tracer can be executed again and the L2 lookup is successful if the Destination MAC address was found.
VXLAN support in packet-tracer enables you to specify inner packet Layer 2 source and destination MAC addresses, Layer 3 source and destination IP addresses, Layer 4 protocol, Layer 4 source and destination port numbers, and the Virtual Network Interface (VNI) number. Only TCP, SCTP, UDP, raw IP, and ICMP are supported for the inner packet.
You can specify a user identity for the source using domain/user format. The ASA searches for the user's IP address and uses it in packet trace testing. If a user is mapped to multiple IP addresses, the most recent login IP address is used and the output shows that more IP address-user mapping exists. If user identity is specified in the source part of this command, then the ASA searches for the user's IPv4 or IPv6 address based on the destination address type that the user entered.
You can specify security group name or security group tag as a source. The ASA searches for the IP address based on the security group name or security group tag and uses it in packet trace testing. If a security group tag or security group name is mapped to multiple IP addresses, then one of the IP addresses is used and the output shows that more IP address-to-security group tag mapping exists.
You can also specify a FQDN as both the source and destination address. The ASA performs DNS lookup first, then retrieves the first returned IP address for packet construction.
For traffic scenarios like L3 to Bridge Virtual Interface and Bridge Virtual Interface to Bridge Virtual Interface, where destination IP is the next hop through BVI interface on ASA, then, packet tracer does double ROUTE-LOOKUP. Also, the flow is not created.
With ARP and MAC address table entry cleared, the packet tracer always does double ROUTE-LOOKUP and destination MAC address is resolved and stored in database. Whereas this is not the case for any other traffic scenario. Destination MAC address is never resolved and stored in database, when it is a L3 interface. Since the BVI interface is configured with nameif and has L3 properties, the DMAC lookup should not be done.
This behavior is seen only in first attempt when there are no MAC address and ARP entries present. Once the entry is present for DMAC, the packet tracer output is as expected. The flow is created.
With persistent tracing, it is possible to trace a packet when it passes between cluster units. The packet you want to track across cluster units must be injected using the persist option. The persistent tracing for each packet is equipped with a packet-id and a hop count with which it is possible to determine the injected packet origin and packet hop phases through the cluster nodes. The packet-id is a combination of <node name of the device where the packet originated> and an incremental number. The packet-id is unique for each new packet received for the first time on a node. The hop count populates every time the packet moves from one cluster member to another. For example, packets in clustering arrive to a member based on external load-balancing numbered list. The Host-1 sends a packet to Host-2. The injected packet is redirected between the cluster nodes before it is sent to Host-2. The metadata output displays Tracer origin-id B:7 hop 0
, Tracer origin-id B:7 hop 1
, and Tracer origin-id B:7 hop 2
respectively. Where B is the name of the cluster node from which the packet originated. And 7 is an incremental number, representing this is the 7th packet originating from this cluster node. This number increases with each new packet originating from this node. “B” and “7” together forms a unique-id to identify a packet. A cluster unit local name is the same for every packet that is passing through this unit. Each packet is differentiated when the global buffer uses the unique-id and the hop count. Once the packets are traced, the persistent traces are available on each node until the time you manually discard them to free up some memory. The enabled persistent traces in a context are stored in a per-context buffer. Use the origin-owner-ID (two values <origin-owner> <id>), to locate the traces in the set.
It is possible to allow simulated packets to egress the ASA. Using the transmit option via packet-tracer, you can let the packets be transmitted on the network. By default, the packet-tracer discards the packet before transmitting it. A flow is generated in the flow table once the packets are egressed.
By using the bypass-checks option via packet-tracer, it is possible to bypass ACL, VPN filters, uRPF, and IPsec spoof checks. It applies for both ingress and egress conditions and the simulated IPsec packets are not dropped.
It is possible to inject a decrypted packet in a VPN tunnel, which is generic and applicable for both IPSec and TLS. It is also possible to simulate a packet that comes across a VPN tunnel. The simulated ‘decrypted’ packet would be matched against an existing VPN tunnel and the associated tunnel policies would be applied.
Examples
The following example traces a TCP packet for the HTTP port from 201.1.1.1 to 202.1.1.1.
The following example traces a TCP packet for the HTTP port from 10.100.10.10 to 10.100.11.11. The result indicates that the packet will be dropped by the implicit deny access rule.
The following example shows how to trace a packet from inside host 10.0.0.2 to outside host 20.0.0.2 with the username of CISCO\abc:
The following example shows how to trace a packet from inside host 20.0.0.2 with the username of CISCO\abc and display the trace results in XML format:
The following example shows how to trace a packet from inside host xyz.example.com to external host abc.example.com.
The following example displays output from the packet-tracer command to show security group tag mapping to an IP address:
The following example displays output from the packet-tracer command to show Layer 2 SGT Imposition:
The following example outlines VXLAN support for UDP/TCP and ICMP inner packets
packet-tracer in inside udp 30.0.0.2 12345 30.0.0.100 vxlan vxlan-inner 1234 1.1.1.1 11111 2.2.2.2 22222 aaaa.bbbb.cccc aaaa.bbbb.dddd detailed
Outer packet: UDP from 30.0.0.2 to 30.0.0.100 (vtep/nve source-interface IP) with default vxlan destination port.
The following example displays output for persistent tracing when it passes between cluster units:
The following example displays output when packets are traced using origin and id options from the cluster nodes:
The following example outlines clearing persistent traces from the cluster nodes:
For injecting decrypted packets in an IPSec tunnel, there are some conditions. When the IPSec tunnel is not negotiated, an error message is displayed. Secondly, when the IPSec tunnel is negotiated, the packet goes through.
The following example outlines when IPSec tunnel is not negotiated for injecting decrypted packets:
The following example outlines when IPSec tunnel is negotiated for injecting decrypted packets:
The following example uses the transmit option to allow simulated packets to egress and capture the same on the outgoing interface:
The following example outlines the ICMP packet being captured on the outgoing interface:
The examples for the bypass-checks option for packet-tracer is outlined through the following phases as listed. Specific examples are provided for each scenario:
– When the IPSec tunnel between spoke and hub is not created.
– The IPSec tunnel between two boxes must be negotiated and the initial packet triggers tunnel establishment.
– The IPSec negotiation is complete and the tunnel comes up.
– Once the tunnel is up, the packets injected will be sent through the tunnel. The security checks (ACLs, VPN filtering..) that is available along with the packet path will be bypassed or skipped.
The IPSec tunnel is not created:
The tunnel negotiation process commences:
Once the IPSec tunnel is negotiated and the tunnel comes up:
The packet is allowed to pass through once the tunnel is up and since the bypass-checks option is applied, the security checks are skipped:
The following example traces a TCP packet in a directly connected hosts having the ARP entry for nexthop.
The following example traces a TCP packet that is dropped due to absence of a valid ARP entry for nexthop. Note that the drop reason provides the tip to check the ARP table.
The following example depicts packet tracer for sub-optimal routing with NAT and a reachable nexthop.
Related Commands
|
|
---|---|
Displays the capture configuration when no options are specified. |
pager
To set the default number of lines on a page before the “ ---More---
”
prompt appears for Telnet sessions, use the pager command in global configuration mode.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
This command was changed from a privileged EXEC mode command to a global configuration mode command. The terminal pager command was added as the privileged EXEC mode command. |
Usage Guidelines
This command changes the default pager line setting for Telnet sessions. If you want to temporarily change the setting only for the current session, use the terminal pager command.
If you Telnet to the admin context, then the pager line setting follows your session when you change to other contexts, even if the pager command in a given context has a different setting. To change the current pager setting, enter the terminal pager command with a new setting, or you can enter the pager command in the current context. In addition to saving a new pager setting to the context configuration, the pager command applies the new setting to the current Telnet session.
Examples
The following example changes the number of lines displayed to 20:
Related Commands
page style
To customize the WebVPN page displayed to WebVPN users when they connect to the security appliance, use the page style command in webvpn customization configuration mode. To remove the command from the configuration and cause the value to be inherited, use the no form of this command.
Syntax Description
Cascading Style Sheet (CSS) parameters (maximum 256 characters). |
Defaults
The default page style is background-color:white;font-family:Arial,Helv,sans-serif
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The style option is expressed as any valid Cascading Style Sheet (CSS) parameters. Describing these parameters is beyond the scope of this document. For more information about CSS parameters, consult CSS specifications at the World Wide Web Consortium (W3C) website at www.w3.org. Appendix F of the CSS 2.1 Specification contains a convenient list of CSS parameters, and is available at www.w3.org/TR/CSS21/propidx.html.
Here are some tips for making the most common changes to the WebVPN pages—the page colors:
- You can use a comma-separated RGB value, an HTML color value, or the name of the color if recognized in HTML.
- RGB format is 0,0,0, a range of decimal numbers from 0 to 255 for each color (red, green, blue); the comma separated entry indicates the level of intensity of each color to combine with the others.
- HTML format is #000000, six digits in hexadecimal format; the first and second represent red, the third and fourth green, and the fifth and sixth represent blue.

Note To easily customize the WebVPN pages, we recommend that you use ASDM, which has convenient features for configuring style elements, including color swatches and preview capabilities.
Examples
The following example customizes the page style to large:
Related Commands
|
|
parameters
To enter parameters configuration mode to set parameters for an inspection policy map, use the parameters command in policy-map configuration mode.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Modular Policy Framework lets you configure special actions for many application inspections. When you enable an inspection engine using the inspect command in the Layer 3/4 policy map (the policy-map command), you can also optionally enable actions as defined in an inspection policy map created by the policy-map type inspect command. For example, enter the inspect dns dns_policy_map command where dns_policy_map is the name of the inspection policy map.
An inspection policy map may support one or more parameters commands. Parameters affect the behavior of the inspection engine. The commands available in parameters configuration mode depend on the application.
Examples
The following example shows how to set the maximum message length for DNS packets in the default inspection policy map:
Related Commands
|
|
---|---|
Creates an inspection class map to match traffic specific to an application. |
|
participate
To force the device to participate in the virtual load-balancing cluster, use the participate command in VPN load-balancing configuration mode. To remove a device from participation in the cluster, use the no form of this command.
Syntax Description
Defaults
The default behavior is that the device does not participate in the vpn load-balancing cluster.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
You must first configure the interface using the interface and nameif commands, and use the vpn load-balancing command to enter VPN load-balancing mode. You must also have previously configured the cluster IP address using the cluster ip command and configured the interface to which the virtual cluster IP address refers.
This command forces this device to participate in the virtual load-balancing cluster. You must explicitly issue this command to enable participation for a device.
All devices that participate in a cluster must share the same cluster-specific values: ip address, encryption settings, encryption key, and port.

Note When using encryption, you must have previously configured the command isakmp enable inside, where inside designates the load-balancing inside interface. If isakmp is not enabled on the load-balancing inside interface, you get an error message when you try to configure cluster encryption.
If isakmp was enabled when you configured the cluster encryption command, but was disabled before you configured the participate command, you get an error message when you enter the participate command, and the local device will not participate in the cluster.
Examples
The following is an example of a VPN load-balancing command sequence that includes a participate command that enables the current device to participate in the vpn load-balancing cluster:
Related Commandsciscoasa(config-load-balancing)# participate
|
|
---|---|
passive-interface (ipv6 router ospf)
To suppress the sending and receiving of routing updates on an interface or across all interfaces that are using an OSPFv3 process, use the passive-interface command in ipv6 router ospf configuration mode. To reenable routing updates on an interface or across all intterfaces that are using an OSPFv3 process, use the no form of this command.
passive-interface [ interface_name ]
no passive-interface [ interface_name ]
Syntax Description
(Optional) Specifies the interface name on which the OSPFv3 process is running. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Examples
The following example suppresses the sending and receiving of routing updates on the inside interface.
Related Commands
|
|
---|---|
Displays the router configuration commands in the running configuration. |
passive-interface (isis)
To select ISIS hello packets and routing updates on interfaces while still including the interface addresses in the topology database, use the passive-interface command in router isis configuration mode. To reenable outgoing hello packets and routing updates, use the no form of this command.
passive-interface [default | inside | management | management2]
no passive-interface [default | inside | management | management2]
Syntax Description
Defaults
The default is to suppress routing updates on all interfaces.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Examples
The following example suppresses the sending and receiving of routing updates on the inside interface.
Related Commands
passive-interface (router eigrp)
To disable the sending and receiving of EIGRP routing updates on an interface, use the passive-interface command in router eigrp configuration mode. To reenable routing updates on an interface, use the no form of this command.
passive-interface { default | if_name }
no passive-interface { default | if_name }
Syntax Description
(Optional) The name of the interface, as specified by the nameif command, to passive mode. |
Defaults
All interfaces are enabled for active routing (sending and receiving routing updates) when routing is enabled for that interface.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Enables passive routing on the interface. For EIGRP, this disables the transmission and reception of routing updates on that interface.
You can have more than one passive-interface command in the EIGRP configuration. You can use the passive-interface default command to disable EIGRP routing on all interfaces, and then use the no passive-interface command to enable EIGRP routing on specific interfaces.
Examples
The following example sets the outside interface to passive EIGRP. The other interfaces on the security appliance send and receive EIGRP updates.
The following example sets all interfaces except the inside interface to passive EIGRP. Only the inside interface will send and receive EIGRP updates.
Related Commands
|
|
---|---|
Displays the router configuration commands in the running configuration. |
passive-interface (router rip)
To disable the transmission of RIP routing updates on an interface, use the passive-interface command in router rip configuration mode. To reenable RIP routing updates on an interface, use the no form of this command.
passive-interface { default | if_name }
no passive-interface { default | if_name }
Syntax Description
Defaults
All interfaces are enabled for active RIP when RIP is enabled.
If an interface or the default keyword is not specified, the commands defaults to default and appears in the configuration as passive-interface default.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Enables passive RIP on the interface. The interface listens for RIP routing broadcasts and uses that information to populate the routing tables, but does not broadcast routing updates.
Examples
The following example sets the outside interface to passive RIP. The other interfaces on the security appliance send and receive RIP updates.
Related Commands
|
|
---|---|
Enables the RIP routing process and enters rip router configuration mode. |
|
passwd
To set the login password for Telnet, use the passwd command in global configuration mode. To reset the password, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
Usage Guidelines
When you enable Telnet with the telnet command, you can log in with the password set by the passwd comamnd. After you enter the login password, you are in user EXEC mode. If you configure CLI authentication per user for Telnet using the aaa authentication telnet console command, then this password is not used.
This password is also used for Telnet sessions from the switch to the ASASM (see the session command).
Examples
The following example sets the password to Pa$$w0rd:
The following example sets the password to an encrypted password that you copied from another ASA:
Related Commands
|
|
---|---|
Shows the currently logged in username and the user privilege level. |
|
password (crypto ca trustpoint)
To specify a challenge phrase that is registered with the CA during enrollment, use the password command in crypto ca trustpoint configuration mode. To restore the default setting, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command lets you specify the revocation password for the certificate before actual certificate enrollment begins. The specified password is encrypted when the updated configuration is written to NVRAM by the ASA.
The CA typically uses a challenge phrase to authenticate a subsequent revocation request.
If this command is enabled, you will not be prompted for a password during certificate enrollment.
Examples
The following example enters crypto ca trustpoint configuration mode for trustpoint central, and includes a challenge phrase registered with the CA in the enrollment request for trustpoint central:
Related Commands
|
|
---|---|
password encryption aes
To enable password encryption using a master passphrase, use the password encryption aes command in global configuration mode. To disable password encryption, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
You must enter both the key config-key password-encrypt command and the password encryption aes command in any order to trigger password encryption. Enter write memory to save the encrypted passwords to the startup configuration. Otherwise, passwords in the startup configuration may still be visible. In multiple context mode, use write memory all in the system execution space to save all context configurations. If you later disable password encryption using the no password encryption aes command, all existing encrypted passwords are left unchanged, and as long as the master passphrase exists, the encrypted passwords will be decrypted, as required by the application.
This command will only be accepted in a secure session, for example by console, SSH, or ASDM via HTTPS.
Enabling or changing password encryption in Active/Standby failover causes a write standby, which replicates the active configuration to the standby unit. Without this replication, the encrypted passwords on the standby unit will differ even though they use the same passphrase; configuration replication ensures that the configurations are the same. For Active/Active failover, you must manually enter write standby. A write standby can cause traffic interruption in Active/Active mode, because the configuration is cleared on the secondary unit before the new configuration is synced. You should make all contexts active on the primary ASA using the failover active group 1 and failover active group 2 commands, enter write standby, and then restore the group 2 contexts to the secondary unit using the no failover active group 2 command.
The write erase command when followed by the reload command will remove the master passphrase and all configuration if it is lost.
Examples
The following example sets the passphrase used for generating the encryption key, and enables password encryption:
ciscoasa(config)#
key config-key password-encryption
Related Commands
|
|
---|---|
Removes the master passphrase if it is lost when followed by the reload command. |
password-history
This command appears in the configuration for the username attributes command when you enable the password-policy reuse-interval command and is not user-configurable. It stores previous passwords in an encrypted form.
password-history hash1,hash2,hash3...
Syntax Description
Shows previous passwords that have been hashed using PBKDF2 (Password-Based Key Derivation Function 2). |
Command Default
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command is not user-configurable, and only shows in show output when you enable the password-policy reuse-interval command.
Examples
The following example changes a password two times, and then shows the previous hashed passwords:
Related Commands
|
|
---|---|
password-management
To enable password management, use the password-management command in tunnel-group general-attributes configuration mode. To disable password management, use the no form of this command. To reset the number of days to the default value, use the no form of the command with the password-expire-in-days keyword specified.
password-management [ password-expire-in-days days ]
no password-management password-expire-in-days [ days ]
Syntax Description
Defaults
The default is no password management. If you do not specify the password-expire-in-days keyword for an LDAP server, the default length of time to start warning before the current password expires is 14 days.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The ASA supports password management for the RADIUS and LDAP protocols. It supports the “password-expire-in-days” option for LDAP only.
You can configure password management for IPsec remote access and SSL VPN tunnel-groups.
When you configure the password-management command, the ASA notifies the remote user at login that the user’s current password is about to expire or has expired. The ASA then offers the user the opportunity to change the password. If the current password has not yet expired, the user can still log in using that password.
This command is valid for AAA servers that support such notification; that is, natively to LDAP servers and RADIUS proxied to an NT 4.0 or Active Directory server. The ASA ignores this command if RADIUS or LDAP authentication has not been configured.

Note Some RADIUS servers that support MSCHAP currently do not support MSCHAPv2. This command requires MSCHAPv2 so please check with your vendor.
The ASA, releases 7.1 and later, generally supports password management for the following connection types when authenticating with LDAP or with any RADIUS configuration that supports MS-CHAPv2:
- AnyConnect VPN Client (ASA software version 8.0 and higher)
- IPsec VPN Client
- Clientless SSL VPN (ASA software version 8.0 and higher) WebVPN (ASA software versions 7.1 through 7.2.x)
- SSL VPN Client full tunneling client
These RADIUS configurations include RADIUS with LOCAL authentication, RADIUS with Active Directory/Kerberos Windows DC, RADIUS with NT/4.0 Domain, and RADIUS with LDAP.
Password management is not supported for any of these connection types for Kerberos/Active Directory (Windows password) or NT 4.0 Domain. The RADIUS server (for example, Cisco ACS) could proxy the authentication request to another authentication server. However, from the ASA perspective, it is talking only to a RADIUS server.

Note For LDAP, the method to change a password is proprietary for the different LDAP servers on the market. Currently, the ASA implements the proprietary password management logic only for Microsoft Active Directory and Sun LDAP servers.
Native LDAP requires an SSL connection. You must enable LDAP over SSL before attempting to do password management for LDAP. By default, LDAP uses port 636.
Note that this command does not change the number of days before the password expires, but rather, the number of days ahead of expiration that the ASA starts warning the user that the password is about to expire.
If you do specify the password-expire-in-days keyword, you must also specify the number of days.
Specifying this command with the number of days set to 0 disables this command. The ASA does not notify the user of the pending expiration, but the user can change the password after it expires.
Note Radius does not provide a password change, or provide a password change prompt.
Examples
The following example sets the days before password expiration to begin warning the user of the pending expiration to 90 for the WebVPN tunnel group “testgroup”:
The following example uses the default value of 14 days before password expiration to begin warning the user of the pending expiration for the IPsec remote access tunnel group “QAgroup”:
Related Commands
|
|
---|---|
Enables negotiation of password update during RADIUS authentication (Deprecated). |
|
password-parameter
To specify the name of the HTTP POST request parameter in which a user password must be submitted for SSO authentication, use the password-parameter command in aaa-server-host configuration mode. This is an SSO with the HTTP Forms command.

Note To configure SSO with HTTP correctly, you must have a thorough working knowledge of authentication and HTTP exchanges.
Syntax Description
Syntax DescriptionSyntax Description
The name of the password parameter included in the HTTP POST request. The maximum password length is 128 characters. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The WebVPN server of the ASA uses an HTTP POST request to submit a single sign-on authentication request to an authenticating web server. The required command password-parameter specifies that the POST request must include a user password parameter for SSO authentication.

Note At login, the user enters the actual password value, which is entered into the POST request and passed on to the authenticating web server.
Examples
The following example, entered in aaa-server-host configuration mode, specifies a password parameter named user_password:
Related Commands
password-policy authenticate enable
To determine whether users are allowed to modify their own user account, use the password-policy authenticate enable command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy authenticate enable
no password-policy authenticate enable
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
If authentication is enabled, the username command does not allow users to change their own password or delete their own account. In addition, the clear configure username command does not allow users to delete their own account.
Examples
The following example shows how to enable users to modify their user account:
Related Commands
|
|
---|---|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
Sets the minimum number of lower case characters that passwords may have. |
password-policy lifetime
To set password policy for the current context and the interval in days after which passwords expire, use the password-policy lifetime command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy lifetime value
no password-policy lifetime value
Syntax Description
Specifies the password lifetime. Valid values range from 0 to 65535 days. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Passwords have a specified maximum lifetime. A lifetime interval of 0 days specifies that local user passwords never expire. Note that passwords expire at 12:00 a.m. of the day following lifetime expiration.
Examples
The following example specifies a password lifetime value of 10 days:
Related Commands
|
|
---|---|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
Sets the minimum number of lower case characters that passwords may have. |
password-policy minimum-changes
To set the minimum number of characters that must be changed between new and old passwords, use the password-policy minimum-changes command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-changes value
no password-policy minimum-changes value
Syntax Description
Specifies the number of characters that must be changed between new and old passwords. Valid values range from 0 to 64 characters. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
New passwords must include a minimum of 4 character changes from the current password and are considered changed only if they do not appear anywhere in the current password.
Examples
The following example specifies a minimum number of character changes between old and new passwords of 6 characters:
Related Commands
|
|
---|---|
Sets the password lifetime in days after which passwords expire. |
|
Sets the minimum number of lowercase characters that passwords may have. |
password-policy minimum-length
To set the minimum length of passwords, use the password-policy minimum-length command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-length value
no password-policy minimum-length value
Syntax Description
Specifies the minimum length for passwords. Valid values range from 3 to 32 characters. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
If the minimum length is less than any of the other minimum attributes (changes, lower case, upper case, numeric, and special), an error message appears and the minimum length is not changed. The recommended password length is 8 characters.
Examples
The following example specifies a minimum number of characters for passwords as 8:
Related Commands
password-policy minimum-lowercase
To set the minimum number of lower case characters that passwords may have, use the password-policy minimum-lowercase command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-lowercase value
no password-policy minimum-lowercase value
Syntax Description
Specifies the minimum number of lower case characters for passwords. Valid values range from 0 to 64 characters. |
Defaults
The default number of minimum lower case characters is 0, which means there is no minimum.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command sets the minimum number of lower case characters that passwords may have. Valid values range from 0 to 64 characters.
Examples
The following example specifies the minimum number of lower case characters that passwords may have as 6:
Related Commands
|
|
---|---|
Sets the password lifetime value in days after which passwords expire. |
|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
password-policy minimum-numeric
To set the minimum number of numeric characters that passwords may have, use the password-policy minimum-numeric command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-numeric value
no password-policy minimum-numeric value
Syntax Description
Specifies the minimum number of numeric characters for passwords. Valid values range from 0 to 64 characters. |
Defaults
The default number of minimum numeric characters is 0, which means there is no minimum.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command sets the minimum number of numeric characters that passwords may have. Valid values range from 0 to 64 characters.
Examples
The following example specifies the minimum number of numeric characters that passwords may have as 8:
Related Commands
|
|
---|---|
Sets the password lifetime value in days after which passwords expire. |
|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
password-policy minimum-special
To set the minimum number of special characters that passwords may have, use the password-policy minimum-special command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-special value
no password-policy minimum-special value
Syntax Description
Specifies the minimum number of special characters for passwords. Valid values range from 0 to 64 characters. |
Defaults
The default number of minimum special characters is 0, which means there is no minimum.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command sets the minimum number of special characters that passwords may have. Special characters include the following: !, @, #, $, %, ^, &, *, '(‘ and ‘)’.
Examples
The following example specifies the minimum number of special characters that passwords may have as 2:
Related Commands
|
|
---|---|
Sets the password lifetime value in days after which passwords expire. |
|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
password-policy minimum-uppercase
To set the minimum number of upper case characters that passwords may have, use the password-policy minimum-uppercase command in global configuration mode. To set the corresponding password policy attribute to its default value, use the no form of this command.
password-policy minimum-uppercase value
no password-policy minimum-uppercase value
Syntax Description
Specifies the minimum number of upper case characters for passwords. Valid values range from 0 to 64 characters. |
Defaults
The default number of minimum upper case characters is 0, which means there is no minimum.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command sets the minimum number of upper case characters that passwords may have. Valid values range from 0 to 64 characters.
Examples
The following example specifies the minimum number of upper case characters that passwords may have as 4:
Related Commands
|
|
---|---|
Sets the password lifetime value in days after which passwords expire. |
|
Sets the minimum number of characters that must be changed between new and old passwords. |
|
password-policy reuse-interval
To prohibit the reuse of a password for a local username, use the password-policy reuse-interval command in global configuration mode. To remove this restriction, use the no form of this command.
password-policy reuse-interval value
no password-policy reuse-interval [ value ]
Syntax Description
Sets the number of previous passwords that you cannot use when creating a new password, between 2 and 7. |
Command Default
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
You can prohibit the reuse of a password that matches previously used passwords. The previous passwords are stored in the configuration under each username in encrypted form using the password-history command; this command is not user-configurable.
Examples
The following example sets the password resuse interval to 5:
Related Commands
|
|
---|---|
Stores previous username passwords. This command is not user-configurable. |
|
password-policy username-check
To prohibit a password that matches a username, use the password-policy username-check command in global configuration mode. To remove this restriction, use the no form of this command.
password-policy username-check
no password-policy username-check
Syntax Description
Command Default
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
You can prohibit a password that matches the name in a username command.
Examples
The following example restricts the password from matching the username john_crichton:
Related Commands
|
|
---|---|
Stores previous username passwords. This command is not user-configurable. |
|
password-prompt
To customize the password prompt of the WebVPN page login box that is displayed to WebVPN users when they connect to the security appliance, use the password-prompt command from webvpn customization mode:
password-prompt { text | style } value
[ no ] password-prompt { text | style } value
To remove the command from the configuration and cause the value to be inherited, use the no form of the command.
Syntax Description
The actual text to display (maximum 256 characters), or Cascading Style Sheet (CSS) parameters (maximum 256 characters). |
Defaults
The default text of the password prompt is “PASSWORD:”.
The default style of the password prompt is color:black;font-weight:bold;text-align:right.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The style option is expressed as any valid Cascading Style Sheet (CSS) parameters. Describing these parameters is beyond the scope of this document. For more information about CSS parameters, consult CSS specifications at the World Wide Web Consortium (W3C) website at www.w3.org. Appendix F of the CSS 2.1 Specification contains a convenient list of CSS parameters, and is available at www.w3.org/TR/CSS21/propidx.html.
Here are some tips for making the most common changes to the WebVPN pages—the page colors:
- You can use a comma-separated RGB value, an HTML color value, or the name of the color if recognized in HTML.
- RGB format is 0,0,0, a range of decimal numbers from 0 to 255 for each color (red, green, blue); the comma separated entry indicates the level of intensity of each color to combine with the others.
- HTML format is #000000, six digits in hexadecimal format; the first and second represent red, the third and fourth green, and the fifth and sixth represent blue.

Note To easily customize the WebVPN pages, we recommend that you use ASDM, which has convenient features for configuring style elements, including color swatches and preview capabilities.
Examples
In the following example, the text is changed to “Corporate Password:”, and the default style is changed with the font weight increased to bolder:
Related Commands
|
|
password-storage
To let users store their login passwords on the client system, use the password-storage enable command in group-policy configuration mode or username configuration mode. To disable password storage, use the password-storage disable command.
To remove the password-storage attribute from the running configuration, use the no form of this command. This enables inheritance of a value for password-storage from another group policy.
password-storage {enable | disable}
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Enable password storage only on systems that you know to be in secure sites.
This command has no bearing on interactive hardware client authentication or individual user authentication for hardware clients.
Examples
The following example shows how to enable password storage for the group policy named FirstGroup:
peer-id-validate
To specify whether to validate the identity of the peer using the peer’s certificate, use the peer-id-validate command in tunnel-group ipsec-attributes mode. To return to the default value, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
You can apply this attribute to all IPsec tunnel-group types.
Examples
The following example entered in config-ipsec configuration mode, requires validating the peer using the identity of the peer’s certificate for the IPsec LAN-to-LAN tunnel group named 209.165.200.225:
Related Commands
|
|
---|---|
Shows the tunnel group configuration for all tunnel groups or for a particular tunnel group. |
|
Configures the tunnel-group ipsec-attributes for this group. |
peer ip
To manually specify the peer VXLAN tunnel endpoint (VTEP) IP address, use the peer ip command in nve configuration mode. To remove the peer address, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
If you specify the peer IP address, you cannot use multicast group discovery. Multicast is not supported in multiple context mode, so manual configuration is the only option. You can only specify one peer for the VTEP.
Examples
The following example configures the GigabitEthernet 1/1 interface as the VTEP source interface, and specifies a peer IP address of 10.1.1.2:
Related Commands
perfmon
To display performance information, use the perfmon command in privileged EXEC mode.
perfmon {verbose | interval seconds | quiet | settings} [ detail ]
Syntax Description
Displays performance monitor information at the ASA console. |
|
Specifies the number of seconds before the performance display is refreshed on the console. |
|
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The perfmon command allows you to monitor the performance of the ASA. Use the show perfmon command to display the information immediately. Use the perfmon verbose command to display the information every 2 minutes continuously. Use the perfmon interval seconds command with the perfmon verbose command to display the information continuously every number of seconds that you specify.
An example of the performance information is displayed as follows:
This information lists the number of translations, connections, Websense requests, address translations (called “fixups”), and AAA transactions that occur each second.
Examples
This example shows how to display the performance monitor statistics every 30 seconds on the ASA console:
Related Commands
|
|
---|---|
periodic
To specify a recurring (weekly) time range for functions that support the time-range feature, use the periodic command in time-range configuration mode. To disable, use the no form of this command.
periodic days-of-the-week time to [ days-of-the-week ] time
no periodic days-of-the-week time to [ days-of-the-week ] time
Syntax Description
Defaults
If a value is not entered with the periodic command, access to the ASA as defined with the time-range command is in effect immediately and always on.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
To implement a time-based ACL, use the time-range command to define specific times of the day and week. Then use the with the access-list extended time-range command to bind the time range to an ACL.
The periodic command is one way to specify when a time range is in effect. Another way is to specify an absolute time period with the absolute command. Use either of these commands after the time-range global configuration command, which specifies the name of the time range. Multiple periodic entries are allowed per time-range command.
If the end days-of-the-week value is the same as the start value, you can omit them.
If a time-range command has both absolute and periodic values specified, then the periodic commands are evaluated only after the absolute start time is reached, and are not further evaluated after the absolute end time is reached.
The time-range feature relies on the system clock of the ASA; however, the feature works best with NTP synchronization.
Examples
|
|
---|---|
The following example shows how to allow access to the ASA on Monday through Friday, 8:00 a.m. to 6:00 p.m. only:
The following example shows how to allow access to the ASA on specific days (Monday, Tuesday, and Friday), 10:30 a.m. to 12:30 p.m.:
Related Commands
|
|
---|---|
Configures a policy for permitting or denying IP traffic through the ASA. |
|
Restores default settings for the time-range command absolute and periodic keywords. |
|
periodic-authentication certificate
To enable periodic certificate verification, use the periodic-authentication certificate command. To inherit the settings from the default group policy, use the no form of this command.
periodic-authentication certificate <time in hours> | none
[no] periodic-authentication certificate <time in hours> | none
Syntax Description
Defaults
The periodic certificate verification is disabled by default.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The command by default will be periodic-authentication certificate none for the default group-policy. Other groups policies inherit the setting from the default policy unless changed.
Examples
permit-errors
To allow invalid GTP packets or packets that otherwise would fail parsing and be dropped, use the permit-errors command in policy map parameters configuration mode. To return to the default behavior, where all invalid packets or packets that failed parsing are dropped. use the no form of this command.
Syntax Description
Defaults
By default, all invalid packets or packets that failed parsing are dropped.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Use the permit-errors command in a GTP inspection policy map parameters to allow any packets that are invalid or encountered an error during inspection of the message to be sent through the ASA instead of being dropped.
Examples
The following example permits traffic containing invalid packets or packets that failed parsing:
Related Commands
|
|
---|---|
Applies a specific GTP map to use for application inspection. |
permit-response
To configure GSN or PGW pooling, use the permit-response command in policy map parameters configuration mode. Use the no form of this command remove the pooling relationship.
permit-response to-object-group to_obj_group_id from-object-group from_obj_group_id
no permit-response to-object-group to_obj_group_id from-object-group from_obj_group_id
Syntax Description
Defaults
The ASA drops GTP responses from GSNs or PGWs that were not specified in the GTP request.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
This command was added. GTP inspection supports IPv4 addresses only. |
|
Usage Guidelines
When the ASA performs GTP inspection, by default the ASA drops GTP responses from GSNs or PGWs that were not specified in the GTP request. This situation occurs when you use load-balancing among a pool of GSNs or PGWs to provide efficiency and scalability of GPRS.
To configure GSN/PGW pooling and thus support load balancing, create a network object group that specifies the GSN/PGW endpoints and specify this on the from-object-group parameter. Likewise, create a network object group for the SGSN/SGW and select it on the to-object-group parameter. If the GSN/PGW responding belongs to the same object group as the GSN/PGW that the GTP request was sent to and if the SGSN/SGW is in an object group that the responding GSN/PGW is permitted to send a GTP response to, the ASA permits the response.
The network object group can identify the endpoints by host address or by the subnet that contains them.
Examples
The following example permits GTP responses from any host on the 192.168.32.0 network to the host with the IP address 192.168.112.57:
Related Commands
|
|
---|---|
Applies a specific GTP map to use for application inspection. |
|
pfs
To enable PFS, use the pfs enable command in group-policy configuration mode. To disable PFS, use the pfs disable command. To remove the PFS attribute from the running configuration, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The PFS setting on the VPN Client and the ASA must match.
Use the no form of this command to allow the inheritance of a value for PFS from another group policy.
In IPsec negotiations, PFS ensures that each new cryptographic key is unrelated to any previous key.
Examples
The following example shows how to set PFS for the group policy named FirstGroup:
phone-proxy (Deprecated)
To configure the Phone Proxy instance, use the phone-proxy command in global configuration mode.
To remove the Phone Proxy instance, use the no form of this command.
no phone-proxy phone_proxy_name
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Only one Phone Proxy instance can be configured on the ASA.
If NAT is configured for the HTTP proxy server, the global or mapped IP address of the HTTP proxy server with respect to the IP phones is written to the Phone Proxy configuration file.
Examples
The following example shows the use of the phone-proxy command to configure the Phone Proxy instance:
ciscoasa(config)# phone-proxy asa_phone_proxy
ciscoasa(config-phone-proxy)#
media-termination address 192.0.2.25 interface inside
ciscoasa(config-phone-proxy)#
media-termination address 128.106.254.3 interface outside
ciscoasa(config-phone-proxy)#
ctl-file asactl
ciscoasa(config-phone-proxy)#
cluster-mode nonsecure
ciscoasa(config-phone-proxy)#
timeout secure-phones 00:05:00
ciscoasa(config-phone-proxy)#
disable service-settings
Related Commands
|
|
---|---|
Specifies the CTL file to create for Phone Proxy configuration or the CTL file to parse from Flash memory. |
|
Specifies the CTL file to use for Phone Proxy configuration. |
|
pim
To re-enable PIM on an interface, use the pim command in interface configuration mode. To disable PIM, use the no form of this command.
Syntax Description
Defaults
The multicast-routing command enables PIM on all interfaces by default.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The multicast-routing command enables PIM on all interfaces by default. Only the no form of the pim command is saved in the configuration.

Note PIM is not supported with PAT. The PIM protocol does not use ports and PAT only works with protocols that use ports.
Examples
The following example disables PIM on the selected interface:
Related Commands
|
|
---|---|
pim accept-register
To configure the ASA to filter PIM register messages, use the pim accept-register command in global configuration mode. To remove the filtering, use the no form of this command.
pim accept-register { list acl | route-map map-name }
Syntax Description
Specifies an access list name or number. Use only extended host ACLs with this command. |
|
Specifies a route-map name. Use extended host ACLs in the referenced route-map. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command is used to prevent unauthorized sources from registering with the RP. If an unauthorized source sends a register message to the RP, the ASA will immediately send back a register-stop message.
Examples
The following example restricts PIM register messages to those from sources defined in the access list named “no-ssm-range”:
Related Commands
|
|
---|---|
pim bidir-neighbor-filter
To control which bidir-capable neighbors can participate in the DF election, use the pim bidir-neighbor-filter command in interface configuration mode. To remove the filtering, use the no form of this command.
no pim bidir-neighbor-filter acl
Syntax Description
Specifies an access list name or number. The access list defines the neighbors that can participate in bidir DF elections. Use only standard ACLs with this command; extended ACLs are not supported. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
Bidirectional PIM allows multicast routers to keep reduced state information. All of the multicast routers in a segment must be bidirectionally enabled for bidir to elect a DF.
The pim bidir-neighbor-filter command enables the transition from a sparse-mode-only network to a bidir network by letting you specify the routers that should participate in DF election while still allowing all routers to participate in the sparse-mode domain. The bidir-enabled routers can elect a DF from among themselves, even when there are non-bidir routers on the segment. Multicast boundaries on the non-bidir routers prevent PIM messages and data from the bidir groups from leaking in or out of the bidir subset cloud.
When the pim bidir-neighbor-filter command is enabled, the routers that are permitted by the ACL are considered to be bidir-capable. Therefore:
Examples
The following example allows 10.1.1.1 to become a PIM bidir neighbor:
Related Commands
|
|
---|---|
Defines a multicast boundary for administratively-scoped multicast addresses. |
|
pim bsr-border
To prevent bootstrap router (BSR) messages from being sent or received through an interface, use the pim bsr-border command in interface configuration mode.

Note A border interface in a PIM sparse mode (PIM-SM) domain requires special precautions to avoid exchange of certain traffic with a neighboring domain reachable through that interface, especially if that domain is also running PIM-SM.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
When this command is configured on an interface, no PIM Version 2 BSR messages will be sent or received through the interface. Configure an interface bordering another PIM domain with this command to avoid BSR messages from being exchanged between the two domains. BSR messages should not be exchanged between different domains, because routers in one domain may elect rendezvous points (RPs) in the other domain, resulting in protocol malfunction or loss of isolation between the domains.

Note This command does not set up multicast boundaries. It only sets up a PIM domain BSR message border.
Examples
The following example configures the interface to be PIM domain border:
Related Commands
|
|
---|---|
pim bsr-candidate
To configure the router to announce its candidacy as a bootstrap router (BSR), use the pim bsr-candidate command in global configuration mode. To remove this router as a candidate for being a bootstrap router, use the no form of this command.
pim bsr-candidate interface-name [hash-mask-length [priority]]
Syntax Description
Defaults
The command is disabled by default.
When a device is configured as a bsr-candidate without hash-length and priority, it assumes a default hash length of 0 and priority as 0.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command causes the ASA to send bootstrap messages to all its PIM neighbors, with the address of the designated interface as the BSR address. Each neighbor compares the BSR address with the address it had from previous bootstrap messages (not necessarily received on the same interface). If the current address is the same or higher address, it caches the current address and forwards the bootstrap message. Otherwise, it drops the bootstrap message.
This ASA continues to be the BSR until it receives a bootstrap message from another candidate BSR saying that it has a higher priority (or if the same priority, a higher IP address).
Examples
The following example configures the ASA as a candidate boot strap router (C-BSR) on the inside interface, with a hash length of 30 and a priority of 10:
Related Commands
|
|
---|---|
pim dr-priority
To configure the neighbor priority on the ASA used for designated router election, use the pim dr-priority command in interface configuration mode. To restore the default priority, use the no form of this command.
Syntax Description
A number from 0 to 4294967294. This number is used to determine the priority of the device when determining the designated router. Specifying 0 prevents the ASA from becoming the designated router. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The device with the largest priority value on an interface becomes the PIM designated router. If multiple devices have the same designated router priority, then the device with the highest IP address becomes the DR. If a device does not include the DR-Priority Option in hello messages, it is regarded as the highest-priority device and becomes the designated router. If multiple devices do not include this option in their hello messages, then the device with the highest IP address becomes the designated router.
Examples
The following example sets the DR priority for the interface to 5:
Related Commands
|
|
---|---|
pim hello-interval
To configure the frequency of the PIM hello messages, use the pim hello-interval command in interface configuration mode. To restore the hello-interval to the default value, use the no form of this command.
no pim hello-interval [ seconds ]
Syntax Description
The number of seconds that the ASA waits before sending a hello message. Valid values range from 1 to 3600 seconds. The default value is 30 seconds. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Examples
The following example sets the PIM hello interval to 1 minute:
Related Commands
|
|
---|---|
pim join-prune-interval
To configure the PIM join/prune interval, use the pim join-prune-interval command in interface configuration mode. To restore the interval to the default value, use the no form of this command.
pim join-prune-interval seconds
no pim join-prune-interval [ seconds ]
Syntax Description
The number of seconds that the ASA waits before sending a join/prune message. Valid values range from 10 to 600 seconds. 60 seconds is the default. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Examples
The following example sets the PIM join/prune interval to 2 minutes:
Related Commands
|
|
---|---|
pim neighbor-filter
To control which neighbor routers can participate in PIM, use the pim neighbor-filter command in interface configuration mode. To remove the filtering, use the no form of this command.
Syntax Description
Specifies an access list name or number. Use only standard ACLs with this command; extended ACLs are not supported. |
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
This command defines which neighbor routers can participate in PIM. If this command is not present in the configuration then there are no restrictions.
Multicast routing and PIM must be enabled for this command to appear in the configuration. If you disable multicast routing, this command is removed from the configuration.
Examples
The following example allows the router with the IP address 10.1.1.1 to become a PIM neighbor on interface GigabitEthernet 0/2:
Related Commands
|
|
---|---|
pim old-register-checksum
To allow backward compatibility on a rendezvous point (RP) that uses old register checksum methodology, use the pim old-register-checksum command in global configuration mode. To generate PIM RFC-compliant registers, use the no form of this command.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The ASA software accepts register messages with checksum on the PIM header and only the next 4 bytes rather than using the Cisco IOS method—accepting register messages with the entire PIM message for all PIM message types. The pim old-register-checksum command generates registers compatible with Cisco IOS software.
Examples
The following example configures the ASA to use the old checksum calculations:
Related Commands
|
|
---|---|
pim rp-address
To configure the address of a PIM rendezvous point (RP), use the pim rp-address command in global configuration mode. To remove an RP address, use the no form of this command.
pim rp-address ip_address [ acl ] [ bidir ]
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
All routers within a common PIM sparse mode (PIM-SM) or bidir domain require knowledge of the well-known PIM RP address. The address is statically configured using this command.

Note The ASA does not support Auto-RP; you must use the pim rp-address command to specify the RP address.
You can configure a single RP to serve more than one group. The group range specified in the access list determines the PIM RP group mapping. If the an access list is not specified, the RP for the group is applied to the entire IP multicast group range (224.0.0.0/4).

Note The ASA always advertises the bidir capability in the PIM hello messages regardless of the actual bidir configuration.
Examples
The following example sets the PIM RP address to 10.0.0.1 for all multicast groups:
Related Commands
|
|
---|---|
pim spt-threshold infinity
To change the behavior of the last hop router to always use the shared tree and never perform a shortest-path tree (SPT) switchover, use the pim spt-threshold infinity command in global configuration mode. To restore the default value, use the no form of this command.
pim spt-threshold infinity [ group-list acl ]
Syntax Description
(Optional) Indicates the source groups restricted by the access list. The acl argument must specify a standard ACL; extended ACLs are not supported. |
Defaults
The last hop PIM router switches to the shortest-path source tree by default.
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
If the group-list keyword is not used, this command applies to all multicast groups.
Examples
The following example causes the last hop PIM router to always use the shared tree instead of switching to the shortest-path source tree:
Related Commands
|
|
---|---|
ping
To test connectivity from a specified interface to an IP address, use the ping command in privileged EXEC mode. The parameters available differ for regular ICMP-based ping compared to TCP ping. Enter the command without parameters to be prompted for values, including characteristics not available as parameters.
ping [ if_name ] host [ repeat count ] [ timeout seconds ] [ data pattern ] [ size bytes ] [ validate ]
ping tcp [ if_name ] host port [ repeat count ] [ timeout seconds ] [ source host port]

Note The source and port options are only available with the tcp option; the data, size, and validate options are not available with the tcp option.
Syntax Description
Defaults
Command Modes
The following table shows the modes in which you can enter the command:
|
|
|
|||
---|---|---|---|---|---|
|
|
|
|
||
|
|
||||
Command History
|
|
---|---|
Usage Guidelines
The ping command allows you to determine if the ASA has connectivity or if a host is available on the network.
When using regular ICMP-based ping, ensure that you do not have icmp rules that prohibit these packets (if you do not use ICMP rules, all ICMP traffic is allowed). If you want internal hosts to ping external hosts over ICMP, you must do one of the following:
- Create an ICMP access-list command for an echo reply; for example, to give ping access to all hosts, use the access-list acl_grp permit icmp any any command and bind the access-list command to the interface that you want to test using the access-group command.
- Configure the ICMP inspection engine using the inspect icmp command. For example, adding the inspect icmp command to the class default_inspection class for the global service policy allows echo replies through the ASA for echo requests initiated by internal hosts.
When using TCP ping, you must ensure that access policies allow TCP traffic on the ports you specify.
This configuration is required to allow the ASA to respond and accept messages generated from the ping command. The ping command output shows if the response was received. If a host is not responding after you enter the ping command, a message similar to the following appears:
To route ping packets, the ASA uses the data routing table, and falls back to the management routing table only if there is not a matching route in the data table. If you specify an interface name in the command, the ASA will send the ping through that interface, and will not use a route lookup. Specifying the source IP address for TCP ping does not affect how the packet is routed. For example, even if you manually specify the source address to match an interface IP address, then the ping will not be sent out of that interface. The egress interface is only determined by the if_name or the route lookup.
Use the show interface command to ensure that the ASA is connected to the network and is passing traffic. The address of the specified if_name is used as the source address of the ping. unless you specify a different source address (TCP ping only).
You can also perform an extended ping by entering ping without parameters. You are prompted for the parameters, including some characteristics not available as keywords.
Examples
The following example shows how to determine if other IP addresses are visible from the ASA:
The following example specifies a host using a DNS name:
The following is an example of an extended ping:
Related Commands
|
|
---|---|
Configures access rules for ICMP traffic that terminates at an interface. |
|