Smart Licensing Guidelines

• The maximum supported number of vCPUs is 16. The maximum supported memory is 64GB for ASA virtual deployed on all platforms other than AWS and OCI. For ASA virtual deployed on AWS and OCI, the maximum supported memory is 128GB. Any ASAv license can be used on any supported ASAv vCPU/memory configuration.

• Session limits for licensed features and unlicensed platform capabilities are set based on the amount of VM memory.

• Session limits for AnyConnect Client and TLS Proxy are determined by the ASAv platform entitlement; session limits are no longer associated with an ASAv model type (ASAv5/10/30/50).

• Session limits have a minimum memory requirement; in cases where the VM memory is below the minimum requirement, the session limits will be set for the maximum number supported by the amount of memory.

• There are no changes to existing entitlements; the entitlement SKU and display name will continue to include the model number (ASAv5/10/30/50).

• The entitlement sets the maximum throughput via a rate limiter.

• There is no change to customer ordering process.

Disk Storage

The ASAv supports a maximum virtual disk of 8 GB by default. You cannot increase the disk size beyond 8 GB. Keep this in mind when you provision your VM resources.

Context Mode Guidelines

Supported in single context mode only. Does not support multiple context mode.

Failover for High Availability Guidelines

For failover deployments, make sure that the standby unit has the same license entitlement; for example, both units should have the 2Gbps entitlement.

Important

When creating a high availability pair using ASAv, it is necessary to add the data interfaces to each ASAv in the same order. If the exact same interfaces are added to each ASAv, but in different order, errors may be presented at the ASAv console. Failover functionality may also be affected.

Unsupported ASA Features

The ASAv does not support the following ASA features:

• Clustering (for all entitlements, except KVM and VMware)

• Multiple context mode

• Active/Active failover

• EtherChannels

• Shared AnyConnect Premium Licenses

Limitations

• The ASAv is not compatible with the 1.9.5 i40en host driver for the x710 NIC. Older or newer driver versions will work. (VMware only)

Performance Guidelines

• Jumbo frame reservation on the 1 GB platform with 9 or more configured e1000 interfaces may cause the device to reload. If jumbo-frame reservation is enabled, reduce the number of interfaces to 8 or less. The exact number of interfaces will depend on how much memory is needed for the operation of other features configured, and could be less than 8.

Performance Guidelines

• Supports 10Gbps of aggregated traffic.

• Supports the following practices to improve ASAv performance:

  • Numa nodes

  • Multiple RX queues

  • SR-IOV provisioning

  • See Performance Tuning and Performance Tuning for more information.

• CPU pinning is recommended to achieve full throughput rates; see Increasing Performance on ESXi Configurations and Increasing Performance on KVM Configurations.

• Jumbo frame reservation with a mix of e1000 and i40e-vf interfaces may cause the i40e-vf interfaces to remain down. If jumbo-frame reservation is enabled, do not mix interface types that use e1000 and i40e-vf drivers.

Limitations

• Transparent mode is not supported.

• The ASAv is not compatible with the 1.9.5 i40en host driver for the x710 NIC. Older or newer driver versions will work. (VMware only)

• Not supported on Hyper-V.

The ASAv includes the following Gigabit Ethernet interfaces:

• Management 0/0

  For AWS and Azure, Management 0/0 can be a traffic-carrying “outside” interface.

• GigabitEthernet 0/0 through 0/8. Note that the GigabitEthernet 0/8 is used for the failover link when you deploy the ASAv as part of a failover pair.

  Note

  To simply configuration migration, Ten GigabitEthernet interfaces, like those available on the VMXNET3 driver, are labeled GigabitEthernet. This has no impact on the actual interface speed and is cosmetic only. The ASAv defines GigabitEthernet interfaces using the E1000 driver as 1Gbps links. Note that VMware no longer recommends using the E1000 driver.

• Hyper-V supports up to eight interfaces. Management 0/0 and GigabitEthernet 0/0 through 0/6. You can use GigabitEthernet 0/6 as a failover link.

The ASAv supports the following vNICs. Mixing vNICs, such as e1000 and vmxnet3, on the same ASAv is not supported.

Disable LRO for VMware and VMXNET3

Large Receive Offload (LRO) is a technique for increasing inbound throughput of high-bandwidth network connections by reducing CPU overhead. It works by aggregating multiple incoming packets from a single stream into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets that have to be processed. However, LRO can lead to TCP perfomance problems where network packet delivery may not flow consistently and could be "bursty" in congested networks.

Important

VMware enables LRO by default to increase overall throughput. It is therefore a requirement to disable LRO for ASAv deployments on this platform.

You can disable LRO directly on the ASAv machine. Power off the virtual machine before you make any configuration changes.

1. Find the ASAv machine in the vSphere Web Client inventory.

   1. To find a virtual machine, select a data center, folder, cluster, resource pool, or host.

   2. Click the Related Objects tab and click Virtual Machines.

2. Right-click the virtual machine and select Edit Settings.

3. Click VM Options.

4. Expand Advanced.

5. Under Configuration Parameters, click the Edit Configuration button.

6. Click Add Parameter and enter a name and value for the LRO parameters:

   • Net.VmxnetSwLROSL | 0

   • Net.Vmxnet3SwLRO | 0

   • Net.Vmxnet3HwLRO | 0

   • Net.Vmxnet2SwLRO | 0

   • Net.Vmxnet2HwLRO | 0

   Note	Optionally, if the LRO parameters exist, you can examine the values and change them if needed. If a parameter is equal to 1, LRO is enabled. If equal to 0, LRO is disabled.

7. Click OK to save your changes and exit the Configuration Parameters dialog box.

8. Click Save.

See the following VMware support articles for more information:

• VMware KB 1027511

• VMware KB 2055140

The specific hardware used for ASAv deployment can vary, depending on size and usage requirements. Licensing for the ASAv explains the compliant resource scenarios that match license entitlement for the different ASAv platforms. In addition, SR-IOV Virtual Functions require specific system resources.

Host Operating System and Hypervisor Support

SR-IOV support and VF drivers are available for:

• Linux 2.6.30 kernel or later

The ASAv with SR-IOV interfaces is currently supported on the following hypervisors:

• VMware vSphere/ESXi

• QEMU/KVM

• AWS

Hardware Platform Support

Note	You should deploy the ASAv on any server class x86 CPU device capable of running the supported virtualization platforms.

This section describes hardware guidelines for SR-IOV interfaces. Although these are guidelines and not requirements, using hardware that does not meet these guidelines may result in functionality problems or poor performance.

A server that supports SR-IOV and that is equipped with an SR-IOV-capable PCIe adapter is required. You must be aware of the following hardware considerations:

• The capabilities of SR-IOV NICs, including the number of VFs available, differ across vendors and devices.

• Not all PCIe slots support SR-IOV.

• SR-IOV-capable PCIe slots may have different capabilities.

  Note	You should consult your manufacturer's documentation for SR-IOV support on your system.

• For VT-d enabled chipsets, motherboards, and CPUs, you can find information from this page of virtualization-capable IOMMU supporting hardware. VT-d is a required BIOS setting for SR-IOV systems.

• For VMware, you can search their online Compatibility Guide for SR-IOV support.

• For KVM, you can verify CPU compatibility. Note that for the ASAv on KVM we only support x86 hardware.

  Note	We tested the ASAv with the Cisco UCS C-Series Rack Server. Note that the Cisco UCS-B server does not support the ixgbe-vf vNIC.

Supported NICs for SR-IOV

• Intel Ethernet Network Adapter X710

  Attention

  The ASAv is not compatible with the 1.9.5 i40en host driver for the x710 NIC. Older or newer driver versions will work. (VMware only)

• Intel Ethernet Server Adapter X520 - DA2

CPUs

• x86_64 multicore CPU

  Intel Sandy Bridge or later (Recommended)

  Note	We tested the ASAv on Intel's Broadwell CPU (E5-2699-v4) at 2.3GHz.

• Cores

  • Minimum of 8 physical cores per CPU socket

  • The 8 cores must be on a single socket.

  Note	CPU pinning is recommended to achieve full throughput rates on the ASAv50 and ASAv100; see Increasing Performance on ESXi Configurations and Increasing Performance on KVM Configurations.

BIOS Settings

SR-IOV requires support in the BIOS as well as in the operating system instance or hypervisor that is running on the hardware. Check your system BIOS for the following settings:

• SR-IOV is enabled

• VT-x (Virtualization Technology) is enabled

• VT-d is enabled

• (Optional) Hyperthreading is disabled

We recommend that you verify the process with the vendor documentation because different systems have different methods to access and change BIOS settings.

Limitations

Be aware of the following limitations when using ixgbe-vf interfaces:

• The guest VM is not allowed to set the VF to promiscuous mode. Because of this, transparent mode is not supported when using ixgbe-vf.

• The guest VM is not allowed to set the MAC address on the VF. Because of this, the MAC address is not transferred during HA like it is done on other ASA platforms and with other interface types. HA failover works by transferring the IP address from active to standby.

  Note	This limitation is applicable to the i40e-vf interfaces too.

• The Cisco UCS-B server does not support the ixgbe-vf vNIC.

• In a failover setup, when a paired ASAv (primary unit) fails, the standby ASAv unit takes over as the primary unit role and its interface IP address is updated with a new MAC address of the standby ASAv unit. Thereafter, the ASAv sends a gratuitous Address Resolution Protocol (ARP) update to announce the change in MAC address of the interface IP address to other devices on the same network. However, due to incompatibility with these types of interfaces, the gratuitous ARP update is not sent to the global IP address that is defined in the NAT or PAT statements for translating the interface IP address to global IP addresses.