cc/td/doc/product/rtrmgmt/ugm/ugm2_1
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Deploying, Discovering, and Exporting Inventory Data with Cisco UGM

Deploying, Discovering, and Exporting Inventory Data with Cisco UGM

Deployment, in the context of Cisco UGM operation, represents the creation of object modeling elements in the database. The creation of these modeling elements is necessary in order for Cisco UGM to manage the corresponding device objects in the network.

The autodiscovery function allows you to examine the network for IP and SNMP devices and create a managed object for each new device discovered.

This chapter contains the following sections:

Overview of Deployment and Discovery

In order to set up Cisco UGM to manage network devices, you must first create new objects representing managed network elements. This created object represents a real object in the network: a managed device (Cisco AS5300, AS5350, AS5400, AS5800, AS5850) is represented by a device object, and the cards and ports in the device are represented by device component objects.

The device object can transition between several states (see the "Overview of Discovering a Device Component" section on page 2-12). Device objects can be manually deployed using the Cisco EMF deployment wizard, or autodiscovered using the Cisco EMF autodiscovery application. Device component objects, however, can only be autodiscovered.

During the course of operation, Cisco UGM rediscovers device components. Rediscovery enables Cisco UGM to synchronize its database with the configuration information on the managed devices in the network, and is necessary to manage the device and component objects.

Refer to the Cisco Element Management Framework User Guide.

The order in which deployment and discovery tasks are carried out are:

    1. Deploy container objects.

    2. Deploy or autodiscover device objects.

    3. Autodiscover device components.

About Container Objects

A container object provides a way to group or organize your network elements. You can group managed devices geographically or functionally, and assign names to the container objects.

In the Cisco EMF Map Viewer, you can deploy these container objects:

Region, site, and bay objects can represent virtual, or actual, regions, sites, or groups on the network.

The Deployment Wizard uses Deployment Profiles to prompt you for information that is required to deploy container objects. For more information on the Deployment Wizard and Deployment Profiles (or templates), refer to the Cisco Element Management Framework User Guide.

Deploying Region, Site, or Bay Container Objects


Step 1   Right-click the physical node where you want to deploy the container object, and select Deployment > Deploy generic objects.

Step 2   In the Deployment Wizard dialog box, select one of these options: Region, Site, or Bay.

Step 3   Click Next.

Step 4   Enter responses to the Deployment Selector Screen and click Next.

Step 5   In the Object Details screen, specify a site name.

Step 6   In the Deployment Summary screen, click Finish and wait until the deployment process is completed.

For details on creating region, site, and bay objects, refer to the Cisco Element Management Framework User Guide.


About Device States in Deployment and Discovery

State Description

Deploying

Device components are being created in the database.

Initializing

Device data is being loaded from the database.

Commissioning

Device components are being discovered (SNMP discovery).

Handover

The active device is taking over the dial-shelf cards (only for Cisco AS5800 and AS5850 redundant systems).

Normal

Deployment or initializing are successfully completed.

Decommissioned

The device is deployed as decommissioned, or is manually decommissioned.

Errored

The device is unreachable.

About Cisco UGM-Assigned Names for Device Objects

If a managed device has an assigned hostname, Cisco UGM uses that hostname as part of the device object name that appears in the Map Viewer.

Deployment Type Device Hostname Assigned Name in Map Viewer

Autodiscovery

Yes

SystemName1_IP address

Example:

LM-5300-1.cisco.com_171.22.41.95

Autodiscovery

No

ChassisClassName_IP address

Example:

AS5300.cisco.com_171.22.41.95

Manual deployment by using the Template for AS5xxx as Decommissioned

N/A

IP address or loopback address

Example:

171.22.41.95

Manual deployment by using the Template for AS5xxx with Sub-Chassis Discovery

Yes

SystemName2_IP address

Example:

LM-5300-1.cisco.com_171.22.41.95

Manual deployment by using the Template for AS5xxx with Sub-Chassis Discovery

No

ChassisClassName_IP address

Example:

AS5300_171.22.41.95

1The SystemName consists of the device name and domain name.
2The SystemName consists of the device name and domain name.


Note



About Deploying Device Objects

You can deploy Cisco UGM device objects manually by using deployment profiles or templates. You can start the Deployment Wizard only from a container object. (See the "Deploying a Device Object Manually" section on page 2-8.)

In addition, you can discover device objects automatically by using the autodiscovery function.

You can use either of the following templates for each type of managed device in your network:


Tip This template creates an object in a decommissioned state. (See the "Overview of Discovering a Device Component" section on page 2-12.)

You can create an object in a decommissioned state to use it as a placeholder for a device that is currently unavailable or for future expansion of your network.

The device objects are discovered and located in the region or site from where you manually initiated the deployment.

Deploying a Device Object Manually


Caution   When you manually deploy device objects:

Check that the IP address or loopback address that you specify is not already used in the network of Cisco UGM-managed devices. If a conflict is detected, the manual deployment fails.

Verify that the type of NAS device matches the template that you specify. If you use an AS5xxx template to deploy an AS5yyy device type, Cisco UGM detects a conflict and raises an alarm. The created device object cannot be used by Cisco UGM. Delete the object and deploy a device object that matches the template.


Step 1   Right-click a site or region in the left pane and choose: Deployment > Deploy Access Servers> Deployment Wizard—Templates. Select the template that you want.

Step 2   Enter the number of objects. If you enter a number greater than 1, repeat Step 3 for each object.

Step 3   Enter the IP address or loopback address of the device that you want to deploy.

Step 4   Enter values for:

The defaults are public for the Read (SNMP Get) variable and private for the Write (SNMP Set) variable.

Step 5   Select an SNMP version.

Step 6   Enter the Login User Name as specified in the Device Authentication Information dialog box. (See the "Task 1: Authenticating the Device Object" section on page 4-3.)

Step 7   Enter the Login Password as specified in the Device Authentication Information dialog box. (See the "Task 1: Authenticating the Device Object" section on page 4-3.

Step 8   Enter the Enable Password as specified in the Device Authentication Information dialog box. (See the "Task 1: Authenticating the Device Object" section on page 4-3.


Note   Cisco UGM does not validate the entries in these fields.

Step 9   Click Forward.

The device components are deployed automatically only if you chose a template with component (subchassis) discovery.

See the "Overview of Initializing Cisco UGM Devices" section on page 2-25.


About Autodiscovery of Device Objects

The autodiscovery function allows you to examine the network for IP and SNMP devices and create a managed object for each new device that is discovered.


Note   The difference between this method of populating your network view and that described in the "Deploying a Device Object Manually" section on page 2-8 is that this procedure is automatic. Cisco UGM examines the network for relevant objects.

Device objects are discovered first, followed by component objects. After device objects are discovered, Cisco UGM discovers device component objects. (See the "About the Device Component Discovery Throttling Mechanism" section on page 2-12.)

Device and component objects are discovered and located in the region or site from where you initiate discovery.

If your network has devices configured to support redundancy, see the "Overview of Redundancy and High Availability Support" section on page 2-18.

Autodiscovering a Device Object

Cisco UGM first discovers all the managed device objects and then proceeds to discover device components, such as cards and ports. This component discovery leads to the creation (under the NAS object) of the hierarchy of component objects.

Each device object discovery is immediately followed by the creation of a corresponding Config Files folder, which is created for both commissioned and decommissioned devices.


Step 1   From the Cisco EMF Launchpad, click Auto discovery.

Or

From the Map Viewer, select the container object (region, site, or bay) that you want to discover.

Step 2   To open the Discover Network Devices window, right-click the container object and select Deployment > Auto discovery.

Step 3   Enter a range of device IP addresses.

This confines the discovery process to a known area of the network. You can enter a loopback address.

Step 4   Enter the Device Subnet Mask address.

Step 5   Click the drop-down menu next to Discovery Method and select SNMP or IP and SNMP.

Step 6   Set the Hop Count to the number of subsequent levels of subnets that you want to discover.

Step 7   For IP devices in the Ping Retries data entry box, specify the number of times the system should try Internet Control Message Protocol (ICMP) ping to identify whether an active machine is connected to a specified address.

The maximum number of ping retries is 10.

Step 8   Enter a value for SNMP Retries. This is the number of times the system tries to get the RFC1213-MIB.system attribute from a device without receiving a reply before the device is discarded as not being an SNMP device.

The maximum number is 10.

Step 9   In the data entry box next to SNMP Timeout, enter the required time. The default is 10 seconds.

Step 10   In the New Community data entry box, select Read-Write.

If you do not select Read-Write, autodiscovery works, but subsequent tasks such as image management fail.

Step 11   Click Add.

Step 12   In the Physical Location panel, click Use Physical Path. If required, select Get Path for the correct physical view.

Step 13   (Optional) You can restrict the IP address range that the system explores by double-clicking a range of addresses in the Interface Attributes panel.

The Discovery Interface window appears.

Step 14   (Optional) Specify a range of IP addresses (or even a single address) by entering a start address and a stop address. Only IP addresses within the specified address range are discovered.

Step 15   To start the discovery process, select the device from the Interface Attributes list.

Step 16   Click Start.


Note   You can stop creating and deploying device objects by clicking Stop.


Overview of Discovering a Device Component

When Cisco UGM is discovering device components, the parent device object is in these states:

See the "Overview of Discovering a Device Component" section on page 2-12.

About the Device Component Discovery Throttling Mechanism

The discovery and deployment functions can impact overall system performance and overload the management network. A throttle mechanism controls the number of device objects actively being discovered and deployed.

The discovery and deployment activities are controlled independently from other Cisco UGM operations.

About SNMP Tables Retrieved While Discovering a Device Component

Cisco UGM discovers device components by analyzing the information in the following SNMP tables:

About Events Generated while Discovering a Device Component

There are two kinds of events generated during component discovery:

These events cancel each other and can be an be viewed only in the Event History table that has an advantage over log files because there are no size or aging parameters to truncate the table.


Tip In case a device component discovery hangs, you can change these values: SNMP timeout, which is set by default to 500msec, and SNMP retries, which are set to 4 (meaning a maximum of 5 packets are sent)

In the <CEMFdirectory>/config/ASMainCtrl/ASMainCtrlUserData.ini file, change these values:

[deployment]
attrValueSnmpRetries =
4
attrValueSnmpTimeout = 500

You must stop and start Cisco EMF for the changes to take affect.

Alarm Event Description

Discovery failed due to loss of communication with device.

Usually caused by network delays. See the previous Tip for suggestions.

Discovery failed due to UGM internal error.

Caused by an internal Cisco UGM error or by a Cisco IOS image error.

Deployment failed due to UGM internal error.

Discovery interrupted.

You manually interrupted the deployment or discovery of the device or its components.

Deployment interrupted.

About Cisco UGM-Assigned Names for Device Component Objects

When Cisco UGM discovers a card, it automatically assigns a name with this format:

Card type-Slot-Serial number

Example:

8CT1_4Serial-0-Serial#:21668561

Where,

8CT1_4Serial—represents the type of card.

-0—represents the device slot in which the card is installed.

Serial#:21668561—represents a unique identifier read directly from the card.


Tip If the Map Viewer does not display the complete card object name, open the Card Properties dialog box to check if all card information was entered.

Autodiscovering Device Component Objects


Note   You cannot manually deploy device components.


Step 1   From the Cisco EMF Launchpad, click Auto discovery.

Or

From the Map Viewer, select the object (region, site, or device) that you want to discover.

Step 2   To open the Discover Network Devices window, right-click the device and select Deployment > Auto discovery.

Step 3   Enter a range of device IP addresses.

You can enter a loopback address.


Tip Enter a range of IP addresses for Cisco UGM to discover. Doing so confines the discovery process to a known area of the network.

Step 4   Enter the Device Subnet Mask address.

Step 5   From the drop-down menu next to Discovery Method, select SNMP or IP and SNMP.

Step 6   Set the Hop Count to the number of subsequent levels of subnets that you want to discover.


Note   The maximum number of subnets that you can discover is 16.

Step 7   For IP devices in the Ping Retries data entry box, specify the number of times the system should try Internet Control Message Protocol (ICMP) ping to identify whether an active machine is connected to a specified address.

The maximum number of ping retries is 10.

Step 8   Enter a value for SNMP Retries. This is the number of times the system tries to get the RFC1213-MIB.system attribute from a device without receiving a reply before the device is discarded as not being an SNMP device.

The maximum number is 10.

Step 9   In the data entry box next to SNMP Timeout, enter the required time. The default is set to 10 seconds.

Step 10   In the New Community data entry box, select Read-Write.

If you do not select Read-Write, autodiscovery works, but subsequent tasks such as image management fail.

Step 11   Click Add.

Step 12   In the Physical Location panel, click Use Physical Path. If required, select Get Path for the correct physical view.

Step 13   (Optional) You can restrict the IP address range that the system interrogates by double-clicking a range of addresses in the Interface Attributes panel.

The Discovery Interface window appears.

Step 14   (Optional) Specify a range of IP addresses (or even a single address) by entering a start address and a stop address. Only IP addresses within the specified address range are discovered.

Step 15   To start the discovery process, select the device from the Interface Attributes list.

Step 16   Click Start.


Note   You can stop creating and deploying device component objects by clicking Stop.


Changing SNMP Community Strings for Devices Managed by Cisco UGM


Step 1   From the Map Viewer, select and right-click the device object.

Step 2   Choose Tools > Open Object Configuration.

Step 3   From the Object Types list, select Community Strings (SNMP v2).

Step 4   Enter values for the Read Community and the Write Community.

Step 5   Click the Save icon in the toolbar.


Overview of Rediscovery

After initially discovering devices, Cisco UGM rediscovers device components to synchronize the database with the device configuration.


Note   In some cases, if you reconfigure a device by using the configlet window (see the "(Optional) Task 11: Viewing and Editing Configuration Files and Configlets" section on page 3-31), the database may not be synchronized with the device.

If this occurs, manually deploy the device object and discover its component objects.

Rediscovery is triggered by:

If the underlying device components have changed, corresponding changes are made during rediscovery leading to deleting or creating of device component objects.

For more details, refer to the Cisco Element Management Framework User Guide.

About Monitoring Device Reload Events

Cisco UGM monitors device reload events that trigger rediscovery:

Presence Polling based on RFC1213.sysUpTime Object

Cisco UGM uses the presence polling feature to read the sysUpTime value of the device.

The last reboot time for the device is calculated based on the sysUpTime value and the current time on the server. The reboot time is then checked against the values in the database. If a mismatch (of 60 seconds or more) is detected, the chassis is rediscovered. See the "Overview of Attributes Sampled for Presence Polling" section on page 9-3.


Note   In order to obtain accurate readings for the sysUpTime and server clock values, make sure that you synchronize the Cisco UGM clock with the clocks of all managed devices in the network. Use NTP to achieve this synchronization.

If you do not synchronize clocks, the timings for the Cisco UGM server and managed devices may drift and cause inaccurate readings of the sysUpTime value. This may cause false indications of device reboots.

Cold and Warm Start Traps

When a cold start or warm start trap is received, Cisco UGM triggers rediscovery.

About Card Insertion and Removal Events

Cisco UGM uses two methods of monitoring card insertion and removal events that trigger rediscovery:

Cisco UGM uses the presence polling feature to read the device's cardTablevalue. This attribute detects if cards were installed or removed from the device

Cisco UGM receives an Online Insertion and Deletion (OIR) trap (from a device that supports OIR).

Overview of Redundancy and High-Availability Support

Cisco UGM supports redundancy features for Cisco AS5800 devices, and High-Availability support for Cisco AS5850 devices in the areas of discovery, deployment, and configuration. These features implement cold standby redundancy: An active device controls a set of feature cards. In the event of a failure, the redundant peer device identifies the failure, resets the feature cards, and controls them.

Cisco UGM identifies redundant devices and creates a new container object in the Physical view. This container object is a visual representation of the association between devices in a redundant pair.

Feature card objects are created under a device object only if the device object actually controls these cards at deployment.

About Cisco AS5800 Redundancy Support

The Cisco AS5800 device works in one of the following configurations:

Each time a Cisco AS5800 device is discovered or deployed, its redundancy status is read from the device.

Redundant Cisco AS5800 devices can be in one of the two states: active or standby.

About Identifying Redundant Cisco AS5800 Devices (Redundancy Identifier)

To facilitate matching Cisco AS5800 redundant device pairs, each device is identified by its dial-shelf identification (id). If two devices have the same dial-shelf id, they are identified as redundant peers. In this context, the dial-shelf id is called the redundancy identifier.


Note   Configure the dial-shelf id, so that redundant devices have the same dial-shelf id value, and the dial-shelf id values are unique across the managed network.

When deploying Cisco AS5800 devices, Cisco UGM reads the dial-shelf id from the device. The device is then reparented under a special redundancy container object. If Cisco UGM detects a redundant peer (for the device), Cisco UGM positions the redundant peer under the redundancy container object, and the new device is reparented under the same container object. If there is no peer device, a new redundancy container is created, and the new device is reparented under it.

Cisco AS5800 Device Redundancy Container Object

The redundancy container object shows an association between redundant Cisco AS5800 device objects. Such a container object is assigned a name which contains the redundancy identifier of the corresponding devices.

About the Cisco AS5800 Device Failover Event

In the event of a failure, the redundancy state of one or both redundant devices changes. The standby device becomes active and vice versa. Traps are sent from the devices to alert the management station about the failure event. Cisco UGM monitors these traps. When such a trap is received, the device transitions to a handover state. This new state in the Cisco AS5800 state machine waits until the active device finishes the takeover of the dial-shelf cards. This process can take up to several minutes.

When the takeover is completed, Cisco UGM starts device rediscovery. The device remains in the handover state for a predefined period, which is currently set to 90 seconds.

You can change this time duration by accessing:

ASMainCtrlUserData.ini

AS5800ChassisHandoverLingerSec

When the time duration ends, the device is moved into a commissioning state to finish the rediscovery.

Because traps can be unreliable, Cisco UGM also uses a redundancy polling feature to ensure that changes in redundancy state are identified. If the polling mechanism identifies a change for a given device, rediscovery is started by moving the device into the commissioning state.

If a redundancy state change is identified, a warning severity alarm is raised against the device object.

About Identifying a Cisco AS5800 Dial-Shelf Card

In a redundancy configuration, only the cards controlled by a device object are created as device component objects.

If a card is not controlled by the device, its operational status is:

value not specified (1).

About Configuration Changes for Cisco AS5800 Devices

If a device undergoes a configuration change that affects redundancy, the periodic redundancy presence polling eventually detects this, and rediscovery occurs. If a device becomes nonredundant, it is reparented under the immediate parent of the corresponding redundancy container in the Physical view. If the device was the last object under the redundancy container, the container is deleted.

If a redundancy identifier is modified, the device is reparented under the redundancy container corresponding to the new redundancy identifier. If such a container does not exist, it is created.

About Backward Compatibility of Cisco IOS Images for
Cisco AS5800 Devices

Since the redundancy feature for Cisco AS5800 devices is only supported by newer Cisco IOS images, Cisco UGM addresses the issue of backward compatibility with older Cisco IOS images. The redundancy feature comes with a management interface that uses the CISCO-C8500-REDUNDANCY-MIB. If this MIB is not supported, Cisco UGM assumes that the current Cisco IOS image does not support redundancy. In this case, Cisco UGM sets the redundancy state to N/A.

About the Cisco AS5800 Redundancy Status Dialog Box

The Redundancy Status dialog box shows the current redundancy status of the device, and is described in the "Checking the Redundancy Status of a Cisco AS5800 Device" section on page 7-39.


Note   This dialog box shows the status as read from the device. Cisco UGM may be temporarily unsynchronized with the status on the device. It may take several minutes for redundancy presence polling to get the new status from the device and to reflect the new status in the dialog box.

Cisco AS5850 High-Availability Feature Support

The Cisco AS5850 device has 14 slots. Slots 6 and 7 are designated for Router Shelf Controller (RSC) cards.

In a High-Availability configuration, RSCs control their parts of the shelf under normal conditions. If one RSC fails, the surviving RSC takes control of all the cards that were formerly controlled by the failed RSC, reloads the cards, and places them back in service.

Every time a Cisco AS5850 device is discovered or deployed, Cisco UGM reads the redundancy status from the device. If a device is configured in High Availability mode, a special container object is created in the Physical view, and the device is reparented under this container.

A redundant Cisco AS5850 device can be in one of three states:

Redundancy Identifier for Cisco AS5850 Devices

To match redundant Cisco AS5850 peer devices, every device is identified by using its backplane shelf identifier. This string identifier is programmed during the manufacturing process. If two devices have the same backplane shelf identifier, they share the shelf.


Note   The redundancy identifier for the Cisco AS5850 device is transparent. Its value is unique across any managed network in the entire universe.

During Cisco AS5850 device deployment, Cisco UGM reads the redundancy identifier from the device. The device is then reparented under a special redundancy container object. If the redundant peer (for the device) has been discovered, it is already positioned under the redundancy container object, so that the new device is reparented under the same container object. If there is no peer device a new redundancy container is created, and the new device is reparented under this new container.


Tip The redundancy container object shows an association between redundant
Cisco AS5850 peer devices. The name assigned to this container object contains the redundancy identifier of the corresponding device.

Cisco AS5850 Device Failover Event

In an event of a failover, the redundancy state of one or both redundant devices changes. The traps are usually sent from the devices to alert the management station about the event. Cisco UGM monitors these traps. When such a trap is received, the device transitions to a handover state. This is a new state in the
Cisco AS5850 state machine, which represents the wait until the active device finishes the takeover of the dial-shelf cards. This process can take up to several minutes.

When the takeover ends, you can start rediscovering devices. The device remains in the handover state for a predefined period, which is currently set to 90 seconds.

You can change this time by accessing:

ASMainCtrlUserData.ini

AS5850ChassisHandoverLingerSec

When the timer ends, the device is moved into the commissioning state to finish the rediscovery.

Because traps can be unreliable, Cisco UGM also uses a special redundancy polling feature to ensure that changes in redundancy state are identified. If the polling mechanism identifies a change for a given device, rediscovery is started by moving the device into the Commissioning state.

If a redundancy state change is identified, a warning severity alarm is raised against a device object.

About Identifying Cisco AS5850 Router Shelf Cards

In a High-Availability configuration, only the resources controlled by a device object are created as the device component objects.

If a card is not controlled by the device, its operational status is "value not specified (1)."

Cisco AS5850 Configuration Changes

If a Cisco AS5850 device undergoes a configuration change which affects redundancy, the periodic redundancy presence polling detects this and rediscovery takes place. If a device becomes nonredundant it is reparented under the immediate parent of the current redundancy container in the Physical view. If it was the last object in the redundancy container, the container is also deleted.

If a redundancy identifier is modified, the device is reparented under the redundancy container corresponding to the new redundancy identifier. If such a container does not exist, it is created.

About Cisco IOS Image Support for the High Availability Feature in Cisco AS5850 Devices

Since the High Availability feature is only supported by newer Cisco IOS images, Cisco UGM addresses the issue of backward compatibility with older Cisco IOS images. The High Availability feature includes a management interface that uses CISCO-RF-MIB. If this MIB is not supported, Cisco UGM assumes that the current Cisco IOS image does not support this feature. In this case, Cisco UGM sets the redundancy state to N/A.

Cisco AS5850 Redundancy and Configuration Status Dialog Box

The Redundancy Status and Configuration dialog box shows the current High Availability status of the Cisco AS5850 device. The dialog box is described in "Checking the Redundancy Status of a Cisco AS5850 Device" section on page 7-40.


Note   The Redundancy Status and Configuration dialog box shows the status value as read from the device. At times, Cisco UGM may be temporarily unsynchronized with the status on the device, and may take several minutes for redundancy presence polling to get the new status from the device.

Overview of Initializing Cisco UGM Devices

When you stop and restart Cisco UGM, existing device objects move into an Initializing state where all devices and components are reconciled with the Cisco UGM database. Values from the device object initialization are later used for performance polling and rediscovery.

<CEMFROOT>/config/ASMainCtrl/ASMainCtrlUser.ini

[ChassisInitialization]

maxSubChassisQueries=

In order for this change to take effect, stop and start Cisco EMF. See the Cisco Element Management Framework Installation and Administration Guide.

Alarms Generated During Device Initialization

You can view these major alarms in the Event Browser.

If either of these conditions occur, decommission and then commission the device in order to initiate initialization. If a chassis was not initialized properly, the performance polling and rediscovery will fail.

State Changes that Accompany Device Object Initialization


Table 2-1: Device Object Initialization State Changes
State Before Initializing State After Initializing

deploying

commissioning

IOSImageDownload

normal

IOSImageUpgrade

normal

IOSImageDownloadToRouter

normal

IOSImageDownloadToDial

normal

ModemImageDownload

normal

ModemImageUpgrade

normal

SPEImageDownload

normal

SPEImageUpgrade

normal

VFCImageDownload

normal

VFCImageUpgrade

normal

For all other states not described in this table, the device state after initialization is the same as the state before initialization.

Overview of Exporting Inventory Data

With Cisco UGM, you can export your system inventory data into a flat text file. By using report-generating software, you can format this data into a report. Exporting files allows you to export data from the database to a UNIX directory; then, you can send the file to an external system through File Transfer Protocol (FTP).

Updating Inventory Data

Inventory data is retrieved during the discovery of network objects. You can update the inventory data by forcing rediscovery of any number of network objects.


Step 1   In the Map Viewer, right-click the device, region, or site where you want to initiate rediscovery.

Step 2   For a site or region, select ASMainEM > Chassis Commissioning.

Or

For a single device object, select Chassis > Chassis Commissioning.

Step 3   From the object list, select the device or multiple devices that you want to rediscover.

Step 4   Click Decommission and wait for the object to transition to the Decommissioned state.

Step 5   Click Commission to discover network objects. Wait until the objects transition to the Normal state.

Inventory data is updated for the selected objects. To export the inventory data, see the "Exporting Inventory Data Immediately" section on page 2-28.


Exporting Inventory Data Immediately


Step 1   In the Map Viewer, choose ASEMSConfig > File Export > File Export Properties.

Step 2   In the File Export Properties dialog box, click the Inventory tab.

Step 3   Select on demand.

Step 4   Select an action to be performed when file aging occurs:

Step 5   Enter the aging interval (in days) of the file before the selected aging action is performed. Export then continues in the newly created file.

Step 6   Enter a location where the file is moved to (or moveTarCompressed to) when aging occurs.

Step 7   Click Save.

Step 8   Click Export Now.

The export data filename is invFileName.EXPORT_YY-MM-DD_HH-MM-SEC

Where,

invFileName is the filename specified in Step 6.

EXPORT_YY-MM-DD_HH-MM-SEC is a timestamp appended to the file.


Scheduling Inventory Data Export

By default, the inventory data export feature is disabled. Follow these steps to enable this feature:


Step 1   In the Map Viewer, choose ASEMSConfig > File Export > Open File Export Properties.

Step 2   In the Export Type field, select Scheduled.

Step 3   Enter a storage path for the inventory data file.

Step 4   Select an action to be performed when file aging occurs:

Step 5   Enter the aging interval (in days) of the file before the selected aging action is performed. Export then continues in the newly created file.

Step 6   Enter a location where the file is moved to (or moveTarCompressed to) when aging occurs.

Step 7   Select the frequency of data export:

Step 8   Select the hour for the export:

Step 9   Select the scheduled week day for the export:

Step 10   Select the scheduled day of the month for the export:

Step 11   Click Save.


See the "Format of Exported Data" section on page 2-36.

Attributes Sampled for Inventory Data Export


Note   If a device or component is not listed in this table, no attribute information is generated for it; just the pathname and device type appear.

Any unrecognized devices appear as "Unknown" for the device type.


Table 2-2: Inventory Data Export Attributes

Object Attribute Attribute Name Value

Region

Name

regionName

0 to 255 characters

Site

Name

SiteName

0 to 255 characters

Contact name

AV-SITE-MIB.contact1Name

0 to 255 characters

Contact phone

AV-SITE-MIB.contact1Phone

0 to 255 characters

Contact pager

AV-SITE-MIB.contact1Pager

0 to 255 characters

Contact e-mail

AV-SITE-MIB.contact1Email

0 to 255 characters

Site Phone

AV-SITE-MIB.sitePhone

0 to 255 characters

Site Fax

AV-SITE-MIB.siteFax

0 to 255 characters

Site Address

AV-SITE-MIB.siteAddress

0 to 255 characters

Site City

AV-SITE-MIB.siteCity

0 to 255 characters

Site State

AV-SITE-MIB.siteState

0 to 255 characters

Site ZIP

AV-SITE-MIB.siteZip

0 to 255 characters

AS5300

AS5350

AS5400

AS5800

AS5850

IP address

AMAF-MGMT-MIB.ipaddress

N/A

Chassis version

OLD-CISCO-CHASSIS-MIB.
chassisVersion

0 to 255 characters

Chassis type

OLD-CISCO-CHASSIS-MIB.
chassisType

Enumeration
(integer 00-99)

Chassis ID

OLD-CISCO-CHASSIS-MIB.
chassisId

0 to 255 characters

Slots in chassis

OLD-CISCO-CHASSIS-MIB.
chassisSlots

Integer

ROM monitor version

OLD-CISCO-CHASSIS-MIB.
romVersion

0 to 255 characters

ROM system software version

OLD-CISCO-CHASSIS-MIB.
romSysVersion

0 to 255 characters

System name

SNMPv2-MIB.sysName

0 to 255 characters

System contact

SNMPv2-MIB.sysContact

0 to 255 characters

System location

SNMPv2-MIB.sysLocation

0 to 255 characters

System description

SNMPv2-MIB.sysDescr

0 to 255 characters

Card

Software version

OLD-CISCO-CHASSIS-MIB.
cardSwVersion

0 to 255 characters

Hardware version

OLD-CISCO-CHASSIS-MIB.
cardHwVersion

0 to 255 characters

Serial number

OLD-CISCO-CHASSIS-MIB.
cardSerial

Integer
(0 to 9999999999)

Slot number

OLD-CISCO-CHASSIS-MIB.
cardSlotNumber

Integer (00 to 99)

Slots in this card

OLD-CISCO-CHASSIS-MIB.
cardSlots

Integer (00 to 99)

Example of an Inventory Export File

See the "Format of Exported Data" section on page 2-36 for a description of fields in this file.


Note   If Cisco UGM fails to retrieve a value for an attribute, "no value retrieved" appears. In the example shown in this section, the value of the AV-SITE-MIB.attributes are " ."

<region> RegionName="West" <Site> SiteName="Site-1" AV-SITE-MIB.siteZIP="" AV-SITE-MIB.siteState="" AV-SITE-MIB.siteCity="" AV-SITE-MIB.siteAddress="" AV-SITE-MIB.siteFAX="" AV-SITE-MIB.sitePhone="" AV-SITE-MIB.contact1EMail="" AV-SITE-MIB.contact1Pager="" AV-SITE-MIB.contact1Phone="" AV-SITE-MIB.contact1Name="" <Chassis> AMAF-MGMT-MIB.ipaddress="10.85.66.112" OLD-CISCO-CHASSIS-MIB.chassisVersion="A.32" OLD-CISCO-CHASSIS-MIB.chassisType=73 OLD-CISCO-CHASSIS-MIB.chassisId="21667966" OLD-CISCO-CHASSIS-MIB.chassisSlots=3 OLD-CISCO-CHASSIS-MIB.romVersion=" System Bootstrap, Version 12.0(2)XD1, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Copyright (c) 2001 by cisco Systems, Inc. TAC:Home:SW:IOS:Specials for info "OLD-CISCO-CHASSIS-MIB.romSysVersion="Cisco Internetwork Operating System Software IOS (tm) 5300 Software (C5300-BOOT-M), Version 12.0(4)T1, RELEASE SOFTWARE (fc1) Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Fri 18-May-01 13:58 by kpma" RFC1213-MIB.sysLocation="" RFC1213-MIB.sysDescr="Cisco Internetwork Operating System Software IOS (tm) 5300 Software (C5300-JS-M), Version 12.2(1a), RELEASE SOFTWARE (fc1) Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Fri 25-May-01 22:32 by pwade" RFC1213-MIB.sysContact="" RFC1213-MIB.sysName="lm-5300-1" <Card> OLD-CISCO-CHASSIS-MIB.cardDescr="Quad Port Channelized T1/PRI Dial Feature Card" OLD-CISCO-CHASSIS-MIB.cardSwVersion="" OLD-CISCO-CHASSIS-MIB.cardHwVersion="1.1" OLD-CISCO-CHASSIS-MIB.cardSerial=41706 OLD-CISCO-CHASSIS-MIB.cardSlotNumber=2 OLD-CISCO-CHASSIS-MIB.cardSlots=0 </Card> <Card> OLD-CISCO-CHASSIS-MIB.cardDescr="Nextport Dial Feature Card" OLD-CISCO-CHASSIS-MIB.cardSwVersion="" OLD-CISCO-CHASSIS-MIB.cardHwVersion="3.4" OLD-CISCO-CHASSIS-MIB.cardSerial=3440083 OLD-CISCO-CHASSIS-MIB.cardSlotNumber=1 OLD-CISCO-CHASSIS-MIB.cardSlots=0 </Card> <Card> OLD-CISCO-CHASSIS-MIB.cardDescr="Nextport Dial Feature Card" OLD-CISCO-CHASSIS-MIB.cardSwVersion="" OLD-CISCO-CHASSIS-MIB.cardHwVersion="4.2" OLD-CISCO-CHASSIS-MIB.cardSerial=41803 OLD-CISCO-CHASSIS-MIB.cardSlotNumber=3 OLD-CISCO-CHASSIS-MIB.cardSlots=0 </Card> </Chassis> </Site>

Format of Exported Data

Inventory export data in the flat file follows a defined sequence and structure.

The file consists of nested values. Each record begins with an <object> tag and ends with a </object> tag. These records can contain other values.


Note   Inventory data flat files do not contain object names. For additional information on objects (chassis, card), open the Device Properties dialog box or the Card Properties dialog box.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Dec 4 14:27:16 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.