Cookbook scenario 11 and 12 why not always??

[Duhaas_2]

So in looking @ the different configs, it would seem like the majority of the time one would want to use scenario 11 or 12? It seems to make the most sense instead of having a config where your network is spanned across two VC's and you only have one being active, why not create two network same vlan one on each vc spanning two-four ports and then assigning nics in a host to each network created??? My example I guess would be: VC0 - PORTS 1-2 - VLAN1 ACTIVE VC1 - PORTS 1-2 - VLAN1 ACTIVE ESX HOST or EVEN JUST WINDOWS HOST ESX HOST NIC0 - VC0 network NIC1 - VC1 network Windows Host NIC1 - VC0 network NIC2 - VC1 network Its that easy right??? Am I missing something, this is the config I have deployed, and it seems to cover me in the following areas: 1) switch failure 2) vc failure 3) nic failure

[Duhaas_2]

just looking to see if anyone has any thoughts. any help you can provide would be great.

[Steven McLean]

Yes, these may be the most popular scenarios when VLAN tagging is not required, of if the host is handling the VLAN translation. Key advantage is that all uplinks are used (active). If bandwidth is an issue, this may be the best solution for you. I have some customers that are more concerned with availability and not bandwidth and would go with the simpler design of a single vNet and have active/standby uplinks. However, If VLANs are using, then Scenario 13 may make more sense. And, if you want to take advantage of all the uplinks, scenario 13 could be implemented as TWO Shared Uplink Sets, and have the NICs teamed across them. Also, if Flex-10 is used, you will need to have more than TWO networks to take full advantage of the FlexNIC, such as in scenarios 17 and 18. So, Ideally, VC provides significant flexibility, but it really boils down to what OS are you supporting, how many NICs the host requires, how many VLANs you need to support and what bandwidth/availability do you require. Then, select the configuration (scenario) that makes sense for the implementation. Keeping in mind, the VC cookbook does not cover all possible configurations, and is meant to provide examples of what could be done. Also, keep your eyes out for a new version of the VC Cookbook, it should be out within the next few weeks. Regards, Steve

[cjheimantx]

If you connect to core instead of access switches and your network architect does not want "planned" active uplinks connected (copper or fiber) to his standby core switch (maybe its an older core switch with slow cross connect or he just does not want that type of traffic pattern). We have approximately 1000 servers pumping across virtual connect...maybe our situation is unique. With the availability of newer rack mount access switches this may change in the very near future. Thanks for shaking up my thinkin muscle. Easy is always good.

[Duhaas_2]

thanks everyone for their insights, i really appreciate it. this is a combination esx hosts and windows hosts cabinet so i will do a variation of the two.

[Steven McLean]

Yes, I have a couple customers that want the second set of uplinks to be in STBY, and only become live in the event of a failure. They have two core switches, one of which is only passing traffic if a fail-over of uplinks occurs.