{"id":132,"date":"2010-05-08T09:20:35","date_gmt":"2010-05-08T15:20:35","guid":{"rendered":"http:\/\/www.unifiedcomputingblog.com\/?p=132"},"modified":"2010-05-08T09:20:35","modified_gmt":"2010-05-08T15:20:35","slug":"ucs-with-disjointed-l2-domains","status":"publish","type":"post","link":"https:\/\/www.unifiedcomputingblog.com\/?p=132","title":{"rendered":"UCS with disjointed L2 Domains"},"content":{"rendered":"

How do we deal with disjointed L2 domains in UCS?<\/p>\n

To start, what’s a disjointed L2 domain? \u00a0This is where you have two Ethernet “clouds” that never connect, but must be accessed by the same UCS Fabric Interconnect. \u00a0 Take, for example, a multi-tenant scenario where we have multiple customer’s servers within the same UCS cluster that must access different L2 domains.<\/p>\n

\"\"<\/a><\/p>\n

How do we ensure that all traffic from Customer A’s blade only goes to their cloud, while Customer B’s blades only connect to their cloud?<\/p>\n

The immediately obvious answer is to use UCS pin groups to tie each customers interfaces (through their vNIC configuration) to the uplinks that go to their cloud. \u00a0 Unfortunately, this only solves half of the problem.<\/p>\n

In the default operational mode of the Fabric Interconnects (called Ethernet Host Virtualizer, sometimes called End Host Virtualizer), only one uplink is used to receive multicast or broadcast traffic. \u00a0 EHV mode assumes a single L2 fabric on the uplinks (VLAN considerations notwithstanding). \u00a0So in this example, only broadcasts or multicasts from one of the two fabrics would be accepted. \u00a0 Obviously, this is a problem.<\/p>\n

The only way to get around this is to put the Fabric Interconnects into Ethernet Switching mode. \u00a0 This causes the Fabric Interconnect to behave as a standard L2 switch, including spanning tree considerations. \u00a0Now uplinks can receive broadcasts and multicasts regardless of the fabrics they are connected to. \u00a0 This does, however, increase the administrative overhead of the Fabric Interconnects and reduces your flexibility in uplink configuration since now we must channel all ports going into the same L2 domain in order to use the bandwidth.<\/p>\n

To me, a more ideal situation would be to leave the Fabric Interconnects in EHV mode, and use another L2 switch to perform the split between fabrics, such as the following:<\/p>\n

\"\"<\/a><\/p>\n

This configuration allows the Fabric Interconnect to remain in EHV mode and has the upstream L2 switches performing the split between the L2 domains. \u00a0ACLs can be configured on the L2 switches as necessary to isolate the networks, something that cannot be done on the Fabric Interconnect regardless of mode.<\/p>\n

Both of these scenarios assume that each of the two customer L2 clouds are using different VLAN numbering, since there’s no capacity in UCS to distinguish between the same VLAN numbers on either Fabric. \u00a0 There are certainly L3 and other translation tricks that you could use to accomodate this, but that’s an entirely different post. \u00a0\ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"

How do we deal with disjointed L2 domains in UCS? To start, what’s a disjointed L2 domain? \u00a0This is where you have two Ethernet “clouds” that never connect, but must be accessed by the same UCS Fabric Interconnect. \u00a0 Take, for example, a multi-tenant scenario where we have multiple customer’s servers within the same UCS … Continue reading UCS with disjointed L2 Domains<\/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,8],"tags":[20,33],"class_list":["post-132","post","type-post","status-publish","format-standard","hentry","category-ucs-hardware","category-ucs-management","tag-ehv","tag-l2"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/132","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=132"}],"version-history":[{"count":0,"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=\/wp\/v2\/posts\/132\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=132"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=132"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.unifiedcomputingblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=132"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}