|
|
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:
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). 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:
2. Deploy or auto-discover device objects.
3. Auto discover device components.
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.
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.
| State | Description |
|---|---|
The active device is taking over the dial-shelf cards (only for Cisco AS5800 and AS5850 redundant systems). |
|
The device is deployed as decommissioned, or is manually decommissioned. |
|
If the managed device has an assigned hostname, Cisco UGM uses that hostname as part of the device object name that appears in the Map Viewer.
| 1The SystemName consists of the device name and domain name.
2The SystemName consists of the device name and domain name. |
 |
Note |
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.)
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.) Cisco UGM does not communicate with a decommissioned device, and consequently does not process its traps or collect its performance data. 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.
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.)
Step 7 Enter the Login Password as specified in the Device Authentication Information dialog box. (See the "Task 1: Authenticating the Device Object" section.
Step 8 Enter the Enable Password as specified in the Device Authentication Information dialog box. (See the "Task 1: Authenticating the Device Object" section.
|
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 (sub-chassis) discovery.
See the "Overview of Initializing Cisco UGM Devices" section.
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, is that this procedure is automatic. Cisco UGM goes out and examines the network for relevant objects. |
Device objects are discovered first, followed by the component objects. After device objects are discovered, Cisco UGM discovers device component objects. (See the "About the Device Component Discovery Throttling Mechanism" section.)
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.
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 Select 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.
|
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.
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 Read-Write is not selected, autodiscovery will work, 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 objects by clicking Stop. |
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.
When Cisco UGM is discovering device components, the parent device object is in these states:
See the "Overview of Discovering a Device Component" section.
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.
Cisco UGM discovers device components by analyzing the information in the following SNMP tables:
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] 4attrValueSnmpTimeout = 500 You must stop and start Cisco EMF for the changes to take affect. |
When Cisco UGM discovers a card, it automatically assigns a name with this format:
8CT1_4Serial-0-Serial#:21668561
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 to check if all card information was entered. |
|
Note You cannot manually deploy device components. |
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. This confines the discovery process to a known area of the network. |
Step 4 Enter the Device Subnet Mask address.
Step 5 Select 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.
|
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.
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 will work, 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. |
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
2-28), the database may not be synchronized with the device. If this occurs, manually deploy the device object and discover its component objects. |
If the underlying device components have changed, corresponding changes are made during rediscovery leading to deletion or creation of device component objects.
For more details, refer to the Cisco Element Management Framework User Guide.
Cisco UGM monitors device reload events that trigger rediscovery:
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.
|
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. |
When a cold start or warm start trap is received, Cisco UGM triggers rediscovery.
Cisco UGM monitors two 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).
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 takes control of 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 the time of deployment.
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.
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 has detected the redundant peer (for the device), it is already positioned 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.
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.
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 of time, which is currently set to 90 seconds.
You can change this time duration by accessing:
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.
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:
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.
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 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 IOS image does not support redundancy. In this case Cisco UGM sets the redundancy state to N/A.
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.
|
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. |
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:
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.
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.
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:
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.
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)."
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.
Since the High Availability feature is only supported by newer Cisco IOS images, Cisco UGM addresses the issue of backward compatibility with older 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.
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.
|
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. |
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
In order for this change to take effect, stop and start Cisco EMF. See the Cisco Element Management Framework Installation and Administration Guide.
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.
Table 1-1 Device Object Initialization State Changes
| State Before Initializing | State After Initializing |
|---|---|
For all other states not covered in this table, the device state after initialization is the same as the state before initialization.
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).
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 2 For a site or region, select ASMainEM > Chassis Commissioning.
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.
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.
The export data filename is invFileName.EXPORT_YY-MM-DD_HH-MM-SEC
invFileName is the filename specified in Step 6.
EXPORT_YY-MM-DD_HH-MM-SEC is a timestamp appended to the file.
By default, the inventory data export feature is disabled. Follow these steps to enable this feature:
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.
|
Note 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. |
|
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. |
See the "Format of Exported Data" section 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 " ." |
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. |
Posted: Fri Apr 4 23:22:14 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
