![]() |
Table Of Contents
Release Notes for the Cisco ASA Series, Version 9.0(x)
New Features in Version 9.0(4)
New Features in Version 9.0(3)
New Features in Version 9.0(2)
New Features in Version 9.0(1)
Downloading the Software from Cisco.com
Upgrading a Failover Pair or ASA Cluster
Upgrading an Active/Standby Failover Pair
Upgrading an Active/Active Failover Pair
Resolved Caveats in Version 9.0(4)
Resolved Caveats in Version 9.0(3)
Resolved Caveats in Version 9.0(2)
Obtaining Documentation and Submitting a Service Request
Release Notes for the Cisco ASA Series, Version 9.0(x)
Released: October 29, 2012Updated: December 5, 2013This document contains release information for Cisco ASA software Version 9.0(1) through 9.0(4). This document includes the following sections:
•
Obtaining Documentation and Submitting a Service Request
Important Notes
•
ASA Clustering—Due to many caveat fixes, we recommend the 9.0(2) release or later for ASA clustering. If you are running 9.0(1) or 9.1(1), you should upgrade to 9.0(2) or later. Note that due to CSCue72961, hitless upgrading is not supported.
•
Downgrading issues—Upgrading to Version 9.0 includes ACL migration (see the "ACL Migration in Version 9.0" section). Therefore, you cannot downgrade from 9.0 with a migrated configuration. Be sure to make a backup copy of your configuration before you upgrade so you can downgrade using the old configuration if required.
•
Per-session PAT disabled when upgrading— Starting in Version 9.0, by default, all TCP PAT traffic and all UDP DNS traffic use per-session PAT (see the xlate per-session command in the command reference). If you upgrade to Version 9.0 from an earlier release, to maintain the existing functionality of multi-session PAT, the per-session PAT feature is disabled during configuration migration. The ASA adds the following deny rules:
xlate per-session deny tcp any4 any4xlate per-session deny tcp any4 any6xlate per-session deny tcp any6 any4xlate per-session deny tcp any6 any6xlate per-session deny udp any4 any4 eq domainxlate per-session deny udp any4 any6 eq domainxlate per-session deny udp any6 any4 eq domainxlate per-session deny udp any6 any6 eq domainTo enable per-session PAT after you upgrade, enter:
clear configure xlateThe above deny rules are cleared so that only the default permit rules are still in place, which enables per-session PAT.
•
No Payload Encryption for export—You can purchase some models with No Payload Encryption. For export to some countries, payload encryption cannot be enabled on the Cisco ASA series. The ASA software senses a No Payload Encryption model and disables the following features:
–
Unified Communications
–
VPN
You can still install the Strong Encryption (3DES/AES) license for use with management connections and encrypted route messages for OSPFv3. For example, you can use ASDM HTTPS/SSL, SSHv2, Telnet and SNMPv3. You can also download the dynamic database for the Botnet Traffic Filer (which uses SSL) and redirect traffic to Cloud Web Security.
•
Two ASA caches are used for processing server certificate verification information. The global cache is 30 seconds while the session cache is 30 minutes, although the cache timeout values are not configurable.
Limitations and Restrictions
•
Clientless SSL VPN with a self-signed certificate on the ASA—When the ASA uses a self-signed certificate or an untrusted certificate, Firefox 4 and later and Safari are unable to add security exceptions when browsing using an IPv6 address HTTPS URL (FQDN URL is OK): the "Confirm Security Exception" button is disabled. See https://bugzilla.mozilla.org/show_bug.cgi?id=633001. This caveat affects all SSL connections originating from Firefox or Safari to the ASA (including clientless SSL VPN connections, and ASDM connections). To avoid this caveat, configure a proper certificate for the ASA that is issued by a trusted certificate authority. For Internet Explorer 9 and later, use compatibility mode.
•
Citrix Mobile Receiver and accessing Virtual Desktop Infrastructure (VDI):
–
CSD is not supported.
–
HTTP redirect is not supported.
–
Using Citrix Receiver mobile clients to access web interface of Citrix servers is not supported.
–
Certificate or smart card authentication is not supported as a means of auto sign-on.
–
You must install the XML service and configure it on XenApp and XenDesktop servers.
–
Make sure that the ports 443, 1494, 2598, and 80 are open on any intermediate firewalls between the ASA and the XenApp/XenDesktop server.
–
The password-expire-in-days notification on a tunnel group that is used by VDI is not supported.
•
When configuring for IKEv2, for security reasons, you should use groups 21, 20, 19, 24, 14, and 5. We do not recommend Diffie Hellman Group1 or Group2. For example, use
crypto ikev2 policy 10 group 21 20 19 24 14 5•
With a heavy load of users (around 150 or more) using a WebVPN plugin, you may experience large delays because of the processing overload. Using Citrix web interface reduces the ASA rewrite overhead. To track the progress of the enhancement request to allow WebVPN plug files to be cached on the ASA, refer to CSCud11756.
•
Inter-context OSPF adjacency is not supported. To work around this, use the point-to-point non-broadcast options under the interface configuration and the neighbor command under the router ospf section. See the following example for reference:
interface Redundant1.189description to corenameif coresecurity-level 0ip address 172.18.0.2 255.255.255.0ospf network point-to-point non-broadcastrouter ospf 1router-id 172.18.0.2network 172.18.0.0 255.255.255.0 area 0log-adj-changesneighbor 172.18.0.7 interface core•
(ASA 5510, ASA 5520, ASA 5540, and ASA 5550 only) We strongly recommend that you enable hardware processing using the crypto engine large-mod-accel command instead of software for large modulus operations such as 2048-bit certificates and DH5 keys. If you continue to use software processing for large keys, you could experience significant performance degradation due to slow session establishment for IPsec and SSL VPN connections. We recommend that you initially enable hardware processing during a low-use or maintenance period to minimize a temporary packet loss that can occur during the transition of processing from software to hardware.
Note
For the ASA 5540 and ASA 5550 using SSL VPN, in specific load conditions, you may want to continue to use software processing for large keys. If VPN sessions are added very slowly and the ASA runs at capacity, then the negative impact to data throughput is larger than the positive impact for session establishment.
The ASA 5580/5585-X platforms already integrate this capability; therefore, crypto engine commands are not applicable on these platforms.•
Only users with a privilege level of 15 may copy files to the ASA using the secure copy protocol (SCP).
System Requirements
For information about ASA/ASDM requirements and compatibility, see Cisco ASA Compatibility:
http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html
For VPN compatibility, see the Supported VPN Platforms, Cisco ASA 5500 Series:
http://www.cisco.com/en/US/docs/security/asa/compatibility/asa-vpn-compatibility.html
New Features
•
New Features in Version 9.0(4)
•
New Features in Version 9.0(3)
•
New Features in Version 9.0(2)
•
New Features in Version 9.0(1)
Note
New, changed, and deprecated syslog messages are listed in the syslog message guide.
New Features in Version 9.0(4)
Released: December 5, 2013There are no new features in Version 9.0(4).
New Features in Version 9.0(3)
Released: July 22, 2013Table 1 lists the new features for ASA Version 9.0(3).
Note
Features added in 8.4(4.x), 8.4(5), and 8.4(6) are not included in 9.0(3) unless they were listed in the 9.0(1) feature table.
New Features in Version 9.0(2)
Released: February 25, 2013Table 2 lists the new features for ASA Version 9.0(2).
Note
Features added in 8.4(4.x), 8.4(5), and 8.4(6) are not included in 9.0(2) unless they were listed in the 9.0(1) feature table.
New Features in Version 9.0(1)
Released: October 29, 2012Table 3 lists the new features for ASA Version 9.0(1).
Note
Features added in 8.4(4.x), 8.4(5), and 8.4(6) are not included in 9.0(1) unless they are explicitly listed in this table.
Table 3 New Features for ASA Version 9.0(1)
Feature Description Firewall FeaturesCisco TrustSec integration
Cisco TrustSec provides an access-control solution that builds upon an existing identity-aware infrastructure to ensure data confidentiality between network devices and integrate security access services on one platform. In the Cisco TrustSec solution, enforcement devices utilize a combination of user attributes and end-point attributes to make role-based and identity-based access control decisions.
In this release, the ASA integrates with Cisco TrustSec to provide security group based policy enforcement. Access policies within the Cisco TrustSec domain are topology-independent, based on the roles of source and destination devices rather than on network IP addresses.
The ASA can utilize the Cisco TrustSec solution for other types of security group based policies, such as application inspection; for example, you can configure a class map containing an access policy based on a security group.
We introduced or modified the following commands: access-list extended, cts sxp enable, cts server-group, cts sxp default, cts sxp retry period, cts sxp reconcile period, cts sxp connection peer, cts import-pac, cts refresh environment-data, object-group security, security-group, show running-config cts, show running-config object-group, clear configure cts, clear configure object-group, show cts, show object-group, show conn security-group, clear cts, debug cts.
We introduced the following MIB: CISCO-TRUSTSEC-SXP-MIB.
Cisco Cloud Web Security (ScanSafe)
Cisco Cloud Web Security provides content scanning and other malware protection service for web traffic. It can also redirect and report about web traffic based on user identity.
Note
Clientless SSL VPN is not supported with Cloud Web Security; be sure to exempt any clientless SSL VPN traffic from the ASA service policy for Cloud Web Security.
We introduced or modified the following commands: class-map type inspect scansafe, default user group, http[s] (parameters), inspect scansafe, license, match user group, policy-map type inspect scansafe, retry-count, scansafe, scansafe general-options, server {primary | backup}, show conn scansafe, show scansafe server, show scansafe statistics, user-identity monitor, whitelist.
Extended ACL and object enhancement to filter ICMP traffic by ICMP code
ICMP traffic can now be permitted/denied based on ICMP code.
We introduced or modified the following commands: access-list extended, service-object, service.
Unified communications support on the ASASM
The ASASM now supports all Unified Communications features.
NAT support for reverse DNS lookups
NAT now supports translation of the DNS PTR record for reverse DNS lookups when using IPv4 NAT, IPv6 NAT, and NAT64 with DNS inspection enabled for the NAT rule.
Per-session PAT
The per-session PAT feature improves the scalability of PAT and, for ASA clustering, allows each member unit to own PAT connections; multi-session PAT connections have to be forwarded to and owned by the master unit. At the end of a per-session PAT session, the ASA sends a reset and immediately removes the xlate. This reset causes the end node to immediately release the connection, avoiding the TIME_WAIT state. Multi-session PAT, on the other hand, uses the PAT timeout, by default 30 seconds. For "hit-and-run" traffic, such as HTTP or HTTPS, the per-session feature can dramatically increase the connection rate supported by one address. Without the per-session feature, the maximum connection rate for one address for an IP protocol is approximately 2000 per second. With the per-session feature, the connection rate for one address for an IP protocol is 65535/average-lifetime.
By default, all TCP traffic and UDP DNS traffic use a per-session PAT xlate. For traffic that can benefit from multi-session PAT, such as H.323, SIP, or Skinny, you can disable per-session PAT by creating a per-session deny rule.
We introduced the following commands: xlate per-session, clear configure xlate, show running-config xlate.
ARP cache additions for non-connected subnets
The ASA ARP cache only contains entries from directly-connected subnets by default. You can now enable the ARP cache to also include non-directly-connected subnets. We do not recommend enabling this feature unless you know the security risks. This feature could facilitate denial of service (DoS) attack against the ASA; a user on any interface could send out many ARP replies and overload the ASA ARP table with false entries.
You may want to use this feature if you use:
•
Secondary subnets.
•
Proxy ARP on adjacent routes for traffic forwarding.
We introduced the following command: arp permit-nonconnected.
Also available in 8.4(5).
SunRPC change from dynamic ACL to pin-hole mechanism
Previously, Sun RPC inspection does not support outbound access lists because the inspection engine uses dynamic access lists instead of secondary connections.
In this release, when you configure dynamic access lists on the ASA, they are supported on the ingress direction only and the ASA drops egress traffic destined to dynamic ports. Therefore, Sun RPC inspection implements a pinhole mechanism to support egress traffic. Sun RPC inspection uses this pinhole mechanism to support outbound dynamic access lists.
Also available in 8.4(4.1).
Inspection reset action change
Previously, when the ASA dropped a packet due to an inspection engine rule, the ASA sent only one RST to the source device of the dropped packet. This behavior could cause resource issues.
In this release, when you configure an inspection engine to use a reset action and a packet triggers a reset, the ASA sends a TCP reset under the following conditions:
•
The ASA sends a TCP reset to the inside host when the service resetoutbound command is enabled. (The service resetoutbound command is disabled by default.)
•
The ASA sends a TCP reset to the outside host when the service resetinbound command is enabled. (The service resetinbound command is disabled by default.)
For more information, see the service command in the ASA command reference.
This behavior ensures that a reset action will reset the connections on the ASA and on inside servers; therefore countering denial of service attacks. For outside hosts, the ASA does not send a reset by default and information is not revealed through a TCP reset.
Also available in 8.4(4.1).
Increased maximum connection limits for service policy rules
The maximum number of connections for service policy rules was increased from 65535 to 2000000.
We modified the following commands: set connection conn-max, set connection embryonic-conn-max, set connection per-client-embryonic-max, set connection per-client-max.
Also available in 8.4(5)
High Availability and Scalability FeaturesASA Clustering for the ASA 5580 and 5585-X
ASA Clustering lets you group multiple ASAs together as a single logical device. A cluster provides all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices. ASA clustering is supported for the ASA 5580 and the ASA 5585-X; all units in a cluster must be the same model with the same hardware specifications. See the configuration guide for a list of unsupported features when clustering is enabled.
We introduced or modified the following commands: channel-group, clacp system-mac, clear cluster info, clear configure cluster, cluster exec, cluster group, cluster interface-mode, cluster-interface, conn-rebalance, console-replicate, cluster master unit, cluster remove unit, debug cluster, debug lacp cluster, enable (cluster group), health-check, ip address, ipv6 address, key (cluster group), local-unit, mac-address (interface), mac-address pool, mtu cluster, port-channel span-cluster, priority (cluster group), prompt cluster-unit, show asp cluster counter, show asp table cluster chash-table, show cluster, show cluster info, show cluster user-identity, show lacp cluster, show running-config cluster.
OSPF, EIGRP, and Multicast for clustering
For OSPFv2 and OSPFv3, bulk synchronization, route synchronization, and spanned EtherChannels are supported in the clustering environment.
For EIGRP, bulk synchronization, route synchronization, and spanned EtherChannels are supported in the clustering environment.
Multicast routing supports clustering.
We introduced or modified the following commands: show route cluster, debug route cluster, show mfib cluster, debug mfib cluster.
Packet capture for clustering
To support cluster-wide troubleshooting, you can enable capture of cluster-specific traffic on the master unit using the cluster exec capture command, which is then automatically enabled on all of the slave units in the cluster. The cluster exec keywords are the new keywords that you place in front of the capture command to enable cluster-wide capture.
We modified the following commands: capture, show capture.
Logging for clustering
Each unit in the cluster generates syslog messages independently. You can use the logging device-id command to generate syslog messages with identical or different device IDs to make messages appear to come from the same or different units in the cluster.
We modified the following command: logging device-id.
Configure the connection replication rate during a bulk sync
You can now configure the rate at which the ASA replicates connections to the standby unit when using Stateful Failover. By default, connections are replicated to the standby unit during a 15 second period. However, when a bulk sync occurs (for example, when you first enable failover), 15 seconds may not be long enough to sync large numbers of connections due to a limit on the maximum connections per second. For example, the maximum connections on the ASA is 8 million; replicating 8 million connections in 15 seconds means creating 533 K connections per second. However, the maximum connections allowed per second is 300 K. You can now specify the rate of replication to be less than or equal to the maximum connections per second, and the sync period will be adjusted until all the connections are synchronized.
We introduced the following command: failover replication rate rate.
Also available in 8.4(4.1) and 8.5(1.7).
IPv6 FeaturesIPv6 Support on the ASA's outside interface for VPN Features.
This release of the ASA adds support for IPv6 VPN connections to its outside interface using SSL and IKEv2/IPsec protocols.
This release of the ASA continues to support IPv6 VPN traffic on its inside interface using the SSL protocol as it has in the past. This release does not provide IKEv2/IPsec protocol on the inside interface.
Remote Access VPN support for IPv6:
IPv6 Address Assignment PolicyYou can configure the ASA to assign an IPv4 address, an IPv6 address, or both an IPv4 and an IPv6 address to an AnyConnect client by creating internal pools of addresses on the ASA or by assigning a dedicated address to a local user on the ASA.
The endpoint must have the dual-stack protocol implemented in its operating system to be assigned both types of addresses.
Assigning an IPv6 address to the client is supported for the SSL protocol. This feature is not supported for the IKEv2/IPsec protocol.
We introduced the following commands: ipv6-vpn-addr-assign, vpn-framed-ipv6-address.
Remote Access VPN support for IPv6:
Assigning DNS Servers with IPv6 Addresses to group policiesDNS servers can be defined in a Network (Client) Access internal group policy on the ASA. You can specify up to four DNS server addresses including up to two IPv4 addresses and up to two IPv6 addresses.
DNS servers with IPv6 addresses can be reached by VPN clients when they are configured to use the SSL protocol. This feature is not supported for clients configured to use the IKEv2/IPsec protocol.
We modified the following command: dns-server value.
Remote Access VPN support for IPv6:
Split tunnelingSplit tunneling enables you to route some network traffic through the VPN tunnel (encrypted) and to route other network traffic outside the VPN tunnel (unencrypted or "in the clear"). You can now perform split tunneling on IPv6 network traffic by defining an IPv6 policy which specifies a unified access control rule.
IPv6 split tunneling is reported with the telemetric data sent by the Smart Call Home feature. If either IPv4 or IPv6 split tunneling is enabled, Smart Call Home reports split tunneling as "enabled." For telemetric data, the VPN session database displays the IPv6 data typically reported with session management.
You can include or exclude IPv6 traffic from the VPN "tunnel" for VPN clients configured to use the SSL protocol. This feature is not supported for the IKEv2/IPsec protocol.
We introduced the following command: ipv6-split-tunnel-policy.
Remote Access VPN support for IPv6:
AnyConnect Client Firewall RulesAccess control rules for client firewalls support access list entries for both IPv4 and IPv6 addresses.
ACLs containing IPv6 addresses can be applied to clients configured to use the SSL protocol. This feature is not supported for the IKEv2/IPsec protocol.
We modified the following command: anyconnect firewall-rule.
Remote Access VPN support for IPv6:
Client Protocol BypassThe Client Protocol Bypass 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 AnyConnect 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 AnyConnect 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 AnyConnect 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.
This feature can be used by clients configured to use the SSL or IKEv2/IPsec protocol.
We introduced the following command: client-bypass-protocol.
Remote Access VPN support for IPv6:
IPv6 Interface ID and prefixYou can now specify a dedicated IPv6 address for local VPN users.
This feature benefits users configured to use the SSL protocol. This feature is not supported for the IKEv2/IPsec protocol.
We introduced the following command: vpn-framed-ipv6-address.
Remote Access VPN support for IPv6:
Sending ASA FQDN to AnyConnect clientYou can return the FQDN of the ASA to the AnyConnect client to facilitate load balancing and session roaming.
This feature can be used by clients configured to use the SSL or IKEv2/IPsec protocol.
We introduced the following command: gateway-fqdn.
Remote Access VPN support for IPv6:
ASA VPN Load BalancingClients with IPv6 addresses can make AnyConnect connections through the public-facing IPv6 address of the ASA cluster or through a GSS server. Likewise, clients with IPv6 addresses can make AnyConnect VPN connections through the public-facing IPv4 address of the ASA cluster or through a GSS server. Either type of connection can be load-balanced within the ASA cluster.
For clients with IPv6 addresses to successfully connect to the ASAs public-facing IPv4 address, a device that can perform network address translation from IPv6 to IPv4 needs to be in the network.
This feature can be used by clients configured to use the SSL or IKEv2/IPsec protocol.
We modified the following commands: show run vpn load-balancing.
Remote Access VPN support for IPv6:
Dynamic Access Policies support IPv6 attributesWhen using ASA 9.0 or later with ASDM 6.8 or later, you can now specify these attributes as part of a dynamic access policy (DAP):
•
IPv6 addresses as a Cisco AAA attribute
•
IPv6 TCP and UDP ports as part of a Device endpoint attribute
•
Network ACL Filters (client)
This feature can be used by clients configured to use the SSL or IKEv2/IPsec protocol.
Remote Access VPN support for IPv6:
Session ManagementSession management output displays the IPv6 addresses in Public/Assigned address fields for AnyConnect connections, site-to-site VPN connections, and Clientless SSL VPN connections. You can add new filter keywords to support filtering the output to show only IPv6 (outside or inside) connections. No changes to IPv6 User Filters exist.
This feature can be used by clients configured to use the SSL protocol. This feature does not support IKEv2/IPsec protocol.
We modified the following command: show vpn-sessiondb.
NAT support for IPv6
NAT now supports IPv6 traffic, as well as translating between IPv4 and IPv6 (NAT64). Translating between IPv4 and IPv6 is not supported in transparent mode.
We modified the following commands: nat (in global and object network configuration mode), show conn, show nat, show nat pool, show xlate.
DHCPv6 relay
DHCP relay is supported for IPv6.
We introduced the following commands: ipv6 dhcprelay server, ipv6 dhcprelay enable, ipv6 dhcprelay timeout, clear config ipv6 dhcprelay, ipv6 nd managed-config-flag, ipv6 nd other-config-flag, debug ipv6 dhcp, debug ipv6 dhcprelay, show ipv6 dhcprelay binding, clear ipv6 dhcprelay binding, show ipv6 dhcprelay statistics, and clear ipv6 dhcprelay statistics.
OSPFv3
OSPFv3 routing is supported for IPv6. Note the following additional guidelines and limitations for OSPFv2 and OSPFv3:
Clustering
•
OSPFv2 and OSPFv3 support clustering.
•
When clustering is configured, OSPFv3 encryption is not supported. An error message appears if you try to configure OSPFv3 encryption in a clustering environment.
•
When using individual interfaces, make sure that you establish the master and slave units as either OSPFv2 or OSPFv3 neighbors.
•
When using individual interfaces, OSPFv2 adjacencies can only be established between two contexts on a shared interface on the master unit. Configuring static neighbors is supported only on point-to-point links; therefore, only one neighbor statement is allowed on an interface.
Other
•
OSPFv2 and OSPFv3 support multiple instances on an interface.
•
The ESP and AH protocol is supported for OSPFv3 authentication.
•
OSPFv3 supports Non-Payload Encryption.
We introduced or modified the following commands: ipv6 ospf cost, ipv6 ospf database-filter all out, ipv6 ospf dead-interval, ipv6 ospf hello-interval, ipv6 ospf mtu-ignore, ipv6 ospf neighbor, ipv6 ospf network, ipv6 ospf priority, ipv6 ospf retransmit-interval, ipv6 ospf transmit-delay, ipv6 router ospf, ipv6 router ospf area, ipv6 router ospf default, ipv6 router ospf default-information, ipv6 router ospf distance, ipv6 router ospf exit, ipv6 router ospf ignore, ipv6 router ospf log-adjacency-changes, ipv6 router ospf no, ipv6 router ospf redistribute, ipv6 router ospf router-id, ipv6 router ospf summary-prefix, ipv6 router ospf timers, area range, area virtual-link, default, default-information originate, distance, ignore lsa mospf, log-adjacency-changes, redistribute, router-id, summary-prefix, timers lsa arrival, timers pacing flood, timers pacing lsa-group, timers pacing retransmission, show ipv6 ospf, show ipv6 ospf border-routers, show ipv6 ospf database-filter, show ipv6 ospf flood-list, show ipv6 ospf interface, show ipv6 ospf neighbor, show ipv6 ospf request-list, show ipv6 ospf retransmission-list, show ipv6 ospf summary-prefix, show ipv6 ospf virtual-links, show ospf, show run ipv6 router, clear ipv6 ospf, clear configure ipv6 router, debug ospfv3.
Unified ACL for IPv4 and IPv6
ACLs now support IPv4 and IPv6 addresses. You can also specify a mix of IPv4 and IPv6 addresses for the source and destination. The IPv6-specific ACLs are deprecated. Existing IPv6 ACLs are migrated to extended ACLs.
ACLs containing IPv6 addresses can be applied to clients configured to use the SSL protocol. This feature is not supported for the IKEv2/IPsec protocol.
We modified the following commands: access-list extended, access-list webtype.
We removed the following commands: ipv6 access-list, ipv6 access-list webtype, ipv6-vpn-filter.
Mixed IPv4 and IPv6 object groups
Previously, network object groups could only contain all IPv4 addresses or all IPv6 addresses. Now network object groups can support a mix of both IPv4 and IPv6 addresses.
Note
You cannot use a mixed object group for NAT.
We modified the following command: object-group network.
Range of IPv6 addresses for a Network object
You can now configure a range of IPv6 addresses for a network object.
We modified the following command: range.
Inspection support for IPv6 and NAT64
We now support DNS inspection for IPv6 traffic.
We also support translating between IPv4 and IPv6 for the following inspections:
•
DNS
•
FTP
•
HTTP
•
ICMP
You can now also configure the service policy to generate a syslog message (767001) when unsupported inspections receive and drop IPv6 traffic.
We modified the following command: service-policy fail-close.
Remote Access FeaturesClientless SSL VPN:
Additional SupportWe have added additional support for these browsers, operating systems, web technologies and applications:
Internet browser support: Microsoft Internet Explorer 9, Firefox 4, 5, 6, 7, and 8
Operating system support: Mac OS X 10.7
Web technology support: HTML 5
Application Support: Sharepoint 2010
Clientless SSL VPN:
Enhanced quality for rewriter enginesThe clientless SSL VPN rewriter engines were significantly improved to provide better quality and efficacy. As a result, you can expect a better end-user experience for clientless SSL VPN users.
We did not add or modify any commands for this feature.
Also available in 8.4(4.1).
Clientless SSL VPN:
Citrix Mobile ReceiverThis feature provides secure remote access for Citrix Receiver applications running on mobile devices to XenApp and XenDesktop VDI servers through the ASA.
For the ASA to proxy Citrix Receiver to a Citrix Server, when users try to connect to Citrix virtualized resource, instead of providing the Citrix Server's address and credentials, users enter the ASA's SSL VPN IP address and credentials.
We modified the following command: vdi.
Clientless SSL VPN:
Enhanced Auto-sign-onThis feature improves support for web applications that require dynamic parameters for authentication.
Clientless SSL VPN:
Clientless Java Rewriter Proxy SupportThis feature provides proxy support for clientless Java plug-ins when a proxy is configured in client machines' browsers.
We did not add or modify any commands for this feature.
Clientless SSL VPN:
Remote File ExplorerThe Remote File Explorer provides users with a way to browse the corporate network from their web browser. When users click the Remote File System icon on the Cisco SSL VPN portal page, an applet is launched on the user's system displaying the remote file system in a tree and folder view.
We did not add or modify any commands for this feature.
Clientless SSL VPN:
Server Certificate ValidationThis feature enhances clientless SSL VPN support to enable SSL server certificate verification for remote HTTPS sites against a list of trusted CA certificates.
We modified the following commands: ssl-server-check, crypto, crypto ca trustpool, crl, certificate, revocation-check.
AnyConnect Performance Improvements
This feature improves throughput performance for AnyConnect TLS/DTLS traffic in multi-core platforms. It accelerates the SSL VPN datapath and provides customer-visible performance gains in AnyConnect, smart tunnels, and port forwarding.
We modified the following commands: crypto engine accelerator-bias and show crypto accelerator.
Custom Attributes
Custom attributes define and configure AnyConnect features that have not yet been added to ASDM. You add custom attributes to a group policy, and define values for those attributes.
For AnyConnect 3.1, custom attributes are available to support AnyConnect Deferred Upgrade.
Custom attributes can benefit AnyConnect clients configured for either IKEv2/IPsec or SSL protocols.
We added the following command: anyconnect-custom-attr.
Next Generation Encryption
The National Standards Association (NSA) specified a set of cryptographic algorithms that devices must support to meet U.S. federal standards for cryptographic strength. RFC 6379 defines the Suite B cryptographic suites. Because the collective set of algorithms defined as NSA Suite B are becoming a standard, the AnyConnect IPsec VPN (IKEv2 only) and public key infrastructure (PKI) subsystems now support them. The next generation encryption (NGE) includes a larger superset of this set adding cryptographic algorithms for IPsec V3 VPN, Diffie-Hellman Groups 14 and 24 for IKEv2, and RSA certificates with 4096 bit keys for DTLS and IKEv2.
The following functionality is added to ASA to support the Suite B algorithms:
•
AES-GCM/GMAC support (128-, 192-, and 256-bit keys)
–
IKEv2 payload encryption and authentication
–
ESP packet encryption and authentication
–
Hardware supported only on multi-core platforms
•
SHA-2 support (256-, 384-, and 512-bit hashes)
–
ESP packet authentication
–
Hardware and software supported only on multi-core platforms
•
ECDH support (groups 19, 20, and 21)
–
IKEv2 key exchange
–
IKEv2 PFS
–
Software only supported on single- or multi-core platforms
•
ECDSA support (256-, 384-, and 521-bit elliptic curves)
–
IKEv2 user authentication
–
PKI certificate enrollment
–
PKI certificate generation and verification
–
Software only supported on single- or multi-core platforms
New cryptographic algorithms are added for IPsecV3.
Note
Suite B algorithm support requires an AnyConnect Premium license for IKEv2 remote access connections, but Suite B usage for other connections or purposes (such as PKI) has no limitations. IPsecV3 has no licensing restrictions.
We introduced or modified the following commands: crypto ikev2 policy, crypto ipsec ikev2 ipsec-proposal, crypto key generate, crypto key zeroize, show crypto key mypubkey, show vpn-sessiondb.
Support for VPN on the ASASM
The ASASM now supports all VPN features.
Multiple Context Mode FeaturesSite-to-Site VPN in multiple context mode
Site-to-site VPN tunnels are now supported in multiple context mode.
New resource type for site-to-site VPN tunnels
New resource types, vpn other and vpn burst other, were created to set the maximum number of site-to-site VPN tunnels in each context.
We modified the following commands: limit-resource, show resource types, show resource usage, show resource allocation.
Dynamic routing in Security Contexts
EIGRP and OSPFv2 dynamic routing protocols are now supported in multiple context mode. OSPFv3, RIP, and multicast routing are not supported.
New resource type for routing table entries
A new resource class, routes, was created to set the maximum number of routing table entries in each context.
We modified the following commands: limit-resource, show resource types, show resource usage, show resource allocation.
Mixed firewall mode support in multiple context mode
You can set the firewall mode independently for each security context in multiple context mode, so some can run in transparent mode while others run in routed mode.
We modified the following command: firewall transparent.
Also available in Version 8.5(1).
Module FeaturesASA Services Module support on the Cisco 7600 switch
The Cisco 7600 series now supports the ASASM. For specific hardware and software requirements, see: http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html.
ASA 5585-X support for the ASA CX SSP-10 and -20
The ASA CX module lets you enforce security based on the complete context of a situation. This context includes the identity of the user (who), the application or website that the user is trying to access (what), the origin of the access attempt (where), the time of the attempted access (when), and the properties of the device used for the access (how). With the ASA CX module, you can extract the full context of a flow and enforce granular policies such as permitting access to Facebook but denying access to games on Facebook or permitting finance employees access to a sensitive enterprise database but denying the same to other employees.
We introduced or modified the following commands: capture, cxsc, cxsc auth-proxy, debug cxsc, hw-module module password-reset, hw-module module reload, hw-module module reset, hw-module module shutdown, session do setup host ip, session do get-config, session do password-reset, show asp table classify domain cxsc, show asp table classify domain cxsc-auth-proxy, show capture, show conn, show module, show service-policy.
Also available in 8.4(4.1).
ASA 5585-X Dual SSP support for the SSP-10 and SSP-20 (in addition to the SSP-40 and SSP-60); VPN support for Dual SSPs
The ASA 5585-X now supports dual SSPs using all SSP models (you can use two SSPs of the same level in the same chassis). VPN is now supported when using dual SSPs.
We did not modify any commands.
ACL Migration in Version 9.0
The following ACL configurations will be migrated when upgrading to Version 9.0.
IPv6 ACLs
IPv6 ACLs (ipv6 access-list) will be migrated to extended ACLs (access-list extended); IPv6 ACLs are no longer supported.
If IPv4 and IPv6 ACLs are applied on the same direction of an interface (access-group command), then the ACLs are merged:
•
If both IPv4 and IPv6 ACLs are not used anywhere other than the access-group, then the name of the IPv4 ACL is used for the merged ACL; the IPv6 access-list is removed.
•
If at least one of the ACLs is used in another feature, then a new ACL is created with the name IPv4-ACL-name_IPv6-ACL-name; the in-use ACL(s) continue to be used for other features. ACLs not in use are removed. If the IPv6 ACL is in use for another feature, it is migrated to an extended ACL of the same name.
Any Keyword
Now that ACLs support both IPv4 and IPv6, the any keyword now represents "all IPv4 and IPv6 traffic." Any existing ACLs that use the any keyword will be changed to use the any4 keyword, which denotes "all IPv4 traffic."
In addition, a separate keyword was introduced to designate "all IPv6 traffic": any6.
Note
The any4 and any6 keywords are not available for all commands that use the any keyword. For example, the NAT feature uses only the any keyword; any represents IPv4 traffic or IPv6 traffic depending on the context within the specific NAT command.
Upgrading the Software
This section describes how to upgrade to the latest version and includes the following topics:
•
Downloading the Software from Cisco.com
•
Upgrading a Failover Pair or ASA Cluster
Note
For ASDM procedures, see the ASDM documentation.
Upgrade Path and Migrations
•
If you are upgrading from a pre-8.3 release:
–
See the Cisco ASA 5500 Migration Guide to Version 8.3 and Later for important information about migrating your configuration.
–
You cannot upgrade directly to 9.0 or later. You must first upgrade to Version 8.3 or 8.4 for a successful migration.
•
When upgrading to Version 9.0, because of ACL migration, you cannot later perform a downgrade; be sure to back up your configuration file in case you want to downgrade. See the ACL migration section in the release notes for more information.
•
Software Version Requirements for Zero Downtime Upgrading:
The units in a failover configuration or ASA cluster should have the same major (first number) and minor (second number) software version. However, you do not need to maintain version parity on the units during the upgrade process; you can have different versions on the software running on each unit and still maintain failover support. To ensure long-term compatibility and stability, we recommend upgrading all units to the same version as soon as possible.
Table 1-4 shows the supported scenarios for performing zero-downtime upgrades.
Viewing Your Current Version
Use the show version command to verify the software version of your ASA.
Downloading the Software from Cisco.com
If you have a Cisco.com login, you can obtain the OS and ASDM images from the following website:
http://www.cisco.com/cisco/software/navigator.html?mdfid=279513386
This procedure assumes you put the images on a TFTP server, although other server types are supported.
Upgrading a Standalone Unit
This section describes how to install the ASDM and operating system (OS) images using TFTP. For FTP or HTTP, see the copy command.
Detailed Steps
Command PurposeStep 1
more system:running-configExample:hostname# more system:running-config
(If there is a configuration migration) The output shows the configuration on the terminal so that you can back up your configuration. Copy the output from this command, then paste the configuration in to a text file.
Note
If you are upgrading from a pre-8.3 version, then the running configuration is backed up automatically.
For other methods of backing up, see the configuration guide.
Step 2
copy tftp://server[/path]/asa_image_name {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname# copy tftp://10.1.1.1/asa901-smp-k9.bin disk0:/asa901-smp-k9.bin
Copies the ASA software to the active unit flash memory. For other methods than TFTP, see the copy command.
Step 3
copy tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:hostname# copy tftp://10.1.1.1/asdm-701.bin disk0:/asdm-701.bin
Copies the ASDM image to the active unit flash memory.
Step 4
configure terminal
Example:hostname(config)# configure terminal
If you are not already in global configuration mode, accesses global configuration mode.
Step 5
show running-config boot system
Example:hostname(config)# show running-config boot system
boot system disk0:/cdisk.bin
boot system disk0:/asa841-smp-k9.bin
Shows the current boot images configured (up to 4). The ASA uses the images in the order listed; if the first image is unavailable, the next image is used, and so on. You cannot insert a new image URL at the top of the list; to specify the new image to be first, you must remove any existing entries, and enter the image URLs in the order desired, according to the following steps.
Step 6
no boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# no boot system disk0:/cdisk.bin
hostname(config)# no boot system disk0:/asa841-smp-k9.bin
Removes any existing boot image configurations so you can enter the new boot image as your first choice.
Step 7
boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# boot system disk0://asa901-smp-k9.bin
Sets the ASA image to boot that you just uploaded.
Repeat this command for any backup images you want to use in case this image is unavailable. For example, you can re-enter the images you previously removed in Step 6.
Step 8
asdm image {disk0:/ | disk1:/}[path/]asdm_image_name
Example:hostname(config)# asdm image disk0:/asdm-701.bin
Sets the ASDM image to use that you just uploaded. You can only configure one ASDM image to use, so you do not need to first remove the existing configuration.
Step 9
write memory
Example:hostname(config)# write memory
Saves the new settings to the startup configuration.
Step 10
reload
Example:hostname# reload
Reloads the ASA.
Upgrading a Failover Pair or ASA Cluster
•
Upgrading an Active/Standby Failover Pair
•
Upgrading an Active/Active Failover Pair
Upgrading an Active/Standby Failover Pair
To upgrade the Active/Standby failover pair, perform the following steps.
Requirements
Perform these steps on the active unit.
Detailed Steps
Command PurposeStep 1
more system:running-configExample:active# more system:running-config
(If there is a configuration migration) The output shows the configuration on the terminal so that you can back up your configuration. Copy the output from this command, then paste the configuration in to a text file.
Note
If you are upgrading from a pre-8.3 version, then the running configuration is backed up automatically.
For other methods of backing up, see the configuration guide.
Step 2
copy tftp://server[/path]/asa_image_name {disk0:/ | disk1:/}[path/]asa_image_name
Example:active# copy tftp://10.1.1.1/asa911-smp-k8.bin disk0:/asa911-smp-k8.bin
Copies the ASA software to the active unit flash memory. For other methods than TFTP, see the copy command.
Step 3
failover exec mate copy /noconfirm tftp://server[/path]/filename {disk0:/ | disk1:/}[path/]filename
Example:active# failover exec mate copy /noconfirm tftp://10.1.1.1/asa911-smp-k8.bin disk0:/asa911-smp-k8.bin
Copies the software to the standby unit; be sure to specify the same path as for the active unit.
Step 4
copy tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:active# copy tftp://10.1.1.1/asdm-711.bin disk0:/asdm-711.bin
Copies the ASDM image to the active unit flash memory.
Step 5
failover exec mate copy /noconfirm tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:active# failover exec mate copy /noconfirm tftp://10.1.1.1/asdm-711.bin disk0:/asdm-711.bin
Copies the ASDM image to the standby unit; be sure to specify the same path as for the active unit.
Step 6
configure terminal
Example:active(config)# configure terminal
If you are not already in global configuration mode, accesses global configuration mode.
Step 7
show running-config boot system
Example:hostname(config)# show running-config boot system
boot system disk0:/cdisk.bin
boot system disk0:/asa841-smp-k8.bin
Shows the current boot images configured (up to 4). The ASA uses the images in the order listed; if the first image is unavailable, the next image is used, and so on. You cannot insert a new image URL at the top of the list; to specify the new image to be first, you must remove any existing entries, and enter the image URLs in the order desired, according to Step 8 and Step 9.
Step 8
no boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# no boot system disk0:/cdisk.bin
hostname(config)# no boot system disk0:/asa841-smp-k8.bin
Removes any existing boot image configurations so that you can enter the new boot image as your first choice.
Step 9
boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# boot system disk0://asa911-smp-k8.bin
Sets the ASA image to boot (the one you just uploaded).
Repeat this command for any backup images that you want to use in case this image is unavailable. For example, you can re-enter the images that you previously removed in Step 8.
Step 10
asdm image {disk0:/ | disk1:/}[path/]asdm_image_name
Example:hostname(config)# asdm image disk0:/asdm-711.bin
Sets the ASDM image to use (the one you just uploaded). You can only configure one ASDM image to use, so you do not need to first remove the existing configuration.
Step 11
write memory
Example:active(config)# write memory
Saves the new settings to the startup configuration.
Step 12
failover reload-standby
Example:active# failover reload-standby
Reloads the standby unit to boot the new image.
Wait for the standby unit to finish loading. Use the show failover command to verify that the standby unit is in the Standby Ready state.
Step 13
no failover active
Example:active# no failover active
Forces the active unit to fail over to the standby unit.
Step 14
reload
Example:active# reload
Reloads the former active unit (now the new standby unit). If you want to restore this unit to be active after it reloads, enter the failover active command.
Upgrading an Active/Active Failover Pair
To upgrade two units in an Active/Active failover configuration, perform the following steps.
Requirements
Perform these steps in the system execution space of the primary unit.
Detailed Steps
Command PurposeStep 1
more system:running-configExample:primary# more system:running-config
(If there is a configuration migration) The output shows the configuration on the terminal so that you can back up your configuration. Copy the output from this command, then paste the configuration in to a text file.
Note
If you are upgrading from a pre-8.3 version, then the running configuration is backed up automatically.
For other methods of backing up, see the configuration guide.
Step 2
copy tftp://server[/path]/asa_image_name {disk0:/ | disk1:/}[path/]asa_image_name
Example:primary# copy tftp://10.1.1.1/asa911-smp-k8.bin disk0:/asa911-smp-k8.bin
Copies the ASA software to the primary unit flash memory. For other methods than TFTP, see the copy command.
Step 3
failover exec mate copy /noconfirm tftp://server[/path]/filename {disk0:/ | disk1:/}[path/]filename
Example:primary# failover exec mate copy /noconfirm tftp://10.1.1.1/asa911-smp-k8.bin disk0:/asa911-smp-k8.bin
Copies the software to the secondary unit; be sure to specify the same path as for the primary unit.
Step 4
copy tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:primary# copy tftp://10.1.1.1/asdm-711.bin disk0:/asdm-711.bin
Copies the ASDM image to the primary unit flash memory.
Step 5
failover exec mate copy /noconfirm tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:primary# failover exec mate copy /noconfirm tftp://10.1.1.1/asdm-711.bin disk0:/asdm-711.bin
Copies the ASDM image to the secondary unit; be sure to specify the same path as for the active unit.
Step 6
failover active group 1
failover active group 2
Example:primary# failover active group 1
primary# failover active group 2
Makes both failover groups active on the primary unit.
Step 7
configure terminal
Example:primary(config)# configure terminal
If you are not already in global configuration mode, accesses global configuration mode.
Step 8
show running-config boot system
Example:hostname(config)# show running-config boot system
boot system disk0:/cdisk.bin
boot system disk0:/asa841-smp-k8.bin
Shows the current boot images configured (up to 4). The ASA uses the images in the order listed; if the first image is unavailable, the next image is used, and so on. You cannot insert a new image URL at the top of the list; to specify the new image to be first, you must remove any existing entries, and enter the image URLs in the order desired, according to Step 9 and Step 10.
Step 9
no boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# no boot system disk0:/cdisk.bin
hostname(config)# no boot system disk0:/asa841-smp-k8.bin
Removes any existing boot image configurations so that you can enter the new boot image as your first choice.
Step 10
boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# boot system disk0://asa911-smp-k8.bin
Sets the ASA image to boot (the one you just uploaded).
Repeat this command for any backup images that you want to use in case this image is unavailable. For example, you can re-enter the images that you previously removed in Step 9.
Step 11
asdm image {disk0:/ | disk1:/}[path/]asdm_image_name
Example:hostname(config)# asdm image disk0:/asdm-711.bin
Sets the ASDM image to use (the one you just uploaded). You can only configure one ASDM image to use, so you do not need to first remove the existing configuration.
Step 12
write memory
Example:primary(config)# write memory
Saves the new settings to the startup configuration.
Step 13
failover reload-standby
Example:primary# failover reload-standby
Reloads the secondary unit to boot the new image.
Wait for the secondary unit to finish loading. Use the show failover command to verify that both failover groups are in the Standby Ready state.
Step 14
no failover active group 1
no failover active group 2
Example:primary# no failover active group 1
primary# no failover active group 2
Forces both failover groups to become active on the secondary unit.
Step 15
reload
Example:primary# reload
Reloads the primary unit. If the failover groups are configured with the preempt command, they automatically become active on their designated unit after the preempt delay has passed. If the failover groups are not configured with the preempt command, you can return them to active status on their designated units using the failover active group command.
Upgrading an ASA Cluster
To upgrade all units in an ASA cluster, perform the following steps on the master unit. For multiple context mode, perform these steps in the system execution space.
Detailed Steps
Command PurposeStep 1
more system:running-configExample:master# more system:running-config
(If there is a configuration migration) Back up your configuration file. Copy the output from this command, then paste the configuration in to a text file.
For other methods of backing up, see the configuration guide.
Step 2
cluster exec copy /noconfirm tftp://server[/path]/asa_image_name {disk0:/ | disk1:/}[path/]asa_image_name
Example:master# cluster exec copy /noconfirm tftp://10.1.1.1/asa911-smp-k8.bin disk0:/asa911-smp-k8.bin
Copies the ASA software to all units in the cluster. For other methods than TFTP, see the copy command.
Step 3
cluster exec copy /noconfirm tftp://server[/path]/asdm_image_name {disk0:/ | disk1:/}[path/]asdm_image_name
Example:master# cluster exec copy /noconfirm tftp://10.1.1.1/asdm-711.bin disk0:/asdm-711.bin
Copies the ASDM image to all units in the cluster.
Step 4
configure terminal
Example:master(config)# configure terminal
If you are not already in global configuration mode, accesses global configuration mode.
Step 5
show running-config boot system
Example:hostname(config)# show running-config boot system
boot system disk0:/cdisk.bin
boot system disk0:/asa841-smp-k8.bin
Shows the current boot images configured (up to 4). The ASA uses the images in the order listed; if the first image is unavailable, the next image is used, and so on. You cannot insert a new image URL at the top of the list; to specify the new image to be first, you must remove any existing entries, and enter the image URLs in the order desired, according to Step 6 and Step 7.
Step 6
no boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# no boot system disk0:/cdisk.bin
hostname(config)# no boot system disk0:/asa841-smp-k8.bin
Removes any existing boot image configurations so that you can enter the new boot image as your first choice.
Step 7
boot system {disk0:/ | disk1:/}[path/]asa_image_name
Example:hostname(config)# boot system disk0://asa911-smp-k8.bin
Sets the ASA image to boot (the one you just uploaded).
Repeat this command for any backup images that you want to use in case this image is unavailable. For example, you can re-enter the images that you previously removed in Step 6.
Step 8
asdm image {disk0:/ | disk1:/}[path/]asdm_image_name
Example:hostname(config)# asdm image disk0:/asdm-711.bin
Sets the ASDM image to use (the one you just uploaded). You can only configure one ASDM image to use, so you do not need to first remove the existing configuration.
Step 9
write memory
Example:master(config)# write memory
Saves the new settings to the startup configuration.
Step 10
cluster exec unit slave-unit reload noconfirm
Example:master# cluster exec unit unit2 reload noconfirm
Reload each slave unit by repeating this command for each unit name. To avoid connection loss and allow traffic to stabilize, wait for each unit to come back up (approximately 5 minutes) before reloading the next unit.
To view member names, enter cluster exec unit ?, or enter the show cluster info command.
Step 11
no enable
Example:master(config)# no enable
Disables clustering on the master unit. Wait for 5 minutes for a new master to be selected and traffic to stabilize.
Do not enter write memory; when the master unit reloads, you want clustering to be enabled on it.
Step 12
reload noconfirm
Example:master# reload noconfirm
Reloads the master unit. A new election takes place for a new master unit. When the former master unit rejoins the cluster, it will be a slave.
Open Caveats
Table 5 contains open caveats in the latest maintenance release.
If you are running an older release, and you need to determine the open caveats for your release, then add the caveats in this section to the resolved caveats from later releases. For example, if you are running Version 9.0(1), then you need to add the caveats in this section to the resolved caveats from 9.0(2) and higher to determine the complete list of open caveats.
If you are a registered Cisco.com user, view more information about each caveat using the Bug Search at the following website:
https://tools.cisco.com/bugsearch
Resolved Caveats
•
Resolved Caveats in Version 9.0(4)
•
Resolved Caveats in Version 9.0(3)
•
Resolved Caveats in Version 9.0(2)
Resolved Caveats in Version 9.0(4)
Table 6 contains resolved caveats in ASA software Version 9.0(4).
If you are a registered Cisco.com user, view more information about each caveat using the Bug Search at the following website:
https://tools.cisco.com/bugsearch
Resolved Caveats in Version 9.0(3)
Table 7 contains resolved caveats in ASA software Version 9.0(3).
If you are a registered Cisco.com user, view more information about each caveat using the Bug Search at the following website:
https://tools.cisco.com/bugsearch
Resolved Caveats in Version 9.0(2)
Table 8 contains resolved caveats in ASA software Version 9.0(2).
If you are a registered Cisco.com user, view more information about each caveat using the Bug Search at the following website:
https://tools.cisco.com/bugsearch
End-User License Agreement
For information on the end-user license agreement, go to:
http://www.cisco.com/go/warranty
Related Documentation
For additional information on the ASA, see Navigating the Cisco ASA Series Documentation:
http://www.cisco.com/go/asadocs
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service request, and gathering additional information, see What's New in Cisco Product Documentation at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html.
Subscribe to What's New in Cisco Product Documentation, which lists all new and revised Cisco technical documentation, as an RSS feed and deliver content directly to your desktop using a reader application. The RSS feeds are a free service.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
©2012-2013 Cisco Systems, Inc. All rights reserved.