{"id":146,"date":"2010-06-07T20:28:56","date_gmt":"2010-06-08T02:28:56","guid":{"rendered":"http:\/\/www.unifiedcomputingblog.com\/?p=146"},"modified":"2010-06-07T20:28:56","modified_gmt":"2010-06-08T02:28:56","slug":"correction-to-l2-forwarding-rules-post","status":"publish","type":"post","link":"http:\/\/www.unifiedcomputingblog.com\/?p=146","title":{"rendered":"Correction to L2 Forwarding Rules post"},"content":{"rendered":"

I posted here<\/a> about the L2 forwarding rules when UCS is in EHV mode. \u00a0 Several readers have pointed out a flaw in the logic I posted, which was taken from Cisco’s DCUCI course. \u00a0 In Cisco’s defense, I did write that course. \u00a0 \ud83d\ude42<\/p>\n

At issue is how UCS deals with unknown unicast frames. \u00a0 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. \u00a0 This is not the case.<\/p>\n

The logic behind EHV mode is that it is impossible to have an unknown unicast address “behind” or “south” of the Fabric Interconnect. \u00a0 All adapter MAC addresses are known, either because they were assigned in the service profile or inventoried (if using “derived” values). \u00a0 \u00a0For 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.<\/p>\n

So to clarify, an unknown unicast frame received from a server port will be flooded out ONLY that interface’s pinned uplink. \u00a0 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.<\/p>\n","protected":false},"excerpt":{"rendered":"

I posted here about the L2 forwarding rules when UCS is in EHV mode. \u00a0 Several readers have pointed out a flaw in the logic I posted, which was taken from Cisco’s DCUCI course. \u00a0 In Cisco’s defense, I did write that course. \u00a0 \ud83d\ude42 At issue is how UCS deals with unknown unicast frames. … Continue reading Correction to L2 Forwarding Rules post<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[7],"tags":[20,33],"class_list":["post-146","post","type-post","status-publish","format-standard","hentry","category-ucs-hardware","tag-ehv","tag-l2"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=146"}],"version-history":[{"count":0,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/146\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}