Cisco Systems OL-3597-01 User Manual
CHA PTER
3
Deploying and Discovering Objects
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:
• Automatic Discovery
• Pre–deployment
OL-3597-01
• Deployment
• Commissioning
Cisco Access Router Manager User Guide
3-1
Automatic Discovery
Automatic Discovery
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:
• Automatically Discovering Chassis
• Automatically Discovering Modules
Automatically Discovering Chassis
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.
Chapter 3 Deploying and Discovering Objects
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:
• IP—ICMP pings are used to find chassis in a given IP address range. This finds which IP device
exists, but does not discover what kind of device it is.
• SNMP—SNMP get requests are used to find chassis in a given IP address range. Several SNMP
community strings can be used so that equipment with different community strings can be
discovered in the same discovery session. The SNMP information returned by devices is used to
work out what kind of device has been found.
• IP and SNMP—ICMP pings are used to find chassis and then SNMP requests are used to interrogate
the chassis to find out what kind of chassis they are. This is the default mechanism.
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 on
page 3-22.
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.
3-2
Cisco Access Router Manager User Guide
OL-3597-01
Chapter 3 Deploying and Discovering Objects
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 on page 5-4 and the
“Commissioning Chassis” section on page 3-23 or on page 5-9.
Automatically Discovering Modules
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 on page 1-23.
Automatic Discovery
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 (and associated interfaces)
• Interface cards (and associated interfaces)
• External interface cards (and associated interfaces) and Ethernet interfaces
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.
Figure 3-1 Network Module/Interface Port Naming Convention
Network Module Name–Slot
Interface Type Slot–Port
OL-3597-01
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
Cisco Access Router Manager User Guide
3-3
Automatic Discovery
Chapter 3 Deploying and Discovering Objects
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.
Figure 3-2 Network Module/Interface Port and Interface Card/Port Naming Convention
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.
3-4
Cisco Access Router Manager User Guide
OL-3597-01
Chapter 3 Deploying and Discovering Objects
Figure 3-3 CPU–0 Naming Convention
To clarify, the physical processor module is always automatically named CPU––1, no matter the chassis.
Automatic Discovery
CPU–0 Container
Ethernet Port Interface Type Slot–Port
Interface Card Slot–SubSlot
Interface Type Slot–Port
OL-3597-01
Cisco Access Router Manager User Guide
3-5
Pre–deployment
Pre–deployment
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.
Chapter 3 Deploying and Discovering Objects
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 on page 3-8.
2. Manually deploy the chassis under a generic object. For further information, see the “Manually
Deploying Chassis” section on page 3-18.
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 on page 3-23 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.
3-6
Cisco Access Router Manager User Guide
OL-3597-01
Chapter 3 Deploying and Discovering Objects
Deployment
Manual deployment consists of three stages as shown in the following figure.
Figure 3-4 Deployment Process Workflow
Stage 1: Manually Deploy
Generic Container Objects
(e.g., Sites)
Deployment
Chassis Auto Discovery
Stage 2: Chassis Level
Deployment
Stage 3: Subchassis
Level Discovery
1.
The first deployment stage is to manually deploy a generic object (e.g., Site). A generic object can
Chassis Manual
Deployment
(Quick Start)
Chassis Manual
Deployment
80590
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 on page 3-8.
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 on
page 3-2 or the “Manually Deploying Chassis” section on page 3-18. You can also predeploy
objects (that is, manually predeploy objects before the Cisco hardware arrives on–site). For further
information, see the “Pre–deployment” 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 on page 3-22.
OL-3597-01
Cisco Access Router Manager User Guide
3-7
Deployment
Deploying Generic Objects
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.
Table 3-1 Generic Object Deployment Templates
Chapter 3 Deploying and Discovering Objects
Object to be Deployed
Deployment Templates Available
Generic Bay
IP Device
Region
SNMP Agent
SNMP MIB–2 Agent
SNMP Proxied Device
Site
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 1 Place the cursor over a relevant object to determine the objects you can deploy from. In this example we
will deploy a site object from the Physical view.
Step 2 Press (click and hold down) the right mouse button.
Step 3 Choose Deployment > Deploy Generic Objects.
3-8
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.
Cisco Access Router Manager User Guide
OL-3597-01
Chapter 3 Deploying and Discovering Objects
Figure 3-5 Deployment Wizard – Templates Window
Deployment
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.
Figure 3-6 Deployment Wizard – Object Parameters Window (1 of 2)
OL-3597-01
Cisco Access Router Manager User Guide
3-9
Loading...