Sean Boal

Over the years, I have implemented and inherited just about every size and flavor of network. Some designs were well thought out, others were creative, and I have no idea what some were thinking or what they were trying to accomplish. What I have found to work well over the years is based on five core design rules.

Be consistent

It is better to have everything all right or all wrong. One-offs or multiple one-offs are difficult to account for making implementing changes and troubleshooting more difficult than necessary. If you need to correct something or plan to move in a different direction, it is much easier to correct or change if everything is consistent, even if the consistency is an error.

Say no to temporary solutions

We all have the best intentions to update or correct a temporary solution. Unfortunately, temporary solutions more often than not become permanent. If you find you do not have the resources to implement your permanent solution, wait until you do. In the event, that you have no choice and you need to implement a temporary solution, tattoo it on your arm, write it in red on your to-do list, or make sure you add it to your project list and give it a high priority to unwind your temporary solution and get it into a permanent state as soon as possible.

Kiss: Keep it simple, stupid

I have been blessed to lead some extremely brilliant people in both the private and public sectors. Some of these folks have held multiple degrees, could easily work for NASA, and could run circles around me on my best day. Unfortunately, unless these folks are working with similarly like-minded people, no one understands what they are talking about or what they have implemented. Reduce designs and implementations to the most elementary state while still accomplishing the business need; this will allow your environment to be understood and managed by a broader group. Staff will come and go, and it is important that new staff members with similar skill sets can step in and get to work right away without needing a decoder ring to figure things out.

Plan, plan, and plan some more

There is no perfect network configuration or naming scheme. What works well in one environment may not necessarily work well in another. Take the time to plan out your structure and naming to account for growth, reconfiguration, and ease of understanding for the broadest group of technical folks possible. Again, we don’t want to depend on decoder rings, researching technical documentation, or anything else that might hinder troubleshooting or re-configuring the network. Do everything you can to reduce people having to think. When the network goes down in the middle of the day on payday, you want people to instinctively go to the source of the trouble without having to pull out the decoder ring.

Document and track

Once you have created your masterpiece network design and naming scheme, document it and make sure everyone knows where the documentation is located. Make sure to keep a current hard copy readily available. If and when systems go down, you don’t want your documentation to be stored on the system you are trying to get back up. Also of critical importance is tracking all of the assets you manage. I was once asked why it was so important that we knew where every monitor, computer, server, printer, router, and switch were located at all times since there was much more important work to do. Besides the obvious reason that we are paid to manage exactly that, when malware or any cyber threat occurs, you want to know exactly where every device is so it can be remediated and accounted for without having to run around with a clipboard.

The examples below are not real; they have been compiled from various configurations I have been part of implementing over the years. My desire is to get you started with some concepts that will assist you in designing a solution that works for your environment.

My challenge to you is this: when you are done designing and implementing your network, will it pass the cool kid test? Will it cause other technical folks who visit your environment to leave inspired to attempt to make their network as cool as yours? I hope so!

Servers

Syntax usage example:

• ACC-AP-CH-01
• ACC-AP-CH-02
• ACC-DB-CH-01

Workstations

Since workstations are more likely to move around more frequently than servers, routers, switches, printers, and other devices, using the serial number or asset tracking number as the device name saves time and confusion by not having to rename and re-label the workstation when it moves. Moreover, unless the workstation provides a unique purpose beyond general use, there is not much need to know more about the device via its name. Generally, you are going to remote into a workstation to assist a user or identify it as an asset to move or refresh. In these cases, this can be easily accomplished via your asset tracking solution, Active Directory, System Center, or other management tools. Having used Track-It! for over twenty years, I have found its asset tracking and remote capabilities to be the ideal solution.

Printers

Syntax usage example:

• CH-F2-LJC-01
• CH-F2-LJC-02
• PW-F1-PLC-03

Other Devices

Syntax usage example:

• CH-F1-PDU-03
• CH-F1-SWI-05
• PD-F2-CAM-07