Using VLAN and VLAN Tagging is not working / no connection

[patrickschindle]

Hello,

i´m trying to setup a VLAN between some virtual machines over 3 ESX-Hosts.

I want to do it this way:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100407...

I had 1 dedicated NIC in each ESX Host which is connected to a dvSwitch in which i configured a portgroup

with VLAN ID 2121. I configured each virtual Machine to use this network.

When i put the virtual machines on one single host they are able to communicate.

When they are placed on different Hosts they are (if VLAN is enabled on portgroup) not able to communicate.

So i´m supposing there must be an issue within NIC config on ESX-Hosts or on the switch.

I´m using a HP2910AL on which i enabled trunk mode for each port which is connected to a NIC with

the dvSwitch/Portgroup that i try to use for vlan. In the hp switch i have a default VLAN with ID 1 where

the Ports are marked untagged. I setup a second vlan on the switch with ID 2121 in which i marked

this ports tagged.

Is there anything else to do - perhaps on ESX Host side?

I tried to changed settings like "Forged transmission -> allow" on portgroup and other things i found

in the web, but still no success.

Regards,

Patrick

[vDanielM]

Hi,

Have you allowed vlan 2121 to use the trunk port on your HP swithces?  Cisco equivelent is:

(config t) interface> switchport mode trunk allowed vlan (add) 2121

I think since your tagging at the ESX switch you don't need tagging at the physical HP switch.

Thanks

[depping]

If you tagged the port (access port and not a trunk) then you do not need to provide a VLAN ID on the portgroup. If you create a trunk port (multiple VLANs on a port) then you will need to specify the VLAN ID on the portgroup.

[patrickschindle]

The way i want is using multiple vlans/portgroups with different vlan id on the trunk of 3 hosts (each with 1 nic connected to the dvswitch where

the portgroups were configured).

On the hp switch i created a trunk with the 3 esx-nic-ports and set the port mode for each port to trunk.

This alone does not work.

Therefore i tried additionaly add vlans on the hp switch with the vlan ids configured on the portgroups.

In the vlans i tried setting the trunk to tagged, untagged and no - but no option was working.

I restarted the switch after each configuration.

Any ideas?

[patrickschindle]

Is there another way to allow a vlan to a trunk instead of adding vlan and vlan id to the config

and mark the trunk as tagged? I could not find any suitable command in hp guides?

Regards

[vDanielM]

Can you copy the configuration of the ports you're using for trunking on the HP switch to here, may help get a better understanding?

[patrickschindle]

Attached you´ll find the config of the 3 ports.

This alone has not been working so i added a vlan via webgui with same

vlan id as portgroup and mark the 3 ports as tagged (and untagged, and no...).

Also not working.

[vDanielM]

Can you run: show vlans

[patrickschindle]

Attached you´ll find the screes.

I tried it only with default vlan and trunk configured on ports 19,21 and 23.

And i tried with adding a vlan named "ohoh" with id 2121 (same as portgroup in vmware) and mark

trunk (of ports 19,21 and 23) as tagged.

Screens are of both version.

Also i tried it with gvrp enabled and disabled (as someone said i should test).

Regards

[vDanielM · Accepted solution]

Have you been referring to this guide?:

http://cdn.procurve.com/training/Manuals/2910-ATG-Feb09-2-VLAN.pdf

"show vlan ports" would be my next check to make sure you have the 3 ports connected to your ESXi hosts in the 2121 vlan.

As Duncan has said if you have VLAN ID on the portgroup in the vSwitch and you have the port on the pSwitch as trunk not acess and that VLAN ID is allowed on the pSwitch trunk port you should be ok.  Just to clarify trunk is 802.1q not 802.3ad.

The other way is not VLAN ID on the vSwitch portgroup, use access port on the pSwitch with VLAN ID.  Limits pSwitch port to one VLAN, this may be ok for you?

[patrickschindle]

I checked the port configuration for the trunk and it says that trk1 is member of default vlan and my vlan ohoh.

I also checked the physical connection for the 3 esx hosts to my 3 trunked ports on the switch and they

are 100% correct connected.

Trunk should be 802.1q as i want to have multiple vlans on this 3 esx-nics connected to the 3 switch ports.

As configuration on switch side seems very simple my suggestion was that there is an error on esx-nic-side?

But here i revered to the vmware guides and tested several settings.

There must be a little mess that keeps everything from working...

[patrickschindle]

Some other (silly?) questions :

Is there something more to configure within portgroup on esx side?

- do i need a vmkernel interface for each vlan/portgroup with an ip-address from the vlan subnet?

- must there be an ip address from vlan subnet defined in the vlan settings on the switch?

As i said if i use this portgroup with vlan on a single esx-host communication works between

virtual machines, so i thought it must be a switch problem.

Regards

[vDanielM]

I only have this setup with standard vSwitch but have no vmkernel interface for the vlan on the vSwitch but I do have a vlan interface on the pSwitch.  An IP interface on both switches virtual with vmk and physical may help test connectivity though.  You can use vmkping then from ESXi hosts:http://kb.vmware.com/kb/1003728

[vDanielM]

I would start from the beginning and test end to end connectivity at each step:

pSwitch trunk in place for ports connected to ESXi hosts using default vlan only - test connectivity on default vlan using default vlan IP subnet

Add in vlan 2121 to pSwitch trunk - test connectivity on both default vlan and 2121 using relevant IP subnet from VM on each host and portgroup with no vlan settings.

Add in vlan 2121 to vSwitch portgroup - test connectivity on vlan 2121 IP subnet.

If you have not done this already may give you idea where it's going wrong or in what configuration it does work, that you may not have expected.