| Oracle® Communications Network Integrity MIB-II UIM Integration Cartridge Guide Release 7.1 Part Number E23707-01 |
|
|
View PDF |
| Oracle® Communications Network Integrity MIB-II UIM Integration Cartridge Guide Release 7.1 Part Number E23707-01 |
|
|
View PDF |
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:
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.
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.
The MIB-II SNMP Collector processor is used to collect SNMP variables from a device. See About Poll Lists for more information.
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.
The Detect MIB-II UIM Discrepancies action provides the capability to detect discrepancies between discovered data and inventory data in UIM.
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.
The Discrepancy Detector processor inherits base operations. For more information, see Network Integrity Developer's Guide.
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.
Table 5-2 describes these filters.
| Filter | Filter Qualifier | Pattern | Example |
|---|---|---|---|
|
LogicalDeivceId (UIM ID) |
|
MgmtIPAddress::sysName::”LogicalDevice” |
10.156.68.136.rot3640-11.LogicalDevice |
|
Name |
|
sysName |
rot3640-11 |
|
Mgmt IP Address |
|
N/A |
10.10.10.10 |
|
AssignmentState |
EQUALS |
|
N/A |
|
AdminState |
EQUALS |
|
N/A |
The import functionality is implemented to
Retrieve all the Logical Device Ids that match the filter criteria & have specification “deviceGeneric”.
Iterate over each Id,
Retrieve the Logical Tree from UIM.
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.
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.
The MIB-II UIM Importer fetches and processes the Logical Device tree from UIM. Fetching is done using ora_ni_uim_webservice operations.
The MIB-II UIM Persister stores the Device tree in Network Integrity.
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.
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
Attribute Value Mismatch All
Entity- DeviceInterface
Entity- LogicalDevice
Entity+ LogicalDevice
Entity+ DeviceInterface
Order is important to ensure that for example you create a LogicalDevice before you create a DeviceInterface.
The MIB-II UIM Resolution Initializer is used to register Entity Handlers into BaseResolutionElement. As stated above, there are two handlers: LogicalDeviceHandler and DeviceIntefaceHandler.
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.
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.
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.
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.
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.
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.
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
|
 Copyright © 2010, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
