Skip Headers
Oracle® Communications Network Integrity MIB-II UIM Integration Cartridge Guide
Release 7.1

E23707-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 About the Cartridge Components

This chapter provides information about the components of the Oracle Communications Network Integrity MIB-II UIM Integration Cartridge.

The MIB-II UIM Integration Cartridge is composed of several actions, each containing several processors. The cartridge contains a Discover MIB-II SNMP action, which contains the following processors:

The cartridge contains a Detect MIB-II UIM Discrepancies action, which contains the following processors:

The cartridge contains an Import MIB-II from UIM action, which contains the following processors:

The cartridge contains a Resolve MIB-II in UIM action, which contains the following processors:

Discover MIB-II SNMP Action

The Discover MIB-II SNMP action scans a device and provides a logical hierarchical model of what is discovered. The Network Integrity MIB-II SNMP cartridge is designed to be used on a standalone basis to display the Logical device hierarchy in the Network Integrity GUI.

Figure 5-1 shows an example of a Discover MIB-II SNMP scan action as used in the Network Integrity UI.

Figure 5-1 Discover MIB-II SNMP Scan Action

Displays scan action menu for discover action

MIB-II Properties Initializer Processor

The MIB-II Properties Initializer processor is used to output the following data sets:

  • snmpVendorNameMap: contains a snapshot of industry enterprise numbers to help identify devices in the network.

  • snmpIfTypeMap: contains a snapshot of ifTypes to help identify interface types in the network.

Table 5-1 shows a fragment of each data set output from the MIB-II Properties Initializer.

Table 5-1 MIB-II Properties Initializer Fragment

Sample snmpIfTypeMap Sample snmpVendorNameMap

1: other (1)

0 = Reserved

2: regular1822 (2)

1 = NxNetworks

3: hdh1822 (3)

2 = IBM

4: ddnX25 (4)

3 = Carnegie Mellon

5: rfc877x25 (5)

4 = UNIX

6: ethernetCsmacd (6)

5 = ACC

7: iso88023Csmacd (7)

6 = TWG

8: iso88024TokenBus (8)

7 = CAYMAN

9: iso88025TokenRing (9)

8 = PSI

10: iso88026Man (10)

9 = ciscoSystems

251: vdsl2 (251)

34730 = FRANCILIENNE D'INGENIERIE ET DE SERVICES INFORMATIQUES SAS


The content of these files may change from time to time, so they are maintained as part of cartridge revisions. SDK extensions to this cartridge can update the content of the property files. See Design Studio Extensions for more information.

MIB-II SNMP Collector Processor

The MIB-II SNMP Collector processor is used to collect SNMP variables from a device. See About Poll Lists for more information.

MIB-II SNMP Modeler Processor

The MIB-II SNMP Modeler processor is used to model the data collected from the MIB-II SNMP Collector processor. Modeling includes building the hierarchical relationship of logical device and child Interfaces.

Detect MIB-II UIM Discrepancies Action

The Detect MIB-II UIM Discrepancies action provides the capability to detect discrepancies between discovered data and inventory data in UIM.

MIB-II UIM Filter Initializer Processor

The MIB-II UIM Filter Initializer processor is used to implement the following filters:

  • Filters are implemented to disregard the ID field for the Logical tree, this is not discovered value.

  • Filters are implemented to treat Media Interface and Device Interface as the same object, Media Interface is derived from Device Interface but UIM does not implement Media Interface.

  • Filters are implemented to disregard DeviceInterfaceConfigurationItem, as UIM does not implement this.

  • Filters are implemented to ignore CR/LF in LogicalDevice description field which may not be preserved in UIM.

  • Filters are implemented to use nativeEmsName, EntityType, and Specification as the comparator across all entities to determine if two objects, one from discovery and one from import are one and the same for the Logical tree.

Discrepancy Detector Processor

The Discrepancy Detector processor inherits base operations. For more information, see Network Integrity Developer's Guide.

Import MIB-II from UIM Action

The purpose of the Import MIB-II from UIM action is to import Logical Device Trees from UIM. The user can set filters in the Import scan to determine what can be imported.

Figure 5-2 shows an example of a Import MIB-II from UIM scan action as used in the Network Integrity UI.

Figure 5-2 Import MIB-II from UIM Scan Action

Displays scan action menu for import action

Table 5-2 describes these filters.

Table 5-2 Import Scan Filters

Filter Filter Qualifier Pattern Example

LogicalDeivceId (UIM ID)

  • EQUALS (default)

  • EQUALS_IGNORE_CASE

  • BEGINS_WITH

  • BEGINS_WITH_IGNORE_CASE

  • ENDS_WITH

  • ENDS_WITH_IGNORE_CASE

  • CONTAINS

  • CONTAINS_IGNORE_CASE

MgmtIPAddress::sysName::”LogicalDevice”

10.156.68.136.rot3640-11.LogicalDevice

Name

  • EQUALS

  • EQUALS_IGNORE_CASE

  • BEGINS_WITH (default)

  • BEGINS_WITH_IGNORE_CASE

  • ENDS_WITH

  • ENDS_WITH_IGNORE_CASE

  • CONTAINS

  • CONTAINS_IGNORE_CASE

sysName

rot3640-11

Mgmt IP Address

  • EQUALS (default)

  • EQUALS_IGNORE_CASE

  • BEGINS_WITH

  • BEGINS_WITH_IGNORE_CASE

  • ENDS_WITH

  • ENDS_WITH_IGNORE_CASE

  • CONTAINS

  • CONTAINS_IGNORE_CASE

N/A

10.10.10.10

AssignmentState

EQUALS

  • UNASSIGNED

  • ASSIGNED

  • PENDING_UNASSIGN

  • PENDING_ASSIGN

  • DISCONNECTED

  • TRANSITIONAL

  • PORTED

  • UNAVAILABLE (not supported in UIM)

  • PENDING_UNAVAILABLE (not supported in UIM)

  • PENDING_AVAILABLE (not supported in UIM)

N/A

AdminState

EQUALS

  • NSTALLED

  • END_OF_LIFE

  • PENDING_INSTALL

  • PENDING_UNAVAILABLE

  • UNAVAILABLE

  • PENDING_REMOVE

  • PLANNED

N/A


The import functionality is implemented to

  1. Retrieve all the Logical Device Ids that match the filter criteria & have specification “deviceGeneric”.

  2. Iterate over each Id,

    1. Retrieve the Logical Tree from UIM.

    2. Persist the Logical Device and children interfaces.

This action provides UI parameters that allow the user to set filters when creating an import scan. The filters determine the set of entities included in the import scan.

Logical Device UIM Finder Processor

The Logical Device UIM Finder processor retrieves logical device Ids that match the filter criteria. Retrieval is done using ora_ni_uim_webservice operations.

The implementation includes the filtering for Logical Devices that are constructed with the specification deviceGeneric and interfaces with specification interfaceGeneric. Any Logical Device using another Logical Device specification cannot be imported without custom handling.

A Logical Device with specification other than deviceGeneric is not imported.

A Device Interface with specification other than interfaceGeneric is not imported. The interface branch is pruned at the parent object. An error indicator displays in the Network Integrity GUI to indicate pruning has occurred. If interfaces with other specifications are required, custom handling must be implemented.

Figure 5-3 provides an example of the error indicator. Serial0/0 has a subInterface with a foreign specification and so was pruned.

Figure 5-3 Error Indicator Example

Displays the UI error indicator

MIB-II UIM Importer Processor

The MIB-II UIM Importer fetches and processes the Logical Device tree from UIM. Fetching is done using ora_ni_uim_webservice operations.

MIB-II UIM Persister Processor

The MIB-II UIM Persister stores the Device tree in Network Integrity.

Resolve MIB-II in UIM Action

The Resolve MIB-II in UIM action resolves discrepancies between Network Integrity discovery and UIM import. In other words, the action constructs and updates logical device trees in UIM.

The implementation instantiates a class called BaseResolutionElement, which acts as a "triage system." Handlers registered into BaseResolutionElement deal with particular entities.

When you submit one or more discrepancies to be resolved to UIM, the batch of discrepancies is sent to the BaseResolutionElement, which sets the order and priority of the discrepancies. BaseResolutionElement then calls entity handlers to dispatch the resolution to UIM. The entity handlers use the ora_ni_uim_webservice to communicate with UIM.

Table 5-3 displays the handlers called by BaseResolutionElement with their corresponding discrepancy types and definitions.

Note:

ora_ni_uim_device_sample cartridges must be installed in UIM for this action to function.

Table 5-3 Discrepancy Handling

Handler Discrepancy Type

Logical Device Handler

Entity+

AttributeValueMisMatch

Device Interface Handler

Entity+

Entity-

AttributeValueMisMatch


Note:

The following is a summary of Entity+ Entity-:

  • if Entity+ Entity is missing from UIM, it is created in UIM

  • if Entity- Entity is in UIM but not discovered, it is removed from UIM

  • if AttributeValueMisMatch Entity has field value that differs, UIM is updated

The Entity Handlers use the Oracle Communications Network Integrity UIM Web service to communicate with UIM. See Network Integrity UIM Sample Web Service Guide for more information.

Oracle Communications Network Integrity UIM device sample technology pack must be installed in UIM for this to function. See Network Integrity UIM Device Sample Technology Pack Implementation Guide for more information.

Resolve Framework Initializer Processor

The Resolution Framework Intializer is used to instantiate the BaseResolutionElement and the Web service connection class.

The behavior around the BaseResolutionElement is that discrepancies are sorted, and processed serially to UIM. The order of execution of discrepancies is

  1. Attribute Value Mismatch All

  2. Entity- DeviceInterface

  3. Entity- LogicalDevice

  4. Entity+ LogicalDevice

  5. Entity+ DeviceInterface

Order is important to ensure that for example you create a LogicalDevice before you create a DeviceInterface.

MIB-II UIM Resolution Initializer Processor

The MIB-II UIM Resolution Initializer is used to register Entity Handlers into BaseResolutionElement. As stated above, there are two handlers: LogicalDeviceHandler and DeviceIntefaceHandler.

Resolution Framework Dispatcher Processor

The Resolution Framework Dispatcher is used to tell BaseResolutionElement to start triaging and treating discrepancies using the registered entity handlers.

The behavior around the Web service is as such.

The Entity handler creates a Web service messages and populates data into the body of the message. The connection to UIM is established if it does not exist. The Web service msg is sent to UIM. The entity handler waits for the response. When the response is received, it is inspected to observe the outcome. If a success msg is returned, the discrepancy is marked success, if the msg returns fail, or Exception the discrepancy is marked fail. See Network Integrity UIM Sample Web Service Guide for more details and examples.

Note:

There is no transaction handling across the Web service. This means that if a discrepancy is successful, a subsequent discrepancy failure in the batch does not roll back the former. Each discrepancy is an independent event.

The position of the object in the hierarchy being treated is significant. For example, an Entity+ for Logical Device means requires creating a Logical Device and all child interfaces. If creation of some child entity fails, the cartridge reports partial failure to the discrepancy resolution result. In effect, creation is a “BestEffort” mechanism.

For Entity+ DeviceInterface, the handler attempts to create the Device Interface and all children subDeviceInterfaces where applicable.

Scenario: Creation of Logical Device (LD) in UIM

If there is no pre-existing LD in UIM, the user should see Entity+ for the root logical device. Resolution of this entity executes such that the entire LD tree is created. Creation of the LD tree includes LD and children Device Interface (DI) or subInterfaces.

  1. Creation of any object in the tree is dependent on the Id not being occupied in UIM. If the Id is occupied, object creation is also cancelled for any child objects. If an object fails to be created, the root object that initiated the start of creation is marked fail or partial fail if you are looking at logs. However parts of the tree may be fully created and available in UIM. Cancelling does not rollback any successfully created objects. The next round of import, discovery, and discrepancy detection highlights which objects do and do not exist allowing the user to continue resolution operations.

  2. When objects are about to be created in UIM, there is no searching to see if the object already exists in UIM with the same name/nativeEmsName, along with adopting that object rather than creating it. This is the out-of-box behavior, and can be extended to meet your needs. The user should realize, UIM does not guarantee name uniqueness, so there are considerations that an SI should account for. If one object with the desired name and no children objects are found, you could adopt it. If two objects are found with the same name, custom handling is required. If an object is found with children objects, custom handling is required. If an object is found already participating in a tree, custom handling is required.

    So in summary, the out box behavior is to create objects with the NI Id pattern. If the Id is occupied, creation cancels. Resolution does not search by name for existing objects; it creates them leaving the exercise of handling duplicate objects to a UIM administrator or SI to customize handling.

    The above three paragraphs apply to all resolution scenarios and is not repeated.

Scenario: Creation of Device Interface (DI) in UIM

If a Logical Device (LD) exists in UIM but is missing a child DI, you should see Entity+ for the DI.

Resolution of this entity is executed such that the DI and any children of the DI are created.

Scenario: Deletion of Device Interface (DI)

If a device interface, a child of a logical device or a device interface, exists in UIM, but it is not discovered, you should see Entity-.

Resolution of the Entity- is executed such that the DI is deleted. DI does not exist in isolation it must exist in context of the parent object.

Scenario: Mismatch Data

The following fields are ignored

  • Id is not a discovered field

  • nativeEmsName is used for matching objects and is not considered for mismatch

  • DeviceInterfaceConfigurationItem only exists in NI and not UIM

Scenario: Mismatch of LD data

If a LD in UIM has data that does not match the data discovered, the user should see Mismatch. Resolution updates the mismatched LD attribute in UIM, setting the UIM value to the discovered value.

Scenario: Mismatch of DI data

If a DI in UIM has data that does not match the data discovered, the user should see Mismatch. Resolution updates the mismatched DI attribute in UIM, setting the UIM value to the discovered value.