Herschelle
Enthusiast
Enthusiast

Multiple Port Groups with the same VLanID

Jump to solution

Have a question on peoples experience or knowledge, as we are having a little discussion here at work. If you were to have multiple virtual port groups with the same VLanID in the same cluster, does or will this cause a problem?

0 Kudos
1 Solution

Accepted Solutions
bulletprooffool
Champion
Champion

Tom - we do this regularly.

We have vast amounts of VLans - and often will have VMs from 2 different environments hosted on the same Vlan for Dev purposes - however when we move to production, we wnat to be able to isolate VMs dependent on network provisioned - having the same Vlan in use . . with a different name means that we can quickly determine who is who.

In addition,

I could hhave 1 vSwitch, with 2 pNics (set up for fault tolerance .. not load balancing). . 2 port Groups . . same vLan . . but I can then get Port Group1 to defauilt to pNic 1 and Port Group2, to default to pNic 2 - this means I can isolat e traffic . . except in emergency.

One day I will virtualise myself . . .

View solution in original post

0 Kudos
7 Replies
krowczynski
Virtuoso
Virtuoso

What is your intention with such a config?

MCP, VCP3 , VCP4
0 Kudos
RahulMM
Enthusiast
Enthusiast

No it should not give you any issues. You can have same VLANID for multiple port groups....

0 Kudos
pramodupadhyay5
Enthusiast
Enthusiast

Yeah you can configure multiplevirtual port groups with the same VlanID but ur vercenter and VI Vlients must be on the same Vlan and u have to configure truncing plus inter Vlan routing on the physiacal switch or u can assign some ACL on the physical switch port which will allow the desired vlan id's to communicate with the virtual enviornment.....

I will advice u not to go ahead with this configuration

If you found this or any other answer useful please consider the use of the Helpful or Correct buttons to award points
0 Kudos
bulletprooffool
Champion
Champion

herschelle, this can be done, but there are a few things to be careful of:

1) If you have multiple pNICs in a VLan, you need to make sure that the Physical switch has these set up as a trunk

2) If you're usng the same Vlan, it may be worth while keeping the port groups on the same vSwitches to avoid confusion between your vSwitchs andpSwitches (doesn't happen often, but we once had an issu, due to 2 types of physical switch being between the vSwitch and the router on Blades servers)

3) Multiple port groups with the same VLans will need you to keep a careful eye on what is added to what as by design VLans are a tool for isolating traffic - you'll effectively be putting VMs on these 2 port groups into the same broadcast domain.

but in short - there should not be any problems with this config.

One day I will virtualise myself . . .
0 Kudos
TomHowarth
Leadership
Leadership

I fail to see why you would want multiple port groups with the same VlanID. The whole purpose of a Vlan is to separate traffic. A VMware vSwitch can easily support a very large number of connections.

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
0 Kudos
bulletprooffool
Champion
Champion

Tom - we do this regularly.

We have vast amounts of VLans - and often will have VMs from 2 different environments hosted on the same Vlan for Dev purposes - however when we move to production, we wnat to be able to isolate VMs dependent on network provisioned - having the same Vlan in use . . with a different name means that we can quickly determine who is who.

In addition,

I could hhave 1 vSwitch, with 2 pNics (set up for fault tolerance .. not load balancing). . 2 port Groups . . same vLan . . but I can then get Port Group1 to defauilt to pNic 1 and Port Group2, to default to pNic 2 - this means I can isolat e traffic . . except in emergency.

One day I will virtualise myself . . .
0 Kudos
Herschelle
Enthusiast
Enthusiast

Thanks to all for your input, I think bulletprooffool has what my intent is. We have setup a cluster to support multiple testing environments. These testing environments are "representative" of our production environment in that they use the same VLanID for the data centre designated segments, but use different address ranges in each different testing environment.

Say for example if Prod is 10.10.10.0 with vlan id 200

So we or rather our IT comms guys setup representative vlans in the test areas.

Test Area 1 is 10.50.10.0 with vlan id 200

Test Area 2 is 10.60.10.0 with vlan id 200

Test Area 3 is 10.70.10.0 with vlan id 200

So we have a single ESX server cluster to host all these test areas, We use resource pools to access control and separate the VMs in the different test areas.

Yes we could have smaller say 3 x 2 node clusters, however as in most places money, power, aircon etc is a major issue so we have a single 4 node cluster.

None of our test areas are air gapped as they need access to some systems, like big butt mainframes, that are not easily duplicated or purchased to sit in a testing environment doing nothing 99% of the time.

Neither do we not have Lab Manager at this point in time to take advantage of network fencing etc.

The real crux of the matter which started our discussions here is that in this testing environment we are sometimes having flaky intermittent communications with some of the VMs in this cluster, but not in our prod clusters. VMs within the same virtual port group, across different hosts in the cluster. Some work fine all the time, well appear to since it is intermittent, and others come and go. As it is occurring across different hosts in the same cluster this sort of rules out dodgy ports, flaky cable associated with a single host. Even VMs on the same vportgroup on the same host, one will just stop responding to pings but another will be fine and not drop anything. We even have just one Pnic in the vSwitch. Same OS, same patch revision, same setup etc. So in part of the isolating the potential issues thought I would ask the question posted for my own clarification and understanding, as because this is a configuration that is only on this cluster.

Part of the problem is that I can not easily just take out the testing areas as they are always being used and overtime (out of business hours) is non existent, well management do not want to pay for it, so let's leave it there.

In the end it sounds like from the responses that this is probably not our issue and might be something else.

I do not believe it is the esx hosts as they are exactly same hardware, same esx version and build and configuration. VM tools up to date in the VMs. We have a feeling it might be the VM vnic or the OS, will try removing the vnic and re-adding to one of the VMs and see how it goes...

Thanks again for all your responses, we shall keep digging.

0 Kudos