As per Relevance of the word reference, we have this rfc below:
Network Working Group E.
Request for Comments: 1493 cisco Systems, Inc
Obsoletes: 1286 P.
Digital Equipment
A.
Digital Equipment
K.
Hughes LAN Systems, Inc
July 1993
Definitions of Managed
for
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in TCP/IP based internets
In particular it defines objects for managing MAC bridges based
the IEEE 802.1D-1990 standard between Local Area Network (LAN
segments. Provisions are made for support of transparent bridging
Provisions are also made so that these objects apply to
connected by subnetworks other than LAN segments
Table of
1. The Network Management Framework ...................... 2
2. Objects ............................................... 2
2.1 Format of Definitions ................................ 3
3. Overview .............................................. 3
3.1 Structure of MIB ..................................... 3
3.1.1 The dot1dBase Group ................................ 6
3.1.2 The dot1dStp Group ................................. 6
3.1.3 The dot1dSr Group .................................. 6
3.1.4 The dot1dTp Group .................................. 6
3.1.5 The dot1dStatic Group .............................. 6
3.2 Relationship to Other MIBs ........................... 6
3.2.1 Relationship to the 'system' group ................. 6
3.2.2 Relationship to the 'interfaces' group ............. 7
Decker, Langille, Rijsinghani & McCloghrie [Page 1]
RFC 1493 Bridge MIB July 1993
3.3 Textual Conventions .................................. 8
4. Changes from RFC 1286 ................................. 8
5. Definitions ........................................... 9
5.1 Groups in the Bridge MIB ............................. 11
5.2 The dot1dBase Group Definitions ...................... 11
5.3 The dot1dStp Group Definitions ....................... 14
5.4 The dot1dTp Group Definitions ........................ 22
5.5 The dot1dStatic Group Definitions .................... 28
5.6 Traps for use by Bridges ............................. 31
6. Acknowledgments ....................................... 31
7. References ............................................ 33
8. Security Considerations ............................... 33
9. Authors' Addresses .................................... 34
1. The Network Management
The Internet-standard Network Management Framework consists of
components. They are
STD16/RFC 1155 which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
STD16/RFC 1212 defines a more concise description mechanism,
is wholly consistent with the SMI
RFC 1156 which defines MIB-I, the core set of managed objects
the Internet suite of protocols. STD17/RFC 1213, defines MIB-II
an evolution of MIB-I based on implementation experience and
operational requirements
STD15/RFC 1157 which defines the SNMP, the protocol used
network access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
2.
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI. In particular, each object is named by an
IDENTIFIER, an administratively assigned name, which specifies
object type. The object type together with an object instance
to uniquely identify a specific instantiation of the object.
human convenience, we often use a textual string, termed
descriptor, to also refer to the object type
Decker, Langille, Rijsinghani & McCloghrie [Page 2]
RFC 1493 Bridge MIB July 1993
2.1. Format of
Section 5 contains the specification of all object types contained
this MIB module. The object types are defined using the
defined in the SMI, as amended by the extensions specified in [9,10].
3.
A common device present in many networks is the Bridge. This
is used to connect Local Area Network segments below the
layer
There are two major modes defined for this bridging; transparent
source route. The transparent method of bridging is defined in
draft IEEE 802.1d specification [11]. This memo defines
objects needed for the management of a bridging entity operating
the transparent mode, as well as some objects applicable to all
of bridges
To be consistent with IAB directives and good engineering practice
an explicit attempt was made to keep this MIB as simple as possible
This was accomplished by applying the following criteria to
proposed for inclusion
(1) Start with a small set of essential objects and add
as further objects are needed
(2) Require objects be essential for either fault
configuration management
(3) Consider evidence of current use and/or utility
(4) Limit the total of objects
(5) Exclude objects which are simply derivable from others
this or other MIBs
(6) Avoid causing critical sections to be
instrumented. The guideline that was followed is
counter per critical section per layer
3.1. Structure of
Objects in this MIB are arranged into groups. Each group
organized as a set of related objects. The overall structure
assignment of objects to their groups is shown below.
appropriate the corresponding IEEE 802.1d [11] management object
is also included
Decker, Langille, Rijsinghani & McCloghrie [Page 3]
RFC 1493 Bridge MIB July 1993
Bridge MIB Name IEEE 802.1d
dot1
dot1
BridgeAddress Bridge.
NumPorts Bridge.
Port BridgePort.
DelayExceededDiscards .
MtuExceededDiscards .
dot1
Priority
.
TimeSinceTopologyChange .
TopChanges .
DesignatedRoot .
RootCost .
RootPort .
MaxAge .
HelloTime .
HoldTime .
ForwardDelay .
BridgeMaxAge .
BridgeHelloTime .
BridgeForwardDelay .
Port
.
Priority .
State .
PathCost .
DesignatedRoot .
DesignatedCost .
DesignatedBridge .
DesignatedPort .
dot1
LearnedEntryDiscards BridgeFilter.
.NumDynamic,
AgingTime BridgeFilter.
Decker, Langille, Rijsinghani & McCloghrie [Page 4]
RFC 1493 Bridge MIB July 1993
InFrames BridgePort.
OutFrames .
InDiscards .
dot1
The following IEEE 802.1d management objects have not been
in the Bridge MIB for the indicated reasons
IEEE 802.1d Object
Bridge.BridgeName Same as sysDescr (MIB II
Bridge.BridgeUpTime Same as sysUpTime (MIB II
Bridge.PortAddresses Same as ifPhysAddress (MIB II
BridgePort.PortName Same as ifDescr (MIB II
BridgePort.PortType Same as ifType (MIB II
BridgePort.RoutingType Derivable from the
.BridgeIdentifier Combination of dot1
and dot1
.TopologyChange Since this is transitory,
is not considered useful
.Uptime Same as ifLastChange (MIB II
.PortIdentifier Combination of dot1
and dot1
.TopologyChangeAcknowledged Since this is transitory,
is not considered useful
.DiscardLackOfBuffers
Transmission Priority These objects are not
as per the Pics Proforma
not considered useful
.
.
.
Decker, Langille, Rijsinghani & McCloghrie [Page 5]
RFC 1493 Bridge MIB July 1993
3.1.1. The dot1dBase
This mandatory group contains the objects which are applicable to
types of bridges
3.1.2. The dot1dStp
This group contains the objects that denote the bridge's state
respect to the Spanning Tree Protocol. If a node does
implemented the Spanning Tree Protocol, this group will not
implemented
3.1.3. The dot1dSr
This group contains the objects that describe the entity's state
respect to source route bridging. If source routing is not
this group will not be implemented. This group is applicable
source route only, and SRT bridges. This group will be described
a separate document applicable only to source route bridging
3.1.4. The dot1dTp
This group contains objects that describe the entity's state
respect to transparent bridging. If transparent bridging is
supported this group will not be implemented. This group
applicable to transparent only and SRT bridges
3.1.5. The dot1dStatic
This group contains objects that describe the entity's state
respect to destination-address filtering. If destination-
filtering is not supported this group will not be implemented.
group is applicable to any type of bridge which
destination-address filtering
3.2. Relationship to Other
As described above, some IEEE 802.1d management objects have not
included in this MIB because they overlap with objects in other
applicable to a bridge implementing this MIB. In particular, it
assumed that a bridge implementing this MIB will also implement (
least) the 'system' group and the 'interfaces' group defined in MIB
II [6].
3.2.1. Relationship to the 'system'
In MIB-II, the 'system' group is defined as being mandatory for
systems such that each managed entity contains one instance of
Decker, Langille, Rijsinghani & McCloghrie [Page 6]
RFC 1493 Bridge MIB July 1993
object in the 'system' group. Thus, those objects apply to
entity as a whole irrespective of whether the entity's
functionality is bridging, or whether bridging is only a subset
the entity's functionality
3.2.2. Relationship to the 'interfaces'
In MIB-II, the 'interfaces' group is defined as being mandatory
all systems and contains information on an entity's interfaces,
each interface is thought of as being attached to a `subnetwork'.
(Note that this term is not to be confused with `subnet' which
to an addressing partitioning scheme used in the Internet suite
protocols.) The term 'segment' is used in this memo to refer to
a subnetwork, whether it be an Ethernet segment, a 'ring', a
link, or even an X.25 virtual circuit
Implicit in this Bridge MIB is the notion of ports on a bridge.
of these ports is associated with one interface of the 'interfaces
group, and in most situations, each port is associated with
different interface. However, there are situations in which
ports are associated with the same interface. An example of such
situation would be several ports each corresponding one-to-one
several X.25 virtual circuits but all on the same interface
Each port is uniquely identified by a port number. A port number
no mandatory relationship to an interface number, but in the
case a port number will have the same value as the
interface's interface number. Port numbers are in the
(1..dot1dBaseNumPorts).
Some entities perform other functionality as well as bridging
the sending and receiving of data on their interfaces. In
situations, only a subset of the data sent/received on an
is within the domain of the entity's bridging functionality.
subset is considered to be delineated according to a set
protocols, with some protocols being bridged, and other protocols
being bridged. For example, in an entity which exclusively
bridging, all protocols would be considered as being bridged,
in an entity which performed IP routing on IP datagrams and
bridged other protocols, only the non-IP data would be considered
being bridged
Thus, this Bridge MIB (and in particular, its counters)
applicable only to that subset of the data on an entity's
which is sent/received for a protocol being bridged. All such
is sent/received via the ports of the bridge
Decker, Langille, Rijsinghani & McCloghrie [Page 7]
RFC 1493 Bridge MIB July 1993
3.3. Textual
The datatypes, MacAddress, BridgeId and Timeout, are used as
conventions in this document. These textual conventions have
effect on either the syntax nor the semantics of any managed object
Objects defined using these conventions are always encoded by
of the rules that define their primitive type. Hence, no changes
the SMI or the SNMP are necessary to accommodate these
conventions which are adopted merely for the convenience of readers
4. Changes from RFC 1286
(1) Updated all text to remove references to source
bridging where not applicable. SR MIB will be a
document
(2) Removed dot1dSrPortTable. Retained OID definition
dot1dSr
(3) Updated all references of "draft P802.1d/D9" to "
802.1D-1990".
(4) Updated bibliography
(5) Added clarification to description of dot1dPortPathCost
(6) Put recommended default in description
dot1dStaticAllowedToGoTo
(7) Put recommended default in description
dot1dStaticStatus
(8) Put recommended default in description
dot1dTpAgingTime. Specified range of (10..1000000).
(9) Updated all port number syntaxes, when used as index,
use the range (1..65535).
(10) Updated definition of dot1dTpPortInFrames
dot1dTpPortOutFrames
(11) Added text to the traps indicating that they
optional
(12) Clarified definition of dot1dStpForwardDelay
Decker, Langille, Rijsinghani & McCloghrie [Page 8]
RFC 1493 Bridge MIB July 1993
5.
BRIDGE-MIB DEFINITIONS ::=
Counter,
FROM RFC1155-
mib-2
FROM RFC1213-
OBJECT-
FROM RFC-1212
TRAP-
FROM RFC-1215;
-- All representations of MAC addresses in this MIB
-- use, as a textual convention (i.e. this convention
-- not affect their encoding), the data type
MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet
-- in
-- "canonical
--
-- defined by IEEE 802.1a, i.e., as if it were
-- least significant bit first, even though 802.5 (
-- contrast to other n802.x protocols) requires
-- addresses to be transmitted most significant bit first
--
-- 16-bit addresses, if needed, are represented by
-- their upper 4 octets to all 0's, i.e., AAFF would
-- represented as 00000000AAFF
-- Similarly, all representations of Bridge-Id in this
-- Module use, as a textual convention (i.e.
-- convention does not affect their encoding), the
-- type
BridgeId ::= OCTET STRING (SIZE (8)) --
-- Bridge-
-- as used in
-- Spanning
-- Protocol to uniquely identify a bridge. Its first
-- octets (in network byte order) contain a
-- value and its last 6 octets contain the MAC
-- used to refer to a bridge in a unique
-- (typically, the numerically smallest MAC
-- of all ports on the bridge).
Decker, Langille, Rijsinghani & McCloghrie [Page 9]
RFC 1493 Bridge MIB July 1993
-- Several objects in this MIB module represent values
-- timers used by the Spanning Tree Protocol. In
-- MIB, these timers have values in units of hundreths
-- a second (i.e. 1/100 secs).
-- These timers, when stored in a Spanning Tree Protocol'
-- BPDU, are in units of 1/256 seconds. Note, however
-- that 802.1D-1990 specifies a settable granularity
-- no more than 1 second for these timers. To
-- ambiguity, a data type is defined here as a
-- convention and all representation of these
-- in this MIB module are defined using this data type.
-- algorithm is also defined for converting between
-- different units, to ensure a timer's value is
-- distorted by multiple conversions
-- The data type is
Timeout ::= INTEGER -- a STP timer in units of 1/100
-- To convert a Timeout value into a value in units
-- 1/256 seconds, the following algorithm should be used
--
-- b = floor( (n * 256) / 100)
--
-- where
-- floor = quotient [ignore remainder
-- n is the value in 1/100 second
-- b is the value in 1/256 second
--
-- To convert the value from 1/256 second units back
-- 1/100 seconds, the following algorithm should be used
--
-- n = ceiling( (b * 100) / 256)
--
-- where
-- ceiling = quotient [if remainder is 0],
-- quotient + 1 [if remainder is non-zero
-- n is the value in 1/100 second
-- b is the value in 1/256 second
--
-- Note: it is important that the arithmetic operations
-- done in the order specified (i.e., multiply first,
-- second).
dot1dBridge OBJECT IDENTIFIER ::= { mib-2 17 }
Decker, Langille, Rijsinghani & McCloghrie [Page 10]
RFC 1493 Bridge MIB July 1993
-- groups in the Bridge
dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 }
dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 }
dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 }
-- separately
dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 }
dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 }
-- the dot1dBase
-- Implementation of the dot1dBase group is mandatory for
-- bridges
dot1dBaseBridgeAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"The MAC address used by this bridge when it
be referred to in a unique fashion. It
recommended that this be the numerically
MAC address of all ports that belong to
bridge. However it is only required to be unique
When concatenated with dot1dStpPriority a
BridgeIdentifier is formed which is used in
Spanning Tree Protocol."
"IEEE 802.1D-1990: Sections 6.4.1.1.3 and 3.12.5"
::= { dot1dBase 1 }
dot1dBaseNumPorts OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of ports controlled by this
entity."
"IEEE 802.1D-1990: Section 6.4.1.1.3"
::= { dot1dBase 2 }
dot1dBaseType OBJECT-
Decker, Langille, Rijsinghani & McCloghrie [Page 11]
RFC 1493 Bridge MIB July 1993
SYNTAX INTEGER {
unknown(1),
transparent-only(2),
sourceroute-only(3),
srt(4)
}
ACCESS read-
STATUS
"Indicates what type of bridging this bridge
perform. If a bridge is actually performing
certain type of bridging this will be indicated
entries in the port table for the given type."
::= { dot1dBase 3 }
-- The Generic Bridge Port
dot1dBasePortTable OBJECT-
SYNTAX SEQUENCE OF Dot1
ACCESS not-
STATUS
"A table that contains generic information
every port that is associated with this bridge
Transparent, source-route, and srt ports
included."
::= { dot1dBase 4 }
dot1dBasePortEntry OBJECT-
SYNTAX Dot1
ACCESS not-
STATUS
"A list of information for each port of
bridge."
"IEEE 802.1D-1990: Section 6.4.2, 6.6.1"
INDEX { dot1dBasePort }
::= { dot1dBasePortTable 1 }
Dot1dBasePortEntry ::=
SEQUENCE {
dot1
INTEGER
dot1
INTEGER
dot1
Decker, Langille, Rijsinghani & McCloghrie [Page 12]
RFC 1493 Bridge MIB July 1993
OBJECT IDENTIFIER
dot1
Counter
dot1
}
dot1dBasePort OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS
"The port number of the port for which this
contains bridge management information."
::= { dot1dBasePortEntry 1 }
dot1dBasePortIfIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The value of the instance of the ifIndex object
defined in MIB-II, for the interface
to this port."
::= { dot1dBasePortEntry 2 }
dot1dBasePortCircuit OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"For a port which (potentially) has the same
of dot1dBasePortIfIndex as another port on
same bridge, this object contains the name of
object instance unique to this port. For example
in the case where multiple ports correspond one
to-one with multiple X.25 virtual circuits,
value might identify an (e.g., the first)
instance associated with the X.25 virtual
corresponding to this port
For a port which has a unique value
dot1dBasePortIfIndex, this object can have
value { 0 0 }."
::= { dot1dBasePortEntry 3 }
dot1dBasePortDelayExceededDiscards OBJECT-
SYNTAX
Decker, Langille, Rijsinghani & McCloghrie [Page 13]
RFC 1493 Bridge MIB July 1993
ACCESS read-
STATUS
"The number of frames discarded by this port
to excessive transit delay through the bridge.
is incremented by both transparent and
route bridges."
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dBasePortEntry 4 }
dot1dBasePortMtuExceededDiscards OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of frames discarded by this port
to an excessive size. It is incremented by
transparent and source route bridges."
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dBasePortEntry 5 }
-- the dot1dStp
-- Implementation of the dot1dStp group is optional. It
-- implemented by those bridges that support the Spanning
-- Protocol
dot1dStpProtocolSpecification OBJECT-
SYNTAX INTEGER {
unknown(1),
decLb100(2),
ieee8021d(3)
}
ACCESS read-
STATUS
"An indication of what version of the
Tree Protocol is being run. The
'decLb100(2)' indicates the DEC LANbridge 100
Spanning Tree protocol. IEEE 802.1
implementations will return 'ieee8021d(3)'.
future versions of the IEEE Spanning Tree
are released that are incompatible with
current version a new value will be defined."
Decker, Langille, Rijsinghani & McCloghrie [Page 14]
RFC 1493 Bridge MIB July 1993
::= { dot1dStp 1 }
dot1dStpPriority OBJECT-
SYNTAX INTEGER (0..65535)
ACCESS read-
STATUS
"The value of the write-able portion of the
ID, i.e., the first two octets of the (8
long) Bridge ID. The other (last) 6 octets of
Bridge ID are given by the value
dot1dBaseBridgeAddress."
"IEEE 802.1D-1990: Section 4.5.3.7"
::= { dot1dStp 2 }
dot1dStpTimeSinceTopologyChange OBJECT-
SYNTAX
ACCESS read-
STATUS
"The time (in hundredths of a second) since
last time a topology change was detected by
bridge entity."
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 3 }
dot1dStpTopChanges OBJECT-
SYNTAX
ACCESS read-
STATUS
"The total number of topology changes detected
this bridge since the management entity was
reset or initialized."
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
dot1dStpDesignatedRoot OBJECT-
SYNTAX
ACCESS read-
STATUS
"The bridge identifier of the root of the
tree as determined by the Spanning Tree
as executed by this node. This value is used
Decker, Langille, Rijsinghani & McCloghrie [Page 15]
RFC 1493 Bridge MIB July 1993
the Root Identifier parameter in all
Bridge PDUs originated by this node."
"IEEE 802.1D-1990: Section 4.5.3.1"
::= { dot1dStp 5 }
dot1dStpRootCost OBJECT-
SYNTAX
ACCESS read-
STATUS
"The cost of the path to the root as seen
this bridge."
"IEEE 802.1D-1990: Section 4.5.3.2"
::= { dot1dStp 6 }
dot1dStpRootPort OBJECT-
SYNTAX
ACCESS read-
STATUS
"The port number of the port which offers
lowest cost path from this bridge to the
bridge."
"IEEE 802.1D-1990: Section 4.5.3.3"
::= { dot1dStp 7 }
dot1dStpMaxAge OBJECT-
SYNTAX
ACCESS read-
STATUS
"The maximum age of Spanning Tree
information learned from the network on any
before it is discarded, in units of hundredths
a second. This is the actual value that
bridge is currently using."
"IEEE 802.1D-1990: Section 4.5.3.4"
::= { dot1dStp 8 }
dot1dStpHelloTime OBJECT-
SYNTAX
ACCESS read-
STATUS
Decker, Langille, Rijsinghani & McCloghrie [Page 16]
RFC 1493 Bridge MIB July 1993
"The amount of time between the transmission
Configuration bridge PDUs by this node on any
when it is the root of the spanning tree or
to become so, in units of hundredths of a second
This is the actual value that this bridge
currently using."
"IEEE 802.1D-1990: Section 4.5.3.5"
::= { dot1dStp 9 }
dot1dStpHoldTime OBJECT-
SYNTAX
ACCESS read-
STATUS
"This time value determines the interval
during which no more than two Configuration
PDUs shall be transmitted by this node, in
of hundredths of a second."
"IEEE 802.1D-1990: Section 4.5.3.14"
::= { dot1dStp 10 }
dot1dStpForwardDelay OBJECT-
SYNTAX
ACCESS read-
STATUS
"This time value, measured in units of
of a second, controls how fast a port changes
spanning state when moving towards the
state. The value determines how long the
stays in each of the Listening and
states, which precede the Forwarding state.
value is also used, when a topology change
been detected and is underway, to age all
entries in the Forwarding Database. [Note
this value is the one that this bridge
currently using, in contrast
dot1dStpBridgeForwardDelay which is the value
this bridge and all others would start
if/when this bridge were to become the root.]"
"IEEE 802.1D-1990: Section 4.5.3.6"
::= { dot1dStp 11 }
dot1dStpBridgeMaxAge OBJECT-
SYNTAX Timeout (600..4000)
Decker, Langille, Rijsinghani & McCloghrie [Page 17]
RFC 1493 Bridge MIB July 1993
ACCESS read-
STATUS
"The value that all bridges use for MaxAge
this bridge is acting as the root. Note
802.1D-1990 specifies that the range for
parameter is related to the value
dot1dStpBridgeHelloTime. The granularity of
timer is specified by 802.1D-1990 to be 1 second
An agent may return a badValue error if a set
attempted to a value which is not a whole
of seconds."
"IEEE 802.1D-1990: Section 4.5.3.8"
::= { dot1dStp 12 }
dot1dStpBridgeHelloTime OBJECT-
SYNTAX Timeout (100..1000)
ACCESS read-
STATUS
"The value that all bridges use for HelloTime
this bridge is acting as the root.
granularity of this timer is specified by 802.1D
1990 to be 1 second. An agent may return
badValue error if a set is attempted to a
which is not a whole number of seconds."
"IEEE 802.1D-1990: Section 4.5.3.9"
::= { dot1dStp 13 }
dot1dStpBridgeForwardDelay OBJECT-
SYNTAX Timeout (400..3000)
ACCESS read-
STATUS
"The value that all bridges use for
when this bridge is acting as the root. Note
802.1D-1990 specifies that the range for
parameter is related to the value
dot1dStpBridgeMaxAge. The granularity of
timer is specified by 802.1D-1990 to be 1 second
An agent may return a badValue error if a set
attempted to a value which is not a whole
of seconds."
"IEEE 802.1D-1990: Section 4.5.3.10"
::= { dot1dStp 14 }
Decker, Langille, Rijsinghani & McCloghrie [Page 18]
RFC 1493 Bridge MIB July 1993
-- The Spanning Tree Port
dot1dStpPortTable OBJECT-
SYNTAX SEQUENCE OF Dot1
ACCESS not-
STATUS
"A table that contains port-specific
for the Spanning Tree Protocol."
::= { dot1dStp 15 }
dot1dStpPortEntry OBJECT-
SYNTAX Dot1
ACCESS not-
STATUS
"A list of information maintained by every
about the Spanning Tree Protocol state for
port."
INDEX { dot1dStpPort }
::= { dot1dStpPortTable 1 }
Dot1dStpPortEntry ::=
SEQUENCE {
dot1
INTEGER
dot1
INTEGER
dot1
INTEGER
dot1
INTEGER
dot1
INTEGER
dot1
BridgeId
dot1
INTEGER
dot1
BridgeId
dot1
OCTET STRING
dot1
}
dot1dStpPort OBJECT-
SYNTAX INTEGER (1..65535)
Decker, Langille, Rijsinghani & McCloghrie [Page 19]
RFC 1493 Bridge MIB July 1993
ACCESS read-
STATUS
"The port number of the port for which this
contains Spanning Tree Protocol
information."
"IEEE 802.1D-1990: Section 6.8.2.1.2"
::= { dot1dStpPortEntry 1 }
dot1dStpPortPriority OBJECT-
SYNTAX INTEGER (0..255)
ACCESS read-
STATUS
"The value of the priority field which
contained in the first (in network byte order
octet of the (2 octet long) Port ID. The
octet of the Port ID is given by the value
dot1dStpPort."
"IEEE 802.1D-1990: Section 4.5.5.1"
::= { dot1dStpPortEntry 2 }
dot1dStpPortState OBJECT-
SYNTAX INTEGER {
disabled(1),
blocking(2),
listening(3),
learning(4),
forwarding(5),
broken(6)
}
ACCESS read-
STATUS
"The port's current state as defined
application of the Spanning Tree Protocol.
state controls what action a port takes
reception of a frame. If the bridge has
a port that is malfunctioning it will place
port into the broken(6) state. For ports
are disabled (see dot1dStpPortEnable), this
will have a value of disabled(1)."
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 3 }
Decker, Langille, Rijsinghani & McCloghrie [Page 20]
RFC 1493 Bridge MIB July 1993
dot1dStpPortEnable OBJECT-
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
ACCESS read-
STATUS
"The enabled/disabled status of the port."
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
dot1dStpPortPathCost OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS
"The contribution of this port to the path cost
paths towards the spanning tree root which
this port. 802.1D-1990 recommends that
default value of this parameter be in
proportion to the speed of the attached LAN."
"IEEE 802.1D-1990: Section 4.5.5.3"
::= { dot1dStpPortEntry 5 }
dot1dStpPortDesignatedRoot OBJECT-
SYNTAX
ACCESS read-
STATUS
"The unique Bridge Identifier of the
recorded as the Root in the Configuration
transmitted by the Designated Bridge for
segment to which the port is attached."
"IEEE 802.1D-1990: Section 4.5.5.4"
::= { dot1dStpPortEntry 6 }
dot1dStpPortDesignatedCost OBJECT-
SYNTAX
ACCESS read-
STATUS
"The path cost of the Designated Port of
segment connected to this port. This value
compared to the Root Path Cost field in
Decker, Langille, Rijsinghani & McCloghrie [Page 21]
RFC 1493 Bridge MIB July 1993
bridge PDUs."
"IEEE 802.1D-1990: Section 4.5.5.5"
::= { dot1dStpPortEntry 7 }
dot1dStpPortDesignatedBridge OBJECT-
SYNTAX
ACCESS read-
STATUS
"The Bridge Identifier of the bridge which
port considers to be the Designated Bridge
this port's segment."
"IEEE 802.1D-1990: Section 4.5.5.6"
::= { dot1dStpPortEntry 8 }
dot1dStpPortDesignatedPort OBJECT-
SYNTAX OCTET STRING (SIZE (2))
ACCESS read-
STATUS
"The Port Identifier of the port on the
Bridge for this port's segment."
"IEEE 802.1D-1990: Section 4.5.5.7"
::= { dot1dStpPortEntry 9 }
dot1dStpPortForwardTransitions OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of times this port has
from the Learning state to the Forwarding state."
::= { dot1dStpPortEntry 10 }
-- the dot1dTp
-- Implementation of the dot1dTp group is optional. It
-- implemented by those bridges that support the
-- bridging mode. A transparent or SRT bridge will
-- this group
dot1dTpLearnedEntryDiscards OBJECT-
SYNTAX
Decker, Langille, Rijsinghani & McCloghrie [Page 22]
RFC 1493 Bridge MIB July 1993
ACCESS read-
STATUS
"The total number of Forwarding Database entries
which have been or would have been learnt,
have been discarded due to a lack of space
store them in the Forwarding Database. If
counter is increasing, it indicates that
Forwarding Database is regularly becoming full (
condition which has unpleasant performance
on the subnetwork). If this counter has
significant value but is not presently increasing
it indicates that the problem has been
but is not persistent."
"IEEE 802.1D-1990: Section 6.7.1.1.3"
::= { dot1dTp 1 }
dot1dTpAgingTime OBJECT-
SYNTAX INTEGER (10..1000000)
ACCESS read-
STATUS
"The timeout period in seconds for aging
dynamically learned forwarding information
802.1D-1990 recommends a default of 300 seconds."
"IEEE 802.1D-1990: Section 6.7.1.1.3"
::= { dot1dTp 2 }
-- The Forwarding Database for Transparent
dot1dTpFdbTable OBJECT-
SYNTAX SEQUENCE OF Dot1
ACCESS not-
STATUS
"A table that contains information about
entries for which the bridge has forwarding and/
filtering information. This information is
by the transparent bridging function
determining how to propagate a received frame."
::= { dot1dTp 3 }
dot1dTpFdbEntry OBJECT-
SYNTAX Dot1
ACCESS not-
Decker, Langille, Rijsinghani & McCloghrie [Page 23]
RFC 1493 Bridge MIB July 1993
STATUS
"Information about a specific unicast MAC
for which the bridge has some forwarding and/
filtering information."
INDEX { dot1dTpFdbAddress }
::= { dot1dTpFdbTable 1 }
Dot1dTpFdbEntry ::=
SEQUENCE {
dot1
MacAddress
dot1
INTEGER
dot1
}
dot1dTpFdbAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"A unicast MAC address for which the bridge
forwarding and/or filtering information."
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2"
::= { dot1dTpFdbEntry 1 }
dot1dTpFdbPort OBJECT-
SYNTAX
ACCESS read-
STATUS
"Either the value '0', or the port number of
port on which a frame having a source
equal to the value of the corresponding
of dot1dTpFdbAddress has been seen. A value
'0' indicates that the port number has not
learned but that the bridge does have
forwarding/filtering information about
address (e.g. in the dot1dStaticTable).
Implementors are encouraged to assign the
value to this object whenever it is learned
for addresses for which the corresponding value
dot1dTpFdbStatus is not learned(3)."
::= { dot1dTpFdbEntry 2 }
Decker, Langille, Rijsinghani & McCloghrie [Page 24]
RFC 1493 Bridge MIB July 1993
dot1dTpFdbStatus OBJECT-
SYNTAX INTEGER {
other(1),
invalid(2),
learned(3),
self(4),
mgmt(5)
}
ACCESS read-
STATUS
"The status of this entry. The meanings of
values are
other(1) : none of the following. This
include the case where some
MIB object (not the
instance of dot1dTpFdbPort, nor
entry in the dot1dStaticTable)
being used to determine if and
frames addressed to the value
the corresponding instance
dot1dTpFdbAddress are
forwarded
invalid(2) : this entry is not longer
(e.g., it was learned but has
aged-out), but has not yet
flushed from the table
learned(3) : the value of the
instance of dot1dTpFdbPort
learned, and is being used
self(4) : the value of the
instance of dot1
represents one of the bridge'
addresses. The
instance of dot1
indicates which of the bridge'
ports has this address
mgmt(5) : the value of the
instance of dot1dTpFdbAddress
also the value of an
instance of dot1dStaticAddress."
::= { dot1dTpFdbEntry 3 }
Decker, Langille, Rijsinghani & McCloghrie [Page 25]
RFC 1493 Bridge MIB July 1993
-- Port Table for Transparent
dot1dTpPortTable OBJECT-
SYNTAX SEQUENCE OF Dot1
ACCESS not-
STATUS
"A table that contains information about
port that is associated with this
bridge."
::= { dot1dTp 4 }
dot1dTpPortEntry OBJECT-
SYNTAX Dot1
ACCESS not-
STATUS
"A list of information for each port of
transparent bridge."
INDEX { dot1dTpPort }
::= { dot1dTpPortTable 1 }
Dot1dTpPortEntry ::=
SEQUENCE {
dot1
INTEGER
dot1
INTEGER
dot1
Counter
dot1
Counter
dot1
}
dot1dTpPort OBJECT-
SYNTAX INTEGER (1..65535)
ACCESS read-
STATUS
"The port number of the port for which this
contains Transparent bridging
information."
::= { dot1dTpPortEntry 1 }
-- It would be nice if we could use ifMtu as the size of
-- largest INFO field, but we can't because ifMtu is
Decker, Langille, Rijsinghani & McCloghrie [Page 26]
RFC 1493 Bridge MIB July 1993
-- to be the size that the (inter-)network layer can use
-- can differ from the MAC layer (especially if several
-- of encapsulation are used).
dot1dTpPortMaxInfo OBJECT-
SYNTAX
ACCESS read-
STATUS
"The maximum size of the INFO (non-MAC) field
this port will receive or transmit."
::= { dot1dTpPortEntry 2 }
dot1dTpPortInFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of frames that have been received
this port from its segment. Note that a
received on the interface corresponding to
port is only counted by this object if and only
it is for a protocol being processed by the
bridging function, including bridge
frames."
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 3 }
dot1dTpPortOutFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of frames that have been
by this port to its segment. Note that a
transmitted on the interface corresponding to
port is only counted by this object if and only
it is for a protocol being processed by the
bridging function, including bridge
frames."
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 4 }
dot1dTpPortInDiscards OBJECT-
SYNTAX
ACCESS read-
Decker, Langille, Rijsinghani & McCloghrie [Page 27]
RFC 1493 Bridge MIB July 1993
STATUS
"Count of valid frames received which
discarded (i.e., filtered) by the
Process."
"IEEE 802.1D-1990: Section 6.6.1.1.3"
::= { dot1dTpPortEntry 5 }
-- The Static (Destination-Address Filtering)
-- Implementation of this group is optional
dot1dStaticTable OBJECT-
SYNTAX SEQUENCE OF Dot1
ACCESS not-
STATUS
"A table containing filtering
configured into the bridge by (local or network
management specifying the set of ports to
frames received from specific ports and
specific destination addresses are allowed to
forwarded. The value of zero in this table as
port number from which frames with a
destination address are received, is used
specify all ports for which there is no
entry in this table for that
destination address. Entries are valid
unicast and for group/broadcast addresses."
"IEEE 802.1D-1990: Section 6.7.2"
::= { dot1dStatic 1 }
dot1dStaticEntry OBJECT-
SYNTAX Dot1
ACCESS not-
STATUS
"Filtering information configured into the
by (local or network) management specifying
set of ports to which frames received from
specific port and containing a
destination address are allowed to be forwarded."
"IEEE 802.1D-1990: Section 6.7.2"
Decker, Langille, Rijsinghani & McCloghrie [Page 28]
RFC 1493 Bridge MIB July 1993
INDEX { dot1dStaticAddress, dot1dStaticReceivePort }
::= { dot1dStaticTable 1 }
Dot1dStaticEntry ::=
SEQUENCE {
dot1
MacAddress
dot1
INTEGER
dot1
OCTET STRING
dot1
}
dot1dStaticAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"The destination MAC address in a frame to
this entry's filtering information applies.
object can take the value of a unicast address,
group address or the broadcast address."
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2"
::= { dot1dStaticEntry 1 }
dot1dStaticReceivePort OBJECT-
SYNTAX
ACCESS read-
STATUS
"Either the value '0', or the port number of
port from which a frame must be received in
for this entry's filtering information to apply
A value of zero indicates that this entry
on all ports of the bridge for which there is
other applicable entry."
::= { dot1dStaticEntry 2 }
dot1dStaticAllowedToGoTo OBJECT-
SYNTAX OCTET
ACCESS read-
STATUS
"The set of ports to which frames received from
specific port and destined for a specific
Decker, Langille, Rijsinghani & McCloghrie [Page 29]
RFC 1493 Bridge MIB July 1993
address, are allowed to be forwarded. Each
within the value of this object specifies a set
eight ports, with the first octet specifying
1 through 8, the second octet specifying ports 9
through 16, etc. Within each octet, the
significant bit represents the lowest
port, and the least significant bit represents
highest numbered port. Thus, each port of
bridge is represented by a single bit within
value of this object. If that bit has a value
'1' then that port is included in the set
ports; the port is not included if its bit has
value of '0'. (Note that the setting of the
corresponding to the port from which a frame
received is irrelevant.) The default value
this object is a string of ones of
length."
::= { dot1dStaticEntry 3 }
dot1dStaticStatus OBJECT-
SYNTAX INTEGER {
other(1),
invalid(2),
permanent(3),
deleteOnReset(4),
deleteOnTimeout(5)
}
ACCESS read-
STATUS
"This object indicates the status of this entry
The default value is permanent(3).
other(1) - this entry is currently in use
the conditions under which it
remain so are different from each of
following values
invalid(2) - writing this value to the
removes the corresponding entry
permanent(3) - this entry is currently in
and will remain so after the next
of the bridge
deleteOnReset(4) - this entry is currently
use and will remain so until the
reset of the bridge
deleteOnTimeout(5) - this entry is
in use and will remain so until it
aged out."
Decker, Langille, Rijsinghani & McCloghrie [Page 30]
RFC 1493 Bridge MIB July 1993
::= { dot1dStaticEntry 4 }
-- Traps for use by
-- Traps for the Spanning Tree
newRoot TRAP-
ENTERPRISE dot1
"The newRoot trap indicates that the sending
has become the new root of the Spanning Tree;
trap is sent by a bridge soon after its
as the new root, e.g., upon expiration of
Topology Change Timer immediately subsequent
its election. Implementation of this trap
optional."
::= 1
topologyChange TRAP-
ENTERPRISE dot1
"A topologyChange trap is sent by a bridge
any of its configured ports transitions from
Learning state to the Forwarding state, or
the Forwarding state to the Blocking state.
trap is not sent if a newRoot trap is sent for
same transition. Implementation of this trap
optional."
::= 2
6.
This document was produced on behalf of the Bridge Sub-Working
of the SNMP Working Group of the Internet Engineering Task Force
Over the course of its deliberations, the working group received
separate documents for consideration as the basis for its work.
first was submitted by Stan Froyd of Advanced
Communications; the second by Richard Fox of SynOptics; the third
Eric Decker of cisco Inc. and Keith McCloghrie of Hughes LAN Systems
and the fourth by Paul Langille and Anil Rijsinghani of
Equipment Corp. After considering the submissions, the working
chose to proceed with a document formed as a conjunction of
latter two submissions. This document is the result
Decker, Langille, Rijsinghani & McCloghrie [Page 31]
RFC 1493 Bridge MIB July 1993
The authors wish to thank the members of the Bridge Working Group
their many comments and suggestions which improved this effort.
particular, Fred Baker (chairman of the working group) of ACC,
Sherry of Xyplex, and Frank Kastenholz of Clearpoint Research Corp
Others members of the Bridge Working Group who contributed to
effort are
Bill Anderson,
Karl Auerbach,
Fred Baker, ACC (chair
Terry Bradley,
Ted Brunner,
Jeffrey Buffum,
Chris ChioTasso,
Anthony Chung,
Chuck Davin, MIT-
Andy Davis,
Eric Decker,
Nadya El-Afandi, Network
Gary Ellis,HP/
Richard Fox,
Stan Froyd,
Frank Kastenholz, Clearpoint
Shirnshon Kaufman
Jim Kinder,
Cheryl Krupczak,
Paul Langille,
Peter Lin,
Keith McCloghrie,
Donna McMaster,
Dave Perkins, 3
Jim Reinstedler, Ungermann
Anil Rijsinghani,
Mark Schaefer, David
Steve Sherry,
Bob Stewart,
Emil Sturniolo
Kevin Synott,
Ian Thomas,
Maurice Turcott,
Fei Xu
Decker, Langille, Rijsinghani & McCloghrie [Page 32]
RFC 1493 Bridge MIB July 1993
7.
[1] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.
[4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[5] McCloghrie K., and M. Rose, Editors, "Management Information
for Network Management of TCP/IP-based internets", STD 17,
1213, Performance Systems International, March 1991.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization,
Standard 8824, December 1987.
[7] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation
(ASN.1), International Organization for Standardization
International Standard 8825, December 1987.
[8] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes
Systems, March 1991.
[9] Rose, M., Editor, "A Convention for Defining Traps for use
the SNMP", RFC 1215, Performance Systems International,
1991.
[10] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project 802
Local and Metropolitan Area Networks, (March 8, 1991).
[11] ISO DIS 10038 MAC Bridges
8. Security
Security issues are not discussed in this memo
Decker, Langille, Rijsinghani & McCloghrie [Page 33]
RFC 1493 Bridge MIB July 1993
9. Authors'
Eric B.
cisco Systems, Inc
1525 O'Brien Dr
Menlo Park, CA 94025
Phone: (415) 326-1941
Email: cire@cisco.
Paul
Digital Equipment
Digital Drive, MK02-2/K03
Merrimack, NH 03054
Phone: (603) 884-4045
EMail: langille@edwin.enet.dec.
Anil
Digital Equipment
550 King
Littleton, MA 01460
Phone: (508) 486-6786
EMail: anil@levers.enet.dec.
Keith
Hughes LAN Systems, Inc
1225 Charleston
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.
Decker, Langille, Rijsinghani & McCloghrie [Page 34]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
