This week one of our Vitualisation Engineer’s (James Smith) was trying to come up with a solution for a client that wanted the flexibility to bring in his own VLANs mapped into our vCloud networking stack. We get this request quiet often and we generally configure a one to one relationship between the VLAN being mapped externally to our networking stack and then brought into vCD via a externally connected vORG Network.
As you all know you can configure an ESXi Portgroup either with no VLAN, a single VLAN, multiple VLANs or Private VLANs. In this case the customer wanted preconfigured VLANS as part of the one Portgroup so taking vCloud Director out of play we would configure the Portgroup as follows:
This allows for the tagging of the VLAN at the GuestOS level while allowing those VMs to be on the same Portgroup. The problem arises when you then try to create the External Network in vCloud Director. As shown below vCloud Director looks at the Portgroup, sees the multiple VLANs and marks it down at VLAN 4095.
Regardless of the fact that it’s picked up as VLAN 4095 which wouldn’t be ideal even if we had configured the Portgroup with 4095 you can’t finish off the configuration of the External Network as vCD throws the error seen below.
Another cryptic error from vCD, but in a nutshell it’s telling you that 4095 is in use and the network can’t be created meaning you won’t be able to tie any vORG Network to the ESXi Portgroup. There is a VMwareKB that relates to this error, however searching through the vCD database shows that 4095 isn’t in use as is expected. So it would appear that this is a default vCD behaviour in dealing with a Portgroup configured with multiple VLANs.
Workaround:
We eventually came up with a workaround for this that isn’t 100% fool proof and should be undertaken with the understanding that you could cause issues if VLANs are not managed and noted down on some configuration database. What we did was go back an modify the Portgroup to only have one VLAN. This allows us to create the External Network in vCD and from there create the vORG Network.
From there we go back and edit the Portgroup to make it a trunk as we had it initially. vCD will now show the External Network still created with VLAN 4095 listed as shown below.
From here you can create VMs in vCD, connect them up to the vORG Network and use VLAN tagging in the Guest OS to pass the correct network traffic through. Again just be wary that vCD doesn’t recognize the VLANs being trunked and there is a possibility a duplicate VLAN could be assigned via another External Network.
As a side note, I’ll be chasing this up with the vCloud Director Product team as I believe it should be an option that is allowed…even though VXLAN is taking over there is still a need to cater for traditional VLAN configurations.
References:
http://www.virtualbrigade.com/2014/08/what-is-vlan-id-4095-when-is-it-used.html
Multiple VLANs for an External network in vCloud?
byu/Gusson invmware
