|
|
This chapter outlines the state model followed by C7kM, and contains the following sections:
It is important for the systems integrator to have an understanding of the state model as it provides information regarding the current status of the hardware. The information available from the object state contains the current management state of the hardware and the operational state of the hardware. The validity of certain operations can also be determined from the current object state.
In order to obtain the state of an object, the attribute: virtual:CommonEM-MIB.controllerState should be retrieved against the object. It will contain a string value representing the current state of the object.
As already described, the Chassis class of objects models the physical chassis hardware. The chassis state machine then is used to represent the current status of the physical device to the user and implement behavior appropriate for different states. This section outlines each state in the chassis state machine and describes its relation to the state of the physical device.
States which are modelled for the chassis are as follows:
The normal state represents the basic operational state of the chassis. The chassis is contactable, providing service and is manageable from C7kM.
In the normal state a task runs every 60 seconds and polls for the last change time of the chassis and its chassis type.
If there is a change in the ChassisType between polls, the task will send the stimulus "mismatch" to the C7kM controller which then transitions the object to the mismatched state.
If there is a change in the last change time between polls, the configuration on the device may have changed. As a result of this, the stimulus "change" will be sent. This will transition the object into the discovery state. This will cause the inventory for the object to be updated.
There is also a task associated with the normal state which registers synchronization requests. The run interval is 1800 seconds and every time a poll is received, the task will request a synchronization against the chassis for which the poll returned. The actual type of synchronization that is requested is:
This synchronization type means that the synchronization framework will check whether a synchronization is required before sending out the context.
The normal state has OSI mappings of:
When chassis are deployed in C7kM, they will initially be in the decommissioned state. This represents the fact that the chassis is unmanaged and that C7kM has no information about the chassis connectivity, configuration etc. If a chassis is in the decommissioned state, management operations are logically suspended until the chassis is transitioned to a managed state through rediscovery of the inventory. Chassis may be moved to the decommissioned state at any time if the user no longer wishes to actively manage it.
The decommission state has no periodic behavior. It simply performs some cleanup on the chassis object and ripples the state change down to its child objects. The task sets the performance logging flag to off and the local copy of the chassis last change time to 0 as well as the synchronization flag on the chassis. The task stimulates all immediate children objects with the stimulus "decommission".
The decommissioned state has OSI mappings of:
The discovery state is the state which the chassis enters when it is retrieving inventory information from the chassis and deploying objects in C7kM to represent all of the modules, interfaces etc.
On entering the discovery state, the task performs a get for the local and snmp versions of the OID for the chassis. If these values do not match, the chassis is stimulated to the mismatch state ("mismatch"). If the SNMP value is not returned, the chassis is stimulated to the discovery lost comms state ("lostcomms"). If the two values match, or there is no local value present, the task will initiate a sub chassis discovery to find all of the modules and interfaces under the chassis. This is done by performing a set on the setDiscovery attribute.
If the discovery does not take place i.e. if the object is transitioned to mismatched/discoverylostcomms, an alarm is raised against the chassis to alert the user. The value of the commission failed attribute is also set with a string value describing what went wrong.
The discovery state has OSI mappings of:
The mismatched state represents the scenario when an object in C7kM does not match the physical object in the network. This may occur when a pre-deployed object is discovered and it is a different type. This can also occur if the type of a chassis changes between polls of the normal task.
C7kM will raise a mismatch alarm on entering this state.
On entering the mismatched state the only behavior is to stimulate the children with a stimulus of "mismatch."
The mismatched state has OSI mappings of:
The lost comms state represents the scenario where the management station has lost connectivity with the device. The way this manifests in C7kM is that no values are returned for get commands issued against the hardware. This could be due to network outage or hardware problems on the device. This state waits until connectivity returns by periodically checking for a response.
An alarm of class ciscoChassisLostCommsAlarm and with severity major will be raised on entering this state.
This task has a run interval of 60 seconds, polling for ChassisType and chassis last change time. On entering this state the stimulus "lostcomms" will be sent to the immediate children of the chassis. Each polling interval, the task will check whether the two polled attributes have been returned with valid values. If so, the object will be stimulated with the "regainedcomms" stimulus.
On leaving the group, a synchronization request will be raised containing two synchronizations. The first being low priority, intelligent configuration sync. The second being low priority, forced alarm synchronization.
The lost comms state has OSI mappings of:
The performance gathering state (performanceloggingon) at the chassis level simply represents the fact that performance logging has been turned on at the global level for that chassis. No performance data is actually collected by the chassis tasks, but putting a chassis into this state will attempt to move all of the child objects into a performance gathering state.
The behavior in the performance logging state is the same as that of the normal state.
The performance gathering state has OSI mappings of:
The discovery lost comms state is used to represent when an error or a loss of communication with the device has occurred during the sub-chassis discovery process. This will usually require some action from the user to rectify the problem.
An alarm of class ciscoChassisDiscoveryLostCommsAlarm and with severity major will be raised on entering this state.
This task has a run interval of 60 seconds, polling for the sysobjectID of the chassis.
The task simply stimulates the chassis with the "regainedcomms" stimulus on receipt of a successful poll so that the discovery can make another attempt.
The lost comms state has OSI mappings of:
The chassis is stimulated into a download state when it is downloading a new IOS image. This will happen through the IOS image download action. If a reset is requested after the download, the chassis will enter the reset state, otherwise it will commission.
This task has a run interval of 60 seconds, and operates in the same manner as the CiscoChassisNormalTask.
The discovery lost comms state has OSI mappings of:
If the user opted to perform a reset of the hardware after the IOS image download, the chassis will be stimulated into the reset state. This task will periodically check connectivity with the device to see when it has reinitialized itself after the reset.
This task has a run interval of 60 seconds, and polls for the chassis type and last change time of the chassis.
On entering the state, the chassis will ripple the "reset" stimulus down to all child modules/interfaces (down 2 levels for modules & 3 for interfaces). On the result of each poll, if the attributes come back with values, a writemem is performed on the chassis (using the writemem command attribute) and then a "resetfinished" stimulus is sent to the chassis which will cause it to recommission.
The reset state has OSI mappings of:
The synchronizing state is used to represent the scenario where the chassis is currently synchronizing. This state is tied in to the synchronization framework.
This is a non polling task and always has an operation on controller startup. On startup, the controller sends the "synccommission" stimulus to the objects that are in the synchronizing state. This will prevent objects from getting stuck in commissioning state if C7kM is stopped.
The reset state has OSI mappings of:
As already described, the module class of objects models the physical cards which are present in the chassis. The module state machine then is used to represent the current status of the physical cards to the user and implement behavior appropriate for different states. This section outlines each state in the module state machine and describes its relation to the state of the physical device.
States modelled for the module are as follows:
The normal state represents the basic operational state of a card. The card is contactable, providing service and is manageable from a C7kM perspective.
In this state objects will be polled every 300 seconds for the operational status of the module.
When a module enters the normal state, the performance logging flag for that attribute will be turned off (0).
On the result of each poll, the values of snmp operstatus and serial number will be returned. If the returned value does not match the value from previous polls, the module will be sent the stimulus "commission" so that the module may redetermine the state it should go to.
If any of the polls failed, the module will be given the stimulus "lostcomms".
If the values match those cached, the module will remain in the normal state and continue polling.
The normal state has OSI mappings of:
The downloading state represents the fact that the chassis which is the parent of this module is currently performing an IOS image download. If a reset was requested by the user, the module will then transition to the reset state until the chassis comes back online. This state flow is driven from the chassis level.
The download state has OSI mappings of:
The reset state represents the time when the modules are unreachable due to a restart of the hardware occurring. This will only happen after a download has occurred where the user requested a reset afterwards. This state flow is driven from the chassis level.
In this state the module will be polled every 300 seconds to determine connectivity. If connectivity is detected, the task will stimulate the module with the "resetfinished" stimulus causing it to recommission.
The reset state has OSI mappings of:
The errored state represents the fact that an error is apparent on the module as reported through SNMP. This is based on the operational status of the module.
In this state the module will be polled every 300 seconds to see if its status has changed since the last poll. If not then the module will be re-commissioned by issuing the "commission" stimulus.
The errored state has OSI mappings of:
The decommissioned state represents the fact that the module is not currently being managed by C7kM. No data is collected against the module and no management functions should be performed.
On entering the decommissioned state, the task will set the performance logging flag to "off" and set the module managed flag to "no". The task also stimulates the children of the module with the stimulus "decommission."
The decommissioned state has OSI mappings of:
The commissioning state at the module level occurs when the module is determining which state it should use to represent the current state. Generally all state changes should go through commissioning as it is the place which holds all of the logic for state derivation.
If the module has the same IP address as its parent, the value of CiscoModule-MIB.sameIP will be set to "yes" if not it will be set to "no".
On entering the commission state the task will issue a get on the following attributes:
virtual:CiscoCommon-Mib.objectManaged
The logic of the processing follows:
if the local and cached copies of the module vendor type attribute do not match, the module is sent the "mismatch" stimulus to show that the physical card does not match the C7kM modelled one.
If the snmp attribute for serial number comes back with a null value, the object will be sent the stimulus "lostcomms".
If a valid values are returned from the device for operStatus and serialNumber, the data based local copies will be updated to reflect the new values.
If the operational status is indicated to check the performance logging flag, the state will be driven by the performance logging flag. If the value is "on" the module will be moved to the performance logging state otherwise it will be moved to the normal state.
Those objects which were stimulated to normal will have their children sent the "commission" stimulus.
Modules leaving the state will have their children stimulated with the "interfacediscoveryfinished" stimulus that will cause any sub-modules interfaces to commission and determine state.
The commissioning state has OSI mappings of:
The discovery state represents the fact that C7kM is attempting to discover the inventory which is supported by this module. This will usually involve determining which interfaces etc. are apparent on the physical card.
On entering this task, the state of the modules parent chassis is checked as we will not allow discovery of a module if its parent chassis is decommissioned. In this case the module will be stimulated with the "decommission" stimulus, the reason for failure attribute will be set to "Failed - Commissioning disallowed; chassis is decommissioned.", and an alarm of class ciscoModuleCommissionFailAlarm will be raised.
If the ChassisType attribute of the module is "Entity", then the children of the objects will be sent the "commission" stimulus and the module itself will be sent the discoveryfinished stimulus as sub-module discovery for entity chassis takes place as part of chassis discovery.
If the task was unable to find the parent state it sets the chassisIdValue attribute against the module. This should only happen in a case of data migration. Once this has been done, a new get is sent out for the parent state and the process starts again.
Eventually all of the objects which are available will be established and the process can continue. This will perform a set on the setdiscovery attribute against the module (ciscoModuleCon:CiscoCommon-MIB.SetDiscovery). This will cause the module discovery to start.
The discovery state has OSI mappings of:
The lost communications state represents the scenario where C7kM is unable to contact a physical module. This may be because connection to the containing chassis has degraded or that requests related to the specific card are not coming back with valid values. This may mean that the card has been removed from chassis. Objects in this state will not poll to try and re-establish communications.
This task has no functionality other than stimulating its children with the "regainedcomms" stimulus on leaving the group.
The lostcomms state has OSI mappings of:
The performance gathering state represents that the module is operationally in the same situation as in the normal state but that performance data is being recorded for the module.
This task polls for and caches the following attribute data every 300 seconds.
SNMP:OLD-CISCO-CPU-MIB.busyPer
SNMP:OLD-CISCO-CPU-MIB.avgBusy1
SNMP:OLD-CISCO-CPU-MIB.avgBusy5
The state also has behavior similar to that of the normal state.
The performanceloggingon state has OSI mappings of:
This state represents the fact that the module has lost communications with the device during the discovery process.
Objects in this state will poll for connectivity.
The discoverylostcomms state has OSI mappings of:
The module mismatch state represents two separate scenarios. The first is when, in an entity chassis the operstatus of a particular module is being reported as mismatch (the physical card does not match that which was preprovisioned. The second scenario is when a module is manually deployed into C7kM and it does not match the card which is discovered in the physical chassis.
Objects in this state will be polled every 300 seconds to see if their operational status has changed. If so, they will be sent the stimulus "change".
On entering the state, the task will propagate the "mismatch" stimulus to its children.
The mismatched state has OSI mappings of:
As already described, the interface objects represent the actual interfaces which are on the line cards. The interface state machine then is used to represent the current status of the physical interfaces to the user and implement behavior appropriate for different states. This section outlines each state in the default interface state machine and describes its relation to the state of the physical device.
States modelled for the interface are as follows:
The normal state represents the basic operational state of an interface. The interface is operational, capable of transferring data and is manageable from a C7kM perspective.
This task will set the performance logging flag to 0 for all objects which enter the state. The actual attribute which is set is: virtual:CiscoCommon-MIB.performancelogging. This is the only functionality implemented by the task.
The normal state has OSI mappings of:
The downloading state represents the fact that the chassis which is the parent of this interface is currently performing an IOS image download. If a reset was requested by the user, the interface will then transition to the reset state until the chassis comes back online.
The download state has OSI mappings of:
The reset state represents the time when the interfaces are unreachable due to a restart of the hardware occurring. This will only happen after a download has occurred where the user requested a reset afterwards.
The reset state has OSI mappings of:
The errored state represents the fact that an error is apparent on the interfaces as reported through SNMP. This is based on the operational status of the interface.
Objects in this state will be polled every 300 seconds to retrieve the operational status of the interface. On the result of each poll, the operstatus will be checked to see if the value is equal to 1. If the operstatus check comes back with 1. The performance logging flag will be checked to see whether the interface should move to normal or performance logging state next. If the performance logging flag is not retrieved, the interface will stay in errored.
The errored state has OSI mappings of:
The decommissioned state represents the fact that the interface is not currently being managed by Cisco EMF. No data is collected against the interface and no management functions should be performed.
On entering the decommissioned state, the task will set the performance logging flag to 0 on the interface. The task also stimulates the children of the interface with the stimulus "decommission".
The decommissioned state has OSI mappings of:
The commissioning state at the interface level occurs when the interface is determining which state it should use to represent the current state. Generally all state changes should go through commissioning as it is the place which holds all of the logic for state derivation. Much of interface state derivation depends on the state of the parent module.
On entering this state, the parent interface state is determined. The interface will change state based on the parent module state in the following manner:
If the parent module is in normal or performanceloggingon states the task will get the operstatus and performance logging flags against the interface. If the perf flag is not set, the value will be initialized to 0. If no value is returned for the operstatus of the interface, it will be sent the stimulus "lostcommspoll". If a value is retrieved which represents an operational status of up (1), the stimulus sent will be determined by the perf logging flag: 0 - normal, 1 - performanceon. If the operstatus is not up, the interface will be sent the "error" stimulus.
The commissioning state has OSI mappings of:
The discovery state represents the fact that C7kM is attempting to discover the inventory of the parent chassis. At the interface level this basically just mirrors the state of the parents and waits to be told to commission.
The discovery state has OSI mappings of:
The lost communications state represents the scenario where C7kM is unable to get attributes against a physical interface. This may be because connection to the containing chassis has degraded or that requests related to the specific interface are not coming back with valid values. This may mean that the card has been removed from chassis. Objects in this state will not poll to try and re-establish.
The lostcomms state has OSI mappings of:
The performance gathering state represents that the interface is operationally in the same situation as in the normal state but that performance data is being recorded.
Objects in this state will be polled for their operational status. If the attribute comes back with a value other than 1, the interface will be stimulated with the stimulus "error". Otherwise no stimulus is sent.
This task polls for the following attrs:
On entering the task the performance logging flag on the interface is set to 1.
The actual attributes which are used to calculate bandwidth utilization are configured in a file which is read in by the task. The attributes that are used by the generic IF class are:
The attributes which are set as a result of the calculation are:
The task is also configured to have a bandwidth multiplier of 0.000008. Both transmit and received bandwidth utilization are calculated in a similar manner. The previous values are cached so that the next poll may calculate the utilization using the difference across the polling interval. The algorithm uses this function:
utilization = ((polled in/out octets * multiplier) - (cached in/out octets * multiplier)) * 100
/(current time - cached time) * if speed
the results of this calculation are then cached for performance logging.
The performanceloggingon state has OSI mappings of:
This state represents the fact that the interface has lost communications with the device during the discovery process.
The discoverylostcomms state has OSI mappings of:
The interface mismatch state represents interfaces underneath a mismatched module.
The mismatched state has OSI mappings of:
The Invalid state relates to the operstatus of invalid which is returned from the entity mib. Meaning that the parent card is either unrecognized or recognized but not supported.
The invalid state has OSI mappings of:
The preprovisioned state represents a card operstatus of provisioned, again from the entity mib. This means that there is no physical card in the device but that it has been configured to receive a specific type.
The preprovisioned state has OSI mappings of:
Posted: Thu Oct 2 12:28:50 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.