This issue can occur due to excessive layer-2 unicast flooding and/or excessive broadcast traffic. Due to the architecture of the Nexus 1000V, it must replicate each incoming broadcast for each virtual machine, resulting in the observed deterioration of latency as the number of hosted virtual machines increases.
To improve virtual machine responsiveness, several measures can be taken. Cisco makes these recommendations:
- Reduce the subnet size, or avoid the use of very large subnets. It is more common to see these symptoms with large subnets hosting thousands of Ethernet devices as there will inevitably be a larger volume of broadcast traffic that must be processed.
- Isolation of the top broadcasters. If there are a small number of devices generating the majority of the broadcast traffic, it would be advisable to isolate them into their own subnet/VLAN.
- Optimize the upstream switch to reduce broadcast traffic. One common source of broadcast traffic is ARP requests. Increasing the MAC address aging timer will reduce the frequency of ARP requests which need to be sent and will reduce the overall amount of broadcast traffic in the subnet.
- Implementing UUFB (Unknown Unicast Flood Blocking) can also greatly reduce the load on the Nexus 1000V due to high levels of unicast flooding. Enabling this feature on the Nexus 1000V causes all unknown unicast traffic to be dropped by the VEM module at the uplinks. There are some limitations and precautions that must be taken when implementing UUFB. For more information, see the Blocking Unknown Unicast Flooding section in Cisco's Security Configuration Guide.
- Important note if you are using Microsoft Network Load Balancing (NLB): Because Microsoft NLB configures the same MAC address on multiple ports, that MAC address cannot be learned on any of those ports, and therefore leads to unknown unicast flooding. Best practice is to isolate Microsoft NLB virtual machines in a separate broadcast domain or configure UUFB to limit the scope of the flooding.