I am troubleshooting an environment generating unicast flooding during vMotion'ing.  The environment isn't exactly best practice (vMotion IP, Management IP and Virtual Machine Networks are all on the same logical subnet).  This will be corrected, but I'm trying to understand how and why the unicast flooding is occurring.

We have Dell blades (M1000e) in a Dell chassis with multiple blade center switches.  Each of these switches uplinks to Cisco gear.  When we do a vMotion between a host in the Blade Center and an external host, things work OK for a few minutes, but then unicast flooding begins.  I can send out an ARP request for the vMotion IP (target IP) from a non-involved host -- this seems to add the corresponding MAC address back to the Cisco's CAM table at which point the unicast flooding stops.

Based on my observations, the MAC address is present in the Dynamic Address List on the Dell switch (equivalent of CAM table).  So why is the Cisco expiring it (presumably after 600 seconds have passed)?

I encountered this post which asserts:

Make sure you have all your vkernel ports on separate subnets e.g.  separate vmotion/management/iscsi. Failure to do this can cause lots of flooding during vmotion as the  physical switch does not learn the MAC address for the vmotion port  correctly. And continuously broadcasts to find it.

Is this true?  Known bug?  Is there any documentation describing this?  My theory was that perhaps the ESXi server acting as the vMotion source has the destination IP in its ARP table.  It hasn't expired when the Cisco prunes on the MAC address from its CAM table and keeps transmitting without sending an ARP request.  The Cisco no longer knows where to send the packet so it Unicast Floods.

Am I way off in the weeds here?

Thanks!