If you read my previous blogpost on VLAN backed network pools, then you will know that each of my Organizations had an allocation of 10 VLANs each, with one reserved for use by vCD-NI. It’s worth remind ourselves of what the requirements are for vCDI-NI to work – the main one being at least one network or VLAN, and increasing the MTU value to at least 1524bytes on physical switch and the DvSwitch that backs the portgroup. MTU values are very easy to configure on the Distributed vSwitch, as its always been available in the UI.
If you using the all-new web-client you will find the setting on the properties of Distributed vSwitch, the “Manage” tab, Settings, Properties and button like so:
I think most people just enable “jumbo switches” or MTU values on their switches, and configure to the maximums – that means any packet/frame <=9000 bytes in size will not get fragmented. It’s important to both configure this on physical and virtual switch, before thinking about using either vCD-NI or VXLAN as both require a larger frame size to accommodate their “network overly” functionality. As I’ve said before I think turning on the “VLAN and MTU” health check is a great idea to confirm the configuration is good. That’s done in the same place under “Health Check”, and the status is viewable under the “Monitor” tab.
So here can can see the “VLAN Heath Status” is health, and the host can see VLAN01 and VLAN10 (my external networks/portgroups of ExternalInternetAccess on VLAN01 and ExternalCorpNetwork on VLAN10).
In my scenario I’m viewing the vCD-NI backed network pool as something that will largely used by the “Test & Dev” style vDC within each of my Organizations – that’s because they don’t consume half as many as the VLANs as the VLAN-backed method, plus the requirement for increased MTU sizes might be more achievable in a lab environment where there maybe less change-management-control-politics to overcome. Initially, I’m going to create one vCD-NI backed network resource pool per Organization, and then let it be used by the “Test & Dev” vDC’s and see how I get along. I will then review their usage for the Production based vDC’s later on. I imagine my hand might be forced by the lack of VLANs available in my other pools.
1. Creating the network pools is relatively easy affair – you can kick of the wizard by either selecting 4. Create another network pool from the home page or by navigating to “Manage & Monitor” tab, > Cloud Resources and Network Pools.
2. Click the + icon, and select the network resource you want to use as the backing type. In my case this would “vCDNI-backed”
3. The next step is set the number of vCD-NI networks you require together with a VLAN that will back it. So that’s N networks being created within the context merely 1xVLAN. In my case the CORPHQ Organization was allocated VLAN11 for this purpose (where as VLAN12-20 were allocated to the VLAN backed pool).
Note: Be a little bit careful with the selection of the VLAN ID here, once its set it cannot be modified – without deleting the network pool itself.
One thing I thought was interesting about this configuration is how easy it would be to fat finger the configuration, and type in a VLAN that was already in use elsewhere in vCD – in another network pool or by VXLAN. For fun I put in a VLAN ID that was already in use by CORPHQ’s VLAN backed network pool. I was pleased to see that vCD validates these entries and won’t let you proceed if type in a VLAN ID that is used elsewhere. This validation is done at the end when you try to click the Finish button.
4. Once you have completed the wizard you can set a friendly name and description like so:
============================================>
…..And then I had a little November surprise. I got an error message stating that VLAN11 was in use as well. That was kind of funny in a non-ha ha way because I was sure that this VLAN wasn’t in use…
I did quick test and assigned vCD-NI backed pool to VLAN70 and that passed without error. I could have sworn I’d never allocated VLAN11 to portgroup ever. I did a quick check at my portgroups – and either they were assigned none or VLAN01/10 to my external networks. I decided to reach for PowerCLI to get a listing of all the portgroups and associated VLANs. I got an error message saying that VLAN11 was already in use as well. I wasn’t expect that. In turned out that I had inherited problem from a previous configuration. Prior to going to the colocation and setting up my VLAN configuration proper – I’d created “external networks” point to portgroups called ExternalCorpNetwork and ExternalInternetAccess – I’d assigned VLAN10/11 to these respectively – even though they didn’t exist. [If you look at the last graphic at the end of this post you will see the previous configuration – not the use of VLAN10/11]
Later on after completing the VLAN configuration I actually used VLAN01/10. In vSphere I updated these VLAN values, and refreshed vCD. Everything seemed good. Turns out that wasn’t the case. I turns out that vCD keeps a record of these assignments – and stores them in its in database, merely updating the VLAN setting the backs a portgroup doesn’t release the previous VLAN assignment in the vCD DB. The issue is outlined in Tomas Fojta’s blog and there is a KB article here. For me the easiest resolution to this issue was to delete the external networks and recreate them. The general recommendation is if your faced with this issue is raise an SR and cite the KB article…..
<============================================
Next I had a little check over the settings of the vCD-NI pool and noticed there was tab for the MTU value – which was still set at the 1500byte value. I think its odd how a vCD-NI backed network pool doesn’t expose this in the main wizard, and there isn’t a message about changing or updating this to stop fragmentation.
So that’s 3 places to confirm the configuration of the MTU correct – physical, virtual and vCD. One thing I would say is for the other vCD-NI network pools I created this value was correct. So perhaps there was something funky going on in my setup. Finally, the other the thing I should point out is once you have set the VLAN that the vCD-NI backed network pool will use, it becomes dimmed. That means you cannot change the VLAN ID backing a vCN-NI resource pool without first removing it.
