In my last post, Telecom Network Discovery Primer, I described the importance of Telecom network visibility and detailed a few use-cases and problems this comes to solve.
Today, I want to deep dive into the details of how Network Discovery is achieved and focus on one method, which is discovery directly from the network elements and explore one implementation of this method that will be coming in ServiceNow Yokohoma release. In future blog posts I will describe additional methods and implementations.
When we're discussing Telecom Visibility, this is really broken down into 2 main parts:
- Telecom Network Discovery
- Telecom Network Reconciliation
Where the first part deals with how to connect to the network and gather all required information and data from it, whole the second part deals with how write that data in the inventory or CMDB, reconciling any discrepancies that might be found between network data and inventory/CMDB data.
A Telecom Network is a super complex entity, consisting of multiple domains (wireline access, RAN, Transport, Core, etc.), different technologies (physical, virtual, containerized) and usually the network equipment installed comes from many different vendors. Usually, you will also have various management systems (such as element management system or network. management systems, or EMS/NMS in short) from the different vendors that manage their installed equipment.
In order to be able to achieve a wide and complete coverage as part of Telecom Discovery, you must be able to cater to both discovering data by directly connecting to the network elements and discovering data by connecting to the various management systems that are deployed.
The factors to making a decision whether to connect the elements directly or indirectly span a mix of technical considerations, scale and performance concerns and commercial issues (e.g. some Vendors prohibit another management system from connecting directly to their elements).
In most cases, the decision will be done per domain or even per vendor and you will use both direct and indirect discovery methods for different parts of your network.
Shown below is a typical example of a discovery process, spanning multiple vendors, where you can see we have one arrow going directly to the network elements and one going to their Vendors EMS/NMS systems.
As part of ServiceNow upcoming Telecom Visibility functionality, which will be arriving at the Yokohoma release, early 2025, we plan to support both methods, where the direct discovery will be accomplished using Patterns and the indirect discovery will be accomplished using Service Graph Connectors (and those would enrich the existing rich library of patterns and SGCs available for IT discovery). Today I will focus on such pattern implementation.
The first pattern we chose to implement is Simple Network Management Protocol, or SNMP. SNMP is considered an "old-school" management protocol, but it has proven itself to be an excellent data gathering tool from the elements, and is widely adopted, with more than 95% (probably more) of the Vendors supporting it, even as part of new devices built.
More patterns to cater for more management protocols are going to be added as we progress, and I'll actually cover another one in another blog shortly, so consider this as a teaser 🙂
The work that has done in order to enable Telecom Discovery via SNMP concentrated on enhancing existing SNMP patterns capability and allow them to read a deeper set of data from the network elements and being able to understand and build the inventory hierarchy as it exists on the network equipment, so we are able to read the chassis->slot->card->sub-card->port->interface full hierarchy and write this into TNI/CMDB.
In addition, as part of the new pattern, we are gathering a much bigger set of attributes on the various objects in the aforementioned hierarchy and update them into existing CIs in the TNI/CMDB.
The overall flow is shown in the diagram below, and it consist of:
- Basic scan to detect SNMP elements in a given IP range
- Classification for each element in that range that was determined to "speak" SNMP:
- Each Network Element supporting SNMP has unique identifier called system object ID (SysOID). This SysOID represents the device type of the element and is retrieved as part of initial scan.
- Classification is done, checking if the SysOID of the element is part of the supported elements by the new Telecom SNMP Discovery pattern
- If the Network Element was classified successfully, we run the Telecom SNMP Discovery Pattern and read all data from the Element according to the "instructions" which make up the pattern
- Discovered Data is then stored into CMDB, either by new CI creation or by update to existing CI
- Reconciliation is performed using CMDB compliance and audit tools
- If discrepancies are detected, reconciliation workflows can then be triggered
That's it for today, next time I'll describe the indirect, via EMS/NMS discovery method, hope you'll be looking out for that as well.
Thanks and please do reach me out if you have any interest in Telecom Visibility.
2 Comments
