Network Discovery (part one)

If you’re a network engineer chances are pretty likely you’ve encountered some form of this situation. You get a new job (either assigned to a new customer or a one-off) and are immediately expected to execute a specific task within the network without any previous knowledge of it.

Sound familiar?

The thing is, navigating these situations effectively requires having accurate information for performing network changes and troubleshooting issues reported by the end user. Having the right info is also vital to being a part of the engineering process related to the network’s growth and evolution.

Questions that must be asked: How do you become aware of the network’s blocks, learn all the functions, and work effectively during the “on-boarding” phase? The truth is, the answers to these questions are actually more complicated than they may appear.

Over the years, I have supported lots of networks and many customers — everything from smaller networks with just a few sites across a country, larger ones covering several countries, to enterprise networks with sites worldwide. Personally, I have found that the approach to initial discovery is nearly the same with most networks regardless of size.

To start, it’s highly recommended to obtain a very high-level of information covering lots of sources.

These include but are not limited to:

• engineers also participating on the same project
• existing documentation
• outputs and reports from the running monitoring tools
• hands-on practice on the real infrastructure

Let’s cover each bullet and try to find the optimal way to discovering the unknown networks.

Experienced Colleagues

Reaching out to experienced colleagues is one of the most valuable ways of gaining a great initial view of any network. When a team has been working on a network for some time, they are an excellent resource for information; capable of providing technical background from their hands-on experience during the implementation and troubleshooting process.

Keep in mind; however, that is some cases, although an engineer might be great at their job, it doesn’t necessarily mean they’ll be a good teacher. There may be particular facts concerning the network that they forget to relay because for them the information isn’t important to their job.

“I thought it was pretty obvious…”

I’ve heard this exact sentence a million times, and it’s always been due to the fact that it’s tough for experienced colleagues to remember and explain all of the functions, blocks, and overall behavior.

Existing Documentation

This is the trickiest section, as documentation can either be a highly valuable source of information (if it’s up to date) or can cause a lot of pain and headaches in the case that it hasn’t been updated for a while.

There are few attributes of proper documentation, so let’s name some of them:

• Documentation as itself should be well stored (shared drive, MS Sharepoint, Atlassian Confluence etc.) and should use the user-roles based access.
• The documentation should be structured — one of the best approaches is to use High-Level Design documents (HLD) to give an overview without all the details and then use a set of Low Level Design documents (LLD) to add all the necessary details to be documented.
• All the documents should have the information of the history and versions — usually at the beginning of the specific document.
• There should be a table with the version change records containing the author of the change, date and a few notes. This creates proof the documents are being updated (or, of course, if they aren’t).

Since we could easily spend hours and days talking about documentation, I’m going to move on to the other topics. I’ll return to documentation in a later series.

Monitoring tools

This is the best way to get in touch with the reality of the network (as opposed to something said by a colleague or written in the documents). Utilizing monitoring tools offers a view of the actual state of the network’s devices and functions.

• open-source software like Nagios or Zabbix etc.
• commercial tools like HP IMC, Cisco Prime and other Cisco tools or IBM Netcool
• proprietary solution or personally developed software for controlling the network

An excellent place to start is to go through the tools that are running and collecting a lot of data , such as network inventory to check the specific vendors and architecture and IPAM (IP Address Management). You want to focus on the structure of the network, monitoring features including alarms, and database issues in order to identify the common problems reported by different types of users, etc.

There are plenty of tools that can be run for network discovery and create automated reports, supplying an excellent source for additional information when getting started.

In other words, the approach here is about deploying monitoring tools to acquire the desired data — and that’s my point. It doesn’t matter if I’m using my own scripts (PERL, PYTHON or VBS) or some existing software, the primary goal is to go through the network, collect specific sets of data, and be able to analyze all of the outputs.

Hands-on experiences

Without any doubts, having hands-on experience is the most valuable and reliable resource for information. Yes, this is a slow process since it doesn’t rely on any documents or anyone’s advice. The truth is, though, that by going through different types of devices, different blocks, parts of the network — just to see the configuration and the features being used, you learn so much first-hand. The only requirement needed is access and login to the devices.

For many smaller companies, access is usually available immediately. With larger companies and global enterprises, the process of obtaining the necessary credentials can take days if not weeks. The reasoning for this is that the administration and processes of these companies use a centralized solution to control access, such as RADIUS or TACACS+…

Conclusion

This is the first part of my series exploring how to become more familiar with networks from scratch. To better understand this process, I have built a small lab environment with a lot of features for testing the network discovery process without relying on pre-existing documentation or advice from colleagues.

During this series, I intend to show you the various approaches , manual work, some scripting tips, and use IP Fabric software to illustrate the differences between each method we use.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.