|
|
The first step toward managing a router is to deploy or predeploy the physical objects that you want to manage. Deploying a physical object creates a representative object in Cisco EMF and, as a result, makes the EM aware of the physical object's presence.
If all or most of your chassis objects are physically present and if you have a large amount of objects to deploy, you might want to automate these processes by using auto discovery. For example, if an EM is installed into an existing network of routers, auto discovery can dramatically reduce the amount of operator input required. If you only want to deploy a few objects or if many of your objects are not yet physically present, you might want to manually deploy or predeploy. Predeployment is used when a physical object is not yet connected to the network but is anticipated to be in the future. Predeploying objects allows you to create representative objects within the EM and partially configure them, saving time later.
Once objects deploy, you must commission (discover) them in order to manage them through the EM.
The following sections make up this chapter:
Objects which are physically present in the network can be automatically discovered on the chassis and subchassis levels. You can choose to use the Cisco EMF Auto Discovery tool to detect devices based on IP and/or SNMP data. This capability applies to the chassis only. Similarly, modules automatically discover as a part of subchassis discovery and regular heartbeat polling.
The following sections describes each of these features in detail:
Auto discovery is the application that discovers existing Cisco chassis, saving time and effort. Chassis automatic discovery requires user specification of IP and SNMP data, establishing a range of network elements that the tool then polls for.
The auto discovery window opens from the Viewer or Discovery icons on the Launchpad.
 |
Note For further information regarding the Cisco EMF Launchpad, see the Cisco Element Management Framework User Guide Release 3.2. |
The Auto discovery application has three mechanisms for discovering chassis:
Auto discovery can discover chassis on more than one subnetwork using multi-hop discovery. It can be scheduled to run at preset times. An option is also available to specify the physical location under which discovered objects are created.
|
Note For information on how to set the auto discovery schedule, see the Cisco Element Management Framework Installation and Administration Guide Release 3.2. |
After the chassis is detected, an object representing the chassis creates and is placed under the site from which auto discovery was launched. A map of the chassis also creates, as shown in Figure 3-20.
If you wish to auto-discover a chassis that can be managed by the EM, then the Physical Path option must be enabled and an appropriate Physical Path (terminated with a generic object) must be selected. Providing the above is done, the auto discovery application will create a chassis below the selected Physical Path for each chassis discovered.
Following chassis auto-discovery, you must manually enter the appropriate IOS password and commission the chassis to fully manage the device, including enabling automatic module discovery. For information, see the "Managing Username and Passwords" section and the "Commissioning Chassis" section or on page 5-9.
Assuming the chassis, of which the module is part of, is commissioned and in a managed state (e.g., not the decommissioned or lost comms state), heartbeat polling detects modules (within five minutes' time) and alerts the EM to their 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 discovers, 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. The commissioning process also determines what state the module should go into, which can be the normal, errored, or mismatched state.
 |
Tip For information on individual states, see the "Object States" section. |
Auto discovered modules are assigned standardized module naming conventions using an automatic naming scheme provided. Auto-generated module names consist of the slot and subslot numbers appended to the module type (subslot appended only when applicable). The Cisco Access Router Manager implements automatic naming conventions for the following objects:
Network modules are named by type and slot number. For example, a NM-4T1-IMA module in slot 2 would be automatically named NM-4T1-IMA-2. If the same module were in slot 3, it would be named NM-4T1-IMA-3. The interfaces on each network module are named according to the interface type followed by slot-port number. For example, interfaces on an ATM module, such as the NM-4T1-IMA in slot 3 are named: ATM 3-0, ATM 3-1, ATM 3-2, and ATM 3-3. The last number indicates the port. The following figure captures this example as it appears in the physical hierarchy.
While all network modules supported by Cisco Access Router Manager occupy full slots, only some network modules can accommodate interface cards by way of integrated subslots. The NM-1A-OC3M, NM-4T-IMA and NM-1FE-TX network modules, for example, do not accommodate interface cards, therefore the subslot indicator is irrelevant to these module objects. A WIC-2T module, which may be inserted into a NM-2FE2W network module in slot 1 (i.e., NM-2FE2W-1), occupies a subslot and would be named WIC-2T-1-0 if it were in slot 1 subslot 0. It would be named WIC-2T-1-1 if it were in slot 1 subslot 1.
The interfaces on a network module which contains subslots, such as the NM-2FE2W module, follows two different interface naming conventions. If the NM-2FE2W is in slot 1 (i.e., NM-2FE2W-1), the interfaces directly on the module are named FastEthernet 1-0 and FastEthernet 1-1 indicating the interface type followed by the slot-port number. This interface naming convention is exactly the same as that described in the preceding paragraphs. If the same NM-2FE2W module in slot 1 also contains an interface card in subslot 0, for example a WIC-2T (i.e., WIC-2T-1-0), the associated interfaces would be named Serial 1-0 and Serial 1-1. In this case, notice that the digits following the interface type indicate the slot-port location and do not cite the subslot number of the WIC immediately above the serial interface in the physical hierarchy. If there is another WIC-2T in subslot 1 (i.e., WIC-2T-1-1), the associated interfaces are also named Serial 1-0 and Serial 1-1. Again, the naming convention does not reflect the subslot number and reads the slot number from the parenting network module. The following figure displays this example as the objects appear in the physical hierarchy.
Managed objects which reside outside of the network module slots, directly on the chassis rather than within a network module slot, appear in the Physical view hierarchy beneath the CPU-0 object. The CPU-0 object serves as a container for the external Fast Ethernet port(s) and interface card (e.g., WICs, VICs, VWICs) slot(s), and is not a physical object within the device itself.
Depending on the chassis, there may be one to four Fast Ethernet ports directly on the chassis. The related Ethernet interfaces appear directly beneath the CPU-0 module as Ethernet 0-0, Ethernet 0-1, etc. when discovered. Additionally, depending on the chassis, there may be zero to two supported interface card (e.g., WICs, VICs, VWICs) slots. The interface cards which fill these slots also appear directly beneath the CPU-0 module and may support one or two ports each. The ports on an interface card discover beneath the associated interface card object within the hierarchy, and the name includes the interface type and port number on the interface card. Similar to the naming convention of interface cards and associated ports previously described, the interface card slot number is disregarded. Instead, the slot number is derived from the parenting CPU-0 object. The CPU-0 slot number is a default value.
For example, consider a Cisco 2611 chassis which can accommodate up to two external interface cards and up to two external Ethernet interfaces. Say that both Ethernet ports are occupied and one WIC-2T is present in the chassis (as the following figure illustrates). The Ethernet interfaces are automatically named Ethernet 0-0 and Ethernet 0-1. The WIC-2T is automatically named WIC-2T-0-1, indicating that it is present in the external interface card slot 1. The possible interfaces contained within the WIC-2T could be Serial 0-0 and Serial 0-1. Again, notice that the interface card slot number is not included in the interface port naming convention on the external interface cards.
To clarify, the physical processor module is always automatically named CPU--1, no matter the chassis.
EM chassis objects can be manually pre-deployed before the equipment arrives on-site. Pre deployment is useful if, for example, you know that you will be receiving a certain device, you can manually deploy the specific chassis before it is actually present.
Pre-deployment can save future time and effort. When the device becomes available in the network, you must commission the chassis in order for the EM to detect its presence. Assuming that the chassis successfully moves into a managed state (e.g., not the decommissioned or lost comms state), subchassis discovery begins. If the device is not present at the time of commissioning, the EM chassis object moves into the lost comms state (i.e., is not managed). The discovered chassis object adopts all the configuration parameters you pre-applied to it (e.g., name).
Pre-deployment is desirable in a situation where the expected hardware is known, but configuration information is perhaps not readily available. If you want to manually predeploy only, follow only the pre-deployment procedure following, then perform device synchronization. Manually pre-deployed objects assume whatever configuration is currently on the device, and this information displays in the appropriate EM configuration windows.
Currently, only the chassis object is available for (manual) pre-deployment. Modules, processor, and supporting modules are not available for manual deployment.
For instance, say that you are expecting a Cisco 3661-AC chassis and various modules (with respective interfaces). You can perform the following steps to perform both manual pre-deployment and offline configuration:
1. Manually deploy a generic object. For further information, see the "Deploying Generic Objects" section.
2. Manually deploy the chassis under a generic object. For further information, see the "Manually Deploying Chassis" section.
Now you have pre-deployed and thus created representative objects in the EM for your expected hardware. All of these objects will remain in the Decommissioned state until the hardware is physically present on the network.
When all of your pre-deployed objects become available, you can synchronize the EM to the device. This process synchronizes the information on the device with the pre-deployment information in the EM. Synchronization is achieved by commissioning the chassis object. Chassis commissioning allows the EM to detect the presence of the chassis. When you commission the chassis, the EM discovers not only the presence of the chassis, but the presence of all existing objects within the chassis. For further information, see the "Commissioning Chassis" section or on page 5-9.
Synchronization effectively tells the EM that you now have a real working system. All objects typically pass through the following state sequence: decommissioned to discovery to normal to sync to normal.
Manual deployment consists of three stages as shown in the following figure.
1. The first deployment stage is to manually deploy a generic object (e.g., Site). A generic object can be looked upon as a container object where you can deploy further objects that represent the chassis, line cards and interfaces contained within the chassis. For further information, see the "Deploying Generic Objects" section.
2. The second deployment stage is at the chassis level. The chassis can be auto discovered or manually deployed. For further information, see the "Automatically Discovering Chassis" section or the "Manually Deploying Chassis" section. You can also predeploy objects (that is, manually predeploy objects before the Cisco hardware arrives on-site). For further information, see the "Predeployment" section on the previous page.
3. The third deployment stage is subchassis level discovery. Subchassis discovery involves either chassis commissioning or auto discovery of objects within a managed chassis. For further information, see the "Chassis Commissioning and Subchassis Discovery" section.
Some generic objects are technology specific (e.g., IP Device, SNMP Agent, SNMP MIB-2 Agent, SNMP Proxied Agent), while others are not (e.g., region, site, bay). Non-technology specific generic objects can be used to organize the components of your network when deployed beforehand. For example, you may ultimately choose to organize a number of bays within a generic region object, a number of sites within a generic bay object, and a number of chassis within a generic site object. In general you can organize generic objects as you wish. However, in order to support successful deployment of non-generic chassis objects, chassis objects must be deployed directly beneath a generic site object.
Generic object deployment uses the Cisco EMF Deployment Wizard templates. When deploying a generic object, the information you are prompted to provide differs according to the type and number of generic objects you are deploying.
The following table displays a list of generic objects that can be deployed using the generic deployment templates.
This section provides an example that shows how to deploy a non-technology specific site object.
|
Note For additional information on deploying generic objects, including deployment from the Class Palette, see the Cisco Element Management Framework User Guide Release 3.2. Additionally, know that the Cisco Shelf object on the Class Palette is not applicable (not valid) to this EM. |
To deploy a Generic (Site) object, proceed as follows:
Step 2 Press (click and hold down) the right mouse button.
Step 3 Choose Deployment > Deploy Generic Objects.
The Deployment Wizard - Templates window appears displaying a list of available generic object deployment profiles. Deployment profiles are templates that prompt you for the appropriate information required to deploy the selected object successfully.
Step 4 Select the generic object that you wish to deploy from the list supplied. In this example select the deployment profile for a site object.
Step 5 Click Forward.
The Deployment Wizard - Object Parameters window appears.
Step 6 Enter the number of (Site) objects to deploy.
Step 7 Click Forward.
A second Deployment Wizard - Object Parameters window appears.
Step 8 Enter a (Site) object name. Each object must have a unique name.
Step 9 Click Forward.
Step 10 Click Select to select a physical view.
The Object Selector window appears.
Step 11 Choose the object you want to place the generic object under within the Physical view. Objects which are not available for selection are greyed out. Click on the + sign to expand the view as required.
Step 12 Click Apply.
The Deployment Wizard - Views window re-appears with the selection displayed.
You are prompted to repeat Steps 8 to 13 if you are deploying more than one generic object.
The Deployment - Wizard Summary window appears. The Summary window provides details of the object you are about to deploy.
The number of objects deployed reflects the number of sites entered in Step 6. This entry directly correlates to the number of objects listed in the deployment summary information.
Step 14 Click Finish to deploy the object and close the Summary window if the deployment information is correct. If the information is incorrect, click Cancel to stop deployment and close the Summary window.
The new object(s) deploy accordingly and display in the Map Viewer window.
Chassis objects deploy by either automatic discovery or manual deployment. When manually deploying, you can choose to automatically commission a chassis immediately following deployment or you may choose to simply initiate commissioning activities at a later time.
Regardless of the chassis deployment method used, in order to successfully deploy a chassis object you must deploy the chassis beneath a generic site object. This means that you must deploy a site before deploying a chassis. For instruction on deploying a site object, see the "Deploying Generic Objects" section.
The Deploying Chassis section contains the following areas:
The chassis manual deployment quick start method allows you to deploy a chassis object, then automatically begin commissioning and subchassis discovery activities on the deployed chassis.
|
Tip It is recommended that you ping the router you intend to deploy before using the manual deployment Quick Start method to ensure the device is contactable. If the device is not contactable, consider predeploying. |
To deploy a chassis using the quick start method, proceed as follows:
The Deployment Wizard appears.
You can click Cancel at any point to cancel the deployment.
Step 2 Select the appropriate chassis type Quick Start option, then click Forward.
The Deployment Wizard - Object Parameters window appears.
Step 3 Enter the number of chassis objects you want to deploy.
Step 4 Click Forward.
A second Deployment Wizard - Object Parameters window appears.
Step 5 Enter the following information:
Step 6 Click Forward.
You are prompted to repeat Step 5 if you are deploying more than one chassis.
Deployment summary details appear in the Deployment Wizard - Summary window.
The number of objects deployed is equal to the number of chassis entered in Step 3. This entry directly correlates to the number of objects listed in the deployment summary information.
Step 7 Click Finish to deploy the chassis and close the summary window if the deployment summary information is correct. If the Deployment Summary information is incorrect, click Cancel to stop deployment and close the summary window.
The deployed chassis object(s) appear in the left-hand pane of the Map Viewer beneath the generic object from which deployment was initiated and the corresponding icon(s) appear in the right-hand pane of the Map Viewer.
Commissioning activities start with chassis discovery. If successful, the chassis moves into the appropriate managed state then initiates subchassis discovery which begins to detect the physical objects (that is, modules and interfaces) within the chassis and places them onto the chassis map. Modules and interfaces are automatically named as described in the "Automatically Discovering Modules" section. Following subchassis discovery, all objects enter a specific state. For further information, see the "Object States" section.
Successful commissioning not only discovers the chassis and all the physical objects within the chassis, but also initiates heartbeat polling, which allows alarms to be raised on the chassis and all physical objects within the chassis.
Commissioning automatically starts active management (such as polling) on the chassis and all commissioned objects within the chassis. There is no indicator regarding the success or failure of the quick start commission. To optionally check the outcome of the commission, review the status of the Last Commission field on the Chassis Configuration window. For further information on the Chassis Configuration window, see the "Chassis Configuration" section. The chassis state is an additional indicator of a failed commission. If the state is lost comms or mismatched, the commissioning failed.
As a result of manual deployment, a chassis object creates within the EM. In order to manage the chassis through the EM, you must commission the chassis following deployment. For further information, see the "Commissioning Chassis" section or on page 5-9.
The EM also provides you with the option to deploy a chassis and commission it from the deployment operation (i.e., quick start deployment). All Cisco Access Router Manager routers support the quick start feature. For further information, see the "Manually Deploying Chassis Using Quick Start" section.
The following procedure is appropriate for predeployment, where the device deployed is not yet available on the network.
To deploy a chassis, proceed as follows:
The Deployment Wizard appears.
You can choose Cancel at any point to cancel the deployment.
Step 2 Select the chassis type you want to deploy, then click Forward.
The Deployment Wizard - Object Parameters window appears.
Selecting a chassis type with "(Quick Start)" beside the name allows you to deploy a chassis object and automatically commission the chassis following deployment. For further information, see the "Manually Deploying Chassis Using Quick Start" section.
Step 3 Enter the number of chassis objects you want to deploy.
Step 4 Click Forward.
A second Deployment Wizard - Object Parameters window appears.
Step 5 Enter the following information:
If you are deploying more than one chassis, you are prompted to repeat Steps 5 and 6.
The Deployment Summary details appear in the Deployment Summary window.
The number of objects deployed is equal to the number of chassis entered in Step 3. This entry directly correlates to the number of objects listed in the deployment summary information.
Step 7 Click Finish to deploy the chassis and close the Summary window if the deployment summary information is correct. If the Deployment Summary information is incorrect, click Cancel to stop deployment and close the Summary window.
The deployed chassis object(s) appear in the left-hand pane of the Map Viewer beneath the generic object from which deployment was initiated and the corresponding icon(s) appear in the right-hand pane of the Map Viewer.
At any time following successful chassis deployment, you may initiate subchassis discovery by commissioning the chassis. Until you do so, the chassis remains in an unmanaged state (e.g., decommissioned). For further information, see the "Chassis Commissioning and Subchassis Discovery" section or the "Commissioning a Chassis" section.
The Commissioning section covers the following areas:
After you deploy a chassis, the next step in creating a manageable system is to commission the chassis (which begins the process of subchassis discovery). The following figure shows a Cisco 3662-AC chassis map before subchassis discovery. Subchassis discovery identifies all physical objects (that is, modules and interfaces) within the chassis and places them into the chassis map.
Line cards and interfaces located within the chassis are discovered at this time. Commissioning not only discovers the chassis and all the physical objects within the chassis, but also initiates heartbeat polling, which allows alarms to be raised on the chassis and all physical objects within the chassis.
Because the chassis is the highest-level object, all objects under the chassis are commissioned as well when you commission the chassis. One level down, if you commission a module interface, you commission all physical objects underneath that level. If you commission a port adapter, you commission all interfaces on that port adapter, and so on. However, note that before you can commission any physical object within a chassis, the chassis object itself must be commissioned. This means that you must run subchassis discovery by commissioning the chassis before you can decommission or recommission any individual objects under the chassis. If you do not want to actively manage all objects within the chassis, you can decommission the objects you are not ready to manage.
For information on decommissioning subchassis objects, see the "Decommissioning Modules" section or page 5-20 and the "Decommissioning an Interface" section.
When you successfully commission a chassis, subchassis discovery begins automatically. Subchassis discovery discovers and commissions all objects within the chassis. Commissioning automatically starts active management (such as polling) on the chassis and all commissioned objects within the chassis. If commissioning is unsuccessful, the chassis moves into the mismatched or lost comms state. To resolve the errors which results in theses states, see the "Object States" section.
To commission a chassis, proceed as follows:
The Chassis Configuration window appears displaying the Configuration tab.
Step 2 Select the chassis you want to commission from the Chassis list box at left of the window.
|
Tip If commissioning several chassis at once, use the Shift or Ctrl key to select multiple chassis from the Chassis list box. To make a contiguous selection, select an initial item, press the Shift key, then select the last item. To make a non-contiguous selection, select an initial item, press the Ctrl key, then select other items as necessary. |
Step 3 Ensure the chassis has proper configuration. For information on chassis configuration attributes, see the "Chassis Configuration" section.
Step 4 Click Commission (located in the Actions area).
The chassis commissions and all objects contained within commission through subchassis discovery. As subchassis objects discover, they display in the left-hand pane of the Map Viewer window and populate the chassis map in right-hand pane of the Map Viewer. An Action Report window appears displaying the outcome of the chassis commission. Additionally, status information displays in the Commission Status area of the Chassis Configuration window reiterating the outcome of the commissioning action as either Succeeded or Failed.
When viewing the Chassis Configuration window in future instances, the Commission Status area displays the result of the last commission action, either Succeeded or Failed.
Step 5 Click Close to close the Action Report window.
Step 6 Choose File > Close to close the Chassis Configuration window.
The following figure shows a Cisco 3662 chassis map in the Physical view after subchassis discovery. Modules and interfaces are automatically discovered within the chassis and enter the appropriate post-commissioning state. For details about object states, see the "Object States" section.
The Cisco 2600 series and 3620/3540 chassis maps do not look the same as the 3660.
After commissioning a chassis you can configure and manage the chassis objects. For further details, see the "Chassis Configuration" section.
Decommissioning a chassis decommissions all objects within the chassis, and active management (such as polling) stops on the chassis and on all objects within the chassis.
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.
To decommission a chassis, proceed as follows:
The Chassis Configuration window appears displaying the Configuration tab (see Figure 3-21).
Step 2 Select the chassis you want to decommission in the Chassis list box on the left-hand side of the window.
Step 3 Click Decommission (located in the Actions area).
The chassis and all objects contained within are decommissioned. Decommissioned objects remain in the left-hand pane of the Map Viewer window and appear grayed out in the chassis map which displays in the right-hand pane of the Map Viewer. An Action Report window appears displaying the outcome of the chassis decommissioning. If decommissioning is successful, the state of the chassis and subchassis objects change to decommissioned.
Step 4 Click Close to close the Action Report window.
Step 5 Choose File > Close to close the Chassis Configuration window.
The Module Commissioning and Discovery section covers the following areas:
As previously described, there are several types of modules the EM supports, including line cards, processors, and supporting modules (e.g., power supplies). Commissioning modules discovers and commissions the module and all the objects within the module when applicable, and begins heartbeat polling. Overall, successful commissioning places the module in a manageable state (by the EM).
The following lists the activities which occur when commissioning line cards and processor modules.
Commissioning a module initiates the following activities:
Commissioning any supporting module initiates the following activities:
To commission a module, proceed as follows:
The Module Configuration window appears.
Step 2 Select a chassis from the Chassis list box at left of the window, then select a module from the Module list box.
Step 3 Ensure the module has proper configuration. For information on module configuration attributes, see the "Module Configuration" section.
Step 4 Click Commission (located in the Actions area).
The module and all objects it contains commission through discovery. An Action Report window appears displaying the outcome of the module commission. Additionally, status information displays in the Commission Status area of the Module Configuration window reiterating the outcome of the commissioning action as either Succeeded or Failed.
When viewing the Module Configuration window in future instances, the Commission Status area displays the result of the last commission action, either Succeeded or Failed.
Step 5 Click Close to close the Action Report window.
Step 6 Choose File > Close to close the Module Configuration window.
Decommissioning modules also decommissions all objects beneath the card. As a part of decommissioning, heartbeat polling, status gathering, and performance monitoring terminates. These activities put the module in a state that is unmanageable from the EM.
The following lists the activities which occur when decommissioning line cards and supporting modules.
Decommissioning a module initiates the following activities:
Decommissioning any supporting module initiates the following activities:
It is recommended that you decommission a module prior to physically removing it from a managed chassis. Decommissioning a module before physically removing it prevents alarms.
To decommission a module, proceed as follows:
The Module Configuration window appears (see Figure 3-23).
Step 2 Select a chassis from the Chassis list box at left of the window, then select a module from the Module list box.
Step 3 Click Decommission to decommission the selected module.
An Action Report window appears describing the outcome of the decommissioning action.
The module and all objects contained within are decommissioned. Decommissioned objects remain in the left-hand pane of the Map Viewer window and appear grayed out in the chassis map which displays in the right-hand pane of the Map Viewer. An Action Report window appears displaying the outcome of the module decommissioning. If decommissioning is successful, the state of the module and objects contained within change to decommissioned.
Step 4 Choose Close to close the Action Report window.
Step 5 Choose File > Close to close the Module Configuration window.
Posted: Wed Feb 12 10:21:37 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
