Computersight -

We will start by tidying up a few loose ends in our naming conventions and physical labeling structures by taking a brief look at what the manufacturer give us that can be used to our own ends.

Manufacturer Naming and Labeling Conventions

More often than not manufacturers tend to use the following conventions for defining the various ports, I/O interfaces of their products are:

• Device – Product family and/or series numbers, model numbers, serial numbers etc.
• Slot – May be fixed, factory installed or field upgradeable
• Interface and Port Numbers – May also be fixed, factory installed or field upgradeable
• Port Numbers – Usually based on some form of numeric naming convention structure and are usually to be factory labeled which is very convenient for us. In the case of field upgradeable and field installable add-on modules you will usually find that the various add-on modules will also be factory labeled.

Logical Naming Conventions

Manufacturer naming and labeling conventions are great when it comes to dealing with a devices operating system or any other installed software that you use for administrative purposes. Most of their documentation will point you in the direction of using their designated naming and labeling conventions with respect to the OS of their hardware.

The problems can arise once you begin to start subdividing your network into subnets and Virtual Local Area Networks (VLAN) then you and the rest of your administrative staff will need to have some form of physical naming and labeling conventions to fall back on.

The importance of this will surface when it comes to troubleshooting at the physical level (connectivity issues for example). Considering the high port densities on modern switches this is a necessity.

One simple and very practical example of the melding of logical and physical naming structures that I use is in the naming of routers and switches. I would name a distribution switch “RedSales”, “SalesRed”, “RStarSales” or something along these lines.

I think it is obvious that now the logical name of the device actually ties into the physical naming and labeling conventions structure. More “human friendly” reminders that we are all talking about the same devices. The importance and value of visual clues cannot be underestimated.

The greatest enemies of any communications and networking center are ambiguity and confusion. “What we have here is a failure to communicate.” Here is a phrase you do not want to have connected in any manner with your communications center. Those saying it are not being complimentary.

Visual Clues

Using visual clues such as a red star to indicate that workgroup switches connect to the similarly encoded red star distribution switch is a good idea. It also ties in with your logical naming conventions structure. The importance of this is becoming ever more so by the day. One reason for this is the needs and requirements of the unified communications converged network.

Unified Communications and Network Convergence

Most IP Telephony solutions utilising Voice over Internet Protocol (VoIP) require the voice data and other “normal” network data streams to be via different Virtual LANs (VLAN).

Quality of Service (QoS)

Part of the reason for this need to separate the two data streams is due to the negative impact that carrying low performance just-in-time data such as voice has on more bandwidth demanding networking applications such as large file transfers.

It is all a question of Quality of Service (QoS). Jittery voice traffic can quickly become counter-productive in that users will revert to the more traditional telephony systems that do not exhibit QoS issues. The best solutions have been to separate both streams and then either multiplex them centrally or deliver them as separate data streams to your carrier who will multiplex them.

Today with the capabilities of networking infrastructure, core and distribution devices truly “converged” data streams of both types is possible. The result is that solutions such as those offered by the likes of Cisco® do require the separation of both types of data streams at the access level.

Virtual Local Area Networks (VLAN) to the Rescue

The result is an increase in the number of VLANs that need to be implemented one for each workgroups “normal” data and another for the voice traffic. This adds an extra layer of complexity to the physical connectivity situation.

Physical Connectivity Troubleshooting

Whenever troubleshooting connectivity issues are concerned, the more help that the techie can get from your clever use of a naming and labeling convention where it counts most the better. In front of the poor bewildered user’s eyes when speedy resolution is all that counts.

All right, I know it may seem that I am harping on this physical connectivity-troubleshooting theme but the statistics show that over 80% of all connectivity issues are in fact physical connectivity issues. Devices plugged into the wrong outlet and the power not turned on being at the top of the list.

Label Security

All good naming and labeling systems will pay great attention to the physical security of the labels. I have already given an example of why this is so important earlier in this article under the heading of predictability.

In the scenario I outlined you can see how the greatest labeling and naming convention system in the world can fall flat on its face. Labels prone to easy dislodgement are a prime culprit here.

Take Preventative Precautionary Measures

One simple precaution that would have prevented the confusion that arose from misplacement of labels could have been by simply making the labels fixed. By fixed I mean attached securely in a manner that is free from risk of accidental displacement and relocation.

One way of doing this is the use of a crosscheck system. Remember that your router can’t yell out loud that “Hey! They’ve put the wrong tag on me!” You have to be the routers voice in this type of event. Your only real option is prevention and not telepathy.

Crosscheck Systems

This one is very simple and easy to implement. For example in the case of rack mounted devices or rack located devices (not physically bolted to the rack) you would attach one label to the device and another corresponding label will be fixed to the rack.

Paired Tags

In its simplest form, both labels would have the same (twin) tags. The devices and storage unit that houses them can now be easily counter referenced one against the other and verified as correct in situ courtesy of your matching labels.

Any misplacement is detectable at first sight given that the person accessing the devices at the physical level does follow policy and performs the verification check.

Device Placement

One of the most interesting facets about network infrastructure centers is that devices tend to be static. Perpetual moving or temporary setup locales are not for these devices. I guess that is why they we classify them as network infrastructure. Permanent labeling systems are right at home here.

It is essential that you give due care, attention and thought in planning the physical placement of devices in your network infrastructure centers. This goes for the home network as well. Placement makes the creation of naming conventions and the physical labeling of devices and their physical housing locations much easier than it could be.

Crosschecking

When using a physical naming and labeling system similar that has built-in crosschecking capabilities it is important that you use it.

Whenever there is the need for physical interaction with your network infrastructure devices and their physical storage locations it is critical that you interact with the correct device. This is where your carefully constructed naming convention and labeling system will pay handsome dividends.

Whoever is to perform the physical attendance work must first confirm that they have located the correct device’s physical storage location and then that the correct device is actually in that location. Do this by checking the label tags for both device and physical location to verify that they match. As already mentioned machines cannot actively scream out that, the naming labels are wrong.

Checklists

Always maintain system and infrastructure naming conventions and labeling implementations checklists that clearly identify both process and procedure in a systematic progression. This helps to reduce confusion as well as ensuring that whatever needs doing is done correctly and in accordance with prescribed procedures, the first time every time.

Using Checklists

Checklists are also vital for the effective functioning of anybody who is not intimately familiar with your systems and infrastructure.

The new staff member does not “need to learn the ropes” in order to be immediately productive even in the most complex of environments. All that needs to be done is for the new guy to be given thorough instruction concerning the use and procedural peculiarities of this facility and all within it. The rest he will learn along the way.

The beauty here is that most of his learning takes place as he works and without even realizing it. Certainly saves a lot of time training people for things they may need one day. When that day arrives, you have a procedural checklist ready to deal with it.

The technicians only need to know where to locate the appropriate checklist and a known solution or workaround will be implemented post haste.

Teamwork

It is advisable to use teamwork when undertaking tasks that we are not familiar with one a day-to-day basis. Both members of a pair will act to ensure that the actions taken in any specific situation or crisis are in accordance with the correct prescribed procedure.

One example that is most familiar to most people is the concept of cockpit checklists and procedures. The flight routines are not optional. Most of us have seen this process at work in a movie or air crash investigation so the concept should not be alien to us.

Another very important function that using checklist provides is to act as a reminder of what is to come next. A quick review of the checklist prior to commencement of the procedure and it all comes flooding back to us. This is one of the fundamental philosophies behind “open book” exams.

Well next time we will discuss drilling, rehearsal and trialing procedures. The focus will be upon providing you with pointers towards designing your own procedures. Until then enjoy!