-- MIB file created 21-Jun-2007 17:17:58, by
--   SMICng version 2.2.11-beta(PRO)(Solaris), January 20, 2001. Enterprise key cisco.com

CISCO-ENTITY-REDUNDANCY-TC-MIB DEFINITIONS ::= BEGIN

-- From file: "CISCO-ENTITY-REDUNDANCY-TC-MIB.my"
-- Compile options "4 7 F H N O W 03 06 0B 0G 0N 0T"

IMPORTS
    ciscoMgmt
            FROM CISCO-SMI;

ciscoEntityRedunTcMIB OBJECT IDENTIFIER ::= { ciscoMgmt 494 }
-- MODULE-IDENTITY
--  LastUpdated
--    200510010000Z
--  OrgName
--    Cisco Systems, Inc.
--  ContactInfo
--    Cisco Systems, Inc.
--     Customer Service
--     Postal: 170 W. Tasman Drive
--             San Jose, CA  95134-1706
--             USA
--     Tel: +1 800 553-NETS
--     Email: cs-ha@cisco.com
--  Descr
--    This module defines the textual conventions used within
--     Cisco Entity Redundancy MIBs.
--     
--  RevDate
--    200510010000Z
--  RevDescr
--    The initial version of this MIB module.

CeRedunType ::= INTEGER {
        other(1),
        yCable(2),
        aps(3),
        featureCard(4),
        externalSwitch(5),
        slotPair(6),
        cmts(7)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    Defines the following group redundancy types:
--    
--     other(1)
--       Indicates a type of redundancy which doesn't fall into
--       any other listed category.
--    
--     yCable(2)
--       A form of redundancy in which signals from a common line 
--       are connected to ports on two redundant members using a 
--       special Y-shaped splitter/combiner cable.  The receive 
--       signals are split and fed to the receive ports on each 
--       redundant member. The transmit signals are combined from 
--       the transmit ports on each member. However, only the active
--       redundant member transmits a signal, while the standby 
--       member suppresses sending a signal into the Y-combiner.
--    
--     aps(3) 
--       Automatic Protection Switching.  A form of redundancy 
--       using redundant lines with one connected to the working 
--       port on the primary member and the other connected to 
--       the protection port on the secondary member.  APS 
--       redundancy protects against line (or fiber) failures in 
--       addition to protecting against port module hardware 
--       failures.
--    
--     featureCard(4)
--       The featureCard option is used when the module
--       does not have external line interfaces. Examples are
--       modules which provide packet processing, additional
--       memory or even fans or power supplies.
--    
--     externalSwitch(5)
--       A form of redundancy similar to yCable but using an
--       external switch to select or direct the receive or 
--       transmit signals from a common line to ports on 
--       redundant members. Additional control (not provided in
--       this general MIB) may be necessary in order to control
--       and monitor the external switch.
--     
--     slotPair(6)
--       Some platforms require the user to configure a slot-pair
--       group in order to allow internal signals to be bridged to 
--       redundant linecards in the slot-pair.  But redundancy groups
--       would also need to be configured for contained entities, 
--       such as ports. Switchovers should take place independently 
--       for each contained entity (e.g. port).
--    
--       The slotPair groups support only basic group and member
--       configuration including the primary/secondary designation.
--       Switchovers may only be supported for the contained
--       entity.  The primary/secondary roles of contained group 
--       members must match the primary/secondary role of the 
--       containing entity.
--     
--      cmts(7)
--       redundancy is provided for Cable Modem Termination Systems.

CeRedunScope ::= INTEGER {
        other(1),
        local(2),
        remoteChassis(3),
        remoteSystem(4)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    Defines the following group redundancy scopes:
--    
--     other(1)
--       The scope is not described by any of the other 
--       categories listed below.
--    
--     local(2)
--       All redundancy group members reside on a single
--       managed system and are reachable through a single 
--       management IP address.
--    
--     remoteChassis(3)
--       This redundancy group has peer members on physically 
--       separate local and remote managed systems with separate 
--       management IP addresses.  
--    
--       But the local and remote systems can communicate with 
--       each other and are contained in the same instance of 
--       a supercontainer 'stack' entPhysicalClass, even if they
--       don't physically reside in close proximity. Therefore the 
--       members in the separate systems can be represented by a 
--       common entPhysicalIndex numbering scheme.
--    
--       An example might be a multi-shelf system where redundant
--       member linecards are located on separate shelves. Each
--       shelf may have a separate management port to allow SNMP 
--       control, but the linecards are designated by a common 
--       shelf/slot numbering instead of just a slot number.
--       Therefore both members can be configured by communicating
--       with one of the SNMP managed systems even though only 
--       one member is physically located on that managed shelf.
--     
--     remoteSystem(4)
--       This redundancy group has peer members on physically 
--       separate local and remote managed systems with separate 
--       management IP addresses.  
--    
--       The local and remote systems have independent 
--       entPhysicalIndex numbering. The local and remote members 
--       may be tied together by some other means, such as by 
--       configuration of an InetAddress for the remote peer member
--       and the requirement to use matching ceRedunGroupTypeIndex
--       and ceRedunGroupIndex values on the local and remote 
--       systems.
--    
--       Because of the independent PhysicalIndex numbering, the 
--       primary member configuration would need to be done on one
--       managed system and the peer secondary member configuration
--       would need to be done on the remote managed system.

CeRedunArch ::= INTEGER {
        other(1),
        oneToOne(2),
        onePlusOne(3),
        oneToN(4),
        mToN(5),
        loadSharing(6)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    The architecture of the redundancy group.
--    
--     other(1)
--       The redundancy architecture doesn't fall into one 
--       of the categories listed below.
--    
--     oneToOne(2)
--    
--       1:1 redundancy allows a secondary member to protect 
--       only one primary member. 
--     
--     onePlusOne(3)
--     
--       1+1 redundancy also allows a secondary member to protect
--       only one primary member. In 1+1 architecture the transmit 
--       signal is bridged so that it is transmitted identically 
--       on both redundant lines. So it only applies to the
--       aps redundancy type.
--    
--     oneToN(4)
--    
--       The 1:n architecture allows a secondary member to
--       protect for any of N primary members.  But the secondary 
--       can only take over as active for one primary at any
--       given time.
--    
--     mToN(5)
--    
--       The m:n architecture allows M secondary members to
--       protect for any of N primary members.  Each secondary 
--       member can only take over as active for one primary at 
--       any given time.
--    
--     loadSharing(6)
--     
--       In load sharing architectures, redundant peers can actively 
--       provide some of the functionality normally provided by a 
--       single member, so that either the capacity of the system 
--       can be increased or else the loading on the primary member
--       can be decreased. 

CeRedunSwitchCommand ::= INTEGER {
        noCmdInEffect(1),
        clear(2),
        manualSwitchAway(3),
        forcedSwitchAway(4),
        lockoutProtection(5)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    The following redundancy switch command values are defined.
--     However some platforms, group types or redundancy types
--     may only support a subset of these commands:
--    
--     noCmdInEffect(1)
--    
--       This value should be returned by a read request when no 
--       switch command has been written to the member in question
--       since initialization or the last command is no longer in
--    effect due to either a later clear command or because 
--    switch commands never remain in effect on this managed 
--    system. This value may not be used in a write operation.
--    
--     clear(2)
--    
--       Clears any switch command in effect for the specified 
--       member.  If the member number is sent as -1, then it 
--       clears all switch commands in effect for all members.
--    Following a clear command, the value read back should
--    be noCmdInEffect.
--    
--    
--     manualSwitchAway(3)
--    
--       Switches away from the specified member, so that it will
--       become (or remain) standby. It should succeed only if the 
--       peer member is present with no switchable alarm conditions 
--       and has no equal or higher precedence switch command 
--       in effect.
--    
--     forcedSwitchAway(4)
--    
--       Switches away from the specified member, so that it will
--       become (or remain) standby. This should succeed when the 
--       peer member is present even when it has a degraded alarm 
--       condition or a manual switch in effect.
--     
--       When applied to a primary member it should not succeed
--       if the secondary peer has a failure alarm condition.
--    
--       However, if applied to a secondary member it should succeed
--       even if the peer primary member has a failure alarm 
--       condition. 
--    
--     lockoutProtection(5)
--    
--       When applied to a secondary member, this command should
--       prevent the secondary from taking over as active for any 
--       primary member. It should if necessary, cause a switch back
--       to the corresponding primary member even when there is an
--       existing alarm or forced switch in effect for the primary 
--       member. 
--    
--       When applied to a primary member in a 1:n architecture, 
--       it should prevent just the one primary member from going 
--       standby.

CeRedunMode ::= INTEGER {
        primary(1),
        secondary(2)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    Primary and secondary mode. The designation as primary or
--     secondary is configured and is static. It doesn't change due 
--     to a switchover.
--    
--     primary
--       The member which normally defaults to active at system
--       startup and following a ceRedunGroupWaitToRestore timeout
--       for a revertive group. For APS redundancy types, this 
--       is called the working member.
--     
--     secondary
--       The member which normally defaults to standby at system
--       startup. It represents the extra member which has been 
--       added in order to provide backup to the primary member(s).
--       For APS redundancy types, the secondary member is called 
--       the protection member.

CeRedunMbrStatus ::= OCTET STRING(SIZE(1..2))
        -- BITS are:
        --   protectionLockedOut(0)
        --   degraded(1)
        --   failure(2)
        --   standby(3)
        --   protectionProvided(4)
        --   forcedStandby(5)
        --   manualStandby(6)
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    Bitflags indicating the current redundancy status of a 
--     redundant member. Some combinations of multiple bitflags
--     may be set at the same time.
--    
--     protectionLockedOut
--    
--       This bit, when applied to a primary member, indicates
--       that the member is prevented from switching to standby.
--       When applied to a secondary member, this bit indicates 
--       that it may not take over as active for any primary member.
--    
--     degraded
--    
--       A degraded alarm condition is in effect for the member.
--       This is any alarm condition which allows the member to 
--       provide some usable level of functionality, but should 
--       still result in a switchover if the peer member is good. 
--         
--       Any other minor alarm conditions which should not result in
--       switchovers, should not cause the degraded bit to be set.
--    
--     failure
--    
--       A failure alarm condition is in effect for the member.
--       This is any alarm condition which prevents or seriously 
--       degrades the ability of the member to provide a usable
--       level of functionality.
--    
--     standby
--    
--       The standby bit should be set for primary member any 
--       time a secondary member has taken over as active for it. 
--    
--       The standby bit should be set for a secondary member 
--       during the entire time when that member has not taken 
--       over as active for a primary member. 
--    
--     protectionProvided
--    
--       This bit is set whenever the standby bit is not set and a 
--       corresponding standby member has reached its terminal 
--       standby state so that it is fully capable of providing 
--       protection for this active member.
--    
--       It should be suppressed if the protectionLockedOut bit or 
--       the forcedStandby bit is set for either member.  However 
--       it may remain set while the manualStandby bit is set for 
--       a corresponding standby member as long as switchover 
--       protection is still being offered for this active member 
--       under some conditions.
--    
--     forcedStandby
--    
--       This bit is applied if a forcedSwitchAway command is in
--       effect for the member.
--    
--     manualStandby
--    
--       This bit is applied if a manualSwitchAway command is in
--       effect for the member. 
--     

CeRedunStateCategories ::= INTEGER {
        other(1),
        disabled(2),
        inactive(3),
        failed(4),
        initializing(5),
        negotiation(6),
        activeOther(7),
        activeImageInitialize(8),
        activeConfigInitialize(9),
        activeRunStateInitialize(10),
        activeFromStandbyTransition(11),
        activeReconciliation(12),
        activeWait(13),
        active(14),
        standbyOther(15),
        standbyImageInitialize(16),
        standbyConfigInitialize(17),
        standbyRunStateInitialize(18),
        standbyReconciliation(19),
        standbyWait(20),
        standbyColdFinal(21),
        standbyWarmFinal(22),
        standbyHotFinal(23),
        standbySwitchingToActive(24)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    A list of categories of possible member internal states 
--     which may be considered significant for redundancy control.
--     Managed systems may report only a subset of these state
--     categories. Managed systems may also report multiple states 
--     that fall into the same categories:
--    
--     other(1)
--       The internal state doesn't fall into any other category 
--       listed below.
--     
--     disabled(2)
--       The member is disabled from participating in protection
--       for this group, due to some user or automatic action.
--    
--     inactive(3)
--       The member is not active, but is not considered as 
--       providing standby protection for this group.
--    
--     failed(4)
--       The member can no longer provide protection for the
--       redundancy group because of a failure condition.
--    
--       Note: Managed systems may optionally leave members 
--       with failures in other internal states, but may just 
--       report an alarm condition for the member.
--    
--     initializing(5)
--       The member is undergoing initialization.
--     
--     negotiation(6)
--       The member is determining its active/standby 
--       classification.
--    
--     activeOther(7)
--       The member is considered as active, but doesn't fit
--       into any other active category listed below.
--    
--     activeImageInitialize(8)
--       The member has been chosen as active but is in the
--       process of downloading or otherwise initializing
--       a software or firmware image.
--    
--     activeConfigInitialize(9)
--       The member has been chosen as active but is in the 
--       process of downloading or otherwise initializing
--       its configuration.
--    
--     activeRunStateInitialize(10)
--       The member has been chosen as active but is in the 
--       process of downloading or otherwise initializing other 
--       information considered as part of its run-time state.
--    
--     activeFromStandbyTransition(11)
--       The member is in the process of transitioning from
--       active to standby.
--     
--     activeReconciliation(12)
--       The member is reconciling in order to bring some 
--       internal configuration or run-time state to be consistent
--       with some other entity.
--    
--     activeWait(13)
--       The member is doing some unspecified activity prior 
--       to reaching its final active state.
--    
--     active(14)
--       The member is in its final active state.
--    
--     standbyOther(15)
--       The member is considered as standby, but doesn't fit
--       into any other standby category listed below.
--    
--     standbyImageInitialize(16)
--       The member has been chosen as standby but is in the
--       process of downloading or otherwise initializing a
--       software or firmware image.
--    
--     standbyConfigInitialize(17)
--       The member has been chosen as standby but is in the 
--       process of downloading or otherwise initializing 
--       its configuration.
--    
--     standbyRunStateInitialize(18)
--       The member has been chosen as standby but is in the 
--       process of downloading or otherwise initializing other
--       information considered as part of its run-time state.
--    
--     standbyReconciliation(19)
--       The member is reconciling in order to bring some 
--       internal configuration or run-time state to be consistent
--       with some other entity.
--    
--     standbyWait(20)
--       The member is doing some unspecified activity prior 
--       to reaching its final standby state.
--    
--     standbyColdFinal(21)
--       The member is in its final standby state, but 
--       it will require a substantial interval of additional 
--       activities before it can be fully active following
--       a switchover.
--    
--     standbyWarmFinal(22)
--       The member is in its final standby state, but it 
--       will require a small interval of additional
--       activities before it can be fully active following
--       a switchover.
--    
--     standbyHotFinal(23)
--       The member is in its final standby state and will
--       be able to take over as active immediately following
--       a switchover. 
--    
--     standbySwitchingToActive(24)
--       The member is still considered standby, but is in the 
--       process of transitioning to active.

CeRedunReasonCategories ::= INTEGER {
        other(1),
        unsupported(2),
        notKnown(3),
        userManual(4),
        userForced(5),
        userLockout(6),
        activeMbrFailed(7),
        activeMbrRemoved(8),
        activeMbrDisabled(9),
        revertiveSwitchover(10),
        remoteRequest(11)
        }
-- TEXTUAL-CONVENTION
--  Status
--    mandatory
--  Descr
--    A list of categories of possible switchover reasons.
--     Managed systems may report only a subset of these reason
--     categories. Managed systems may also report multiple reasons
--     that fall into the same categories.:
--    
--     other(1)
--       The specified reason doesn't fall into any of the 
--       categories listed below.
--    
--     unsupported(2)
--       The reason code is an unsupported feature
--    
--     notKnown(3)
--       The managed system was not able to determine the
--       reason for the last switchover.
--    
--     userManual(4)
--       The switchover was a result of a manualSwitchAway 
--       command by a user.
--    
--     userForced(5)
--       The switchover was a result of a forcedSwitchAway 
--       command by a user.
--    
--     userLockout(6)
--       The switchover was a result of a lockoutProtection 
--       command by a user.
--    
--     activeMbrFailed(7)
--       The switchover was triggered by a degrade or failure
--       alarm on the previously active member.
--    
--     activeMbrRemoved(8)
--       The switchover was triggered by the removal of
--       the previously active member.
--         
--     activeMbrDisabled(9)
--       The switchover was triggered by some other user
--       controlled action which placed the prior active member
--       into an offline, disabled or shutdown state.
--    
--     revertiveSwitchover(10)
--       The switchover was the result of a timeout of
--       the wait-to-revert timer for a group configured
--       for revertive switching.
--     
--     remoteRequest(11)
--       The switchover was triggered due to a request from
--       a remote system. 


END

