I have been thinking up an interesting scenario in my head, and I'm convinced the answer is a simple one that I'm overlooking. However, I've been at it for a while and decided to post the concept here and get some eyes on it.
Let's say your topology includes a pair of Nexus 7Ks, a pair of Nexus 5Ks, and a single server running VMware ESXI (lets say the vSwitch is the Nexus 1000v). This is just a simple rackmount server without anything special like a Cisco VIC - just a pair of NICs connected to the same vSwitch.
Because of this, we're able to choose between pretty much two vSwitch load sharing policies. In vSphere, the default policy is "route based on originating virtual port ID" - which isnt' exactly the identical to, but will result in the same general behavior as source MAC hashing. Let's say we're using the same policy on our Nexus 1000v. Effectively, a single source in the hypervisor will only send traffic up one link. This means that traffic from this virtual machine should only ever go to one Nexus 5K in the pair.
The result as shown above is that this virtual machine's MAC address is learned on po13 on both 5Ks (synchronized to the other switch because of the vPC peer-link). Traffic from the 5K to the 7K pair is load balanced based on ip hash, so it could go to either 7K from there, but that doesn't matter because, again, vPC synchronization will result in that MAC address being learned on port channel 12 in any case. I don't see a problem in this topology because MAC addresses can only be learned on one interface (even if it's a port channel interface).
However, things get more interesting when we start load-balancing based on IP hash on the server as well. In this scenario, traffic from a single virtual machine (and therefore single MAC address) could egress out of either link - it all depends on the IP source and destination.
From a 5K perspective, we don't have a problem - even if we send traffic up both links to the 5K pair, vPC synchronization once again saves the day and the MAC address tables on both 5Ks read correctly that the MAC address for our virtual machine has been learned on po13.
This gets to be a problem when you realize that both 5K switches are connected to the 7K pair on separate vPCs (and separate port channel IDs). Since traffic from our virtual machine will be entering the 7K pair from both 5Ks, this MAC address will be learned on po11 and po12 alternately - a less brutal way of describing a MAC flap. vPC synchronization doesn't help us here because the MAC address is being learned on multiple interfaces - vPC synchronization only helps us if the other switch is receiving frames from the same source on the same interface name, which is not the case here.
As a result of this, I'm concerned I'm missing something fundamental to how these components work. Anyone who can help and point out my gap in knowledge is certainly welcome to do so.
