Port Group and vLAN naming convention

[TheVMinator]

What is the best naming convention for port groups on vSwitches?  Should this naming convention match how vlans are named on physical switches and how important is that?

[weinstein5]

I have always named port groups so that it will identify what vlan tag is being applied - 

[TheVMinator]

OK thanks - I'm wondering what are some recommendations in terms of what that looks like:

i.e.:

[iiiii]-[ppppp]

where i = vlan id

p = port group name

or something better?

[grasshopper]

IMHO, it is preferred to include the VLANID and the first 3 octets of the network address in the portgroup name (optionally add the subnet mask in CIDR notatation).  This makes it easy to determine the correct network at a glance (i.e. via Edit Settings on the VM).  If your company always uses straight Class C (a.k.a. "/24 bit") masks such as 255.255.255.0, then you may not need to add the CIDR notation (i.e. /24).  For companies that have compex networks and multiple variations of subnet mask (i.e. /22, /23, etc.) it is helpful to include that important detail in the portgroup as well.

The following is an example for a 10.100.141.x network that has a mask of 255.255.254.0 (a.k.a. /23 in CIDR notation).

Example Portgroup Names:

Vlan141_10.100.141.x

-or-

Vlan141_10.100.141.x /23

-or-

Vlan141_10.100.141.x_23

Some also add in the function or description of the network along with the first 3 octets (i.e. DMZ-Guest-206.252.10.x).  Personally, I like having the VLANID listed in the port group.  This becomes handy when using higher VLANIDs that cannot be gleaned from the network address (i.e. typically, the VLANID on /24 networks is the 3rd octet.  Of course, there is no guarantee of this, especially when using VLANIDs higher than 255).

NonStandard Example:  VLAN860

Your network folks can make the VLANID anything they want.  Sometimes this gets confusing when the VLANID has nothing to do with the actual network.  For example, your network team gives you a 192.168.10.x /24 and calls it VLAN860 for some random reason.  For you, it would be hard to know what this maps to unless you refer to a spreadsheet, or perhaps get lucky and can sort your existing VMs by IP address in the vSphere client and then figure out which IPs match, then Edit Settings on the example VM to glean to the proper port group for the desired network.  That's a lot of work.

So in this case, keeping to the standard of using the VLANID and network detail in the portgroup name makes it instantly clear what the whole story is:

Vlan860_192.168.10.x_24

If you need to troubleshoot a VM, you already know the network info just from the portgroup name.  If the network team needs to troubleshoot, you can tell them the VLAN in question.  Just a couple of thoughts anyway based on my experience.  Keep in mind these names are case sensitive, special characters such as / and _ are ok (spaces are ok as well), but depending on your scripting guy's favorite tools, he may or may not like these or may have a preference.  I have had no issues with PowerCLI dealing with the special characters, but YMMV.

[TheVMinator]

These are great ideas - thanks.  Are these methods pretty standard or has there been any other efforts to develop "best practices" for port group naming conventions or any other commonly referenced views on this?

[grasshopper · Accepted solution]

Hi VMinator,

To answer your question, there is no agreed upon 'standard' for portgroup names.  It's all about what you are comfortable with supporting and what works for you and your organization.  Kinda like server names; some companies go hardcore with naming conventions and others name them after sci-fi characters or world of warcraft bosses

The more forensics you pack into a naming standard the more control you have (i.e. for scripting, health checking, etc. see below).  Also, if the very name itself answers questions on its own and saves you a phone call that's priceless.  For example - unix guy says... "um what network do I choose for my new VM.  My IP is blah blah blah."  Well, with the right portgroup name, that question would have answered itself... and perhaps even saved some downtime in other cases by simply being clear and effective in the communication of how this virtual device is expected to function: purely expressed through a proper naming convention.

Here's another example.  At my last gig we had thousands of VMs that had to move datacenters and when they landed, they needed to change IPs and start using 3 vNICs (up from 1) on each VM.  Each vNIC having a different subnet mask.  All support had to be carried out by an outsourced team with minimal VMware experience.  The only way to support something like that and be effective is to PowerCLI.  With just that naming convention alone, you can perform various tasks such as interrogate the VM and review it's portgroup settings compared to its actual IP information in the guest os, initiate a .NET ping to the VM, if there are issues take action automatically.  Some actions that would be performed include, for example, changing the portgroup, or the mask on a set of guests;  Or interrogate the hosts and glean network information (i.e. CDP,vSwitch, portgroup, etc. info) and compare observed network vs. expected network listed in the PG naming convention. etc. etc.  The list of actions you can take are only limited by your creativity.  The naming standards give you the power to be effective both in manual and automated efforts.

Again, just one man's opinion, but each site that I care and feed typically ends up with a PG standard similar to what I first described above in my previous post.  Keep in mind my example naming convention is basic.  There are many more attributes you can add (i.e. in vCloud deployments, in addition to the network info you may choose to identify various functionality specific to vCloud such as org-networks, etc).

TBH most companies just have portgroups named VM-Network (ok not that bad) or some random shortname that doesn't help troubleshooting.  They are easy enough to fix and also modify over time if needed.  You can easily drag and drop a set of VMs (although I don't personally do it this way) onto the new port group (i.e. via the networking page at CTRL+SHIFT+N) or PowerCLI it (yes!  way to go).  Of course, always run ping tests before and after the change.  There are lots of scripts out there (or ask master lucd by posting in the VMTN PowerCLI forums).  If this is net-new then you're ahead of the game and will have a standard to follow, whatever that may be.

Best of luck and have fun!

[TomHowarth]

I tend to use the following convention, Customer-Site-Usage-VLAN  so BigBank-NYC-MGNT-1095, Also I ever leave spaces in any of my conventions, I either user a - _ or CamelCase, as this makes them eaiser to script against.

[TheVMinator]

Thanks for the input