CISCO-RF-MIB

TEXTUAL-CONVENTION

Administrative commands to invoke in the RF subsystem. noAction - no action (do nothing) reloadPeer - reset the redundant peer unit reloadShelf - reset the entire shelf switchActivity - safely SWACT to peer unit and go standby forceSwitchActivity - switch activity; ignoring pre-conditions, system warnings and safety checks. When the value is set to 'noAction' no operation is performed. When read, the value 'noAction' is always returned.

TEXTUAL-CONVENTION

The status of a RF client before, during and after switchover. noStatus - No status information is available for this client. clientNotRedundant - Client is active. But there is no redundancy to this client. This could be because there is no standby or the client cannot claim that the standby client can take over without losing data or traffic during a switchover. clientRedundancyInProgress - The client is trying to sync all data to standby and achieve redundancy. clientRedundant - The client is redundant and ready for switchover. The client can safely claim that there is no data or traffic loss if there is a switchover.

TEXTUAL-CONVENTION

ISSU state represents the current system state. unset - unset state; if the system is booted from tftp or from ROMMON such that the image is not the first in BOOT init - init state; the first ISSU state that the system will move to after the unset state, when the ISSU process has just been kicked off. The first CLI that is executed to make this happen is the loadversion CLI. loadVersion - Once the loadversion CLI has been executed, the state of the system is changed to reflect this, and this state is called the loadVersion state. The boot variable on the Standby is updated to point to the new image that the Standby needs to load and then it is reset. runVersion - runVersion state; When the system is in the loadversion state, the Active is running the old image and the Standby is running the new image. When the runversion CLI is executed, a switchover occurs, and the Standby running the new image takes over as the Active. The state of the system at this stage is updated to runversion. commitVersion - in the runversion state, the Active is running the new image, and the Standby is running the old image. When the user is satisfied with the functioning of the system, they execute the commitversion CLI, which will prepend the boot variable on the Standby with the new image, and then the Standby is reset. After this, the Standby comes up with the new image, and the state of the system is updated to reflect the commitVersion state.

TEXTUAL-CONVENTION

ISSU state represents the current system state. init - This state represents the initial state of the system. The ISSU process is not running at this stage. The only CLI for ISSU process that can be executed in this state is the loadversion CLI. systemReset - If a system reset occurs, or the abortversion CLI is executed, the state of the system is pushed to this state. loadVersion - When the Standby signs in after the loadversion CLI is executed, the state of the system is changed to loadVersion. loadVersionSwitchover - If a switchover occurs in the loadVersion state, by the user, or because the Active crashes, the new state of the system will be loadVersionSwitchover. It is analogous to the runVersion state, except that the runversion CLI was not executed. runVersion - When the Standby signs in after executing the runversion CLI, the state of the system is changed to runVersion. runVersionSwitchover - if a switchover occurs while the system is in the runVersion state, the new state will be called runVersionSwitchover. It is analogous to the loadVersion state. commitVersion - When the Standby signs in after the commitversion CLI is executed, the state of the system is changed to commitVersion.

TEXTUAL-CONVENTION

The characterization of the redundancy subsystem. nonRedundant - the system is not redundant. staticLoadShareNonRedundant - the system is *not* redundant but is load sharing. The load sharing is *not* based on operational load (i.e. number of calls, etc). dynamicLoadShareNonRedundant - the system is *not* redundant but is load sharing. Load sharing is based on operational load. staticLoadShareRedundant - the system is redundant and is load sharing. The load sharing is *not* based on operational load. dynamicLoadShareRedundant - the system is redundant and is load sharing. Load sharing is based on operational load. coldStandbyRedundant - the system is redundant but the redundant peer unit is not fully initialized and is not able to retain established calls. warmStandbyRedundant - the system is redundant and the redundant peer unit is immediately able to handle new calls. The redundant unit is unable to retain established calls. hotStandbyRedundant - the system is redundant and the redundant peer unit is able to 'instantaneously' retain established calls and immediately able to handle new calls.

TEXTUAL-CONVENTION

The current state of the RF subsystem. notKnown - state is unknown disabled - RF is not operational on this unit initialization - establish necessary system services negotiation - peer unit discovery and negotiation standbyCold - client notification on standby unit *standbyColdConfig - standby configuration is updated from active configuration *standbyColdFileSys - standby file system (FS) is updated from the active FS *standbyColdBulk - clients sync data from active to standby standbyHot - incremental client data sync continues. This unit is ready to take over activity. activeFast - call maintenance efforts during a SWACT activeDrain - client clean-up phase activePreconfig - unit is active but has not read its configuration activePostconfig - unit is active and is post-processing its configuration active - unit is active and processing calls activeExtraload - unit is active and processing calls for all feature boards in the system activeHandback - unit is active, processing calls and is in the process of handing some resources to the other unit in the system * Sub-state of 'standbyCold'

TEXTUAL-CONVENTION

Reason codes for the switch of activity from an active redundant unit to its standby peer unit. unsupported - the 'reason code' is an unsupported feature none - no SWACT has occurred notKnown - reason is unknown userInitiated - a safe, manual SWACT was initiated by user userForced - a manual SWACT was forced by user; ignoring pre-conditions, warnings and safety checks activeUnitFailed - active unit failure caused an auto SWACT activeUnitRemoved - active unit removal caused an auto SWACT activeGWdown - SWACT due to active losing gateway connectivity activeRMIportdown - SWACT due to RMI port going down on active

TEXTUAL-CONVENTION

A unique identifier for Active/Standby unit.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-TYPE

A unique identifier for this redundant unit. This identifier is implementation-specific but the method for selecting the id must remain consistent throughout the redundant system. Some example identifiers include: slot id, physical or logical entity id, or a unique id assigned internally by the RF subsystem.

OBJECT-TYPE

The current state of RF on this unit.

OBJECT-TYPE

A unique identifier for the redundant peer unit. This identifier is implementation-specific but the method for selecting the id must remain consistent throughout the redundant system. Some example identifiers include: slot id, physical or logical entity id, or a unique id assigned internally by the RF subsystem.

OBJECT-TYPE

The current state of RF on the peer unit.

OBJECT-TYPE

Indicates whether this is the primary redundant unit or not. If this unit is the primary unit, this object is true. If this unit is the secondary unit, this object is false. Note that the terms 'primary/secondary' are not synonymous with the terms 'active/standby'. At any given time, the primary unit may be the active unit, or the primary unit may be the standby unit. Likewise, the secondary unit, at any given time, may be the active unit, or the secondary unit may be the standby unit. The primary unit is given a higher priority or precedence over the secondary unit. In a race condition (usually at initialization time) or any situation where the redundant units are unable to successfully negotiate activity between themselves, the primary unit will always become the active unit and the secondary unit will fall back to standby. Only one redundant unit can be the primary unit at any given time. The algorithm for determining the primary unit is system dependent, such as 'the redundant unit with the lower numeric unit id is always the primary unit.'

OBJECT-TYPE

Indicates whether the redundant peer unit has been detected or not. If the redundant peer unit is detected, this object is true. If the redundant peer unit is not detected, this object is false.

OBJECT-TYPE

Indicates whether a manual switch of activity is permitted. If a manual switch of activity is allowed, this object is false. If a manual switch of activity is not allowed, this object is true. Note that the value of this object is the inverse of the status of manual SWACTs. This object does not indicate whether a switch of activity is or has occurred. This object only indicates if the user-controllable capability is enabled or not. A switch of activity is the event in which the standby redundant unit becomes active and the previously active unit becomes standby.

OBJECT-TYPE

The reason for the last switch of activity.

OBJECT-TYPE

The value of sysUpTime when the primary redundant unit took over as active. The value of this object will be 0 till the first switchover.

OBJECT-TYPE

The value of sysUpTime when the peer redundant unit entered the standbyHot state. The value will be 0 on system initialization.

OBJECT-TYPE

This table containing a list of redundancy modes that can be supported on the device.

OBJECT-TYPE

An entry containing the device implementation specific terminology associated with the redundancy mode that can be supported on the device.

OBJECT-TYPE

The redundancy mode that can be supported on the device.

OBJECT-TYPE

The description of the device implementation specific terminology associated with its supported redundancy mode.

OBJECT-TYPE

The current ISSU state of the system.

OBJECT-TYPE

The current ISSU state of the system.

OBJECT-TYPE

The IOS version from with the user is upgrading

OBJECT-TYPE

The IOS version to with the user is upgrading

OBJECT-IDENTITY

OBJECT-TYPE

Indicates whether redundant units may communicate synchronization messages with each other. If communication is not permitted, this object is set to true. If communication is permitted, this object is set to false. In split mode (true), the active unit will not communicate with the standby unit. The standby unit progression will not occur. When split mode is disabled (false), the standby unit is reset to recover. Split mode (true) is useful for maintenance operations.

OBJECT-TYPE

On platforms that support keep-alives, the keep-alive threshold value designates the number of lost keep-alives tolerated before a failure condition is declared. If this occurs, a SWACT notification is sent. On platforms that do not support keep-alives, this object has no purpose or effect.

OBJECT-TYPE

The minimum acceptable value for the cRFCfgKeepaliveThresh object.

OBJECT-TYPE

The maximum acceptable value for the cRFCfgKeepaliveThresh object.

OBJECT-TYPE

On platforms that support keep-alives, the keep-alive timer value is used to guard against lost keep-alives. The RF subsystem expects to receive a keep-alive within this period. If a keep-alive is not received within this time period, a SWACT notification is sent. On platforms that do not support keep-alives, this object has no purpose or effect.

OBJECT-TYPE

The minimum acceptable value for the cRFCfgKeepaliveTimer object.

OBJECT-TYPE

The maximum acceptable value for the cRFCfgKeepaliveTimer object.

OBJECT-TYPE

Note that the term 'notification' here refers to an RF notification and not an SNMP notification. As the standby unit progresses to the 'standbyHot' state, asynchronous messages are sent from the active unit to the standby unit which must then be acknowledged by the standby unit. If the active unit receives the acknowledgement during the time period specified by this object, progression proceeds as normal. If the timer expires and an acknowledgement was not received by the active unit, a switch of activity occurs.

OBJECT-TYPE

The minimum acceptable value for the cRFCfgNotifTimer object.

OBJECT-TYPE

The maximum acceptable value for the cRFCfgNotifTimer object.

OBJECT-TYPE

This variable is set to invoke RF subsystem action commands. The commands are useful for maintenance and software upgrade activities.

OBJECT-TYPE

Allows enabling/disabling of RF subsystem notifications.

OBJECT-TYPE

Indicates whether redundant units may communicate synchronization messages with each other. If communication is not permitted, this object is set to 'true'. If communication is permitted, this object is set to 'false'. If the value of this object is 'true', the redundant system is considered to be in a maintenance mode of operation. If the value of this object is 'false', the redundant system is considered to be in a normal (non-maintenance) mode of operation. In maintenance mode (true), the active unit will not communicate with the standby unit. The standby unit progression will not occur. When maintenance mode is disabled (false), the standby unit is reset to recover. Maintenance mode (true) is useful for maintenance-type operations.

OBJECT-TYPE

Indicates the redundancy mode configured on the device.

OBJECT-TYPE

Further clarifies or describes the redundancy mode indicated by cRFCfgRedundancyMode. Implementation-specific terminology associated with the current redundancy mode may be presented here.

OBJECT-TYPE

Indicate the operational redundancy mode of the device.

OBJECT-IDENTITY

OBJECT-TYPE

Maximum number of entries permissible in the history table. A value of 0 will result in no history being maintained.

OBJECT-TYPE

A table that tracks the history of all switchovers that have occurred since system initialization. The maximum number of entries permissible in this table is defined by cRFHistoryTableMaxLength. When the number of entries in the table reaches the maximum limit, the next entry would replace the oldest existing entry in the table.

OBJECT-TYPE

The entries in this table contain the switchover information. Each entry in the table is indexed by cRFHistorySwitchOverIndex. The index wraps around to 1 after reaching the maximum value.

OBJECT-TYPE

A monotonically increasing integer for the purpose of indexing history table. After reaching maximum value, it wraps around to 1.

OBJECT-TYPE

Indicates the primary redundant unit that went down.

OBJECT-TYPE

Indicates the secondary redundant unit that took over as active.

OBJECT-TYPE

Indicates the reason for the switchover.

OBJECT-TYPE

Indicates the Date & Time when switchover occurred.

OBJECT-TYPE

Indicates the number of system cold starts. This includes the number of system cold starts due to switchover failure and the number of manual restarts.

OBJECT-TYPE

Indicates the cumulative time that a standby redundant unit has been available since last system initialization.

OBJECT-IDENTITY

OBJECT-TYPE

This table contains a list of RF clients that are registered on the device. RF clients are applications that have registered with the Redundancy Facility (RF) to receive RF events and notifications. The purpose of RF clients is to synchronize any relevant data with the standby unit.

OBJECT-TYPE

An entry containing information on various clients registered with the Redundancy Facility (RF). Entries in this table are always created by the system. An entry is created in this table when a redundancy aware application registers with the Redundancy Facility. The entry is destroyed when that application deregisters from the Redundancy Facility.

OBJECT-TYPE

A unique identifier for the client which registered with the Redundancy Facility.

OBJECT-TYPE

The description of the client which has registered with the Redundancy Facility.

OBJECT-TYPE

The sequence number of the client. The system assigns the sequence numbers based on the order of registration of the Redundancy Facility clients. This is used for deciding order of RF events sent to clients.

OBJECT-TYPE

Time taken for this client to become Redundant. This value is meaningful when the value of cRFStatusRFClientStatus is not 'noStatus'.

OBJECT-TYPE

This object provides the status of the Redundancy Facility client.

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY

OBJECT-IDENTITY