I posted here about the L2 forwarding rules when UCS is in EHV mode. Several readers have pointed out a flaw in the logic I posted, which was taken from Cisco’s DCUCI course. In Cisco’s defense, I did write that course. 🙂
At issue is how UCS deals with unknown unicast frames. The other post incorrectly states than an unknown unicast frame received from a server port would be flooded out all other server ports participating in the same VLAN. This is not the case.
The logic behind EHV mode is that it is impossible to have an unknown unicast address “behind” or “south” of the Fabric Interconnect. All adapter MAC addresses are known, either because they were assigned in the service profile or inventoried (if using “derived” values). For MAC addresses that are generated within a host, say for a virtual machine, the assumption is that at creation (or arrival through vMotion, etc) the MAC address will be announced using gratuitous ARP or other traffic generation techniques and the Fabric Interconnect can learn the address through normal L2 methods.
So to clarify, an unknown unicast frame received from a server port will be flooded out ONLY that interface’s pinned uplink. Otherwise, all traffic destined for MAC addresses outside of UCS (such as the MAC address of a default gateway, for example) would also get flooded internally – which would not be a good thing.