MrMeeb/snmp_mib_archive
1
0
Fork 0
mirror of https://github.com/hsnodgrass/snmp_mib_archive.git synced 2025-04-17 16:03:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
snmp_mib_archive/CISCO-ENTITY-REDUNDANCY-TC-MIB.my
Heston Snodgrass 89bf4b016e initial commit
2016-12-15 15:03:18 -07:00

610 lines
23 KiB
Plaintext
Raw Blame History

-- *********************************************************************
-- CISCO-ENTITY-REDUNDANCY-TC-MIB.my
-- List of Textual Conventions used in the CISCO-ENTITY-REDUNDANCY-MIB
--
-- Feb 2005, Fred Frazer
--
-- Copyright (c) 2005, 2006 by Cisco Systems, Inc.
-- All rights reserved.
-- *********************************************************************
CISCO-ENTITY-REDUNDANCY-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
ciscoMgmt FROM CISCO-SMI
;
ciscoEntityRedunTcMIB MODULE-IDENTITY
LAST-UPDATED "200510010000Z"
ORGANIZATION "Cisco Systems, Inc."
CONTACT-INFO
"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"
DESCRIPTION
"This module defines the textual conventions used within
Cisco Entity Redundancy MIBs.
"
REVISION "200510010000Z"
DESCRIPTION
"The initial version of this MIB module."
::= { ciscoMgmt 494 }
-- Start of Textual Conventions
CeRedunType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
other(1),
yCable(2),
aps(3),
featureCard(4),
externalSwitch(5),
slotPair(6),
cmts(7)
}
CeRedunScope ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
other(1),
local(2),
remoteChassis(3),
remoteSystem(4)
}
CeRedunArch ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
other(1),
oneToOne(2),
onePlusOne(3),
oneToN(4),
mToN(5),
loadSharing(6)
}
CeRedunSwitchCommand ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
noCmdInEffect(1),
clear(2),
manualSwitchAway(3),
forcedSwitchAway(4),
lockoutProtection(5)
}
CeRedunMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
primary(1),
secondary(2)
}
CeRedunMbrStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX BITS {
protectionLockedOut(0),
degraded(1),
failure(2),
standby(3),
protectionProvided(4),
forcedStandby(5),
manualStandby(6)
}
CeRedunStateCategories ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX 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)
}
CeRedunReasonCategories ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"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.
"
SYNTAX INTEGER {
other(1),
unsupported(2),
notKnown(3),
userManual(4),
userForced(5),
userLockout(6),
activeMbrFailed(7),
activeMbrRemoved(8),
activeMbrDisabled(9),
revertiveSwitchover(10),
remoteRequest(11)
}
END
Reference in New Issue View Git Blame Copy Permalink