4 min read time

Flexible CI Type and Attribute Mapping with NNMi-UCMDB Integration

by   in IT Operations Cloud

Lack of visibility and inaccurate topology create ongoing issues from troubleshooting to security governance, especially as IT infrastructure grows more dynamic.  Organizations must be able to clearly understand their IT estate and trust their data.  Network Node Manager i (NNMi) works together with Universal CMDB (UCMDB) to capture the ever-changing network infrastructure using our patented high-speed spiral discovery (rated as “Outstanding” by EMA in their Network Performance Management Radar Report).  Read on to learn more about how OpenText helps your organization confront these business issues.

NNMi is a network management solution that focuses on real-time discovery of multi-layer network topology. It offers proactive monitoring and continuous compliance for physical, virtual, wireless and software defined network (SDN) infrastructure, supporting multiple vendors. Access NNMi documentation here.

UCMDB is a configuration management database that collects (by discovery or integration), reconciles, manages, and presents data about configuration items and their relationships. Access UCMDB documentation here.

When these two products are integrated, the Layer 2 topology objects discovered in NNMi are pushed and stored in UCMDB’s database as Configuration Items (CIs) with certain default attributes.

NNMi now introduces the flexibility in the CI Type mapping, allowing users to choose between strong and weak type mapping. This means that network devices can be mapped to appropriate CI Types, like “Router”, instead of just being labeled as “Node” in UCMDB. NNMi also provides flexibility to configure CI attribute information, for network elements such as IP Address, Interfaces, etc., as required.

To achieve this, users can modify or update two parsing templates, known as “mapping files”, found in the $NnmDataDir/shared/nnm/conf/im folder. One template is for CI Type mapping, and the other is for attribute mapping.

CI Type Mapping (strong typing)

Prior to 2021.11, all network devices, including switches, routers, firewall, load balancers, IP phones, and servers were defined as "Node" and mapped to the Node CI Type in UCMDB. This required users to check the attributes of the Node to determine the device type (e.g., router, server). With the enhanced integration, NNMi now accurately represents different device types in UCMDB, allowing clear visualization and improved categorization of network devices. It offers more granular node CI Types for NNMi discovered nodes.

The configuration options provided by the out-of-the-box file include:

  • Mapping a node discovered in NNMi to any Node CI Type in UCMDB
  • Adding a new category or capability in the configuration file and mapping it to a Node CI Type
  • Creating a custom attribute for a specific node in NNMi to mapping it to a Node CI Type

Weak vs Strong CI Type Mapping

The ability to map node CI Types makes it easier for administrators to understand events from NNMi in OBM and determine the corresponding node types.

CI Attribute Mapping Flexibility

In the integration prior to 2021.11, attribute mapping between NNMi objects (e.g., nodes, IP addresses, interfaces) and UCMDB CI attributes was fixed and unalterable. However, starting from the 2022.05 release, users can configure this attribute mapping.

The configuration options include:

  • Choosing not to send certain attribute information. For example, NNMi discovers the Device Model of a node as “Microsoft Windows NT Server, while UCMDB has already populated the Node CI attribute as “ProLiant DL380p Gen8 from UCMDB”. Users can prevent NNMi from overwriting the Device Model in UCMDB.
  • Mapping a specific NNMi attribute to multiple UCMDB CI attributes or even to out-of-the-box or other newly added attributes.

uCMDB receives network data from other sources as well, allowing for Nodes and their attributes to be overwritten. This capability provides flexibility to control and maintain the information in the network element attributes as desired.

For instance, as seen in the picture below, by default the “discovered_description” is populated by NNMi, however with this new capability, the user can configure to map the “discovered_description” value to a newly created UCMDB attribute “desc_test”, to an already existing attribute “description” and can choose to not populate the value to the default attribute “discovered_description”.

If any issues arise with the integration, the parsing templates can be validated using the “nnmucmdbimtool.ovpl” CLI available on the NNMi system. When executed against the new template, the CLI analyses syntax and semantics, providing guidance to correct the templates, reload the mapping, and resynchronize the data.

Overall, this feature offers tremendous flexibility for admins to configure and map devices and their attributes from NNMi to UCMDB based on their organizational use cases and needs.

For more detailed information, please refer to the NNMi documentation site.

written by Waheeda Anjum M


Want to join learn more about NNMi, Network Automation (NA), and Network Operations Management (NOM)? Join our monthly Special Interest Group calls where we discuss (and welcome questions and feedback on) roadmap, industry trends, product enhancements, and more.

Additional Resources


What's New in NOM, NA, and NNMi 2023.05 (blog post)
What's New in NOM 2023.05 (recorded webinar)

Labels:

Network Operations Management