|
|
This chapter describes the various Cisco 6100 Series system states, their meanings, and their impact on system operation. This chapter also includes instructions for accessing the state of a Cisco 6100 Series system entity.
This chapter includes the following sections:
Of these states, Administrative, Operational, and Usage states are International Organization for Standardization (ISO) compliant. The remaining states are specific to the Cisco 6100 Series.
As the operator, you define the Administrative state. The system determines and provides all other states. The system provides state information through the following sources:
To access the state of a particular entity in ViewRunner, complete the following steps:
Choose Module and Status to view the module state of that module on the Status tab.
Step 2 Choose Module and Configuration to open the Module Properties dialog box Configuration tab where you can manage the Administrative state.
The alarm severity for module operational states displays on the module tabs and as a bell icon on the ViewRunner Chassis View.
The values of each state that display within ViewRunner are a function of the most recent Cisco 6100 Series SNMP agent poll of the Cisco 6100 Series system event log. ViewRunner displays these states on the Module Properties dialog box Status tab. ViewRunner retrieves these states from the Cisco 6100 Series system whenever you open a dialog box and click a Status tab.
Step 3 Use the Refresh button, provided on most of the graphical user interface (GUI) dialog boxes, when you manage service-affecting changes.
The Refresh button captures the most up-to-date values for the fields in the opened dialog box; this information can help you make decisions based on real-time data.
You can display the states of a particular module or port in ViewRunner on the module and port dialog boxes. The following types of modules function in ViewRunner:
The Status tabs are similar for both modules and ports. These tabs contain the following information:
The Status tab on a Module Properties dialog box displays state information about that specific module. Figure 3-1 is representative of the display of states on module Status tabs for all the modules.
 |
Note The Status and Configuration tabs on the dual-port DMT-2 ATU-C module and ports dialog boxes are similar to those of the dual-port CAP ATU-C module. For this reason, illustrations of and references to the CAP ATU-C module dialog boxes also refer to the dual-port DMT-2 ATU-C module dialog boxes. The Status and Configuration tabs of the Quad-port STU-C module dialog boxes are represented separately if they differ from those of the ATU-C module, other than number of ports present. |
The Administrative and Operational states are located under the Service State Details group box. If one or more of these states takes on a "negative" state, relative to its ability to provide service, the Service State changes from In Service to Out of Service. For example, if you change the Administrative state from Unlocked to Locked, the Service State changes from In Service to Out of Service.
To display additional information, click the Configuration tab. This tab includes the Inventory Details group box, ATU-C (or LIM) Connect on Demand, and the Administrative state, which allows you to lock or unlock the particular module.
The Status tab on a port displays state information about a specific port. Figure 3-2 is representative of the display of states on module Status tabs for all the modules in the user interface.
When the Usage state is Busy, you can click the LIM Properties button to get information on the LIM that corresponds to the CAP ATU-C port that you selected. When the CAP ATU-C Port field displays Trained, the dialog box also displays port information such as the upstream and downstream rates.
Click the Configuration tab to display the Administrative state of the port. You can use the Port Configuration tab to lock or unlock a particular port or to edit a physical or logical pool.
To fully understand states and their impact on system operations, a review of terminology may be helpful. Key terminology includes entities and the containment hierarchy.
Figure 3-3 illustrates the specific containment hierarchy model that the system uses to propagate state changes between various entities. Within the containment hierarchy, superior entities contain subordinate entities. Chassis are superior to slots; slots are superior to modules; and modules are superior to ports. Some entities can be both superior and subordinate. For example, a module is a superior entity to its ports, and a subordinate entity to its chassis.
Supporting or subordinate resource relationships are also important when you manage resource deletions. See "Deleting System Components," for more information on deleting entities.
The Cisco 6100 Series system detects states by using a polling algorithm. ViewRunner retrieves state information from the Cisco 6100 Series system and displays this information on the Module Properties dialog box Status tab. You can click Refresh on the Status tab to refresh the current state information.
The data is not real time. For example, if the Usage state of a particular module is Idle, and you click Refresh before beginning the process of removing that modem from the pool, you might disconnect a subscriber who accessed that modem just after you clicked Refresh.
The following sections describe the states that are detected by ViewRunner:
Table 3-1 describes each Usage state that can appear on the Status tab.
| Display | Description |
|---|---|
Busy | The entity is 100 percent in use. This state is normally associated with ports. For a module to be Busy, all of its subordinate ports must be busy. |
Idle | The entity is not in use. |
Active | The entity is in use, but has more capacity. For example, a module is Active when one, but not all, of its subordinate ports are busy. The Active state provides a quick check for any subordinate resources that are in use. Active states apply to modules, logical pools, chassis, and nodes. |
Table 3-2 describes each Slot state on the Status tab.
| Display | Description |
|---|---|
Empty Unprovisioned | Neither a module nor a module-managed object exists. |
Empty Provisioned | A module-managed object exists. However, the system has not detected the presence of the module since power up or since you previously deleted the managed module that was configured for that slot. |
Filled Invalid | The module that is detected is invalid for the slot. |
In addition to the Slot state value, ViewRunner also displays (just below the Slot state on the Status tab) the type of module it has discovered. For ATU-C modules, you see "Direct Connect" or "Digital Off-Hook" next to the module name. Which of these descriptions you see depend on how you have jumpered the module. Refer to the appropriate Cisco 6100 with NI-1 installation guide for more information about CAP ATU-C jumpering.
|
Note ViewRunner DOH configurations support CAP ATU-C modules only. |
The system controller module monitors states when a particular port or connection is available. For example, the system controller module does not send a connection request to a modem that has a Service state of Out of Service.
Table 3-3 describes each Service state.
| Display | Description |
|---|---|
In Service | The resource has all necessary permission and can provide service when requested. |
Out of Service | One or more assigned or derived attributes of the resource prevent it from providing service. |
If the Service state of a supporting entity is Out of Service, that state propagates downward through the Cisco 6100 Series system containment hierarchy to all subordinate entities. The Subordinate Service state depends on the Service state of its supporting entity.
A supporting entity is defined as containing subordinate entities. For example, a module is a supporting entity to its ports, and conversely a port is a subordinate entity to a module. The states of all entities change depending on how the state of the supporting entity is set.
The Service state of the Cisco 6100 Series system describes whether an entity is able to provide service. This state is derived from a combination of Administrative, Operational, and Supporting Entity Service states.
The Supporting Entity Service state is a key aspect of the Service state. The Supporting Entity Service state causes an Out-of-Service state to propagate downward through the Cisco 6100 Series system object containment hierarchy to all subordinate entities.
When the Service state of an entity transitions Out of Service, the service states of all subordinate resources are also automatically transitioned to Out of Service, according to the Service state of their supporting entity. The Cisco 6100 Series system tears down active calls for entities that transition to Out of Service and does not attempt to use them for new calls.
The Supporting Entity Service state is the service state of the supporting entity in the containment hierarchy. This state represents the administrative permissions and the operational capabilities of all the higher-level entities that depend on this resource. If the Supporting Entity Service state is Out of Service, the Subordinate Entity Service state is also Out of Service.
|
Note Currently, a module is the only valid supporting entity in the system. Therefore, Port Status tabs display the module Service state as a component of the port Service state. Supporting Entity is a derived state. |
Table 3-4 describe each Supporting Entity Service state.
| Display | Description |
|---|---|
In Service | All resources that this resource depends on can provide service when requested. |
Out of Service | A resource that this resource depends on cannot provide service. |
The Administrative state serves two purposes. It enables you to lock an entity to prevent it from providing service. This state also provides a mechanism for triggering state changes in the Cisco 6100 Series system configuration.
The Status tab displays the Administrative state for an entity. You can use the Configuration tab to display and modify the Administrative state for an entity. To access the Administrative state, open the Configuration tab on the Module Properties dialog box for any entity. The Administrative state is either Locked or Unlocked. When an entity is Locked, it cannot actively participate in node operation.
|
Note A quick way to determine whether a module is Locked or Unlocked is to look for the lock icon on the GUI Chassis View of the module. If the icon is a lock with a key below it, some but not all of the module ports are Locked. If the lock icon is a closed lock, the module and all of its ports are Locked. If the lock icon is open or unlocked, the module and all of its ports are Unlocked. Examples of the lock icon are shown in Figure 3-4. |
When you unlock an entity, you give it administrative permission to perform its function. Table 3-5 describes the Administrative states.
| Tab Display | Description |
|---|---|
Locked | Entity does not have administrative permission to perform its function. |
Unlocked | Entity has administrative permission to perform its function. |
An Administrative state is a component of the Service state. If the Administrative state is Locked, the Service state becomes Out of Service.
When an administrator locks an entity, the lock ripples downward through the Cisco 6100 Series system containment hierarchy to all of its subordinate resources. As a result, the Service state for every subordinate resource changes to Out of Service.
In summary:
ViewRunner does not apply configuration changes to an entity until after you have set its Administrative state to Locked. You can enter configuration changes into the entity configuration tab while the entity is Unlocked. However, ViewRunner does not apply these changes until the Administrative state of the entity is subsequently Locked and Unlocked again.
ViewRunner requires you to carefully evaluate whether to administratively lock an entity. Locking an entity takes it Out of Service and terminates any active calls.
ViewRunner requires the highest-level entity to be administratively locked before you execute an action that results in ViewRunner locking subordinate entities. This restriction guarantees that possible configuration changes are not sent to an In-Service entity without first forcing a transition to the Unlocked state.
|
Note Currently, to change configurations requires terminating a call or continuing to monitor ViewRunner to see when the connection terminates. When you lock an entity, ViewRunner presents a confirmation dialog box if the entity or any of its subordinates are involved in an active ADSL or SDSL connection. |
ViewRunner requires an entity to be locked before you can modify or delete the service-affecting configuration parameters of the entity. Service-affecting parameters are any parameters that alter the service (DOH connection or PVC) that you have provided to a subscriber. Examples of service-affecting parameters include bit rate configuration, Administrative state, and PVC configuration.
Nonservice-affecting configuration parameters do not require an unlock transition to take effect in the Cisco 6100 Series system. Nonservice-affecting parameters include entity names, such as Subscriber ID, and other system configuration parameters that are not directly involved with services. You can use the ViewRunner dialog boxes to modify these non service-affecting parameters while they are unlocked, by clicking OK or Apply after you specify the modifications.
When you click OK or Apply, ViewRunner determines the configuration modifications that you have requested. If you have only modified nonservice-affecting data, ViewRunner proceeds to modify the Administrative state of the entity.
In some instances, ViewRunner sends lock messages to the Cisco 6100 Series system without an explicit state change. ViewRunner sends these messages for the sake of convenience, which saves you from having to lock entities when locking is clearly required before you can take further action.
ViewRunner performs automatic locks under the following conditions:
|
Note In releases prior to Release 2.0, you had to lock each LIM and port to complete the deletion of a chassis. |
|
Note The preceding user interface rule is required to prevent the Cisco 6100 Series system from making DOH connection attempts on unassigned LIM ports. You must set LIM ports to Locked unless they are assigned to a pool. Therefore, ViewRunner disables the LIM port unlocking until you assign the port to a pool. Conversely, ViewRunner prevents LIM port release from a pool unless the port is Locked. |
Operational states specify whether the resource is in an alarmed condition. You cannot change operational states; they display only in the Port Status tab, in a read-only field.
Table 3-6 describes each ViewRunner Operational state.
|
Note Administrative and Operational state changes function independently from each other. |
| Display | Description |
|---|---|
Enabled | The resource is not in an alarm state. The resource is partially or fully operable and can provide service. |
Disabled | The resource is currently in an alarm state because ViewRunner has detected a fault. The resource is inoperable and unable to provide service. |
|
Note The Operational state is a component of an entity Service state. Therefore, when the Operational state of an entity is Disabled, every subordinate resource has an Out-of-Service state. |
The Operational state signals that ViewRunner has detected a fault for a resource. The Operational state provides details of specific alarms or the severity of an alarm. You can view specific alarms directly below the Operational State field in the Service State Details group box. This box displays all current alarms for the resource, along with the severity of each alarm.
Operational state alarms also display on the module ejector tabs on the Chassis View. The alarms and the corresponding colors are listed in order of severity in Table 3-7.
| Color | State |
|---|---|
Blue | Provisioned |
Red | Critical Alarm |
Orange | Major Alarm |
Yellow | Minor Alarm |
Green | No Alarms |
|
Note The Operational state becomes disabled when any alarms occur and forces the service state of a resource to Out of Service. |
Posted: Tue Feb 15 06:50:20 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.