Managing Phantom Devices Like A Boss
Do you love surprises?
Most of us do – in terms of birthday presents or unexpected visits of good friends. But when it comes to the network we are managing, this is an entirely different story.
Usually, many tools are employed to allow for better visibility and traceability. CMDBs are populated with data, implemented processes are technically backed up, and your infrastructure is monitored by a network management system (NMS). Alas, initial IP range discoveries at customer site are an often jaw-dropping experience for everybody: Devices emerge from the dust of the IT cloud that should not be there in the first place or – even worse – are completely unknown.
Surprise, you have just discovered a phantom device – a device that should be monitored, but is currently not under management of your NMS. The reasons for the existence of such devices might be diverse, the actual impact unpredictable. It might be a developer workstation that has been reactivated for one of those new interns (that sometimes tend to appear out of thin air). However, an unauthorized BYOD that synchronizes its media playlist via the corporate internet connection might have a serious work impact. Unfortunately, the culprit with those phantoms is that they are “invisible” from the NOC point of view which makes troubleshooting time-consuming and thus expensive, not to mention the fact that you might have a vulnerable device in your network which, in a worst-case scenario, might serve as a gateway for an unknown number of threats.
Reveal, Unmask, Organize
Once you know about the existence of a phantom, you can gather more information and decide on the next steps. So, obviously, it’s a good idea to implement means to automatically detect phantoms in your network. A simple, yet powerful approach is as follows:
- Discover the relevant IP address ranges of your network.
- Omit already known devices.
- Tag all new devices as phantoms.
Surprise, it really is fairly easy to get started and obtain an IP address list of your phantoms. The next step is to gather more information, for which you can tap multiple resources. A DNS lookup is a good method to start with, because the name might already indicate responsible persons. Also, the IP address itself is a valuable information which could point you to the network administrator. Often, phantom devices are test devices to some extent and therefore, a standard SNMP community might be in place or a known corporate standard could work. Another source of information is routing tables and protocols like MPLS or LLDP, only to name a few. Analyzing such connectivity data can be an important step on your road to unmasking these nifty phantoms.
Putting it all together, you can assemble a list of those “not-so-phantom-anymore” devices, enriched with all available data. It must then be decided what to do with them. Is it a relevant machine or should you just get rid of it? Configurations might become necessary to fix vulnerabilities or to meet certain SLAs. Some of them might be worth being automated to avoid repeating the same things all over again and to prevent errors in the process (a good example is configuring SNMP). Eventually, they must be organized, i.e. put under monitoring in your NMS – Invisibility is not an option anymore.
Revealing, Unmasking, Organizing describes a process better known as reconciliation. This dephantomization procedure necessarily contains manual tasks and can therefore not be fully automated. It is also important to be careful when integrating such a process in your NMS workflow. Phantoms are very likely to not meeting your company standards and are prone to generate false-positive alarms in your NOC when applying your standard metrics and monitoring plans. Also, you should avoid high additional load in your business hours. The following figure depicts a dephantomization approach (black) that can be implemented in parallel of your business discovery mechanisms (green).
Figure 1: The dephantomization process
The big advantage of this approach is the maximum amount of automation. The only thing you have to focus on is handling the phantoms and updating your device DB. This way, the former phantom devices become part of the normal monitoring as soon as they are prepared for it and until then the NOC does not even notice that the Phantom devices are becoming part of your NMS, because they are kept in a separate space of the NMS inventory. Nevertheless, you can make use of the full reporting and automation functionalities of your NMS during the dephantomization phase and could extend the whole approach to cover automatic updates of your CMDB or even zero-touch provisioning scenarios.
As you got those phantoms covered, you do not need to stop loving surprises, at least not when it comes to your network.
Share this Blog post:
Consultant & Developer at Infosim