VMware Cloud Community
CTJohn26
Contributor
Contributor

The Big Q: 1 vswitch w/ multiple port groups vs multiple vswitches

I know this has been discussed in previous threads, however there doesn't appear to be a consensus. Why would I want multiple vSwitches (or dvSwitches) if I can do everything at the port group level? I know of only one reason why you would want separate vSwitches, Jumbo Frames. Some have referred to multiple vSwitches as more "secure" and "reliable." How? I can't think of any reasons (other than the one I mentioned) to have multiple vswitches over a single vswitch with multiple port groups. Please share your opinion on this topic.

13 Replies
weinstein5
Immortal
Immortal

In my view it is all going to depend on the physical network you are connecting - if you have segments that need to be secure, like a DMZ, than it would make sense to havemultiple vswitches -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
Reply
0 Kudos
NuggetGTR
VMware Employee
VMware Employee

I find using port groups is easier to manage, that way you can have all your nics assigned to the one vswitch then you just manage the port groups, once you start using vswitches you start breaking up your vmnics or having vmnics servicing multiple vswitches.

For me it comes down to administration and which is easier for the environment

________________________________________ Blog: http://virtualiseme.net.au VCDX #201 Author of Mastering vRealize Operations Manager
Reply
0 Kudos
depping
Leadership
Leadership

These days i only create multiple vSwitches when there is physical separation of the customer does not want to create a trunk. otherwise it is easier and more effective to use a single vSwitch. From a "visual" perspective using multiple vSwitches is definitely easier to understand. In the end it doesn't really matter.



Duncan

VMware Communities User Moderator | VCP | VCDX

-


Now available: <a href="http://www.amazon.com/gp/product/1439263450?ie=UTF8&tag=yellowbricks-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1439263450">Paper - vSphere 4.0 Quick Start Guide (via amazon.com)</a> | <a href="http://www.lulu.com/product/download/vsphere-40-quick-start-guide/6169778">PDF (via lulu.com)</a>

Blogging: http://www.yellow-bricks.com | Twitter: http://www.twitter.com/DuncanYB

Reply
0 Kudos
TomHowarth
Leadership
Leadership

Your switch design is lead by your phyiscal design for example is it recommended that you have as seperate managment network, both for management, vMotion FT, iSCSI or NFS etc., this is to keep traffic off your production networks thereby preventing congestion, but it is also to increase the security of your environment,

Remember the the Service Console of Management network are the keys to the kingdom. also FT and vMotion are very bandwitdh intensive. seperate them off to their own switches with dedicated uplinks. same goes for Backup.

on first sight a single vSwitch with multiple portgroups seems the easiest way to go, but you need to take a step back.

this argument seems to hold more water with dvSwitches, however if you are using a virtualised instance of vCenter see how easy it is to move that to a dvSwitch :smileygrin: infact most people recommend a hybrid approach in this matter.

Personally my view is that there should be at least two switches one for Guests and one to cover management (SC/Management Interface, FT, vMotion etc) if you are adding iSCSI or NFS there should be a third, to allow you to activate Jumbo Frams on that switch.

That is just my 0.03p worth, 3 pence due to inflation.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

Contributing author on "[VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment|http://www.amazon.co.uk/VMware-VSphere-Virtual-Infrastructure-Security/dp/0137158009/ref=sr_1_1?ie=UTF8&s=books&qid=1256146240&sr=1-1]&rdquo;.

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
TomHowarth
Leadership
Leadership

the majority of my clients have requiremment for physical seperation, and have higher security than "normal" clients. a single vSwitch/ dvSwitch does not cut the mustard with them

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

Contributing author on "[VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment|http://www.amazon.co.uk/VMware-VSphere-Virtual-Infrastructure-Security/dp/0137158009/ref=sr_1_1?ie=UTF8&s=books&qid=1256146240&sr=1-1]&rdquo;.

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Reply
0 Kudos
CTJohn26
Contributor
Contributor

I did some additional reserach, still don't have a case for multiple vSwitches. Please see the following, which I cut and paste from Internetwork Expert:

The vSwitch ILLUSION: What you see isn’t what you get

The conventional thinking up to this point has been that multiple

vSwitches can be configured on an ESX Host to maintain a consistent

architecture of physical network separation. Why would anybody think

any differently? After all, when you configure networking on an ESX

Host you see multiple vSwitches right before your very eyes that are

presented to you as being separate from one another. This visual

provides the sense that adding a new separate vSwitch is no different

than adding a new separate physical switch, right?

Figure 5 – The vSwitch view from VMware VI Client

!http://internetworkexpert.s3.amazonaws.com/2010/vswitch-dmz/vswitch-viclient-illusion.png!

Figure 5 - VI Client shows multiple separate switches



First of all, lets ask ourselves this question: What is the unique
security posture characteristic of two physically separate switches?
Most people would tell you that each physical switch has its own
software and unique forwarding control plane. A software bug or
security vulnerability in one switch may not affect the other switch
because each could be driven by different code. On the other hand,
what is the unique security posture characteristic of a single switch
with logical partitions? Most people would say that this switch is
using a common code and common control plane implementing separation
via unique logical partitions.


With that understanding in mind, if I create multiple vSwitches on
an ESX Host, each vSwitch should have it’s own unique software that
drives it, and a unique control plane that does not require any logical
partitioning to separate it from other vSwitches, right? Lets go ahead
and put this theory to the test. Lets see how much Host memory is used
when there is only 1 vSwtich configured:


Figure 6 below shows Host memory usage with (1) vSwitch

!http://internetworkexpert.s3.amazonaws.com/2010/vswitch-dmz/1vswitch.png!

Figure 6 - Host memory with (1) vSwitch



In Figure 6 above I have just (1) vSwitch configured on a Host with
no virtual machines, and the memory used by the Host is 764MB.
Perfect, we now have a memory baseline to proceed. If in fact every
new vSwitch on an ESX Host provides the same physical separation
characteristics as two separate physical switches, then each new
vSwitch should result in a new copy of vSwitch code, consuming more
host memory, right? Lets add (10) more vSwitches to this Host and see
what happens…


Figure 7 below shows a Host memory usage with (11) vSwitches

!http://internetworkexpert.s3.amazonaws.com/2010/vswitch-dmz/11vswitches.png!

Figure 7 - Host memory with (11) vSwitches

Figure 7 above shows the same ESX Host with (11) vSwitches

configured an no virtual machines. As you can see the Host memory

usage is still 764MB. Adding (10) vSwitches did not add 1 single MB of

Host memory overhead. This is one simple example to show that (11),

(20), or even (200) configured vSwitches on a Host is really just 1

Switch, running one piece of common code and control plane, and each

new “vSwitch” is nothing more than a new unique logical forwarding

partition, no different than a single physical switch with a bunch of

VLANs.

Still don’t believe me? Let me go back to Paul Fazzone’s article Two vSwitches are better than 1, right? in which Paul quotes Cisco’s principal software architect of the Nexus 1000V, Mark Bakke, from a video interview in which Mark says:

Each vSwitch is just a data structure saying what ports are connected to it (along with other information).
So while using vSwitches sounds more compartmentalized than VLANs, they provide equivalent separation
- Mark Bakke, Nexus 1000V Principal Software Architect, Cisco Systems

Mark would know better than anybody else, and my Host memory

experiment above agrees with him. The conventional thinking that

multiple vSwitches are providing physical separation is nothing more

than an ILLUSION.

The reality for the customer is that having an ESX Host with multiple

vSwitches is providing the same security posture as a single switch

with logical partitions, same as &lt;GASP&gt; … VLANs! And when the

customer attaches their multiple vSwitches to physically separate

networks, the result is inconsistent policy and the holistic data center network is reduced to a security posture of logical separation.

Reply
0 Kudos
NuggetGTR
VMware Employee
VMware Employee

Tom I agree, general practice is a vswitch for the service console and vmotion etc

and another vswitch for the other things, But how is having everything on 1 vswitch separated by port groups any less secure than separating them with vswitches?

from what ive seen they are the same just different way of achieving the end goal.

________________________________________ Blog: http://virtualiseme.net.au VCDX #201 Author of Mastering vRealize Operations Manager
Reply
0 Kudos
CTJohn26
Contributor
Contributor

Ahh.. the fundamental quesiton I have been trying to answer, why is having everything on one vswitch separated by port groups less secure than separate vswitches? I can't find any evidence to suggest that is less secure. The reasons for separate vswitches at this point are traffic segmentation (you are physically connected to separate networks, no VLANs) and Jumbo Frames (which must be enabled at both the switch and vmkernel port level).

Reply
0 Kudos
NuggetGTR
VMware Employee
VMware Employee

im not sure about other people but generally my port groups are my vlans so your getting the network seperation there. Now i could see the fact that you could have the vmnics dedicated to a particular vswitch that go off to a phicically separate and secure network and the others go off to the general network. but the same result can be achieved using vlans and is just as secure.

________________________________________ Blog: http://virtualiseme.net.au VCDX #201 Author of Mastering vRealize Operations Manager
Reply
0 Kudos
CTJohn26
Contributor
Contributor

Remove physical separation from list of reasons for multiple vswitches. This can be achieved by active/inactive uplinks on the port group level. So now I down to my original thought, Jumbo Frames is the only reason for multiple vswitches. However, that may not be a factor either. You can enable Jumbo Frames at the switch level and have vmkernel ports that aren't setup with a mtu of 9000 (for example), correct?

Reply
0 Kudos
TomHowarth
Leadership
Leadership

No the result is not the same and VLANS are no way near as secure as physical seperation. I suggest you do a search on VLAN vuneralbities before you make such a sweeping statement. there are reasons why the security peeps want white space.

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

Contributing author on "[VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment|http://www.amazon.co.uk/VMware-VSphere-Virtual-Infrastructure-Security/dp/0137158009/ref=sr_1_1?ie=UTF8&s=books&qid=1256146240&sr=1-1]&rdquo;.

Tom Howarth VCP / VCAP / vExpert
VMware Communities User Moderator
Blog: http://www.planetvm.net
Contributing author on VMware vSphere and Virtual Infrastructure Security: Securing ESX and the Virtual Environment
Contributing author on VCP VMware Certified Professional on VSphere 4 Study Guide: Exam VCP-410
Reply
0 Kudos
CTJohn26
Contributor
Contributor

You can still achieve physical separation with a port group, no? If you have 8 uplinks and two are on a separate physical switch, you can make those active uplinks and the others inactive. I am not trying to make a statement about security... I am asking why one would have multiple vswitches when most can be done with port groups. I know that VLANs are not the same as physical separation, as its logically implemented.

Reply
0 Kudos
NuggetGTR
VMware Employee
VMware Employee

arnt vswitches in their nature just a logical seperation being within a virtual environment there is no actual physical separation. I see what your saying with vlans have vuneralbities, but from within the virtual environment port groups "look" to act the same as vswitches.

either way i dont think its the best idea to be mixing high security networks/servers with low security networks/servers on the same cluster of esx hosts, I would have them and do have them physicaly seperated on different hardware. But i know not every place has coin to spend like that.

would be awesome to see a white paper or something similar on this topic, cause i can see the reasoning from both sides but there is nothing offical out there that says you must do this or must do that because of this..... just seems that it comes down to the vm admins way of doing it, or a client saying they want it this way etc.

________________________________________ Blog: http://virtualiseme.net.au VCDX #201 Author of Mastering vRealize Operations Manager
Reply
0 Kudos