|
|
This chapter describes the process of provisioning the C7kM objects. This process can be separated into two distinct phases:
 |
Note Throughout this chapter, the instruction steps for each workflow use terms which are explained in the Cisco Element Management Framework CORBA Gateway Developer Guide , this guide should be referred to when trying to understand these instructions. |
This section contains the following sub-sections:
Before a device can be managed, it must first be deployed and then commissioned. Deployment of a 7k chassis involves creating several different objects. Typically these objects would be deployed in the following order:
1. Chassis (models the high level system attributes of the device).
2. Module (models the different line cards present).
3. Interface (responsible for the interfaces belonging to the line cards).
Chassis can be deployed either by using Auto-Discovery or by performing manual deployment, both of these options are discussed in this section. Refer Synchronization for the details of the objects being deployed for modules and interfaces during discovery.
Auto-Discovery can be initiated from the MapViewer or Discovery icons in the C7kM Launchpad. When this process is initiated, the network is examined for IP and SNMP devices. AutoDiscovery is provided by C7kM but requires an object model to provide the class of managed object to be deployed and managed. For every Cisco 7k chassis that is discovered on a specified network a chassis object is created.
Chassis objects deployed via AutoDiscovery are deployed in the decommissioned state.
Operators can manually deploy chassis. The deployment wizard uses template files provided by C7kM which provide information about the objects being deployed and also detail any information required from the user in order to complete deployment.
Manual deployment allows the operator to pre-deploy chassis that do not currently exist on the network, ready to be managed when they are physically connected. Pre-deployed chassis are not manageable until connected. Manually deployed chassis are created in the decommissioned state.
The following assumes that you already have a container like a site deployed.
The steps involved in the deployment of the chassis are as follows:
Step 2 Get the object id of the parent site (all ER chassis are placed under a under a container like site,region,bay etc.)
Step 3 Create a vector of ContainmentSpec data structures having the containment relationships of the new shelf in the physical and component managed view.
Step 4 Create a deployment context
Define the following attributes:
Table 6-1 Attribute Table for Chassis Deployment
Step 5 Populate the deployment context with the container object ids (retrieved from Step 1 ) and class ids (retrieved from Step 2 ) and the attributes mentioned above.
Step 6 Initiate the deployment using deployment framework.
The steps involved in the deployment of a module are as follows:
Step 2 Get the parent Cisco 7000 Chassis object id
Step 3 Create a vector of ContainmentSpec data structures having the containment relationships of the new module to be created in the physical and component managed view
Step 4 Create a deployment context
Step 5 Define the following Attributes:
Step 6 Populate the deployment context with the container object ids (retrieved from Xref_Colorparanum) and the class ids (retrieved from Xref_Colorparanum)
Step 7 Initiate the deployment using deployment framework.
This section contains the following sub-sections:
The second stage in the provisioning process is the configuration of the already deployed C7kM objects. C7kM allows these objects to be configured by the setting of attributes associated with an object. There are 2 different types of attributes:
The generic workflow for setting attributes and initiating controller actions is as follows:
Step 2 Check the state of the chosen objects.
Before performing any operations on the objects it is necessary to first determine that they are in a state where they can be managed or a state that is valid for what is required to be done. The state can be fetched by getting the attribute virtual:CommonEM-MIB.controllerState on each of the objects. Check that the returned state is a valid managed state, typically normal, performancelogging and errored.
Step 3 Set the attributes for the objects chosen making sure that the correct configuration attributes are set before setting command attributes that may rely on them.
The actual attributes defined for each workflow are identified later on in Attribute Models . Note that the section for all of these attributes is "virtual:"
Step 4 Check values have been successfully set or that the object is now in the expected state.
Not all attributes provide notification of failure when set, so it is safer to fetch the attributes after they have been set and check that the returned values are what they were set to.
The following sub-sections table the generic attributes defined for objects of the specified type, the MIB attribute or IOS commands they relate to and the valid range of values. The command attributes also specify which configuration attributes they depend on. Note that range checking is not done on the attribute value when they are sent from a Northbound system, therefore range checking needs to be done in the Northbound system. It is also advisable to get the value of an attribute after it has been set to ensure that it was successful.
This section describes the process in provisioning the Voice functionality. It also describes the attributes that need to be set in order to configure the Voice functionality of interfaces from a Northbound system.
This section contains the following sub-sections:
|
Note To obtain the full name of an attribute, simply prefix the attribute named in the table with: virtual:CEMCS-IF-VOICE-MIB. For example, the full name of ds0GroupNumber is "virtual:CEMCS-IF-VOICE-MIB.ds0GroupNumber" |
The CiscoMultiChanFunctionality class defines the attributes that are supported by Voice Interface 7000 series devices. This includes Channel, PRI, TDM and Channel group configuration attributes and also Service Type configuration attributes.
The following section list the attributes defined for the Voice functionality, their purpose, option and limits for the default implementation.
To configure a Voice interface, proceed as follows:
Identify the interfaces which support Voice functionality, that is, interfaces of a class which inherits from CiscoMultiChanFunctionality. This can be achieved by performing a query for objects of a particular class. See the Cisco Element Management Framework Object Model Features chapter in the "Cisco Element Management Framework SDK Controller Designer Developer's Guide" for further information.
Step 2 Check the state of the interfaces.
Before performing any operations on the interfaces it is necessary to first determine they are in a state where they can be managed. The state can be fetched by getting the attribute virtual:CommonEM-MIB.controllerState on each of the interfaces. Check that the returned state is a valid managed state, typically normal, perflogging and errored.
Step 3 Set values on the interface attributes.
The Voice related attributes defined by the Voice component may be set. Refer to the Voice Attributes for a description of attributes.
Step 4 Check values have been successfully set.
Not all attributes provide notification of failure when set so it is safer to fetch the attributes after they have been set and check that the returned values are what they were set to.
Refer to the following sections for more information on how to configure different types of voice interfaces:
Digital service level 0 (DS0) represents a 64-kbps single-channel signal generated by a T1 terminal device such as a channel bank, multiplexer (MUX), or digital PBX. Cisco 7000 Series Manager enables you to create or delete DS0 groups. Before creating a DS0 group, you must configure the service type of the MCX controller. You can configure MCX controllers for voice or data transmissions. Possible configurations include common channel signaling (CCS) voice, channel associated signaling (CAS) voice, or data.
To configure DS0 groups, proceed as follows:
For service type you can set either of these three values
Step 2 To create new DS0 group, set the following attributes on the appropriate interface :
|
Note T1 interfaces support up to 24 time slots (valid entries are 1-24.) E1 interfaces support up to 31 time slots (valid entries are 1-31.) |
Step 3 To delete a DS0 group, set the following attributes :
|
Note You cannot delete time slot withini a group, you need to delete the group and recreate the group with the required time slot. |
|
ISDN is an interface to the PRI. PRI provides access through a single 64-kbps D channel plus 23 (T1) or 30 (E1) B channels for voice or data. Cisco 7000 Series Manager allows you to create or delete PRI groups. You must configure the ISDN switch type before creating a PRI group.
To configure PRI groups, proceed as follows:
isdn switch-type <switch name>
Where <switch name> refers to:
- primary-4ess (Lucent 4ESS switch type for the United States)
- primary-5ess (Lucent 5ESS switch type for the United States)
- primary-dms100 (Northern Telecom DMS-100 switch type for the United States)
- primary-net5 (NET5 switch type for the United Kingdom, Europe, Asia, and Australia)
- primary-ni (National ISDN switch type for the United States)
- primary-ntt (NTT switch type for Japan)
- primary-qsig (QSIG switch type)
- primary-ts014 (TS014 switch type for Australia [obsolete])
Step 2 To create new PRI group, set the following attributes on the appropriate interface :
PRI Time Slots - unique time slot or range of time slots for the new PRI group you are creating.
|
Note T1 interfaces support up to 24 time slots (valid entries are 1-24.) E1 interfaces support up to 31 time slots (valid entries are 1-31). |
Create Action - set the value as "priCreateAction" on priCreateAction attribute which is a command attribute which creates a PRI group with the the values supplied for time slots.
Step 3 To delete a PRI group, set the following attributes :
Delete Action - set the value as "priDeleteAction" on priDeleteAction attribute which is a command attribute and deletes a PRI group from the system.
|
Note You cannot delete time slot within a group, you need to delete the group and recreate the group with the required time slot. |
Time-division multiplexing (TDM) allows for information from multiple channels to be allocated as bandwidth on a single wire based on preassigned time slots, therefore enabling simultaneous support for voice, data, and video transmission over a single network link. Pieces of data from each signal are interwoven into a single link transmission and reconstructed at the destination point. TDM groups are made up of cross-connects referred to as clear channel groups or pass-throughs. Cisco 7000 Series Manager allows you to create and delete TDM groups.
To configure TDM groups, proceed as follows:
|
Note T1 interfaces support up to 24 groups (valid entries are 0-23.) E1 interfaces support up to 31 groups (valid entries are 0-30). |
|
Note T1 interfaces support up to 24 time slots (valid entries are 1-24.) E1 interfaces support up to 31 time slots (valid entries are 1-31). |
Step 2 To delete a TDM group, set the following attributes :
|
Note You cannot delete time slot within a group, you need to delete the group and recreate the group with the required time slot. |
A channel is the smallest subdivision of a communication path on a digital, multiplexed signal for which information can be provided in one direction. Multiple channels can be multiplexed over a single cable in certain environments. Channel groups also referred to as serial interfaces. Cisco 7000 Series Manager enables you to create and delete channel groups.
Table 6-10 Channel Group Configuration Attributes
|
To configure Channel groups, proceed as follows:
|
Note T1 interfaces support up to 24 groups (valid entries are 0-23.) E1 interfaces support up to 31 groups (valid entries are 0-30). |
|
Note T1 interfaces support up to 24 time slots (valid entries are 1-24.) E1 interfaces support up to 31 time slots (valid entries are 1-31). |
Step 2 To delete a Channel group, set the following attributes :
|
Note You cannot delete time slot within a group, you need to delete the group and recreate the group with the required time slot. |
Posted: Thu Oct 2 12:28:27 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.