General

Headline: Packet drops on vPath enabled VEM in the presence of VPC-HM Symptom: Packets, usually the very first packet in a new connection, will be dropped on the VEM. The drops will show up as Tx drops under CLI on the VEM (against the destination VM port). TCP flows do not suffer from the packet drop as the subsequently retransmitted packets will not be dropped. This is due to the fact that the drop happens only when the packet is steered to the VSG. By the time retransmitted traffic hits the vPath enabled VEM, policy decision would have been received from VSG and cached and hence no further steering would be necessary. On the other hand, commands such as ping may show either all or some packets as being dropped depending on the interval between the ICMP echo requests. Conditions: A multitude of conditions have to be met for these drops to happen. 1. Up-links on the VEM Host are configured in VPC-HM mode - leads to pinning of the VM-ports to one of the up-link port-channel sub-groups. 2. VSG is deployed outside the VEM-Host which is hosting the destination-end-point of the dropped connection/flow 3. The traffic is entering the VEM-Host on the up-link which belongs to a different port-channel sub-group than the up-link used to reach the VSG. Workaround: 1. Make the VSG local to the VEM-Host which is hosting the destination-end-point of the dropped traffic OR 2. Use static-pinning (available in port-profile configuration) to pin the VMs hosted on the VEM-host to the same up-link port as the one used to reach the VSG. on the VEM will be helpful in identifying the pinning state. Further Problem Description: None