summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4188.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4188.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4188.txt')
-rw-r--r--doc/rfc/rfc4188.txt2467
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc4188.txt b/doc/rfc/rfc4188.txt
new file mode 100644
index 0000000..686a0e1
--- /dev/null
+++ b/doc/rfc/rfc4188.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group K. Norseth, Ed.
+Request for Comments: 4188 L-3 Communications
+Obsoletes: 1493 E. Bell, Ed.
+Category: Standards Track 3Com Europe Limited
+ September 2005
+
+
+ Definitions of Managed Objects for Bridges
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ 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 on
+ the IEEE 802.1D-1998 standard between Local Area Network (LAN)
+ segments. Provisions are made for the support of transparent
+ bridging. Provisions are also made so that these objects apply to
+ bridges connected by subnetworks other than LAN segments.
+
+ The MIB module presented in this memo is a translation of the
+ BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax.
+
+ This memo obsoletes RFC 1493.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 1]
+
+RFC 4188 Bridge MIB September 2005
+
+
+Table of Contents
+
+ 1. The Internet-Standard Management Framework ......................2
+ 2. Conventions .....................................................2
+ 3. Overview ........................................................3
+ 3.1. Structure of the MIB Module ................................3
+ 3.1.1. The dot1dBase Subtree ...............................6
+ 3.1.2. The dot1dStp Subtree ................................6
+ 3.1.3. The dot1dSr Subtree .................................6
+ 3.1.4. The dot1dTp Subtree .................................6
+ 3.1.5. The dot1dStatic Subtree .............................6
+ 3.2. Relationship to Other MIB Modules ..........................6
+ 3.2.1. Relationship to the SNMPv2-MIB ......................7
+ 3.2.2. Relationship to the IF-MIB ..........................7
+ 4. Definitions .....................................................8
+ 5. IANA Considerations ............................................39
+ 6. Security Considerations ........................................39
+ 7. Acknowledgements ...............................................40
+ 8. Contact Information ............................................41
+ 9. Changes from RFC 1493 ..........................................42
+ 10. References ....................................................42
+ 10.1. Normative References .....................................42
+ 10.2. Informative References ...................................43
+
+1. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL", when they appear in this document, are to be interpreted
+ as described in BCP 14, RFC 2119 [RFC2119].
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 2]
+
+RFC 4188 Bridge MIB September 2005
+
+
+3. Overview
+
+ A common device present in many networks is the Bridge. This device
+ is used to connect Local Area Network segments below the network
+ layer.
+
+ There are two major modes defined for this bridging: transparent and
+ source route. The transparent method of bridging is defined in the
+ IEEE 802.1D specification [IEEE8021D]. This memo defines those
+ objects needed for the management of a bridging entity that operates
+ in the transparent mode, as well as some objects that apply to all
+ types of bridges.
+
+ To be consistent with IAB directives and good engineering practices,
+ an explicit attempt was made to keep this MIB module as simple as
+ possible. This was accomplished by applying the following criteria
+ to objects proposed for inclusion:
+
+ 1. Start with a small set of essential objects and add only as
+ further objects are needed.
+
+ 2. Require that objects be essential for either fault or
+ configuration management.
+
+ 3. Consider evidence of current use and/or utility.
+
+ 4. Limit the total number of objects.
+
+ 5. Exclude objects that are simply derivable from others in this or
+ other MIB modules.
+
+ 6. Avoid causing critical sections to be heavily instrumented. The
+ guideline that was followed is one counter per critical section
+ per layer.
+
+3.1 Structure of the MIB Module
+
+ Objects in this MIB module are arranged into subtrees. Each subtree
+ is organized as a set of related objects. The overall structure and
+ assignment of objects to their subtrees is shown below. Where
+ appropriate, the corresponding IEEE 802.1D [IEEE8021D] management
+ object name is also included.
+
+
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 3]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ Bridge MIB Name IEEE 802.1D Name
+
+ dot1dBridge
+ dot1dBase
+ BridgeAddress Bridge.BridgeAddress
+ NumPorts Bridge.NumberOfPorts
+ Type
+ PortTable
+ Port BridgePort.PortNumber
+ IfIndex
+ Circuit
+ DelayExceededDiscards .DiscardTransitDelay
+ MtuExceededDiscards .DiscardOnError
+ dot1dStp
+ ProtocolSpecification
+ Priority SpanningTreeProtocol
+ .BridgePriority
+ TimeSinceTopologyChange .TimeSinceTopologyChange
+ TopChanges .TopologyChangeCount
+ DesignatedRoot .DesignatedRoot
+ RootCost .RootCost
+ RootPort .RootPort
+ MaxAge .MaxAge
+ HelloTime .HelloTime
+ HoldTime .HoldTime
+ ForwardDelay .ForwardDelay
+ BridgeMaxAge .BridgeMaxAge
+ BridgeHelloTime .BridgeHelloTime
+ BridgeForwardDelay .BridgeForwardDelay
+ PortTable
+ Port SpanningTreeProtocolPort
+ .PortNumber
+ Priority .PortPriority
+ State .SpanningTreeState
+ Enable
+ PathCost .PortPathCost
+ DesignatedRoot .DesignatedRoot
+ DesignatedCost .DesignatedCost
+ DesignatedBridge .DesignatedBridge
+ DesignatedPort .DesignatedPort
+ ForwardTransitions
+
+
+
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 4]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dTp
+ LearnedEntryDiscards BridgeFilter.DatabaseSize
+ .NumDynamic,NumStatic
+ AgingTime BridgeFilter.AgingTime
+ FdbTable
+ Address
+ Port
+ Status
+ PortTable
+ Port
+ MaxInfo
+ InFrames BridgePort.FramesReceived
+ OutFrames .ForwardOutbound
+ InDiscards .DiscardInbound
+ dot1dStatic
+ StaticTable
+ Address
+ ReceivePort
+ AllowedToGoTo
+ Status
+
+ The following IEEE 802.1D management objects have not been included
+ in the BRIDGE-MIB module for the indicated reasons.
+
+ IEEE 802.1D Object Disposition
+
+ Bridge.BridgeName Same as sysDescr (SNMPv2-MIB)
+ Bridge.BridgeUpTime Same as sysUpTime (SNMPv2-MIB)
+ Bridge.PortAddresses Same as ifPhysAddress (IF-MIB)
+ BridgePort.PortName Same as ifDescr (IF-MIB)
+ BridgePort.PortType Same as ifType (IF-MIB)
+ BridgePort.RoutingType Derivable from the implemented
+ subtrees
+
+ SpanningTreeProtocol
+ .BridgeIdentifier Combination of dot1dStpPriority
+ and dot1dBaseBridgeAddress
+ .TopologyChange Since this is transitory, it
+ is not considered useful.
+ SpanningTreeProtocolPort
+ .Uptime Same as ifLastChange (IF-MIB)
+ .PortIdentifier Combination of dot1dStpPort
+ and dot1dStpPortPriority
+ .TopologyChangeAcknowledged Since this is transitory, it
+ is not considered useful.
+ .DiscardLackOfBuffers Redundant
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 5]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ Transmission Priority These objects are not required
+ as per the Pics Proforma and
+ are not considered useful.
+ .TransmissionPriorityName
+ .OutboundUserPriority
+ .OutboundAccessPriority
+
+3.1.1 The dot1dBase Subtree
+
+ This subtree contains the objects that are applicable to all types of
+ bridges.
+
+3.1.2 The dot1dStp Subtree
+
+ This subtree contains the objects that denote the bridge's state with
+ respect to the Spanning Tree Protocol. If a node does not implement
+ the Spanning Tree Protocol, this subtree will not be implemented.
+
+3.1.3 The dot1dSr Subtree
+
+ This subtree contains the objects that describe the entity's state
+ with respect to source route bridging. This subtree described in RFC
+ 1525 [RFC1525] is applicable only to source route bridging.
+
+3.1.4 The dot1dTp Subtree
+
+ This subtree contains objects that describe the entity's state with
+ respect to transparent bridging. If transparent bridging is not
+ supported, this subtree will not be implemented. This subtree is
+ applicable to transparent-only and SRT bridges.
+
+3.1.5 The dot1dStatic Subtree
+
+ This subtree contains objects that describe the entity's state with
+ respect to destination-address filtering. If destination-address
+ filtering is not supported, this subtree will not be implemented.
+ This subtree is applicable to any type of bridge that performs
+ destination-address filtering.
+
+3.2 Relationship to Other MIB Modules
+
+ As described above, some IEEE 802.1D management objects have not been
+ included in this MIB module because they overlap with objects in
+ other MIB modules that are applicable to a bridge implementing this
+ MIB module.
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 6]
+
+RFC 4188 Bridge MIB September 2005
+
+
+3.2.1 Relationship to the SNMPv2-MIB
+
+ The SNMPv2-MIB [RFC3418] defines objects that are generally
+ applicable to managed devices. These objects apply to the device as
+ a whole, irrespective of whether the device's sole functionality is
+ bridging, or whether bridging is only a subset of the device's
+ functionality.
+
+ As explained in Section 3.1, full support for the 802.1D management
+ objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime
+ be implemented. Note that compliance with the current SNMPv2-MIB
+ module requires additional objects and notifications to be
+ implemented, as specified in RFC 3418 [RFC3418].
+
+3.2.2 Relationship to the IF-MIB
+
+ The IF-MIB [RFC2863] defines managed objects for managing network
+ interfaces. A network interface is thought of as being attached to a
+ `subnetwork'. Note that this term is not to be confused with
+ `subnet', which refers to an addressing partitioning scheme used in
+ the Internet suite of protocols. The term 'segment' is used in this
+ memo to refer to such a subnetwork, whether it be an Ethernet
+ segment, a 'ring', a WAN link, or even an X.25 virtual circuit.
+
+ As explained in Section 3.1, full support for the 802.1D management
+ objects requires that the IF-MIB objects ifIndex, ifType, ifDescr,
+ ifPhysAddress, and ifLastChange are implemented. Note that
+ compliance to the current IF-MIB module requires additional objects
+ and notifications to be implemented as specified in RFC 2863
+ [RFC2863].
+
+ Implicit in this BRIDGE-MIB is the notion of ports on a bridge. Each
+ of these ports is associated with one interface of the 'interfaces'
+ subtree, and in most situations, each port is associated with a
+ different interface. However, there are situations in which multiple
+ ports are associated with the same interface. An example of such a
+ situation would be several ports, each corresponding, one-to-one,
+ with several X.25 virtual circuits that are all on the same
+ interface.
+
+ Each port is uniquely identified by a port number. A port number has
+ no mandatory relationship to an interface number, but in the simple
+ case, a port number will have the same value as the corresponding
+ interface's interface number. Port numbers are in the range
+ (1..dot1dBaseNumPorts).
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 7]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ Some entities perform other functionalities as well as bridging
+ through the sending and receiving of data on their interfaces. In
+ such situations, only a subset of the data sent/received on an
+ interface is within the domain of the entity's bridging
+ functionality. This subset is considered to be delineated according
+ to a set of protocols, with some protocols being bridged, and other
+ protocols not being bridged. For example, in an entity that
+ exclusively performs bridging, all protocols would be considered as
+ bridged, whereas in an entity that performs IP routing on IP
+ datagrams and only bridges other protocols, only the non-IP data
+ would be considered as having been bridged.
+
+ Thus, this BRIDGE-MIB (and in particular, its counters) are
+ applicable only to that subset of the data on an entity's interfaces
+ that is sent/received for a protocol being bridged. All such data is
+ sent/received via the ports of the bridge.
+
+4. Definitions
+
+ BRIDGE-MIB DEFINITIONS ::= BEGIN
+
+ -- ---------------------------------------------------------- --
+ -- MIB for IEEE 802.1D devices
+ -- ---------------------------------------------------------- --
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+ Counter32, Integer32, TimeTicks, mib-2
+ FROM SNMPv2-SMI
+ TEXTUAL-CONVENTION, MacAddress
+ FROM SNMPv2-TC
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF
+ InterfaceIndex FROM IF-MIB
+ ;
+
+ dot1dBridge MODULE-IDENTITY
+ LAST-UPDATED "200509190000Z"
+ ORGANIZATION "IETF Bridge MIB Working Group"
+ CONTACT-INFO
+ "Email: bridge-mib@ietf.org
+
+ K.C. Norseth (Editor)
+ L-3 Communications
+ Tel: +1 801-594-2809
+ Email: kenyon.c.norseth@L-3com.com
+ Postal: 640 N. 2200 West.
+ Salt Lake City, Utah 84116-0850
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 8]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ Les Bell (Editor)
+ 3Com Europe Limited
+ Phone: +44 1442 438025
+ Email: elbell@ntlworld.com
+ Postal: 3Com Centre, Boundary Way
+ Hemel Hempstead
+ Herts. HP2 7YU
+ UK
+
+ Send comments to <bridge-mib@ietf.org>"
+ DESCRIPTION
+ "The Bridge MIB module for managing devices that support
+ IEEE 802.1D.
+
+ Copyright (C) The Internet Society (2005). This version of
+ this MIB module is part of RFC 4188; see the RFC itself for
+ full legal notices."
+ REVISION "200509190000Z"
+ DESCRIPTION
+ "Third revision, published as part of RFC 4188.
+
+ The MIB module has been converted to SMIv2 format.
+ Conformance statements have been added and some
+ description and reference clauses have been updated.
+
+ The object dot1dStpPortPathCost32 was added to
+ support IEEE 802.1t and the permissible values of
+ dot1dStpPriority and dot1dStpPortPriority have been
+ clarified for bridges supporting IEEE 802.1t or
+ IEEE 802.1w.
+
+ The interpretation of dot1dStpTimeSinceTopologyChange
+ has been clarified for bridges supporting the Rapid
+ Spanning Tree Protocol (RSTP)."
+ REVISION "199307310000Z"
+ DESCRIPTION
+ "Second revision, published as part of RFC 1493."
+ REVISION "199112310000Z"
+ DESCRIPTION
+ "Initial revision, published as part of RFC 1286."
+ ::= { mib-2 17 }
+
+
+ -- ---------------------------------------------------------- --
+ -- Textual Conventions
+ -- ---------------------------------------------------------- --
+
+ BridgeId ::= TEXTUAL-CONVENTION
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 9]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ STATUS current
+ DESCRIPTION
+ "The Bridge-Identifier, as used in the Spanning Tree
+ Protocol, to uniquely identify a bridge. Its first two
+ octets (in network byte order) contain a priority value,
+ and its last 6 octets contain the MAC address used to
+ refer to a bridge in a unique fashion (typically, the
+ numerically smallest MAC address of all ports on the
+ bridge)."
+ SYNTAX OCTET STRING (SIZE (8))
+
+ Timeout ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "d"
+ STATUS current
+ DESCRIPTION
+ "A Spanning Tree Protocol (STP) timer in units of 1/100
+ seconds. Several objects in this MIB module represent
+ values of timers used by the Spanning Tree Protocol.
+ In this MIB, these timers have values in units of
+ hundredths of a second (i.e., 1/100 secs).
+
+ These timers, when stored in a Spanning Tree Protocol's
+ BPDU, are in units of 1/256 seconds. Note, however, that
+ 802.1D-1998 specifies a settable granularity of no more
+ than one second for these timers. To avoid ambiguity,
+ a conversion algorithm is defined below for converting
+ between the different units, which ensures a timer's
+ value is not distorted by multiple conversions.
+
+ To convert a Timeout value into a value in units of
+ 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 units
+ b is the value in 1/256 second units
+
+ To convert the value from 1/256 second units back to
+ 1/100 seconds, the following algorithm should be used:
+
+ n = ceiling( (b * 100) / 256)
+
+ where:
+ ceiling = quotient [if remainder is 0], or
+ quotient + 1 [if remainder is nonzero]
+ n is the value in 1/100 second units
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 10]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ b is the value in 1/256 second units
+
+ Note: it is important that the arithmetic operations are
+ done in the order specified (i.e., multiply first,
+ divide second)."
+ SYNTAX Integer32
+
+ -- ---------------------------------------------------------- --
+ -- subtrees in the Bridge MIB
+ -- ---------------------------------------------------------- --
+
+ dot1dNotifications OBJECT IDENTIFIER ::= { dot1dBridge 0 }
+
+ dot1dBase OBJECT IDENTIFIER ::= { dot1dBridge 1 }
+ dot1dStp OBJECT IDENTIFIER ::= { dot1dBridge 2 }
+
+ dot1dSr OBJECT IDENTIFIER ::= { dot1dBridge 3 }
+ -- documented in RFC 1525
+
+ dot1dTp OBJECT IDENTIFIER ::= { dot1dBridge 4 }
+ dot1dStatic OBJECT IDENTIFIER ::= { dot1dBridge 5 }
+
+ -- Subtrees used by Bridge MIB Extensions:
+ -- pBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 6 }
+ -- qBridgeMIB MODULE-IDENTITY ::= { dot1dBridge 7 }
+ -- Note that the practice of registering related MIB modules
+ -- below dot1dBridge has been discouraged since there is no
+ -- robust mechanism to track such registrations.
+
+ dot1dConformance OBJECT IDENTIFIER ::= { dot1dBridge 8 }
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dBase subtree
+ -- ---------------------------------------------------------- --
+ -- Implementation of the dot1dBase subtree is mandatory for all
+ -- bridges.
+ -- ---------------------------------------------------------- --
+
+ dot1dBaseBridgeAddress OBJECT-TYPE
+
+ SYNTAX MacAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The MAC address used by this bridge when it must be
+ referred to in a unique fashion. It is recommended
+ that this be the numerically smallest MAC address of
+ all ports that belong to this bridge. However, it is only
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 11]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ required to be unique. When concatenated with
+ dot1dStpPriority, a unique BridgeIdentifier is formed,
+ which is used in the Spanning Tree Protocol."
+ REFERENCE
+ "IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5"
+ ::= { dot1dBase 1 }
+
+ dot1dBaseNumPorts OBJECT-TYPE
+ SYNTAX Integer32
+ UNITS "ports"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of ports controlled by this bridging
+ entity."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.4.1.1.3"
+ ::= { dot1dBase 2 }
+
+ dot1dBaseType OBJECT-TYPE
+ SYNTAX INTEGER {
+ unknown(1),
+ transparent-only(2),
+ sourceroute-only(3),
+ srt(4)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Indicates what type of bridging this bridge can
+ perform. If a bridge is actually performing a
+ certain type of bridging, this will be indicated by
+ entries in the port table for the given type."
+ ::= { dot1dBase 3 }
+
+ -- ---------------------------------------------------------- --
+ -- The Generic Bridge Port Table
+ -- ---------------------------------------------------------- --
+ dot1dBasePortTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dBasePortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table that contains generic information about every
+ port that is associated with this bridge. Transparent,
+ source-route, and srt ports are included."
+ ::= { dot1dBase 4 }
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 12]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dBasePortEntry OBJECT-TYPE
+ SYNTAX Dot1dBasePortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+
+ DESCRIPTION
+ "A list of information for each port of the bridge."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.4.2, 14.6.1"
+ INDEX { dot1dBasePort }
+ ::= { dot1dBasePortTable 1 }
+
+ Dot1dBasePortEntry ::=
+ SEQUENCE {
+ dot1dBasePort
+ Integer32,
+ dot1dBasePortIfIndex
+ InterfaceIndex,
+ dot1dBasePortCircuit
+ OBJECT IDENTIFIER,
+ dot1dBasePortDelayExceededDiscards
+ Counter32,
+ dot1dBasePortMtuExceededDiscards
+ Counter32
+ }
+
+ dot1dBasePort OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The port number of the port for which this entry
+ contains bridge management information."
+ ::= { dot1dBasePortEntry 1 }
+
+ dot1dBasePortIfIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of the instance of the ifIndex object,
+ defined in IF-MIB, for the interface corresponding
+ to this port."
+ ::= { dot1dBasePortEntry 2 }
+
+ dot1dBasePortCircuit OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ MAX-ACCESS read-only
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 13]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ STATUS current
+ DESCRIPTION
+ "For a port that (potentially) has the same value of
+ dot1dBasePortIfIndex as another port on the same bridge.
+ This object contains the name of an object instance
+ unique to this port. For example, in the case where
+ multiple ports correspond one-to-one with multiple X.25
+ virtual circuits, this value might identify an (e.g.,
+ the first) object instance associated with the X.25
+ virtual circuit corresponding to this port.
+
+ For a port which has a unique value of
+ dot1dBasePortIfIndex, this object can have the value
+ { 0 0 }."
+ ::= { dot1dBasePortEntry 3 }
+
+ dot1dBasePortDelayExceededDiscards OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of frames discarded by this port due
+ to excessive transit delay through the bridge. It
+ is incremented by both transparent and source
+ route bridges."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.6.1.1.3"
+ ::= { dot1dBasePortEntry 4 }
+
+ dot1dBasePortMtuExceededDiscards OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of frames discarded by this port due
+ to an excessive size. It is incremented by both
+ transparent and source route bridges."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.6.1.1.3"
+ ::= { dot1dBasePortEntry 5 }
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dStp subtree
+ -- ---------------------------------------------------------- --
+ -- Implementation of the dot1dStp subtree is optional. It is
+ -- implemented by those bridges that support the Spanning Tree
+ -- Protocol.
+ -- ---------------------------------------------------------- --
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 14]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dStpProtocolSpecification OBJECT-TYPE
+ SYNTAX INTEGER {
+ unknown(1),
+ decLb100(2),
+ ieee8021d(3)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "An indication of what version of the Spanning Tree
+ Protocol is being run. The value 'decLb100(2)'
+ indicates the DEC LANbridge 100 Spanning Tree protocol.
+ IEEE 802.1D implementations will return 'ieee8021d(3)'.
+ If future versions of the IEEE Spanning Tree Protocol
+ that are incompatible with the current version
+ are released a new value will be defined."
+ ::= { dot1dStp 1 }
+
+ dot1dStpPriority OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value of the write-able portion of the Bridge ID
+ (i.e., the first two octets of the (8 octet long) Bridge
+ ID). The other (last) 6 octets of the Bridge ID are
+ given by the value of dot1dBaseBridgeAddress.
+ On bridges supporting IEEE 802.1t or IEEE 802.1w,
+ permissible values are 0-61440, in steps of 4096."
+ REFERENCE
+ "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
+ IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
+ ::= { dot1dStp 2 }
+
+ dot1dStpTimeSinceTopologyChange OBJECT-TYPE
+ SYNTAX TimeTicks
+ UNITS "centi-seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The time (in hundredths of a second) since the
+ last time a topology change was detected by the
+ bridge entity.
+ For RSTP, this reports the time since the tcWhile
+ timer for any port on this Bridge was nonzero."
+ REFERENCE
+ "IEEE 802.1D-1998 clause 14.8.1.1.,
+ IEEE 802.1w clause 14.8.1.1."
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 15]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ ::= { dot1dStp 3 }
+
+ dot1dStpTopChanges OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of topology changes detected by
+ this bridge since the management entity was last
+ reset or initialized."
+ REFERENCE
+ "IEEE 802.1D-1998 clause 14.8.1.1."
+ ::= { dot1dStp 4 }
+
+ dot1dStpDesignatedRoot OBJECT-TYPE
+ SYNTAX BridgeId
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The bridge identifier of the root of the spanning
+ tree, as determined by the Spanning Tree Protocol,
+ as executed by this node. This value is used as
+ the Root Identifier parameter in all Configuration
+ Bridge PDUs originated by this node."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.1"
+ ::= { dot1dStp 5 }
+
+ dot1dStpRootCost OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The cost of the path to the root as seen from
+ this bridge."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.2"
+ ::= { dot1dStp 6 }
+
+ dot1dStpRootPort OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The port number of the port that offers the lowest
+ cost path from this bridge to the root bridge."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.3"
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 16]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ ::= { dot1dStp 7 }
+
+ dot1dStpMaxAge OBJECT-TYPE
+ SYNTAX Timeout
+ UNITS "centi-seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The maximum age of Spanning Tree Protocol information
+ learned from the network on any port before it is
+ discarded, in units of hundredths of a second. This is
+ the actual value that this bridge is currently using."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.4"
+ ::= { dot1dStp 8 }
+
+ dot1dStpHelloTime OBJECT-TYPE
+ SYNTAX Timeout
+ UNITS "centi-seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The amount of time between the transmission of
+ Configuration bridge PDUs by this node on any port when
+ it is the root of the spanning tree, or trying to become
+ so, in units of hundredths of a second. This is the
+ actual value that this bridge is currently using."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.5"
+ ::= { dot1dStp 9 }
+
+ dot1dStpHoldTime OBJECT-TYPE
+ SYNTAX Integer32
+ UNITS "centi-seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This time value determines the interval length
+ during which no more than two Configuration bridge
+ PDUs shall be transmitted by this node, in units
+ of hundredths of a second."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.14"
+ ::= { dot1dStp 10 }
+
+ dot1dStpForwardDelay OBJECT-TYPE
+ SYNTAX Timeout
+ UNITS "centi-seconds"
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 17]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This time value, measured in units of hundredths of a
+ second, controls how fast a port changes its spanning
+ state when moving towards the Forwarding state. The
+ value determines how long the port stays in each of the
+ Listening and Learning states, which precede the
+ Forwarding state. This value is also used when a
+ topology change has been detected and is underway, to
+ age all dynamic entries in the Forwarding Database.
+ [Note that this value is the one that this bridge is
+ currently using, in contrast to
+ dot1dStpBridgeForwardDelay, which is the value that this
+ bridge and all others would start using if/when this
+ bridge were to become the root.]"
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.6"
+ ::= { dot1dStp 11 }
+
+ dot1dStpBridgeMaxAge OBJECT-TYPE
+ SYNTAX Timeout (600..4000)
+ UNITS "centi-seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value that all bridges use for MaxAge when this
+ bridge is acting as the root. Note that 802.1D-1998
+ specifies that the range for this parameter is related
+ to the value of dot1dStpBridgeHelloTime. The
+ granularity of this timer is specified by 802.1D-1998 to
+ be 1 second. An agent may return a badValue error if a
+ set is attempted to a value that is not a whole number
+ of seconds."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.8"
+ ::= { dot1dStp 12 }
+
+ dot1dStpBridgeHelloTime OBJECT-TYPE
+ SYNTAX Timeout (100..1000)
+ UNITS "centi-seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value that all bridges use for HelloTime when this
+ bridge is acting as the root. The granularity of this
+ timer is specified by 802.1D-1998 to be 1 second. An
+ agent may return a badValue error if a set is attempted
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 18]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ to a value that is not a whole number of seconds."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.9"
+ ::= { dot1dStp 13 }
+
+ dot1dStpBridgeForwardDelay OBJECT-TYPE
+ SYNTAX Timeout (400..3000)
+ UNITS "centi-seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value that all bridges use for ForwardDelay when
+ this bridge is acting as the root. Note that
+ 802.1D-1998 specifies that the range for this parameter
+ is related to the value of dot1dStpBridgeMaxAge. The
+ granularity of this timer is specified by 802.1D-1998 to
+ be 1 second. An agent may return a badValue error if a
+ set is attempted to a value that is not a whole number
+ of seconds."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.3.10"
+ ::= { dot1dStp 14 }
+
+ -- ---------------------------------------------------------- --
+ -- The Spanning Tree Port Table
+ -- ---------------------------------------------------------- --
+
+ dot1dStpPortTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dStpPortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table that contains port-specific information
+ for the Spanning Tree Protocol."
+ ::= { dot1dStp 15 }
+
+ dot1dStpPortEntry OBJECT-TYPE
+ SYNTAX Dot1dStpPortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of information maintained by every port about
+ the Spanning Tree Protocol state for that port."
+ INDEX { dot1dStpPort }
+ ::= { dot1dStpPortTable 1 }
+
+ Dot1dStpPortEntry ::=
+ SEQUENCE {
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 19]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dStpPort
+ Integer32,
+ dot1dStpPortPriority
+ Integer32,
+ dot1dStpPortState
+ INTEGER,
+ dot1dStpPortEnable
+ INTEGER,
+ dot1dStpPortPathCost
+ Integer32,
+ dot1dStpPortDesignatedRoot
+ BridgeId,
+ dot1dStpPortDesignatedCost
+ Integer32,
+ dot1dStpPortDesignatedBridge
+ BridgeId,
+ dot1dStpPortDesignatedPort
+ OCTET STRING,
+ dot1dStpPortForwardTransitions
+ Counter32,
+ dot1dStpPortPathCost32
+ Integer32
+ }
+
+ dot1dStpPort OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The port number of the port for which this entry
+ contains Spanning Tree Protocol management information."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.8.2.1.2"
+ ::= { dot1dStpPortEntry 1 }
+
+ dot1dStpPortPriority OBJECT-TYPE
+ SYNTAX Integer32 (0..255)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The value of the priority field that is contained in
+ the first (in network byte order) octet of the (2 octet
+ long) Port ID. The other octet of the Port ID is given
+ by the value of dot1dStpPort.
+ On bridges supporting IEEE 802.1t or IEEE 802.1w,
+ permissible values are 0-240, in steps of 16."
+ REFERENCE
+ "IEEE 802.1D-1998 clause 8.10.2, Table 8-4,
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 20]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3."
+ ::= { dot1dStpPortEntry 2 }
+
+ dot1dStpPortState OBJECT-TYPE
+ SYNTAX INTEGER {
+ disabled(1),
+ blocking(2),
+ listening(3),
+ learning(4),
+ forwarding(5),
+ broken(6)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The port's current state, as defined by application of
+ the Spanning Tree Protocol. This state controls what
+ action a port takes on reception of a frame. If the
+ bridge has detected a port that is malfunctioning, it
+ will place that port into the broken(6) state. For
+ ports that are disabled (see dot1dStpPortEnable), this
+ object will have a value of disabled(1)."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.2"
+ ::= { dot1dStpPortEntry 3 }
+
+ dot1dStpPortEnable OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The enabled/disabled status of the port."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.2"
+ ::= { dot1dStpPortEntry 4 }
+
+ dot1dStpPortPathCost OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The contribution of this port to the path cost of
+ paths towards the spanning tree root which include
+ this port. 802.1D-1998 recommends that the default
+ value of this parameter be in inverse proportion to
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 21]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ the speed of the attached LAN.
+
+ New implementations should support dot1dStpPortPathCost32.
+ If the port path costs exceeds the maximum value of this
+ object then this object should report the maximum value,
+ namely 65535. Applications should try to read the
+ dot1dStpPortPathCost32 object if this object reports
+ the maximum value."
+ REFERENCE "IEEE 802.1D-1998: clause 8.5.5.3"
+ ::= { dot1dStpPortEntry 5 }
+
+ dot1dStpPortDesignatedRoot OBJECT-TYPE
+ SYNTAX BridgeId
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The unique Bridge Identifier of the Bridge
+ recorded as the Root in the Configuration BPDUs
+ transmitted by the Designated Bridge for the
+ segment to which the port is attached."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.4"
+ ::= { dot1dStpPortEntry 6 }
+
+ dot1dStpPortDesignatedCost OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The path cost of the Designated Port of the segment
+ connected to this port. This value is compared to the
+ Root Path Cost field in received bridge PDUs."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.5"
+ ::= { dot1dStpPortEntry 7 }
+
+ dot1dStpPortDesignatedBridge OBJECT-TYPE
+ SYNTAX BridgeId
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The Bridge Identifier of the bridge that this
+ port considers to be the Designated Bridge for
+ this port's segment."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.6"
+ ::= { dot1dStpPortEntry 8 }
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 22]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dStpPortDesignatedPort OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (2))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The Port Identifier of the port on the Designated
+ Bridge for this port's segment."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 8.5.5.7"
+ ::= { dot1dStpPortEntry 9 }
+
+ dot1dStpPortForwardTransitions OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of times this port has transitioned
+ from the Learning state to the Forwarding state."
+ ::= { dot1dStpPortEntry 10 }
+
+ dot1dStpPortPathCost32 OBJECT-TYPE
+ SYNTAX Integer32 (1..200000000)
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The contribution of this port to the path cost of
+ paths towards the spanning tree root which include
+ this port. 802.1D-1998 recommends that the default
+ value of this parameter be in inverse proportion to
+ the speed of the attached LAN.
+
+ This object replaces dot1dStpPortPathCost to support
+ IEEE 802.1t."
+ REFERENCE
+ "IEEE 802.1t clause 8.10.2, Table 8-5."
+ ::= { dot1dStpPortEntry 11 }
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dTp subtree
+ -- ---------------------------------------------------------- --
+ -- Implementation of the dot1dTp subtree is optional. It is
+ -- implemented by those bridges that support the transparent
+ -- bridging mode. A transparent or SRT bridge will implement
+ -- this subtree.
+ -- ---------------------------------------------------------- --
+
+ dot1dTpLearnedEntryDiscards OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 23]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of Forwarding Database entries that
+ have been or would have been learned, but have been
+ discarded due to a lack of storage space in the
+ Forwarding Database. If this counter is increasing, it
+ indicates that the Forwarding Database is regularly
+ becoming full (a condition that has unpleasant
+ performance effects on the subnetwork). If this counter
+ has a significant value but is not presently increasing,
+ it indicates that the problem has been occurring but is
+ not persistent."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.7.1.1.3"
+ ::= { dot1dTp 1 }
+
+ dot1dTpAgingTime OBJECT-TYPE
+ SYNTAX Integer32 (10..1000000)
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The timeout period in seconds for aging out
+ dynamically-learned forwarding information.
+ 802.1D-1998 recommends a default of 300 seconds."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.7.1.1.3"
+ ::= { dot1dTp 2 }
+
+
+ -- ---------------------------------------------------------- --
+ -- The Forwarding Database for Transparent Bridges
+ -- ---------------------------------------------------------- --
+
+ dot1dTpFdbTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dTpFdbEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table that contains information about unicast
+ entries for which the bridge has forwarding and/or
+ filtering information. This information is used
+ by the transparent bridging function in
+ determining how to propagate a received frame."
+ ::= { dot1dTp 3 }
+
+ dot1dTpFdbEntry OBJECT-TYPE
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 24]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ SYNTAX Dot1dTpFdbEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information about a specific unicast MAC address
+ for which the bridge has some forwarding and/or
+ filtering information."
+ INDEX { dot1dTpFdbAddress }
+ ::= { dot1dTpFdbTable 1 }
+
+ Dot1dTpFdbEntry ::=
+ SEQUENCE {
+ dot1dTpFdbAddress
+ MacAddress,
+ dot1dTpFdbPort
+ Integer32,
+ dot1dTpFdbStatus
+ INTEGER
+ }
+
+ dot1dTpFdbAddress OBJECT-TYPE
+ SYNTAX MacAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A unicast MAC address for which the bridge has
+ forwarding and/or filtering information."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
+ ::= { dot1dTpFdbEntry 1 }
+
+ dot1dTpFdbPort OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Either the value '0', or the port number of the port on
+ which a frame having a source address equal to the value
+ of the corresponding instance of dot1dTpFdbAddress has
+ been seen. A value of '0' indicates that the port
+ number has not been learned, but that the bridge does
+ have some forwarding/filtering information about this
+ address (e.g., in the dot1dStaticTable). Implementors
+ are encouraged to assign the port value to this object
+ whenever it is learned, even for addresses for which the
+ corresponding value of dot1dTpFdbStatus is not
+ learned(3)."
+ ::= { dot1dTpFdbEntry 2 }
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 25]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dTpFdbStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1),
+ invalid(2),
+ learned(3),
+ self(4),
+ mgmt(5)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The status of this entry. The meanings of the
+ values are:
+ other(1) - none of the following. This would
+ include the case where some other MIB object
+ (not the corresponding instance of
+ dot1dTpFdbPort, nor an entry in the
+ dot1dStaticTable) is being used to determine if
+ and how frames addressed to the value of the
+ corresponding instance of dot1dTpFdbAddress are
+ being forwarded.
+ invalid(2) - this entry is no longer valid (e.g.,
+ it was learned but has since aged out), but has
+ not yet been flushed from the table.
+ learned(3) - the value of the corresponding instance
+ of dot1dTpFdbPort was learned, and is being
+ used.
+ self(4) - the value of the corresponding instance of
+ dot1dTpFdbAddress represents one of the bridge's
+ addresses. The corresponding instance of
+ dot1dTpFdbPort indicates which of the bridge's
+ ports has this address.
+ mgmt(5) - the value of the corresponding instance of
+ dot1dTpFdbAddress is also the value of an
+ existing instance of dot1dStaticAddress."
+ ::= { dot1dTpFdbEntry 3 }
+
+ -- ---------------------------------------------------------- --
+ -- Port Table for Transparent Bridges
+ -- ---------------------------------------------------------- --
+
+ dot1dTpPortTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dTpPortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table that contains information about every port that
+ is associated with this transparent bridge."
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 26]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ ::= { dot1dTp 4 }
+
+ dot1dTpPortEntry OBJECT-TYPE
+ SYNTAX Dot1dTpPortEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A list of information for each port of a transparent
+ bridge."
+ INDEX { dot1dTpPort }
+ ::= { dot1dTpPortTable 1 }
+
+ Dot1dTpPortEntry ::=
+ SEQUENCE {
+ dot1dTpPort
+ Integer32,
+ dot1dTpPortMaxInfo
+ Integer32,
+ dot1dTpPortInFrames
+ Counter32,
+ dot1dTpPortOutFrames
+ Counter32,
+ dot1dTpPortInDiscards
+ Counter32
+ }
+
+ dot1dTpPort OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The port number of the port for which this entry
+ contains Transparent bridging management information."
+ ::= { dot1dTpPortEntry 1 }
+
+ -- It would be nice if we could use ifMtu as the size of the
+ -- largest INFO field, but we can't because ifMtu is defined
+ -- to be the size that the (inter-)network layer can use, which
+ -- can differ from the MAC layer (especially if several layers
+ -- of encapsulation are used).
+
+ dot1dTpPortMaxInfo OBJECT-TYPE
+ SYNTAX Integer32
+ UNITS "bytes"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The maximum size of the INFO (non-MAC) field that
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 27]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ this port will receive or transmit."
+ ::= { dot1dTpPortEntry 2 }
+
+ dot1dTpPortInFrames OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "frames"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of frames that have been received by this
+ port from its segment. Note that a frame received on the
+ interface corresponding to this port is only counted by
+ this object if and only if it is for a protocol being
+ processed by the local bridging function, including
+ bridge management frames."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.6.1.1.3"
+ ::= { dot1dTpPortEntry 3 }
+
+ dot1dTpPortOutFrames OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "frames"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of frames that have been transmitted by this
+ port to its segment. Note that a frame transmitted on
+ the interface corresponding to this port is only counted
+ by this object if and only if it is for a protocol being
+ processed by the local bridging function, including
+ bridge management frames."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.6.1.1.3"
+ ::= { dot1dTpPortEntry 4 }
+
+ dot1dTpPortInDiscards OBJECT-TYPE
+ SYNTAX Counter32
+ UNITS "frames"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of received valid frames that were discarded
+ (i.e., filtered) by the Forwarding Process."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.6.1.1.3"
+ ::= { dot1dTpPortEntry 5 }
+
+ -- ---------------------------------------------------------- --
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 28]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ -- The Static (Destination-Address Filtering) Database
+ -- ---------------------------------------------------------- --
+ -- Implementation of this subtree is optional.
+ -- ---------------------------------------------------------- --
+
+ dot1dStaticTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Dot1dStaticEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "A table containing filtering information configured
+ into the bridge by (local or network) management
+ specifying the set of ports to which frames received
+ from specific ports and containing specific destination
+ addresses are allowed to be forwarded. The value of
+ zero in this table, as the port number from which frames
+ with a specific destination address are received, is
+ used to specify all ports for which there is no specific
+ entry in this table for that particular destination
+ address. Entries are valid for unicast and for
+ group/broadcast addresses."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.7.2"
+ ::= { dot1dStatic 1 }
+
+ dot1dStaticEntry OBJECT-TYPE
+ SYNTAX Dot1dStaticEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Filtering information configured into the bridge by
+ (local or network) management specifying the set of
+ ports to which frames received from a specific port and
+ containing a specific destination address are allowed to
+ be forwarded."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 14.7.2"
+ INDEX { dot1dStaticAddress, dot1dStaticReceivePort }
+ ::= { dot1dStaticTable 1 }
+
+ Dot1dStaticEntry ::=
+ SEQUENCE {
+ dot1dStaticAddress MacAddress,
+ dot1dStaticReceivePort Integer32,
+ dot1dStaticAllowedToGoTo OCTET STRING,
+ dot1dStaticStatus INTEGER
+ }
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 29]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dStaticAddress OBJECT-TYPE
+ SYNTAX MacAddress
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The destination MAC address in a frame to which this
+ entry's filtering information applies. This object can
+ take the value of a unicast address, a group address, or
+ the broadcast address."
+ REFERENCE
+ "IEEE 802.1D-1998: clause 7.9.1, 7.9.2"
+ ::= { dot1dStaticEntry 1 }
+
+ dot1dStaticReceivePort OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Either the value '0', or the port number of the port
+ from which a frame must be received in order for this
+ entry's filtering information to apply. A value of zero
+ indicates that this entry applies on all ports of the
+ bridge for which there is no other applicable entry."
+ ::= { dot1dStaticEntry 2 }
+
+ dot1dStaticAllowedToGoTo OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (0..512))
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The set of ports to which frames received from a
+ specific port and destined for a specific MAC address,
+ are allowed to be forwarded. Each octet within the
+ value of this object specifies a set of eight ports,
+ with the first octet specifying ports 1 through 8, the
+ second octet specifying ports 9 through 16, etc. Within
+ each octet, the most significant bit represents the
+ lowest numbered port, and the least significant bit
+ represents the highest numbered port. Thus, each port
+ of the bridge is represented by a single bit within the
+ value of this object. If that bit has a value of '1',
+ then that port is included in the set of ports; the port
+ is not included if its bit has a value of '0'. (Note
+ that the setting of the bit corresponding to the port
+ from which a frame is received is irrelevant.) The
+ default value of this object is a string of ones of
+ appropriate length.
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 30]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ The value of this object may exceed the required minimum
+ maximum message size of some SNMP transport (484 bytes,
+ in the case of SNMP over UDP, see RFC 3417, section 3.2).
+ SNMP engines on bridges supporting a large number of
+ ports must support appropriate maximum message sizes."
+ ::= { dot1dStaticEntry 3 }
+
+ dot1dStaticStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1),
+ invalid(2),
+ permanent(3),
+ deleteOnReset(4),
+ deleteOnTimeout(5)
+ }
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "This object indicates the status of this entry.
+ The default value is permanent(3).
+ other(1) - this entry is currently in use but the
+ conditions under which it will remain so are
+ different from each of the following values.
+ invalid(2) - writing this value to the object
+ removes the corresponding entry.
+ permanent(3) - this entry is currently in use and
+ will remain so after the next reset of the
+ bridge.
+ deleteOnReset(4) - this entry is currently in use
+ and will remain so until the next reset of the
+ bridge.
+ deleteOnTimeout(5) - this entry is currently in use
+ and will remain so until it is aged out."
+ ::= { dot1dStaticEntry 4 }
+
+ -- ---------------------------------------------------------- --
+ -- Notifications for use by Bridges
+ -- ---------------------------------------------------------- --
+ -- Notifications for the Spanning Tree Protocol
+ -- ---------------------------------------------------------- --
+
+ newRoot NOTIFICATION-TYPE
+ -- OBJECTS { }
+ STATUS current
+ DESCRIPTION
+ "The newRoot trap indicates that the sending agent has
+ become the new root of the Spanning Tree; the trap is
+ sent by a bridge soon after its election as the new
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 31]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ root, e.g., upon expiration of the Topology Change Timer,
+ immediately subsequent to its election. Implementation
+ of this trap is optional."
+ ::= { dot1dNotifications 1 }
+
+ topologyChange NOTIFICATION-TYPE
+ -- OBJECTS { }
+ STATUS current
+ DESCRIPTION
+ "A topologyChange trap is sent by a bridge when any of
+ its configured ports transitions from the Learning state
+ to the Forwarding state, or from the Forwarding state to
+ the Blocking state. The trap is not sent if a newRoot
+ trap is sent for the same transition. Implementation of
+ this trap is optional."
+ ::= { dot1dNotifications 2 }
+
+ -- ---------------------------------------------------------- --
+ -- IEEE 802.1D MIB - Conformance Information
+ -- ---------------------------------------------------------- --
+
+ dot1dGroups OBJECT IDENTIFIER ::= { dot1dConformance 1 }
+ dot1dCompliances OBJECT IDENTIFIER ::= { dot1dConformance 2 }
+
+ -- ---------------------------------------------------------- --
+ -- units of conformance
+ -- ---------------------------------------------------------- --
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dBase group
+ -- ---------------------------------------------------------- --
+
+ dot1dBaseBridgeGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dBaseBridgeAddress,
+ dot1dBaseNumPorts,
+ dot1dBaseType
+ }
+ STATUS current
+ DESCRIPTION
+ "Bridge level information for this device."
+ ::= { dot1dGroups 1 }
+
+ dot1dBasePortGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dBasePort,
+ dot1dBasePortIfIndex,
+ dot1dBasePortCircuit,
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 32]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dBasePortDelayExceededDiscards,
+ dot1dBasePortMtuExceededDiscards
+ }
+ STATUS current
+ DESCRIPTION
+ "Information for each port on this device."
+ ::= { dot1dGroups 2 }
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dStp group
+ -- ---------------------------------------------------------- --
+
+ dot1dStpBridgeGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dStpProtocolSpecification,
+ dot1dStpPriority,
+ dot1dStpTimeSinceTopologyChange,
+ dot1dStpTopChanges,
+ dot1dStpDesignatedRoot,
+ dot1dStpRootCost,
+ dot1dStpRootPort,
+ dot1dStpMaxAge,
+ dot1dStpHelloTime,
+ dot1dStpHoldTime,
+ dot1dStpForwardDelay,
+ dot1dStpBridgeMaxAge,
+ dot1dStpBridgeHelloTime,
+ dot1dStpBridgeForwardDelay
+ }
+ STATUS current
+ DESCRIPTION
+ "Bridge level Spanning Tree data for this device."
+ ::= { dot1dGroups 3 }
+
+ dot1dStpPortGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dStpPort,
+ dot1dStpPortPriority,
+ dot1dStpPortState,
+ dot1dStpPortEnable,
+ dot1dStpPortPathCost,
+ dot1dStpPortDesignatedRoot,
+ dot1dStpPortDesignatedCost,
+ dot1dStpPortDesignatedBridge,
+ dot1dStpPortDesignatedPort,
+ dot1dStpPortForwardTransitions
+ }
+ STATUS current
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 33]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ DESCRIPTION
+ "Spanning Tree data for each port on this device."
+ ::= { dot1dGroups 4 }
+
+ dot1dStpPortGroup2 OBJECT-GROUP
+ OBJECTS {
+ dot1dStpPort,
+ dot1dStpPortPriority,
+ dot1dStpPortState,
+ dot1dStpPortEnable,
+ dot1dStpPortDesignatedRoot,
+ dot1dStpPortDesignatedCost,
+ dot1dStpPortDesignatedBridge,
+ dot1dStpPortDesignatedPort,
+ dot1dStpPortForwardTransitions,
+ dot1dStpPortPathCost32
+ }
+ STATUS current
+ DESCRIPTION
+ "Spanning Tree data for each port on this device."
+ ::= { dot1dGroups 5 }
+
+ dot1dStpPortGroup3 OBJECT-GROUP
+ OBJECTS {
+ dot1dStpPortPathCost32
+ }
+ STATUS current
+ DESCRIPTION
+ "Spanning Tree data for devices supporting 32-bit
+ path costs."
+ ::= { dot1dGroups 6 }
+
+ -- ---------------------------------------------------------- --
+ -- the dot1dTp group
+ -- ---------------------------------------------------------- --
+
+ dot1dTpBridgeGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dTpLearnedEntryDiscards,
+ dot1dTpAgingTime
+ }
+ STATUS current
+ DESCRIPTION
+ "Bridge level Transparent Bridging data."
+ ::= { dot1dGroups 7 }
+
+ dot1dTpFdbGroup OBJECT-GROUP
+ OBJECTS {
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 34]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ dot1dTpFdbAddress,
+ dot1dTpFdbPort,
+ dot1dTpFdbStatus
+ }
+
+ STATUS current
+ DESCRIPTION
+ "Filtering Database information for the Bridge."
+ ::= { dot1dGroups 8 }
+
+ dot1dTpGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dTpPort,
+ dot1dTpPortMaxInfo,
+ dot1dTpPortInFrames,
+ dot1dTpPortOutFrames,
+ dot1dTpPortInDiscards
+ }
+ STATUS current
+ DESCRIPTION
+ "Dynamic Filtering Database information for each port of
+ the Bridge."
+ ::= { dot1dGroups 9 }
+
+ -- ---------------------------------------------------------- --
+ -- The Static (Destination-Address Filtering) Database
+ -- ---------------------------------------------------------- --
+
+ dot1dStaticGroup OBJECT-GROUP
+ OBJECTS {
+ dot1dStaticAddress,
+ dot1dStaticReceivePort,
+ dot1dStaticAllowedToGoTo,
+ dot1dStaticStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "Static Filtering Database information for each port of
+ the Bridge."
+ ::= { dot1dGroups 10 }
+
+ -- ---------------------------------------------------------- --
+ -- The Trap Notification Group
+ -- ---------------------------------------------------------- --
+
+ dot1dNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ newRoot,
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 35]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ topologyChange
+ }
+ STATUS current
+ DESCRIPTION
+ "Group of objects describing notifications (traps)."
+ ::= { dot1dGroups 11 }
+
+ -- ---------------------------------------------------------- --
+ -- compliance statements
+ -- ---------------------------------------------------------- --
+
+ bridgeCompliance1493 MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for device support of bridging
+ services, as per RFC1493."
+
+ MODULE
+ MANDATORY-GROUPS {
+ dot1dBaseBridgeGroup,
+ dot1dBasePortGroup
+ }
+
+ GROUP dot1dStpBridgeGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+ that support the Spanning Tree Protocol."
+
+ GROUP dot1dStpPortGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+ that support the Spanning Tree Protocol."
+
+ GROUP dot1dTpBridgeGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+ that support the transparent bridging mode. A
+ transparent or SRT bridge will implement this group."
+
+ GROUP dot1dTpFdbGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+ that support the transparent bridging mode. A
+ transparent or SRT bridge will implement this group."
+
+ GROUP dot1dTpGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 36]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ that support the transparent bridging mode. A
+ transparent or SRT bridge will implement this group."
+
+ GROUP dot1dStaticGroup
+ DESCRIPTION
+ "Implementation of this group is optional."
+
+ GROUP dot1dNotificationGroup
+ DESCRIPTION
+ "Implementation of this group is optional."
+ ::= { dot1dCompliances 1 }
+
+ bridgeCompliance4188 MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for device support of bridging
+ services. This supports 32-bit Path Cost values and the
+ more restricted bridge and port priorities, as per IEEE
+ 802.1t.
+
+ Full support for the 802.1D management objects requires that
+ the SNMPv2-MIB [RFC3418] objects sysDescr, and sysUpTime, as
+ well as the IF-MIB [RFC2863] objects ifIndex, ifType,
+ ifDescr, ifPhysAddress, and ifLastChange are implemented."
+
+ MODULE
+ MANDATORY-GROUPS {
+ dot1dBaseBridgeGroup,
+ dot1dBasePortGroup
+ }
+
+ GROUP dot1dStpBridgeGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for
+ bridges that support the Spanning Tree Protocol."
+
+ OBJECT dot1dStpPriority
+ SYNTAX Integer32 (0|4096|8192|12288|16384|20480|24576
+ |28672|32768|36864|40960|45056|49152
+ |53248|57344|61440)
+ DESCRIPTION
+ "The possible values defined by IEEE 802.1t."
+
+ GROUP dot1dStpPortGroup2
+ DESCRIPTION
+ "Implementation of this group is mandatory for
+ bridges that support the Spanning Tree Protocol."
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 37]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ GROUP dot1dStpPortGroup3
+ DESCRIPTION
+ "Implementation of this group is mandatory for bridges
+ that support the Spanning Tree Protocol and 32-bit path
+ costs. In particular, this includes devices supporting
+ IEEE 802.1t and IEEE 802.1w."
+
+ OBJECT dot1dStpPortPriority
+ SYNTAX Integer32 (0|16|32|48|64|80|96|112|128
+ |144|160|176|192|208|224|240)
+ DESCRIPTION
+ "The possible values defined by IEEE 802.1t."
+
+ GROUP dot1dTpBridgeGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for
+ bridges that support the transparent bridging
+ mode. A transparent or SRT bridge will implement
+ this group."
+
+ GROUP dot1dTpFdbGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for
+ bridges that support the transparent bridging
+ mode. A transparent or SRT bridge will implement
+ this group."
+
+ GROUP dot1dTpGroup
+ DESCRIPTION
+ "Implementation of this group is mandatory for
+ bridges that support the transparent bridging
+ mode. A transparent or SRT bridge will implement
+ this group."
+
+ GROUP dot1dStaticGroup
+ DESCRIPTION
+ "Implementation of this group is optional."
+
+ GROUP dot1dNotificationGroup
+ DESCRIPTION
+ "Implementation of this group is optional."
+
+ ::= { dot1dCompliances 2 }
+
+ END
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 38]
+
+RFC 4188 Bridge MIB September 2005
+
+
+5. IANA Considerations
+
+ The MIB module in this document uses the following IANA-assigned
+ OBJECT IDENTIFIER values that are recorded in the SMI Numbers
+ registry:
+
+ Descriptor OBJECT IDENTIFIER value
+ ---------- -----------------------
+ dot1dBridge { mib-2 17 }
+
+6. Security Considerations
+
+ There are a number of management objects defined in this MIB module
+ that have a MAX-ACCESS clause of read-write and/or read-create. Such
+ objects may be considered sensitive or vulnerable in some network
+ environments. The support for SET operations in a non-secure
+ environment without proper protection can have a negative effect on
+ network operations.
+
+ Some of the readable objects in this MIB module (i.e., objects with a
+ MAX-ACCESS other than not-accessible) may be considered sensitive or
+ vulnerable in some network environments. It is thus important to
+ control even GET and/or NOTIFY access to these objects and possibly
+ to even encrypt the values of these objects when sending them over
+ the network via SNMP.
+
+ These are the tables and objects and their sensitivity/vulnerability:
+
+ o The writable objects dot1dStpPriority, dot1dStpBridgeMaxAge,
+ dot1dStpBridgeHelloTime, dot1dStpBridgeForwardDelay,
+ dot1dStpPortPriority, dot1dStpPortEnable, dot1dStpPortPathCost,
+ and dot1dStpPortPathCost32 influence the spanning tree protocol.
+ Unauthorized write access to these objects can cause the spanning
+ tree protocol to compute other default topologies or it can change
+ the speed in which the spanning tree protocol reacts to failures.
+
+ o The writable object dot1dTpAgingTime controls how fast
+ dynamically-learned forwarding information is aged out. Setting
+ this object to a large value may simplify forwarding table
+ overflow attacks.
+
+ o The writable dot1dStaticTable provides a filtering mechanism
+ controlling to which ports frames originating from a specific
+ source may be forwarded. Write access to this table can be used
+ to turn provisioned filtering off or to add filters to prevent
+ rightful use of the network.
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 39]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ o The readable objects defined in the BRIDGE-MIB module provide
+ information about the topology of a bridged network and the
+ attached active stations. The addresses listed in the
+ dot1dTpFdbTable usually reveal information about the manufacturer
+ of the MAC hardware, which can be useful information for mounting
+ other specific attacks.
+
+ o The two notifications newRoot and topologyChange are emitted
+ during spanning tree computation and may trigger management
+ systems to inspect the status of bridges and to recompute internal
+ topology information. Hence, forged notifications may cause
+ management systems to perform unnecessary computations and to
+ generate additional SNMP traffic directed to the bridges in a
+ network. Therefore, forged notifications may be part of a denial
+ of service attack.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ Even if the network itself is secure (for example by using IPSec),
+ even then, there is no control as to who on the secure network is
+ allowed to access and GET/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ It is RECOMMENDED that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3410], section 8),
+ including full support for the SNMPv3 cryptographic mechanisms (for
+ authentication and privacy).
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+7. Acknowledgements
+
+ The MIB module presented in this memo is a translation of the
+ BRIDGE-MIB defined in [RFC1493] to the SMIv2 syntax. The original
+ authors of the SMIv1 module were E. Decker, P. Langille, A.
+ Rijsinghani, and K. McCloghrie. Further acknowledgement is given to
+ the members of the original Bridge Working Group in [RFC1493].
+
+ This document was produced on behalf of the Bridge MIB Working Group
+ in the Operations and Management area of the Internet Engineering
+ Task Force. The editors wish to thank the members of the Bridge MIB
+ Working Group, especially Mike MacFadden, John Flick, and Bert
+ Visscher for their many comments and suggestions that improved this
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 40]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ effort. Juergen Schoenwaelder helped in finalizing the document for
+ publication.
+
+8. Contact Information
+
+ The original version of this document was the result of significant
+ work by four major contributors:
+
+ E. Decker
+
+
+ P. Langille
+
+
+ A. Rijsinghan
+ Accton Technology Corporation
+ 5 Mount Royal Ave
+ Marlboro, MA 01752
+ USA
+
+ K. McCloghrie
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ The conversion to the SMIv2 format is based on work done by the
+ following two contributors:
+
+ Kenyon C. Norseth
+ L-3 Communications
+ 640 N. 2200 West
+ Salt Lake City, Utah 84116-0850
+ USA
+
+
+ E. Bell
+ 3Com Europe Limited
+ 3Com Centre, Boundary Way
+ Hemel Hempstead Herts. HP2 7YU
+ UK
+
+
+
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 41]
+
+RFC 4188 Bridge MIB September 2005
+
+
+9. Changes from RFC 1493
+
+ The following changes have been made from RFC 1493.
+
+ 1. Translated the MIB definitions to use SMIv2. This includes the
+ introduction of conformance statements. ASN.1 type definitions
+ have been converted into textual-conventions and several UNITS
+ clauses were added.
+
+ 2. The object dot1dStpPortPathCost32 was added to support IEEE
+ 802.1t.
+
+ 3. Permissible values for dot1dStpPriority and dot1dStpPortPriority
+ have been clarified for bridges supporting IEEE 802.1t or IEEE
+ 802.1w.
+
+ 4. Interpretation of dot1dStpTimeSinceTopologyChange has been
+ clarified for bridges supporting the rapid spanning tree protocol
+ (RSTP).
+
+ 5. Updated the introductory boilerplate text, the security
+ considerations section, and the references to comply with the
+ current IETF standards and guidelines.
+
+ 6. Updated references to point to newer IEEE 802.1d documents.
+
+ 7. Additions and clarifications in various description clauses.
+
+10. References
+
+10.1 Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ STD 58, RFC 2578, April 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Textual Conventions for SMIv2", STD 58, RFC 2579, April
+ 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Conformance Statements for SMIv2", STD 58, RFC 2580,
+ April 1999.
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 42]
+
+RFC 4188 Bridge MIB September 2005
+
+
+ [RFC3418] Presuhn, R., "Management Information Base (MIB) for the
+ Simple Network Management Protocol (SNMP)", STD 62, RFC
+ 3418, December 2002.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+ MIB", RFC 2863, June 2000.
+
+ [IEEE8021D] IEEE Project 802 Local and Metropolitan Area Networks,
+ "ANSI/IEEE Standard 802.1D-1998 MAC Bridges", March 1998.
+
+10.2 Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+ [RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K.
+ McCloghrie, "Definitions of Managed Objects for Bridges",
+ RFC 1493, July 1993.
+
+ [RFC1525] Decker, E., McCloghrie, K., Langille, P., and A.
+ Rijsinghani, "Definitions of Managed Objects for Source
+ Routing Bridges", RFC 1525, September 1993.
+
+Authors' Addresses
+
+ Kenyon C. Norseth (editor)
+ L-3 Communications
+ 640 N. 2200 West
+ Salt Lake City, Utah 84116-0850
+ USA
+
+ Phone: +1 801-594-2809
+ EMail: kenyon.c.norseth@L-3com.com
+
+
+ E. Bell (editor)
+ 3Com Europe Limited
+ 3Com Centre, Boundary Way
+ Hemel Hempstead Herts. HP2 7YU
+ UK
+
+ Phone: +44 1442 438025
+ EMail: elbell@ntlworld.com
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 43]
+
+RFC 4188 Bridge MIB September 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Norseth & Bell, Eds. Standards Track [Page 44]
+