|
|
Change is inevitable in any active network. As your network evolves, you can expect device and module changes to occur. Over time, the addition or removal of physical objects to or from the device may occur, or objects may simply move to different locations within the managed network. Cisco EMF and the EM provide you with the resources and capabilities to successfully manage device changes.
As new devices enter the network, you can predeploy equipment using manual deployment or you can simply configure the EMS to locate new devices in the network and automatically discover them once they are present in the physical network. To determine the preferred method, see the "Adding Devices to the Managed Network" section.
When devices are new to the network, certain device configuration must occur in order for it to communicate with the EM and vice versa. These essential configuration requirements are outlined in the "Prerequisites for Managing Devices" section to provide guidance on the configuration you must perform.
Other probable network changes include the insertion and removal of modules within the managed device. Descriptions of the processes which take place are explored in the "Change Management" section.
In order to keep track of your network make up, the "Identifying the Network Inventory" section provides helpful tips in determining device types and physical location, the hardware components each device supports, IOS version supported, and physical object serial numbers.
The Managing Devices in Your Network chapter contains the following sections:
Network inventory information is available through the EM once network devices are manageable. Using the following sections, you can determine:
Typically, the name of the device is reflected in the chassis name which displays in the Map Viewer object hierarchy. The chassis name may be customized during deployment, thus a more reliable method of determining the device type is through the Chassis Inventory window. The EM provides device type information on the General tab within the Chassis Details area in the Type field.
The following figure provides an example of the Chassis Inventory window, highlighting the device type.
For instructions on navigating to the Chassis Inventory window and a description of the data the window displays, see the "Chassis Inventory" section.
Each managed device supports multiple hardware items. You can determine the hardware each managed device supports using the Module Inventory window and/or the object hierarchy which displays in the Map Viewer.
Assuming each hardware object is automatically named, you can interpret the hardware support for each device using the panel on the left-hand side of the Map Viewer. Expand and collapse the object hierarchy in the Physical view as required using the + and - signs beside each object. Each object present in the device displays. Use the Physical view to see the object hierarchy. The following figure displays the hardware objects a specific Cisco 7000 Series chassis supports.
The Module Inventory window provides the module type on the General tab in the Module Details area in the corresponding field. The following figure provides an example of the Module Inventory window, highlighting the module type.
For instructions on navigating to the Module Inventory window and a description of the data the window displays, see the "Module Inventory" section.
The Chassis and Module Inventory windows provide the product code for devices and hardware modules. Product codes, or serial numbers, are unique identifiers specific to each individual item. The following figures highlight the Serial Number fields on both the Chassis Inventory window and the Module Inventory window.
For instructions on navigating to the Chassis Inventory window and a description of the data the window displays, see the "Chassis Inventory" section.
For instructions on navigating to the Module Inventory window and a description of the data the window displays, see the "Module Inventory" section.
The physical location of a device may be available through the Chassis Configuration window on the Additional Descriptions tab if physical location information has been manually entered. Alternatively, you can load geographical map data in the Map Viewer and locate devices using Cisco EMF.
 |
Note For information on using geographical maps to locate devices on the network, see the Cisco Element
Management Framework User Guide at the following URL: http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps829/products_user_guide_book0918 6a0 0800ffd02.html |
The IOS versions devices and hardware objects support display on the Chassis and Module Inventory windows. Both windows contain an IOS field in the Version Details area on the General tab. The IOS field displays the IOS operating software version in use by the device or module. The following figures display the Chassis Inventory and Module Inventory windows, highlighting the IOS versions which they support.
For instructions on navigating to the Chassis Inventory window and a description of the data the window displays, see the "Chassis Inventory" section.
For instructions on navigating to the Module Inventory window and a description of the data the window displays, see the "Module Inventory" section.
To manage devices using an EM, satisfaction of specific system prerequisites must occur on the device and within the EM. First and foremost, connectivity between the device and the EM must exist. General parameters on the device must be established in order for the EM to discover the device. Additional configuration on the EM is required to enable communication between the device and EM. The following sections describe each of the management prerequisites.
Management connectivity from the EM to the device must be in place, meaning configuration of at least one port or interface. For example, Cisco devices are often used as CPEs and management is in-band over a wide area network (WAN) link and for configuration as a WAN interface.
The following configuration on the device must take place in order to allow for communication with the EM:
The following configuration of the EM must take place in order to allow for communication with the device:
The following sections describe each of these tasks.
When the EM receives traps, alarms arise as necessary on the affected physical objects. Traps are only sent by the device to the EM when trap generation is enabled (i.e., when trap generation is disabled, the EM does not receive any traps and no alarms arise).
You can enable traps per chassis so that specific chassis in your managed network may be displaying alarms while other chassis are not.
It is highly recommended that you enable trap generation whenever possible to ensure that you are aware of network issues as they arise. You manage trap generation capabilities through the SNMP Management window, using the Enable and Disable buttons in the corresponding area. For step by step instructions, see the "Enabling or Disabling Trap Generation" section.
You must set SNMP community strings in order to facilitate the exchange of management information between the device and the EM. Typically, the read setting is `public' and the write setting is `private', however the SNMP community string settings on the EM must match that of the device in order to allow communication between the two.
You provide SNMP settings on the SNMP Management window as the "Configuring SNMP Community Names and Versions" section describes.
You must provide the IOS password for the device and the EM on the Management Information window (IOS Command Line Security tab) in order to allow for any communication between the EM and device. IOS passwords are set using the instructions available in the "System Configuration" section.
Devices may become part of the managed network through auto discovery, manual deployment using the quick start shortcut, or predeployment before the device is actually present in the network. The following sections describe these processes.
Auto Discovery is a Cisco EMF application which uses IP and/or SNMP to automatically detect new routers on the network. Using a pre-defined address range, the EM discovers devices automatically.
|
Note For information on auto discovery, see the Cisco Element Management Framework User Guide Release
3.2 at the following URL:
http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps829/products_user_guide_book0918
6a0 0800ffd02.html. Information on configuring the Auto Discovery application, including scheduling at regular intervals, is available in the Cisco Element Management Framework Installation and Administration Guide Release 3.2 at the following URL: http://www.cisco.com/en/US/partner/products/sw/netmgtsw/ps829/products_installation_and_confi gur ation_guide_book09186a00800ffd0d.html |
If a device exists on the network, the EM offers enhanced manual deployment with a Quick Start capability. Quick Start enables you to deploy and initiate commissioning of the device, which also invokes subchassis discovery, in a single action. Quick start manual deployment uses the Deployment Wizard templates the "Manually Deploying Chassis Using Quick Start" section describes.
Although not as efficient, you also have the option of manually deploying devices that are physically present then manually commissioning. For details, see the "Manually Deploying Chassis" section and the "Chassis Commissioning and Subchassis Discovery" section respectively.
You can predeploy devices which you anticipate, but not yet present, in the network using manual deployment. For step by step instructions on manually deployment, see the "Manually Deploying Chassis" section.
If devices were deployed using the Manual Deployment Quick Start method, you need not commission the device. The Quick Start option automatically commissions the device immediately following discovery.
Following auto discovery or manual deployment (only once the device is physically present in the network), you must commission the device in order to manage it. Commissioning at the chassis level initiates discovery of the device on the network, subchassis discovery, and management functions on the chassis and all subchassis objects. For additional information, see the "Chassis Commissioning and Subchassis Discovery" section or the "Commissioning a Chassis" section.
Removal of managed devices on the network may be necessary due to chassis replacement or the elimination of out-dated equipment. Removing a device from the managed network entails a three step process:
1. Decommission the device on the EM
2. Physically remove the device from the network
3. Delete the chassis object and all subchassis objects from the EM.
The following sections describe these processes in greater detail.
Decommissioning a chassis decommissions all objects within the chassis, and active management (such as polling) stops on the chassis and on all subchassis objects within the chassis. At the completion of decommissioning, the chassis and all subchassis objects enter the decommissioned state.
Decommissioning a managed chassis object is necessary in order to delete a managed chassis object from the EM. Should you attempt to delete a managed chassis object from the EM without first decommissioning it, an error displays indicating that the action cannot complete successfully.
For additional information, see the "Decommissioning Chassis" section or the "Decommissioning a Chassis" section.
Once a chassis is in the decommissioned state, you may physically remove it from the network.
While it is possible to delete the chassis object from the EM prior to physically removing the device from the network, it is not recommended. If the auto discovery feature is configured to run between the time the object was deleted from the EM and the time the device was physically removed from the network, and the device IP address is within the established IP range; the object could rediscover automatically. In order to avoid error messages, it is recommended that you physically remove a decommissioned chassis from the network before deleting the object from the EM.
After a device is physically removed from the network, the representative objects within the EM may be deleted. Should you attempt to delete a managed chassis object from the EM without first decommissioning it, an error displays indicating that the action cannot complete successfully. Objects are deleted from the EM using the Deployment Wizard.
|
Note For instructions on deleting objects from the EM, see the Cisco Element Management Framework User Guide Release 3.2. |
The hardware contents of managed devices on the network may require the occasional module change due to repairs or upgrades. You may replace existing modules or add modules to unoccupied slots on the device.
Removing or inserting modules have implications in the EM and must be handled effectively. You can remove or insert the following items from/into a router chassis:
The following sections describe the processes of module change from the EM perspective. For instructions on the proper methods to physically remove or insert modules from/into the device, see the appropriate hardware manual.
Removing modules may occur in two different fashions: (1) by removing it from the EM (i.e., decommission and delete) and physically removing it from the device, or (2) by removing the module as a managed object. The first is the recommended approach.
In order to avoid alarms, it is recommended that you decommission the module using the EM before removing it from the device whenever possible. Decommissioning a module also decommissions the interfaces and connections present on the module. Heartbeat polling ceases, object states change to decommissioned, status data is no longer available, and performance logging stops on the module and all underlying interfaces and connections when a module is decommissioned. Once decommissioning completes, you may physically remove the module from the device then delete the module from the EM.
It is possible to delete the module from the EM before physically removing it from the device, but this can result in rediscovery if heartbeat polling occurs between actions. Even if rediscovered, the object remains in a non-managed state until you commission it or decommission/recommission the entire chassis of which it is part of. In this case, alarms would occur when the physical module was removed from the device.
The following figure and table outline these steps.
Table 4-1
| Action | Result |
|---|---|
| 1. Decommission the module using the Module Configuration window. For instruction, see the "Decommissioning a Module" section. | |
| 2. Physically remove module from device | Proper removal of object completes without raising alarms on the EM. |
| 3. Delete the module object from the EM by selecting the object in the Map Viewer window and choosing Deployment > Delete Objects. |
The object deletes from the display and is no longer part of the EM. |
Removing a Module—Recommended Method
The processes for removing supporting modules without producing alarms requires additional steps from those the preceding table describes. See the following paragraphs for exceptions.
The fan tray is not a managed object within the EM, therefore you may simply remove and replace it as necessary without encountering alarms through the EM.
Removing a power supply module, without encountering alarms, is much like the process of removing other modules, with the exception that you should shutdown (disable) the power supply on the Chassis Configuration window prior to decommissioning. For details on disabling a power supply module, see the "Configuring the Chassis" section.
The two power supplies which exist on the chassis are identified as PS-0 and PS -1 on the Map Viewer hierarchy, and PS1 and PS2 on the Chassis Configuration window. PS-0 on the Map Viewer is equivalent to PS1 on the configuration window and PS-1 on the Map Viewer is equivalent to PS2 on the configuration window.
After disabling the power supply, you may decommission and delete the module as the previous section describes, then remove the module from the device. The power supply which remains carries the load that the two modules previously shared.
You can remove a module from the device while it is being managed, although it is not the recommended method. When you remove a managed module from a chassis, the EM detects that the module has been removed by heartbeat polling (which occurs every five minutes). Once the EM detects the removed module, a major alarm rises against the chassis object indicating that a card is missing. The removed module is placed in the lost comms state, which initiates a critical alarm against the module.
The following figure displays the sequence of events that occurs when a managed module is removed from a chassis.
To rectify the alarm that generates when the module is removed, replace the module within the chassis or delete the module.
The following table outlines the actions and results this section describes.
Table 4-2
| Action | Result |
|---|---|
| 1. Physically remove managed module from device | As a result of hearbeat polling, an alarm arises on the chassis indicating that a card is missing |
| 2. Heartbeat polling tries to identify which module was removed | The module object does not respond to heartbeat polling, therefore the following occurs: |
| 3. Perform one of the following:
Replace the module within the chassis
Delete the module object from the EM by selecting the object in the Map Viewer window and choosing |
In the case of module replacement, heartbeat polling discovers the module as the Replacing Modules section on the following pages describe. For deleted modules, the object deletes from the display and is no longer part of the EM. |
Removing a Managed Module
Module insertion in the chassis may occur as a replacement or a new module. A module which is a replacement, fills a slot where a previous card once existed in the managed device but is currently not present. Depending on the type of module which previously existed and that which was inserted, varying outcomes result. A new module fills a slot which was not occupied during subchassis discovery nor since, or a slot where a module once existed but has since been deleted from the EM (i.e., no longer managed).
The following figure displays the sequence of events that occurs when a module is inserted into a managed chassis.
The following sections describes the process of inserting new and replacement modules in detail.
Assuming the chassis is commissioned (i.e., managed), the addition of a module to the chassis is automatically found during heartbeat polling (within five minutes' time) and alerts the EM to its presence. When the EM detects the presence of the new module, the chassis enters subchassis discovery to determine the type of module that was inserted. When the new module is discovered, it is added to the appropriate views and automatically commissions. If the module is a port adapter which has interfaces, the interfaces discover during the subchassis discovery process. Following discovery, the commissioning process determines what state the module and any underlying interfaces should be placed into, which can be the normal, errored, or mismatched states.
For information on individual states, see the "Object States" section.
When a module is inserted into a managed chassis, heartbeat polling finds the module (within five minutes' time) and alerts the EM to its presence. When the EM detects the presence of a module, the chassis enters subchassis discovery to determine the type of module that was inserted. The module may be either identical to the previous module or of a completely different type.
If the replacement module is identical to the module that formerly occupied the slot, when the new module discovers representative objects appear under the appropriate views and the module automatically commissions. If the module is a port adapter which has interfaces, the interfaces discover during the subchassis discovery process. In this case, the commissioning process typically determines the state of the module to be normal.
If, however, the inserted module is not identical to the previous module, the discovery process determines a mismatch and a major alarm is raised. In order to resolve the mismatch, first you must assess the source of the problem. If the wrong type of card was inserted into the chassis, the card should be removed. When the card is removed, the EM moves that card into the lost comms state. You must manually delete the removed module and recommission the inserted module. The commissioning process rediscovers the module, and associated interfaces, then determines the appropriate state as a result.
For information on individual states, see the "Object States" section.
Posted: Thu Jun 26 15:48:00 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
