Continuing with the Cisco UCS 101 series, I thought I’d post on MAC, WWPN, WWNN and even UUID pool naming conventions. There’s a number of ways this can be done but as a general rule-of-thumb my pools will ensure a few things:
- Uniqueness of MACs/WWNs/etc. across blades, UCS Domains (aka “Pods”) and sites.
- The MAC’s/WWNs/etc. that are created from your pools should give you some level of description as to the location, fabric and OS that is assigned to that particular address.
- Lastly, the naming convention should be as simple and un-cryptic as possible. Naming conventions are useless if they aren’t easily discernible to those tasked with reading them.
With that out of the way, lets look at a common naming scheme:
This is fairly straight forward. The first three bytes are a Cisco prefix that UCS Manager encourages you not to modify. This can actually be modified but I always keep it the same. The next digit in this naming convention represents a site ID. This can be any physical location where UCS may reside, so a production site might be “1” and a DR site might be “2”. Then we come to “Pod”, in UCS nomenclature a “Domain” or “Pod” is simply a pair of fabric interconnects and any attached chassis’s. For OS, I usually use “1” to denote VMware, “2” for Windows and “3” for a Linux host. Fabric just denotes whether the MAC should be destined for Fabric A or B. The last byte will just be an incremental number assigned by UCS. Let’s look at an example:
In this example pool, the MAC address would belong to a server at site “1” that resides in UCS Pod “1” that is running VMware and should be communicating out of Fabric A. A MAC address of 00:25:B5:23:1B:XX would denote a server at site “2” in the third UCS pod at that site running VMware and communicating out of Fabric B. Another commonly used naming convention would look like this:
The only difference here is that the site/pod distinction has been done away with in favor of just UCS Pod ID. So while this example won’t allow you to easily distinguish a particular site, it will give you much larger Pod ID possibilities. There’s no right answer as to which is best, it really just depends on the environment and personal preference. For WWPN pools, I follow an almost identical naming scheme:
Again, the Cisco prefix can be modified but I just prefer to leave it as it is. For WWNN, I follow a very similar convention except that I exclude Fabric ID:
As you can see, whether I’m looking at the MAC address, WWPN or WWNN I can easily discern from which site and pod the address originates, what OS the address belongs to and what fabric it is communicating out of. UUID pools can be named similarly:
This doesn’t have to and shouldn’t be complicated. These simple, common naming schemes will not only ensure unique, informative and easily discernible addresses but can make common management tasks such as network traces or zoning that much more easy. Use the above examples as a guideline, but feel free to customize if there’s a scheme that fits your environment better. For more on this topic, I recommend the following resources: