IT Operations Management: When is Discovery not Discovery?

The answer: when the devices you're discovering are not being actively probed by ServiceNow or anything else.

Sounds intriguing, right? This process isn’t actually as painful as you might imagine. There are in fact several methods that can be employed to discover devices without actively discovering them, and many use cases where this proves to be a real benefit. In this blog, we take a look at two such cases.

Two of our customers wanted device information discovered, inserted and regularly updated within the CMDB (configuration management database) but without the extra administration overheads - and not to mention MID Server processing and network traffic overheads. With all the benefits that discovery brings, the challenge was on!

Scenario Number One:

Customer A wanted to know about their wireless access points, or WAPs. They didn't want to have a separate discovery schedule go looking for them due to the wide IP ranges employed, meaning that IP Address Ranges were out. IP Address lists were also out of the question, as this would be too long and cumbersome as an ongoing process. So, we had a look at the infrastructure around the WAPs which happened to be all Cisco devices; the customer also employed Wireless LAN (WLAN) controllers to manage the WAPs. Bingo!

Since the WLAN controllers know all about the WAPs, we just needed to set up SNMP discovery on the switch, ensure the right MIBs (Jargon buster alert - see below) were loaded and discover the controllers. The Cisco 5500 series the customer uses are essentially network switches, so they get discovered as such. Neatly however, as this is a Cisco Switch and it manages Cisco WAPs, horizontal discovery triggers the Cisco WAPs extension to pull in the data directly from the switch. This results in the creation of a standard IP Switch CI, multiple WAP CI's (one record for each managed device) and the relationships between them, which in this case is a Controller for: Controlled by relation. For Customer A this was a straightforward way of bringing device data into ServiceNow’s CMDB with little overhead and no additional maintenance tasks.

Scenario Number Two:

Customer B had a similar requirement but for very different devices. This customer wanted to know all about their IP Phones and AV Video devices (AKA telepresence systems). Just like Customer A, they didn't want the overhead of discovering these devices citing similar reasons around overly broad IP range as this would result in an administration nightmare. As with Customer A, Unifii thought laterally about the problem.

What were the devices (Cisco, again) and where were we likely to get the data from? The answer to this is pretty straightforward. For years, Cisco has employed its own discovery protocols to figure out what devices are connected to what - not just on the network layers, but also the physical and neighbour layers. One of these protocols, CDP, is used to figure out what Cisco devices physically connects to its neighbouring devices. For example, looking at the CDP table of a Cisco switch will display all the Cisco devices that are connected to each of its interfaces. Bingo!

Horizontal discovery in ServiceNow when discovering Cisco Switches and Routers deploys the CDP and LLDP (a non-Cisco proprietary neighbour protocol) extension to scan the CDP/LLDP tables for each device. The records in the table are parsed and written to the Device Neighbours table. Information such as Model, IP Address and MAC Address are populated by default. The pattern can be extended to extract other details such as location etc. as was one of the requirements. It just so happens that the MAC address prefix is almost unique for Cisco IP Phones and telepresence systems, so using that plus the model gives us the required idents.

“This is great, but we don't want to look at the Device Neighbours table for all this info!” I hear you cry - and quite rightly so. Well, we have the OOB (out of box) IP Phone table already, so we may as well use that. And while we're at it, we can create a custom table for the AV conferencing systems - meaning all we need to do is copy the data from A to B&C via a Business Rule, right? Well, yes, but instead we decided to create a Flow for this.

The Flow we created triggers on changes to entries in the Device Neighbour table. When network discovery runs and picks up a change to say the location that's been configured in an IP Phone, the Flow runs and updates the CI in the IP Phones table. If a new Phone or AV Video device gets plugged in, network discovery finds it and creates a new record in Device Neighbours. The Flow is triggered into action by this addition and creates a CI for the device in the IP Phone or AV Video table. If devices are removed/retired then this falls into the standard CMDB governance process for handling stale CIs, as it would for both examples.

So there you have it, two examples of how we employ technology already available in the ServiceNow platform to manipulate discovered data into meaningful CIs. And best of all, two happy customers!

Network Jargon Buster:

WAP - Wireless Access Point; devices that enable mobile devices wireless entry to the network

WLAN - Wireless Local Area Network; akin to your WiFi at home or in your local coffee shop

SNMP - Simple Network Management Protocol; a way of managing network devices

MIB - Management Information Base; essentially a database to interpret OIDs

OID - Object Identifier; the ability to translate information gained from an SNMP ‘GET” query for objects in devices such as hostname, device type and a myriad of other entities

CDP - Cisco Device Protocol; Cisco propriety neighbour protocol for discovering Cisco devices

LLDP - Link Layer Device Protocol; non-Cisco propriety neighbour protocol for discovering Cisco and non-Cisco devices