2 About the Cartridge Components

This chapter provides information about the components that comprise the Oracle Communications Network Integrity Cisco Router and Switch UIM Integration cartridge.

The Cisco Router and Switch UIM Integration cartridge is composed of the following actions:

• Discover Enhanced Cisco SNMP Action

• Import Cisco from UIM Action

• Detect Enhanced Cisco Discrepancies Action

• Resolve Cisco in UIM Action

Discover Enhanced Cisco SNMP Action

The Discover Enhanced Cisco SNMP action discovers Cisco devices and provides a physical and logical hierarchical model of what is discovered. This discovery action also models the associations between the physical and logical hierarchies.

This discovery action extends the Discover Generic Cisco SNMP action (from the Cisco Router and Switch SNMP cartridge) and inherits all its processors. For more information about the inherited processors, see Network Integrity Cisco Router and Switch SNMP Cartridge Guide.

The Discover Enhanced Cisco SNMP action contains the following processors run in the following order:

1. MIB-II Properties Initializer (inherited)

2. Cisco SNMP Properties Initializer (inherited)

3. CPU Property Initializer (inherited)

4. Cisco CPU Collector (inherited)

5. Device CPU Set Processor (inherited)

6. CPU Utilization Compare Processor (inherited)

7. MIB-II SNMP Collector (inherited)

8. MIB-II SNMP Modeler (inherited)

9. Cisco SNMP Logical Collector (inherited)

10. Cisco SNMP Physical Collector (inherited)

11. Cisco SNMP Logical Modeler (inherited)

12. Cisco SNMP Physical Modeler (inherited)

13. Cisco Enhanced Modeler

Figure 2-1 illustrates the processor workflow of the Discover Enhanced Cisco SNMP action.

Figure 2-1 Discover Enhanced Cisco SNMP Action Processor Workflow

Description of ''Figure 2-1 Discover Enhanced Cisco SNMP Action Processor Workflow''

Cisco Enhanced Modeler

For discovering Cisco devices, Network Integrity implements the model that uses a generic specification to define its set of attributes. You can extend the generic specification to introduce new attributes. This model is built on the Information Model for Network Integrity, with modifications to support integration with Oracle Communications Unified Inventory Management (UIM).

Specifications are used to classify and categorize the entities that are found or produced. You can augment these entities with additional properties (attributes) using Design Studio. Specifications can be enhanced with characteristics to collect information about entities.

The Discover Enhanced Cisco SNMP action extends the Discover Generic Cisco SNMP action (from the Cisco Router and Switch SNMP cartridge) and inherits all its processors. The Discover Generic Cisco SNMP action creates generic entities and includes processors from MIB II Properties Initializer to Cisco SNMP Physical Modeler as shown in Figure 2-1.

In a typical Discover Enhanced Cisco SNMP Action processor workflow (illustrated in Figure 2-1), the processors run from MIB II Properties Initializer through Cisco SNMP Physical Modeler to retrieve matching entities (such as discovered physical device tree) and model a generic specification.

The Cisco Enhanced Modeler processor is used to programmatically walk the physical device tree and replace the generic specification with a specification that is consistent with Oracle Communications Unified Inventory Management (UIM).

Each physical entity has a field called modelName which is inspected for its value. The value is used as the specification name. The processor checks that the specification exists. If the specification exists, the processor applies that specification to the physical entity, overwriting the generic specification. If the specification is not found, the generic specification remains and the object does not become a UIM object. It is not staged for resolution to UIM. When you run a discovery scan and you no longer see generic specifications in your physical tree, you are ready to resolve the tree to UIM.

The advantage of extending the Discover Generic Cisco SNMP action is that you can use custom implementation to remodel the generic specification to be consistent with the specification of vendor-specific entities.

When a physical entity does not have any value for modelName and its name starts with Artificial (a result of model correction invocation), a lookup table (remodeler.properties) is used to determine what specification to apply. See Cisco Router and Switch SNMP Cartridge Guide for further information about model correction.

The lookup table allows you to specify (as an example) the key as "nativeEmsName and parent specification name" and value as the "specification name" to be applied. Model correction can produce many artificial entities, so using nativeEmsName and parent specification name in combination generally allows you to uniquely identify the intended entity in the hierarchy. A specification is applied to the physical entity when its nativeEmsName and parent specification name match.

Controlling modelName Content and Re-applied Specification

Systems Integrators can control the content of modelName, and so control the re-applied specification. The process is outlined as follows:

ciscoVendorType.properties sample
9 = cevModule
9.1 = cevModuleUnknownCard
9.2 = cevModuleCommonCards
9.3 = cevModuleC36xxType
9.4 = cevModuleVipPortAdapters
9.5 = cevModuleCpuType
9.5.1 = cevC7200Io1fe
9.5.2 = cevC7200Io
9.5.3 = cevCpuAS5300
9.5.7 = cevCpuRpm
9.5.8 = cevCpu2600
9.5.9 = cevCpu7200Npe300
9.5.10 = cevCpu1400
9.5.11 = cevCpu800
9.5.12 = cevCpuPSM1Gbps 

The suffix of discoveredModelNumber can have up to three tokens delimited by a "."

If discoveredModelNumber contains 9.5.12, and the lookup table contains 9.5.12 cevCpuPSM1Gbps, this is yielded.

If 9.5.12 is not found, and 9.5 is found, cevModuleCpuType is yielded.

If 9.5.12 and 9.5 are not found, but 9 is found, cevModule is yielded.

If 9.5.12 and 9.5 and 9 are not found, then modelName is populated with "Unknown".

About remodeler.properties

The Discover Enhanced Cisco SNMP discovery action uses a generic remodeler to apply custom specifications to physical device results.

The process is data driven through a remodeler.properties file. Each line describes a remodeling rule in this format:

setspecification.entity type[.attribute name.attribute match criteria] = [context/]specification

Where entity type is a type of entity, such as PhysicalDevice. The rule applies only to entities of this type.

The attribute name.attribute match criteria is optional. If present, the attribute with the specified name must match the attribute match criteria for the rule to apply. Match criteria has rudimentary substring matching where you can use the asterisk character to match one or more characters.

The context criteria is optional. If present, the context describes the specification that must be present on the parent entity for the rule to apply. For example, cevContainerPowerSupplyBay/artificial6509PowerSupplyHolderCard only matches an entity if the entity's parent has the specification cevContainerPowerSupplyBay. The context can describe the specifications for multiple ancestors, and not just the parent. In this case, specifications for ancestors are separated by "/".

specification is the name of the specification to apply if the entity matches the rule.

The remodeler walks the physical device tree. For each entity, it looks for a matching rule and applies that specification. Rules are processed in the order that they appear in the property file. Once a rule is applied, processing of that entity stops.

Note:

Standard Java property file format must be followed. In particular, spaces and some other special characters on the left side of the equals must be escaped. For a full description of the Java property file format, consult the java doc for the load() method of the java.util.Properties class.

Supported Devices

The Cisco Router and Switch UIM Integration cartridge is built to support three devices for integration with UIM:

• cisco3640

• cisco7206

• cat6509

It does not support a full library of specifications for all hardware permutations found on these devices. If you try to discover these device instances, you may find certain hardware is not supported. To resolve to UIM, you may have to build up a library of specifications on Network Integrity and UIM to model these devices.

About Cisco Switches

Cisco Switches sometimes run CAT OS not IOS, and entityPhysicalVendorType is sparingly populated, so it cannot serve as the mechanism to identify hardware. To model Cisco switches with specifications staged for UIM, Systems Integrators must make extensive use of the remodeler.properties file, creating a mapping between discovered SNMP values and desired specifications.

The recommended SNMP variable is entityPhysicalDesc which is populated into the description field for Equipment. However, different versions of CAT OS may yield varying values for entityPhysicalDesc for the same hardware, so multiple entries may be required if dealing with various OS versions.An example of the use of remodeler.properties is displayed in the following code. The class CiscoEnhancedModelerProcessorImpl contains the following code:

if (discoveredSysObjId.equals(SYSOBJECTID_6509)) {
       new CiscoRemodeler(getClass(),"remodeler.properties").remodelDevice(physicalDevice);
} else {
       new CiscoRemodeler().remodelDevice(physicalDevice);
}

In this example, remodeler.properties is invoked for the Cisco 6509 to handle artificial objects created by model correction.To handle a particular Cisco switch, add another else if statement to identify it, and then invoke a custom remodeler.properties on it.The else statement invokes default properties to use the field modelName as the source for identifying the specification to apply via the mapping table ciscoVendorTypesMap.

Tips for Creating Specifications

This section identifies some integration tips.

• Discovery fills in the field discoveredModelNumber from a SNMP variable entityPhysicalVendorType.

• discoveredModelNumber is interrogated, and the suffix is mapped to an entry in the table ciscoVendorTypesMap yielding modelName. modelName is thereby controlled using the content of the ciscoVendorTypesMap table.

• modelName as default is used to determine what specification to apply.

• If entity nativeEmsName starts with Artificial, and the device is Cisco 6509, remodeler.properties controls what specification to apply.

• If modelName is blank or unknown, you must either update ciscoVendorTypesMap or make use of remodeler.properties to model the device staging it for UIM.

If you discover a new device or a version of the three devices the cartridge supports out of the box, the specifications are applied and are visible in the entityType column in the physical tree in the Network Integrity UI.

If you see a generic specification in the entityType column in the physical tree as opposed to one that starts with "cev", then you must create a specification for this entity in both Network Integrity and UIM to fully support the device and have it staged for UIM.

For example, if you discover a new device, the modelName field is probably filled with a mapped value from ciscoVendorTypesMap, with a generic specification applied. Inspect modelName for each entity in the tree to ascertain what specification to create and what lineage (parent/child) must be set for UIM. When you run a discovery scan and you no longer see generic specifications in your physical tree, you are ready to resolve the tree to UIM.

Specifications in Network Integrity and UIM must exist, and the names must be equivalent. UIM has more requirements on specifications, in that additional properties must be set including:

• Parent child relationship and cardinality.

• Number of slots the Equipment card occupies.

Modeling in UIM for Discovery

The Network Integrity to UIM web service does not consider that equipment could be modeled in UIM such that they occupy multiple equipment holders (for example, a single equipment occupies two equipment holders).

In cases such as this, the web service operations treat the child of each equipment holder as having a unique equipment. Consequently, Network Integrity assumes that two unique equipment exist, when it fact there is only one.This is a theoretical issue because, in Network Integrity, you must model equipment specifications in UIM in accordance with how Network Integrity discovers a device. When executing Cisco SNMP discovery, if an equipment instance occupies two equipment holders, this is not discoverable, and the device reports that an equipment instance occupies one equipment holder while the other equipment holder appears empty, even though the equipment physically occupies two equipment holder.To modify discovery and modeling so that the true representation is rendered, custom handling is required in the cartridges and web service.

Import Cisco from UIM Action

The Import Cisco from UIM action imports logical and physical device trees from UIM for Cisco devices.

This import action extends the Abstract Import from UIM action (from the UIM Integration cartridge) and inherits all its processors. For information about the inherited processors, see Network Integrity UIM Integration Cartridge Guide.

The Import Cisco from UIM action contains the following processors run in the following order:

1. Import UIM Initializer (inherited)

2. Scan parameter Cisco UIM Initializer

3. Logical Device UIM Finder (inherited)

4. Supported Physical Device UIM Finder

5. Physical Device UIM Finder (inherited)

6. Logical Device UIM Importer (inherited)

7. Linked Physical Device UIM Importer (inherited)

8. Logical Device UIM Persister (inherited)

9. Physical Device UIM Importer (inherited)

10. Physical Device UIM Persister (inherited)

Figure 2-2 illustrates the processor workflow of the Import Cisco from UIM action.

Figure 2-2 Import Cisco from UIM Action Processor Workflow

Description of ''Figure 2-2 Import Cisco from UIM Action Processor Workflow''

Scan parameter Cisco UIM Initializer

This processor initializes the scan parameter import filters.

Table 2-1 shows the filters for the Import Cisco from UIM action.

Table 2-1 Filters Used with Import Cisco from UIM Action

Filter	Pattern	Example
Name	Supports comma separated list for multiple values and wildcards	rot3640-11
Management IP Address	Supports comma separated list for multiple values and wildcards	10.10.10.10
Inventory State	INSTALLED UNAVAILABLE	N/A
Network Location / Entity Code	Supports comma separated list for multiple values and wildcards	NYHQ1.D3

Supported Physical Device UIM Finder

This processor:

• Retrieves all the logical device IDs that match the filter criteria and have the deviceGeneric specification.

• Iterates over each ID to:

  • Retrieve the logical device tree and the associated physical device tree from UIM, while caching the ID of the physical device.

  • Persist the logical and physical device trees.

• Retrieves all the physical device IDs that match the filter criteria (if LogicalDeviceId is not set).

• Iterates over each physical ID, if it is not already cached:

  • Retrieve the physical device tree from UIM.

  • Persist the physical device trees.

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

Table 2-2 shows scan filter values used when configuring the filters in the base class.

Table 2-2 Import Scan Parameters (not set by the user)

Filter	Value
Query Physical Devices	true
Import Related Physical or Logical Device	true
Logical Device Specification	deviceGeneric

Detect Enhanced Cisco Discrepancies Action

The Detect Enhanced Cisco Discrepancies action detects discrepancies between Enhanced Cisco SNMP Discovery scan results and data imported from UIM.

This discrepancy detection action extends the Abstract Detect UIM Discrepancies action (from the UIM Integration cartridge) and inherits all its processors. For information about the inherited processors, see Network Integrity UIM Integration Cartridge Guide.

The Detect Enhanced Cisco Discrepancies action contains the following processors run in the following order:

1. UIM Discrepancies Filter Initializer (inherited)

2. Discrepancy Detector (inherited)

Figure 2-3 illustrates the processor workflow of the Detect Enhanced Cisco Discrepancies action.

Figure 2-3 Detect Enhanced Cisco Discrepancies Action Processor Workflow

Description of ''Figure 2-3 Detect Enhanced Cisco Discrepancies Action Processor Workflow''

Resolve Cisco in UIM Action

The Resolve Cisco in UIM action resolves discrepancies on logical and physical hierarchies and associations between logical and physical entities in UIM.

The discrepancy resolution action extends the Abstract Resolve in UIM action (from the UIM Integration cartridge) and inherits all its processors. For information about the inherited processors, see Network Integrity UIM Integration Cartridge Guide.

The Resolve Cisco in UIM action contains the following processors run in the following order:

1. UIM Resolution Framework Initializer (inherited)

2. UIM Resolution Initializer (inherited)

3. UIM Resolution Framework Dispatcher (inherited)

Figure 2-4 illustrates the processor workflow of the Resolve Cisco in UIM action.

Figure 2-4 Resolve Cisco in UIM Action Processor Workflow

Description of ''Figure 2-4 Resolve Cisco in UIM Action Processor Workflow''