As per Relevance of the word filtering, we have this rfc below:
Network Working Group E.
Request for Comments: 2674 3Com Corp
Category: Standards Track A.
Extreme
P.
Newbridge
A.
Cabletron
K.
cisco
August 1999
Definitions of Managed Objects for Bridges with
Classes, Multicast Filtering and Virtual LAN
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
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 two MIB modules for managing the
capabilities of MAC bridges defined by the IEEE 802.1D-1998
Bridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards
bridging between Local Area Network (LAN) segments. One MIB
defines objects for managing the 'Traffic Classes' and '
Multicast Filtering' components of IEEE 802.1D-1998. The other
module defines objects for managing IEEE 802.1Q VLANs
Provisions are made for support of transparent bridging.
are also made so that these objects apply to bridges connected
subnetworks other than LAN segments. This memo also includes
MIB modules in a manner that is compliant to the SMIv2 [V2SMI].
This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent
RFC 1525 [SBRIDGEMIB].
Bell, et al. Standards Track [Page 1]
RFC 2674 Bridge MIB Extensions August 1999
Table of
1 The SNMP Management Framework ................................... 3
2 Overview ........................................................ 4
2.1 Scope ......................................................... 4
3 Structure of MIBs ............................................... 5
3.1 Structure of Extended Bridge MIB module ....................... 5
3.1.1 Relationship to IEEE 802.1D-1998 Manageable Objects ......... 6
3.1.2 Relationship to IEEE 802.1Q Manageable Objects .............. 8
3.1.3 The dot1dExtBase Group ...................................... 8
3.1.4 The dot1dPriority Group ..................................... 9
3.1.5 The dot1dGarp Group ......................................... 9
3.1.6 The dot1dGmrp Group ......................................... 9
3.1.7 The dot1dTpHCPortTable ...................................... 9
3.1.8 The dot1dTpPortOverflowTable ................................ 9
3.2 Structure of Virtual Bridge MIB module ........................ 9
3.2.1 Relationship to IEEE 802.1Q Manageable Objects .............. 9
3.2.2 The dot1qBase Group .........................................13
3.2.3 The dot1qTp Group ...........................................13
3.2.4 The dot1qStatic Group .......................................13
3.2.5 The dot1qVlan Group .........................................13
3.3 Textual Conventions ...........................................13
3.4 Relationship to Other MIBs ....................................14
3.4.1 Relationship to the 'system' group ..........................14
3.4.2 Relation to Interfaces MIB ..................................14
3.4.2.1 Layering Model ............................................15
3.4.2.2 ifStackTable ..............................................16
3.4.2.3 ifRcvAddressTable .........................................16
3.4.3 Relation to Original Bridge MIB .............................16
3.4.3.1 The dot1dBase Group .......................................16
3.4.3.2 The dot1dStp Group ........................................17
3.4.3.3 The dot1dTp Group .........................................17
3.4.3.4 The dot1dStatic Group .....................................17
3.4.3.5 Additions to the Original Bridge MIB ......................18
4 Definitions for Extended Bridge MIB .............................18
5 Definitions for Virtual Bridge MIB ..............................39
6 Acknowledgments .................................................80
7 Security Considerations .........................................80
8 References ......................................................81
9 Authors' Addresses ..............................................84
10 Intellectual Property ..........................................85
11 Full Copyright Statement .......................................86
Bell, et al. Standards Track [Page 2]
RFC 2674 Bridge MIB Extensions August 1999
1. The SNMP Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in an Architecture
Describing SNMP Management Frameworks [ARCH].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described in
16, RFC 1155 [V1SMI], STD 16, RFC 1212 [V1CONCISE] and RFC 1215
[V1TRAPS]. The second version, called SMIv2, is described in
58, RFC 2578 [V2SMI], STD 58, RFC 2579 [V2TC] and STD 58,
2580 [V2CONFORM].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [V1PROTO]. A second version of
SNMP message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901
[V2COMMUNITY] and RFC 1906 [V2TRANS]. The third version of
message protocol is called SNMPv3 and described in RFC 1906
[V2TRANS], Message Processing and Dispatching [V3MPC] and User
based Security Model [V3USM].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [V1PROTO]. A second set
protocol operations and associated PDU formats is described
RFC 1905 [V2PROTO].
o A set of fundamental applications described in SNMPv
Applications [V3APPS] and the view-based access control
described in View-based Access Control Model [V3VACM].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
Bell, et al. Standards Track [Page 3]
RFC 2674 Bridge MIB Extensions August 1999
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
2.
A common device present in many networks is the Bridge. This
is used to connect Local Area Network segments below the
layer. These devices are often known as 'layer 2 switches'.
There are two major modes defined for this bridging: Source-Route
transparent. Source-Route bridging is described by IEEE 802.5
[802.5]. and is not discussed further in this document
The transparent method of bridging is defined by IEEE 802.1D-1998
[802.1D] which is an update to the original IEEE 802.1D
[802.1D-ORIG]. Managed objects for that original specification
transparent bridging were defined in RFC 1493 [BRIDGEMIB].
The original IEEE 802.1D is augmented by IEEE 802.1Q-1998 [802.1Q]
provide support for 'virtual bridged LANs' where a single
physical LAN network may be used to support multiple logical
LANs, each of which offers a service approximately the same as
defined by IEEE 802.1D. Such virtual LANs (VLANs) are an
feature of switched LAN networks. A VLAN can be viewed as a group
end-stations on multiple LAN segments and can communicate as if
were on a single LAN. IEEE 802.1Q defines port-based Virtual
where membership is determined by the bridge port on which
frames are received. This memo defines the objects needed for
management of port-based VLANs in bridge entities
This memo defines those objects needed for the management of
bridging entity operating in the transparent mode, as well as
objects applicable to all types of bridges. Managed objects
Source-Route bridging are defined in RFC 1525 [SRBRIDGEMIB].
2.1.
This MIB includes a comprehensive set of managed objects
attempts to match the set defined in IEEE 802.1D and IEEE 802.1Q
However, to be consistent with the spirit of the SNMP Framework,
subjective judgement was made to omit the objects from
standards most 'costly' to implement in an agent and
'essential' for fault and configuration management. The
are described in section 3 below
Bell, et al. Standards Track [Page 4]
RFC 2674 Bridge MIB Extensions August 1999
Historical note
The original bridge MIB [BRIDGEMIB] used the following principles
determining inclusion of an object in the BRIDGE-MIB module
(1) Start with a small set of essential objects and add only
further objects are needed
(2) Require objects be essential for either fault or
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 heavily instrumented
The guideline that was followed is one counter per
section per layer
3. Structure of
This document defines additional objects, on top of those existing
the original BRIDGE-MIB module defined in [BRIDGEMIB]: that
module is to be maintained unchanged for backwards compatibility
Section 3.4.3 of the present document contains some
regarding usage of objects in the original bridge MIB by
implementing the enhancements defined here
Two MIB modules are defined here
(1) Managed objects for an extended bridge MIB module P-BRIDGE-
for the traffic class and multicast filtering
defined by IEEE 802.1D-1998 [802.1D].
(2) Managed objects for a virtual bridge MIB module Q-BRIDGE-
for the Virtual LAN bridging enhancements defined by
802.1Q-1998 [802.1Q].
3.1. Structure of Extended Bridge MIB
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
Bell, et al. Standards Track [Page 5]
RFC 2674 Bridge MIB Extensions August 1999
3.1.1. Relationship to IEEE 802.1D-1998 Manageable
This section contains a cross-reference to the objects defined
IEEE 802.1D-1998 [802.1D]. It also details those objects that
not considered necessary in this MIB module
Some objects defined by IEEE 802.1D-1998 have been included in
virtual bridge MIB module rather than this one: entries
dot1qTpGroupTable, dot1qForwardAllTable
dot1qForwardUnregisteredTable are required for virtual bridged
with additional indexing (e.g. per-VLAN, per-FDB) and so are
defined here. Instead, devices which do not implement
bridged LANs but do implement the Extended Forwarding
defined by IEEE 802.1D (i.e. dynamic learning of multicast
addresses and group service requirements in the filtering database
should implement these tables with a fixed value for dot1qFdbId (
value 1 is recommended) or dot1qVlanIndex (the value 1
recommended). Devices which support Extended Filtering
should support dot1qTpGroupTable, dot1qForwardAllTable
dot1qForwardUnregisteredTable
Bell, et al. Standards Track [Page 6]
RFC 2674 Bridge MIB Extensions August 1999
Extended Bridge MIB Name IEEE 802.1D-1998
dot1dExtBase
dot1
dot1
dot1
dot1
dot1dGmrpStatus .
dot1
dot1
dot1dPortDefaultUserPriority .
dot1
dot1dUserPriorityRegenTable .
dot1
dot1
dot1dTrafficClassTable .
dot1
dot1
dot1
.
dot1
dot1
dot1
dot1dPortGarpJoinTime .
dot1dPortGarpLeaveTime .
dot1dPortGarpLeaveAllTime .
dot1
dot1
dot1dPortGmrpStatus .
dot1dPortGmrpFailedRegistrations .
dot1dPortGmrpLastPduOrigin .
dot1
dot1
dot1dTpHCPortInFrames .BridgePort.
dot1dTpHCPortOutFrames .
dot1dTpHCPortInDiscards .
dot1
dot1dTpPortInOverflowFrames .BridgePort.
dot1dTpPortOutOverflowFrames .
dot1dTpPortInOverflowDiscards .
Bell, et al. Standards Track [Page 7]
RFC 2674 Bridge MIB Extensions August 1999
The following IEEE 802.1D-1998 management objects have not
included in the Bridge MIB for the indicated reasons
IEEE 802.1D-1998 Object
Bridge.StateValue not considered
Bridge.
not provided per-
(e.g. per-VLAN, per-Group).
Only per-{device,port,application
control is provided in this MIB
3.1.2. Relationship to IEEE 802.1Q Manageable
This section contains section number cross-references to
objects defined in IEEE 802.1Q-1998 [802.1Q]. These objects
been included in this MIB as they provide a natural fit with the
802.1D objects with which they are co-located
Extended Bridge MIB Name IEEE 802.1Q-1998 Section and
dot1dExtBase
dot1
dot1qStaticEntryIndividualPort 5.2 implementation
dot1
dot1
dot1
dot1qConfigurablePvidTagging 12.10.1.1 read bridge
dot1
dot1
dot1
dot1qDot1qTagging 5.2 implementation
dot1
5.2 implementation
dot1qIngressFiltering 5.2 implementation
3.1.3. The dot1dExtBase
This group contains the objects which are applicable to all
implementing the traffic class and multicast filtering features
IEEE 802.1D-1998 [802.1D]. It includes per-device configuration
GARP and GMRP protocols. This group will be implemented by
devices which implement the extensions defined in 802.1D-1998.
Bell, et al. Standards Track [Page 8]
RFC 2674 Bridge MIB Extensions August 1999
3.1.4. The dot1dPriority
This group contains the objects for configuring and reporting
of priority-based queuing mechanisms in a bridge. This includes per
port user_priority treatment, mapping of user_priority in frames
internal traffic classes and outbound user_priority
access_priority
3.1.5. The dot1dGarp
This group contains the objects for configuring and reporting
operation of the Generic Attribute Registration Protocol (GARP).
3.1.6. The dot1dGmrp
This group contains the objects for configuring and reporting
operation of the GARP Multicast Registration Protocol (GMRP).
3.1.7. The dot1
This table extends the dot1dTp group from the original bridge
[BRIDGEMIB] and contains the objects for reporting port
statistics for high capacity network interfaces
3.1.8. The dot1
This table extends the dot1dTp group from the original bridge
[BRIDGEMIB] and contains the objects for reporting the upper bits
port bridging statistics for high capacity network interfaces
when 32-bit counters are inadequate
3.2. Structure of Virtual Bridge MIB
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.
manageable objects defined in the original bridge MIB [BRIDGEMIB
need to be indexed differently when they are used in a VLAN
environment: these objects are, therefore, effectively duplicated
new objects with different indexing which are defined in the
Bridge MIB
3.2.1. Relationship to IEEE 802.1Q Manageable
This section contains section-number cross-references to
objects defined in clause 12 of IEEE 802.1Q-1998 [802.1Q]. It
details those objects that are not considered necessary in this
module
Bell, et al. Standards Track [Page 9]
RFC 2674 Bridge MIB Extensions August 1999
Note: unlike IEEE 802.1D-1998, IEEE 802.1Q-1998 [802.1Q] did
define exact syntax for a set of managed objects: the
cross-references indicate the section numbering of the
of management operations from clause 12 in the latter document
Virtual Bridge MIB object IEEE 802.1Q-1998
dot1
dot1qVlanVersionNumber 12.10.1.1 read bridge vlan
dot1qMaxVlanId 12.10.1.1 read bridge vlan
dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan
dot1
dot1qGvrpStatus 12.9.2.1/2 read/set
applicant
dot1
dot1
dot1
dot1qFdbDynamicCount 12.7.1.1.3 read filtering d/
dot1
dot1
dot1
dot1
dot1qTpGroupTable 12.7.7.1 read filtering
dot1
dot1
dot1
dot1qForwardAllTable 12.7.7.1 read filtering
dot1
dot1
dot1
dot1qForwardUnregisteredTable 12.7.7.1 read filtering
dot1
dot1
dot1
dot1
dot1qStaticUnicastTable 12.7.7.1 create/delete/
filtering
12.7.6.1 read permanent
dot1
dot1
dot1
dot1
dot1qStaticMulticastTable 12.7.7.1 create/delete/
filtering
12.7.6.1 read permanent
dot1
dot1
dot1
Bell, et al. Standards Track [Page 10]
RFC 2674 Bridge MIB Extensions August 1999
dot1
dot1
dot1
dot1
dot1qVlanCurrentTable 12.10.2.1 read vlan
12.10.3.5 read VID to
12.10.3.6 read FID allocated
12.10.3.7 read VIDs allocated
dot1
dot1
dot1
dot1
dot1
dot1
dot1
dot1qVlanStaticTable 12.7.7.1/2/3 create/delete/
filtering
12.7.6.1 read permanent
12.10.2.2 create vlan
12.10.2.3 delete vlan
dot1qVlanStaticName 12.4.1.3 set bridge
dot1
dot1
dot1
dot1
dot1
dot1qPortVlanTable 12.10.1.1 read bridge
dot1qPvid 12.10.1.2 configure PVID
dot1qPortAcceptableFrameTypes 12.10.1.3 configure
frame types
dot1qPortIngressFiltering 12.10.1.4 configure
filtering
dot1qPortGvrpStatus 12.9.2.2 read/set garp
dot1
dot1
dot1qPortVlanStatisticsTable 12.6.1.1 read forwarding
dot1
dot1
dot1
dot1
dot1
dot1
Bell, et al. Standards Track [Page 11]
RFC 2674 Bridge MIB Extensions August 1999
dot1qPortVlanHCStatisticsTable 12.6.1.1 read forwarding
dot1
dot1
dot1
dot1qLearningConstraintsTable 12.10.3.1/3/4 read/set/
vlan learning
12.10.3.2 read vlan
constraints for
dot1
dot1
dot1
dot1
dot1
dot1
The following IEEE 802.1Q management objects have not been
in the Bridge MIB for the indicated reasons
IEEE 802.1Q-1998 Operation
reset bridge (12.4.1.4) not considered
reset vlan bridge (12.10.1.5) not considered
read forwarding port counters (12.6.1.1)
discard on error details not considered
read permanent database (12.7.6.1)
permanent database size not considered
number of static filtering count rows
entries dot1qStaticUnicastTable +
dot1
number of static VLAN count rows
registration entries dot1
read filtering entry range use GetNext operation
(12.7.7.4)
read filtering database (12.7.1.1)
filtering database size not considered
number of dynamic group address count rows applicable to
entries (12.7.1.3) FDB in dot1
Bell, et al. Standards Track [Page 12]
RFC 2674 Bridge MIB Extensions August 1999
read garp state (12.9.3.1) not considered
notify vlan registration failure not considered
(12.10.1.6)
notify learning constraint
(12.10.3.10) not considered
3.2.2. The dot1qBase
This mandatory group contains the objects which are applicable to
bridges implementing IEEE 802.1Q virtual LANs
3.2.3. The dot1qTp
This group contains objects that control the operation and report
status of transparent bridging. This includes management of
dynamic Filtering Databases for both unicast and
forwarding. This group will be implemented by all bridges
perform destination-address filtering
3.2.4. The dot1qStatic
This group contains objects that control static
information for transparent bridging. This includes management
the static entries in the Filtering Databases for both unicast
multicast forwarding
3.2.5. The dot1qVlan
This group contains objects that control configuration and
status of the Virtual LANs known to a bridge. This
management of the statically configured VLANs as well as
VLANs discovered by other means e.g. GVRP. It also
configuration and reports status of per-port objects relating
VLANs and reports traffic statistics. It also provides
management of the VLAN Learning Constraints
3.3. Textual
The datatypes MacAddress, BridgeId, Timeout, EnabledStatus, PortList
VlanIndex and VlanId are used as textual conventions in
document. These textual conventions have NO effect on either
syntax nor the semantics of any managed object. Objects
using these conventions are always encoded by means of the rules
define their primitive type. Hence, no changes to the SMI or
SNMP are necessary to accommodate these textual conventions which
adopted merely for the convenience of readers
Bell, et al. Standards Track [Page 13]
RFC 2674 Bridge MIB Extensions August 1999
3.4. 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 defined in MIB-II [MIB2], the 'interfaces
group defined in [INTERFACEMIB] and the original bridge
[BRIDGEMIB].
3.4.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
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.4.2. Relation to Interfaces
The Interfaces Group MIB [INTERFACEMIB], requires that any MIB
is an adjunct of the Interfaces Group MIB, clarify specific
within the Interfaces Group MIB. These areas were intentionally
vague in the Interfaces Group MIB to avoid over-constraining the MIB
thereby precluding management of certain media-types
The Interfaces Group MIB enumerates several areas which a media
specific MIB must clarify. Each of these areas is addressed in
following subsection. The implementor is referred to the
Group MIB in order to understand the general intent of these areas
In the Interfaces Group MIB, the 'interfaces' group is defined
being mandatory for all systems and contains information on
entity's interfaces, where each interface is thought of as
attached to a `subnetwork'. (Note that this term is not to
confused with `subnet' which refers to an addressing
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
Ethernet segment, a 'ring', a WAN link, or even an X.25
circuit
Implicit in this Extended Bridge MIB is the notion of ports on
bridge. Each of these ports is associated with one interface of
'interfaces' group (one row in ifTable) and, in most situations,
port is associated with a different interface. However, there
situations in which multiple ports are associated with the
Bell, et al. Standards Track [Page 14]
RFC 2674 Bridge MIB Extensions August 1999
interface. An example of such a situation would be several
each corresponding one-to-one with several X.25 virtual circuits
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 Extended Bridge MIB (and in particular
its counters) is applicable only to that subset of the data on
entity's interfaces which is sent/received for a protocol
bridged. All such data is sent/received via the ports of the bridge
3.4.2.1. Layering
This memo assumes the interpretation of the Interfaces Group to be
accordance with the Interfaces Group MIB [INTERFACEMIB] which
that the interfaces table (ifTable) contains information on
managed resource's interfaces and that each sub-layer below
internetwork layer of a network interface is considered an interface
This document recommends that, within an entity, VLANs which
instantiated as an entry in dot1qVlanCurrentTable by
management configuration through dot1qVlanStaticTable or by
means (e.g. through GVRP), are NOT also represented by an entry
ifTable
Where an entity contains higher-layer protocol entities e.g. IP-
interfaces that transmit and receive traffic to/from a VLAN,
should be represented in the ifTable as interfaces of
propVirtual(53). Protocol-specific types such as l3ipxvlan(137)
should not be used here since there is no implication that the
will perform any protocol filtering before delivering up to
virtual interfaces
Bell, et al. Standards Track [Page 15]
RFC 2674 Bridge MIB Extensions August 1999
3.4.2.2.
In addition, the Interfaces Group MIB [INTERFACEMIB] defines a
'ifStackTable' for describing the relationship between
interfaces within an entity. It is anticipated that
will use this table to describe the binding of e.g. IP interfaces
physical ports, although the presence of VLANs makes
representation less than perfect for showing connectivity:
ifStackTable cannot represent the full capability of the IEEE 802.1
VLAN bridging standard since that makes a distinction between
bindings on 'ingress' to and 'egress' from a port:
relationships may or may not be symmetrical whereas Interface
Evolution assumes a symmetrical binding for transmit and receive
This makes it necessary to define other manageable objects
configuring which ports are members of which VLANs
3.4.2.3.
This table contains all MAC addresses, unicast, multicast,
broadcast, for which an interface will receive packets and
them up to a higher layer entity for local consumption. Note
this does not include addresses for data-link layer control
such as Spanning-Tree, GMRP or GVRP. The format of the address
contained in ifRcvAddressAddress, is the same as for ifPhysAddress
This table does not include unicast or multicast addresses which
accepted for possible forwarding out some other port. This table
explicitly not intended to provide a bridge address
mechanism
3.4.3. Relation to Original Bridge
This section defines how objects in the original bridge MIB
[BRIDGEMIB] should be represented for devices which implement
extensions: some of the old objects are less useful in such
but must still be implemented for reasons of backwards compatibility
Note that formal conformance statements for that MIB module do
exist since it is defined in SMIv1.
3.4.3.1. The dot1dBase
This mandatory group contains the objects which are applicable to
types of bridges. Interpretation of this group is unchanged
Bell, et al. Standards Track [Page 16]
RFC 2674 Bridge MIB Extensions August 1999
3.4.3.2. The dot1dStp
This group contains the objects that denote the bridge's state
respect to the Spanning Tree Protocol. Interpretation of this
is unchanged
3.4.3.3. The dot1dTp
This group contains objects that describe the entity's state
respect to transparent bridging
In a device operating with a single Filtering Database
interpretation of this group is unchanged
In a device supporting multiple Filtering Databases, this group
interpreted as follows
dot1
The number of times that *any* of the FDBs became full
dot1
This applies to all Filtering Databases
dot1
Report MAC addresses learned on each port, regardless of
Filtering Database they have been learnt in. If an address
been learnt in multiple databases on a single port, report
only once. If an address has been learnt in
databases on more than one port, report the entry on any one
the valid ports
dot1
This table is port-based and is not affected by
Filtering Databases or multiple VLANs. The counters
include frames received or transmitted for all VLANs. Note
equivalent 64-bit port statistics counters, as well as
objects to represent the upper 32 bits of these counters,
defined in this document for high capacity network interfaces
These have confromance statements to indicate for which speeds
interface they are required
3.4.3.4. The dot1dStatic
This optional group contains objects that describe the
of destination-address filtering
In a device operating with a single Filtering Database
interpretation of this group is unchanged
Bell, et al. Standards Track [Page 17]
RFC 2674 Bridge MIB Extensions August 1999
In a device supporting multiple Filtering Databases, this group
interpreted as follows
dot1
Entries read from this table include all static entries from
of the Filtering Databases. Entries for the same MAC
and receive port in more than one Filtering Database must
only once since these are the indices of this table. This
should be implemented as read-only in devices that
multiple Forwarding Databases - instead, write access should
provided through dot1qStaticUnicastTable
dot1qStaticMulticastTable, as defined in this document
3.4.3.5. Additions to the Original Bridge
In addition to the objects in the original bridge MIB [BRIDGEMIB],
this document contains
(1) support for multiple traffic classes and dynamic
filtering as per IEEE 802.1D-1998 [802.1D].
(2) support for bridged Virtual LANs as per IEEE 802.1Q-1998
[802.1Q].
(3) support for 64-bit versions of original bridge MIB [BRIDGEMIB
port counters
4. Definitions for Extended Bridge
P-BRIDGE-MIB DEFINITIONS ::=
-- -------------------------------------------------------------
-- MIB for IEEE 802.1p
-- -------------------------------------------------------------
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Counter64
FROM SNMPv2-
TruthValue, TimeInterval, MacAddress, TEXTUAL-
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-
dot1dTp, dot1dTpPort, dot1dBridge
dot1dBasePortEntry, dot1
FROM BRIDGE-MIB
Bell, et al. Standards Track [Page 18]
RFC 2674 Bridge MIB Extensions August 1999
pBridgeMIB MODULE-
LAST-UPDATED "9908250000Z
ORGANIZATION "IETF Bridge MIB Working Group
CONTACT-
" Les
Postal: 3Com Europe Ltd
3Com Centre, Boundary
Hemel Hempstead, Herts. HP2 7
Phone: +44 1442 438025
Email: Les_Bell@3Com.
Andrew
Postal: Extreme
3585 Monroe St
Santa Clara CA 95051
Phone: +1 408 579 2821
Email: andrew@extremenetworks.
Paul
Postal: Newbridge
5 Corporate
Andover, MA 01810
Phone: +1 978 691 4665
Email: langille@newbridge.
Anil
Postal: Cabletron
50 Minuteman
Andover, MA 01810
Phone: +1 978 684 1295
Email: anil@cabletron.
Keith
Postal: cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 526 5260
Email: kzm@cisco.com
"The Bridge MIB Extension module for managing
and Multicast Filtering, defined by IEEE 802.1D-1998."
Bell, et al. Standards Track [Page 19]
RFC 2674 Bridge MIB Extensions August 1999
-- revision
REVISION "9908250000Z
"Initial version, published as RFC 2674."
::= { dot1dBridge 6 }
pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }
-- -------------------------------------------------------------
-- Textual
-- -------------------------------------------------------------
EnabledStatus ::= TEXTUAL-
STATUS
"A simple status value for the object."
SYNTAX INTEGER { enabled(1), disabled(2) }
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- groups in the P-BRIDGE
-- -------------------------------------------------------------
dot1dExtBase OBJECT IDENTIFIER ::= { pBridgeMIBObjects 1 }
dot1dPriority OBJECT IDENTIFIER ::= { pBridgeMIBObjects 2 }
dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 }
dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 }
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- the dot1dExtBase
-- -------------------------------------------------------------
dot1dDeviceCapabilities OBJECT-
SYNTAX BITS {
dot1dExtendedFilteringServices(0),
-- can perform filtering
-- individual multicast
-- controlled by GMRP
dot1dTrafficClasses(1),
-- can map user priority
-- multiple traffic classes
Bell, et al. Standards Track [Page 20]
RFC 2674 Bridge MIB Extensions August 1999
dot1qStaticEntryIndividualPort(2),
-- dot1qStaticUnicastReceivePort &
-- dot1
-- can represent non-zero entries
dot1qIVLCapable(3), -- Independent VLAN Learning
dot1qSVLCapable(4), -- Shared VLAN Learning
dot1qHybridCapable(5),
-- both IVL & SVL simultaneously
dot1qConfigurablePvidTagging(6),
-- whether the
-- supports the ability
-- override the default
-- setting and its egress
-- (VLAN-Tagged or Untagged)
-- each port
dot1dLocalVlanCapable(7)
-- can support multiple
-- bridges, outside of the
-- of 802.1Q defined VLANs
}
MAX-ACCESS read-
STATUS
"Indicates the optional parts of IEEE 802.1D and 802.1
that are implemented by this device and are
through this MIB. Capabilities that are allowed on
per-port basis are indicated in dot1dPortCapabilities."
"ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2, 12.10.1.1.3/b/2"
::= { dot1dExtBase 1 }
dot1dTrafficClassesEnabled OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The value true(1) indicates that Traffic Classes
enabled on this bridge. When false(2), the
operates with a single priority level for all traffic."
DEFVAL { true }
::= { dot1dExtBase 2 }
dot1dGmrpStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Bell, et al. Standards Track [Page 21]
RFC 2674 Bridge MIB Extensions August 1999
"The administrative status requested by management
GMRP. The value enabled(1) indicates that GMRP
be enabled on this device, in all VLANs, on all
for which it has not been specifically disabled.
disabled(2), GMRP is disabled, in all VLANs, on
ports and all GMRP packets will be
transparently. This object affects both Applicant
Registrar state machines. A transition from disabled(2)
to enabled(1) will cause a reset of all GMRP
machines on all ports."
DEFVAL { enabled }
::= { dot1dExtBase 3 }
-- -------------------------------------------------------------
-- Port Capabilities
-- -------------------------------------------------------------
dot1dPortCapabilitiesTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table that contains capabilities information
every port that is associated with this bridge."
::= { dot1dExtBase 4 }
dot1dPortCapabilitiesEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"A set of capabilities information about this
indexed by dot1dBasePort."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortCapabilitiesTable 1 }
Dot1dPortCapabilitiesEntry ::=
SEQUENCE {
dot1
}
dot1dPortCapabilities OBJECT-
SYNTAX BITS {
dot1qDot1qTagging(0), -- supports 802.1Q VLAN tagging
-- frames and GVRP
dot1qConfigurableAcceptableFrameTypes(1),
-- allows modified values
Bell, et al. Standards Track [Page 22]
RFC 2674 Bridge MIB Extensions August 1999
-- dot1qPortAcceptableFrameTypes
dot1qIngressFiltering(2)
-- supports the discarding of
-- frame received on a Port
-- VLAN classification does
-- include that Port in its
-- set
}
MAX-ACCESS read-
STATUS
"Indicates the parts of IEEE 802.1D and 802.1Q that
optional on a per-port basis that are implemented
this device and are manageable through this MIB."
"ISO/IEC 15802-3 Section 5.2,
IEEE 802.1Q/D11 Section 5.2"
::= { dot1dPortCapabilitiesEntry 1 }
-- -------------------------------------------------------------
-- the dot1dPriority
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- Port Priority
-- -------------------------------------------------------------
dot1dPortPriorityTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table that contains information about every port
is associated with this transparent bridge."
::= { dot1dPriority 1 }
dot1dPortPriorityEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"A list of Default User Priorities for each port of
transparent bridge. This is indexed by dot1dBasePort."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortPriorityTable 1 }
Dot1dPortPriorityEntry ::=
SEQUENCE {
Bell, et al. Standards Track [Page 23]
RFC 2674 Bridge MIB Extensions August 1999
dot1
INTEGER
dot1
}
dot1dPortDefaultUserPriority OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS read-
STATUS
"The default ingress User Priority for this port.
only has effect on media, such as Ethernet, that do
support native User Priority."
::= { dot1dPortPriorityEntry 1 }
dot1dPortNumTrafficClasses OBJECT-
SYNTAX INTEGER (1..8)
MAX-ACCESS read-
STATUS
"The number of egress traffic classes supported on
port. This object may optionally be read-only."
::= { dot1dPortPriorityEntry 2 }
-- -------------------------------------------------------------
-- User Priority Regeneration
-- -------------------------------------------------------------
dot1dUserPriorityRegenTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A list of Regenerated User Priorities for each
User Priority on each port of a bridge. The
User Priority value may be used to index the
Class Table for each input port. This only has
on media that support native User Priority. The
values for Regenerated User Priorities are the same
the User Priorities."
"ISO/IEC 15802-3 Section 6.4"
::= { dot1dPriority 2 }
Bell, et al. Standards Track [Page 24]
RFC 2674 Bridge MIB Extensions August 1999
dot1dUserPriorityRegenEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"A mapping of incoming User Priority to a
User Priority."
INDEX { dot1dBasePort, dot1dUserPriority }
::= { dot1dUserPriorityRegenTable 1 }
Dot1dUserPriorityRegenEntry ::=
SEQUENCE {
dot1
INTEGER
dot1
}
dot1dUserPriority OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS not-
STATUS
"The User Priority for a frame received on this port."
::= { dot1dUserPriorityRegenEntry 1 }
dot1dRegenUserPriority OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS read-
STATUS
"The Regenerated User Priority the incoming
Priority is mapped to for this port."
::= { dot1dUserPriorityRegenEntry 2 }
-- -------------------------------------------------------------
-- Traffic Class
-- -------------------------------------------------------------
dot1dTrafficClassTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table mapping evaluated User Priority to
Class, for forwarding by the bridge. Traffic class is
number in the range (0..(dot1dPortNumTrafficClasses-1))."
Bell, et al. Standards Track [Page 25]
RFC 2674 Bridge MIB Extensions August 1999
"ISO/IEC 15802-3 Table 7-2"
::= { dot1dPriority 3 }
dot1dTrafficClassEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"User Priority to Traffic Class mapping."
INDEX { dot1dBasePort, dot1dTrafficClassPriority }
::= { dot1dTrafficClassTable 1 }
Dot1dTrafficClassEntry ::=
SEQUENCE {
dot1
INTEGER
dot1
}
dot1dTrafficClassPriority OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS not-
STATUS
"The Priority value determined for the received frame
This value is equivalent to the priority indicated
the tagged frame received, or one of the
priorities, determined according to the media-type
For untagged frames received from Ethernet media,
value is equal to the dot1dPortDefaultUserPriority
for the ingress port
For untagged frames received from non-Ethernet media
this value is equal to the dot1dRegenUserPriority
for the ingress port and media-specific user priority."
::= { dot1dTrafficClassEntry 1 }
dot1dTrafficClass OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS read-
STATUS
"The Traffic Class the received frame is mapped to."
::= { dot1dTrafficClassEntry 2 }
-- -------------------------------------------------------------
Bell, et al. Standards Track [Page 26]
RFC 2674 Bridge MIB Extensions August 1999
-- Outbound Access Priority
-- -------------------------------------------------------------
dot1dPortOutboundAccessPriorityTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table mapping Regenerated User Priority to
Access Priority. This is a fixed mapping for all
types, with two options for 802.5 Token Ring."
"ISO/IEC 15802-3 Table 7-3"
::= { dot1dPriority 4 }
dot1dPortOutboundAccessPriorityEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"Regenerated User Priority to Outbound Access
mapping."
INDEX { dot1dBasePort, dot1dRegenUserPriority }
::= { dot1dPortOutboundAccessPriorityTable 1 }
Dot1dPortOutboundAccessPriorityEntry ::=
SEQUENCE {
dot1
}
dot1dPortOutboundAccessPriority OBJECT-
SYNTAX INTEGER (0..7)
MAX-ACCESS read-
STATUS
"The Outbound Access Priority the received frame
mapped to."
::= { dot1dPortOutboundAccessPriorityEntry 1 }
-- -------------------------------------------------------------
-- the dot1dGarp
-- -------------------------------------------------------------
-- -------------------------------------------------------------
-- The GARP Port
-- -------------------------------------------------------------
Bell, et al. Standards Track [Page 27]
RFC 2674 Bridge MIB Extensions August 1999
dot1dPortGarpTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table of GARP control information about every
port. This is indexed by dot1dBasePort."
::= { dot1dGarp 1 }
dot1dPortGarpEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"GARP control information for a bridge port."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortGarpTable 1 }
Dot1dPortGarpEntry ::=
SEQUENCE {
dot1
TimeInterval
dot1
TimeInterval
dot1
}
dot1dPortGarpJoinTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The GARP Join time, in centiseconds."
DEFVAL { 20 }
::= { dot1dPortGarpEntry 1 }
dot1dPortGarpLeaveTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The GARP Leave time, in centiseconds."
DEFVAL { 60 }
::= { dot1dPortGarpEntry 2 }
Bell, et al. Standards Track [Page 28]
RFC 2674 Bridge MIB Extensions August 1999
dot1dPortGarpLeaveAllTime OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The GARP LeaveAll time, in centiseconds."
DEFVAL { 1000 }
::= { dot1dPortGarpEntry 3 }
-- -------------------------------------------------------------
-- The GMRP Port Configuration and Status
-- -------------------------------------------------------------
dot1dPortGmrpTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table of GMRP control and status information
every bridge port. Augments the dot1dBasePortTable."
::= { dot1dGmrp 1 }
dot1dPortGmrpEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"GMRP control and status information for a bridge port."
AUGMENTS { dot1dBasePortEntry }
::= { dot1dPortGmrpTable 1 }
Dot1dPortGmrpEntry ::=
SEQUENCE {
dot1
EnabledStatus
dot1
Counter32,
dot1
}
dot1dPortGmrpStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
Bell, et al. Standards Track [Page 29]
RFC 2674 Bridge MIB Extensions August 1999
"The administrative state of GMRP operation on this port.
value enabled(1) indicates that GMRP is enabled on this
in all VLANs as long as dot1dGmrpStatus is also enabled(1).
A value of disabled(2) indicates that GMRP is disabled
this port in all VLANs: any GMRP packets received
be silently discarded and no GMRP registrations will
propagated from other ports. Setting this to a value
enabled(1) will be stored by the agent but will only
effect on the GMRP protocol operation if dot1
also indicates the value enabled(1). This object
all GMRP Applicant and Registrar state machines on
port. A transition from disabled(2) to enabled(1)
cause a reset of all GMRP state machines on this port."
DEFVAL { enabled }
::= { dot1dPortGmrpEntry 1 }
dot1dPortGmrpFailedRegistrations OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The total number of failed GMRP registrations, for
reason, in all VLANs, on this port."
::= { dot1dPortGmrpEntry 2 }
dot1dPortGmrpLastPduOrigin OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The Source MAC Address of the last GMRP
received on this port."
::= { dot1dPortGmrpEntry 3 }
-- -------------------------------------------------------------
-- High Capacity Port Table for Transparent
-- -------------------------------------------------------------
dot1dTpHCPortTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table that contains information about every
capacity port that is associated with this
bridge."
::= { dot1dTp 5 }
Bell, et al. Standards Track [Page 30]
RFC 2674 Bridge MIB Extensions August 1999
dot1dTpHCPortEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
STATUS
"Statistics information for each high capacity port of
transparent bridge."
INDEX { dot1dTpPort }
::= { dot1dTpHCPortTable 1 }
Dot1dTpHCPortEntry ::=
SEQUENCE {
dot1
Counter64,
dot1
Counter64,
dot1
Counter64
}
dot1dTpHCPortInFrames OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS
"The number of frames that have been received by
port from its segment. Note that a frame received
the interface corresponding to this port is only
by this object if and only if it is for a protocol
processed by the local bridging function,
bridge management frames."
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 1 }
dot1dTpHCPortOutFrames OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS
"The number of frames that have been transmitted by
port to its segment. Note that a frame transmitted
the interface corresponding to this port is only
by this object if and only if it is for a protocol
processed by the local bridging function,
bridge management frames."
Bell, et al. Standards Track [Page 31]
RFC 2674 Bridge MIB Extensions August 1999
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 2 }
dot1dTpHCPortInDiscards OBJECT-
SYNTAX Counter64
MAX-ACCESS read-
STATUS
"Count of valid frames that have been received by
port from its segment which were discarded (i.e.,
filtered) by the Forwarding Process."
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpHCPortEntry 3 }
-- ----------------------------------------------------
-- Upper part of High Capacity Port Table for Transparent
-- ----------------------------------------------------
dot1dTpPortOverflowTable OBJECT-
SYNTAX SEQUENCE OF Dot1
MAX-ACCESS not-
STATUS
"A table that contains the most-significant bits
statistics counters for ports that are associated with
transparent bridge that are on high capacity interfaces,
defined in the conformance clauses for this table. This
is provided as a way to read 64-bit counters for agents
support only SNMPv1.
Note that the reporting of most-significant
least-significant counter bits separately runs the risk
missing an overflow of the lower bits in the interval
sampling. The manager must be aware of this possibility,
within the same varbindlist, when interpreting the results
a request or asynchronous notification."
::= { dot1dTp 6 }
dot1dTpPortOverflowEntry OBJECT-
SYNTAX Dot1
MAX-ACCESS not-
Bell, et al. Standards Track [Page 32]
RFC 2674 Bridge MIB Extensions August 1999
STATUS
"The most significant bits of statistics counters for a
capacity interface of a transparent bridge. Each object
associated with a corresponding object in dot1
which indicates the least significant bits of the counter."
INDEX { dot1dTpPort }
::= { dot1dTpPortOverflowTable 1 }
Dot1dTpPortOverflowEntry ::=
SEQUENCE {
dot1
Counter32,
dot1
Counter32,
dot1
Counter32
}
dot1dTpPortInOverflowFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times the associated dot1
counter has overflowed."
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpPortOverflowEntry 1 }
dot1dTpPortOutOverflowFrames OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
"The number of times the associated dot1
counter has overflowed."
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpPortOverflowEntry 2 }
dot1dTpPortInOverflowDiscards OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
Bell, et al. Standards Track [Page 33]
RFC 2674 Bridge MIB Extensions August 1999
"The number of times the
dot1dTpPortInDiscards counter has overflowed."
"ISO/IEC 15802-3 Section 14.6.1.1.3"
::= { dot1dTpPortOverflowEntry 3 }
-- -------------------------------------------------------------
-- IEEE 802.1p MIB - Conformance
-- -------------------------------------------------------------
pBridgeConformance OBJECT IDENTIFIER ::= { pBridgeMIB 2 }
pBridgeGroups OBJECT IDENTIFIER ::= { pBridgeConformance 1 }
pBridgeCompliances OBJECT
::= { pBridgeConformance 2 }
-- -------------------------------------------------------------
-- units of
-- -------------------------------------------------------------
pBridgeExtCapGroup OBJECT-
OBJECTS {
dot1dDeviceCapabilities
dot1
}
STATUS
"A collection of objects indicating the
capabilites of the device."
::= { pBridgeGroups 1 }
pBridgeDeviceGmrpGroup OBJECT-
OBJECTS {
dot1
}
STATUS
"A collection of objects providing device-level
for the Multicast Filtering extended bridge services."
::= { pBridgeGroups 2 }
Bell, et al. Standards Track [Page 34]
RFC 2674 Bridge MIB Extensions August 1999
pBridgeDevicePriorityGroup OBJECT-
OBJECTS {
dot1
}
STATUS
"A collection of objects providing device-level
for the Priority services."
::= { pBridgeGroups 3 }
pBridgeDefaultPriorityGroup OBJECT-
OBJECTS {
dot1
}
STATUS
"A collection of objects defining the User
applicable to each port for media which do not
native User Priority."
::= { pBridgeGroups 4 }
pBridgeRegenPriorityGroup OBJECT-
OBJECTS {
dot1
}
STATUS
"A collection of objects defining the User
applicable to each port for media which support
User Priority."
::= { pBridgeGroups 5 }
pBridgePriorityGroup OBJECT-
OBJECTS {
dot1dPortNumTrafficClasses
dot1
}
STATUS
"A collection of objects defining the traffic
within a bridge for each evaluated User Priority."
::= { pBridgeGroups 6 }
Bell, et al. Standards Track [Page 35]
RFC 2674 Bridge MIB Extensions August 1999
pBridgeAccessPriorityGroup OBJECT-
OBJECTS {
dot1
}
STATUS
"A collection of objects defining the media
outbound access level for each priority."
::= { pBridgeGroups 7 }
pBridgePortGarpGroup OBJECT-
OBJECTS {
dot1dPortGarpJoinTime
dot1dPortGarpLeaveTime
dot1
}
STATUS
"A collection of objects providing port level
and status information for GARP operation."
::= { pBridgeGroups 8 }
pBridgePortGmrpGroup OBJECT-
OBJECTS {
dot1dPortGmrpStatus
dot1dPortGmrpFailedRegistrations
dot1
}
STATUS
"A collection of objects providing port level
and status information for GMRP operation."
::= { pBridgeGroups 9 }
pBridgeHCPortGroup OBJECT-
OBJECTS {
dot1dTpHCPortInFrames
dot1dTpHCPortOutFrames
dot1
}
STATUS
"A collection of objects providing 64-bit
counters for high capacity bridge ports."
::= { pBridgeGroups 10 }
Bell, et al. Standards Track [Page 36]
RFC 2674 Bridge MIB Extensions August 1999
pBridgePortOverflowGroup OBJECT-
OBJECTS {
dot1dTpPortInOverflowFrames
dot1dTpPortOutOverflowFrames
dot1
}
STATUS
"A collection of objects providing overflow
counters for high capacity bridge ports."
::= { pBridgeGroups 11 }
-- -------------------------------------------------------------
-- compliance
-- -------------------------------------------------------------
pBridgeCompliance MODULE-
STATUS
"The compliance statement for device support of
and Multicast Filtering extended bridging services."
MANDATORY-GROUPS { pBridgeExtCapGroup }
GROUP
"This group is mandatory for devices supporting the
application, defined by IEEE 802.1D Extended
Services."
GROUP
"This group is mandatory only for devices
the priority forwarding operations defined by
802.1D."
GROUP
"This group is mandatory only for devices
the priority forwarding operations defined by
extended bridge services with media types, such
Ethernet, that do not support native User Priority."
Bell, et al. Standards Track [Page 37]
RFC 2674 Bridge MIB Extensions August 1999
GROUP
"This group is mandatory only for devices
the priority forwarding operations defined by IEEE 802.1
and which have interface media types that
native User Priority e.g. IEEE 802.5."
GROUP
"This group is mandatory only for devices
the priority forwarding operations defined by IEEE 802.1D."
GROUP
"This group is optional and is relevant only for
supporting the priority forwarding operations defined
IEEE 802.1D and which have interface media types that
native Access Priority e.g. IEEE 802.5."
GROUP
"This group is mandatory for devices supporting
of the GARP applications: e.g. GMRP, defined by
extended filtering services of 802.1D; or GVRP
defined by 802.1Q (refer to the Q-BRIDGE-MIB
conformance statements for GVRP)."
GROUP
"This group is mandatory for devices supporting
GMRP application, as defined by IEEE 802.1D
Filtering Services."
GROUP
"Support for this group in a device is mandatory for
bridge ports which map to network interfaces that have
value of the corresponding instance of
greater than 650,000,000 bits/second."
GROUP
"Support for this group in a device is mandatory for
bridge ports which map to network interfaces that have
value of the corresponding instance of
greater than 650,000,000 bits/second."
Bell, et al. Standards Track [Page 38]
RFC 2674 Bridge MIB Extensions August 1999
OBJECT dot1
MIN-ACCESS read-
"Write access is not required."
OBJECT dot1
MIN-ACCESS read-
"Write access is not required."
OBJECT dot1
MIN-ACCESS read-
"Write access is not required."
::= { pBridgeCompliances 1 }
5. Definitions for Virtual Bridge
Q-BRIDGE-MIB DEFINITIONS ::=
-- -------------------------------------------------------------
-- MIB for IEEE 802.1Q
-- -------------------------------------------------------------
MODULE-IDENTITY, OBJECT-TYPE
Counter32, Counter64, Unsigned32,
FROM SNMPv2-
RowStatus, TruthValue, TEXTUAL-CONVENTION,
FROM SNMPv2-
FROM SNMP-FRAMEWORK-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-
dot1dBridge, dot1dBasePortEntry, dot1
FROM BRIDGE-
FROM P-BRIDGE-
FROM RMON2-MIB
qBridgeMIB MODULE-
LAST-UPDATED "9908250000Z
ORGANIZATION "IETF Bridge MIB Working Group
Bell, et al. Standards Track [Page 39]
RFC 2674 Bridge MIB Extensions August 1999
CONTACT-
" Les
Postal: 3Com Europe Ltd
3Com Centre, Boundary
Hemel Hempstead, Herts. HP2 7
Phone: +44 1442 438025
Email: Les_Bell@3Com.
Andrew
Postal: Extreme
3585 Monroe St
Santa Clara CA 95051
Phone: +1 408 579 2821
Email: andrew@extremenetworks.
Paul
Postal: Newbridge
5 Corporate
Andover, MA 01810
Phone: +1 978 691 4665
Email: langille@newbridge.
Anil
Postal: Cabletron
50 Minuteman
Andover, MA 01810
Phone: +1 978 684 1295
Email: anil@cabletron.
Keith
Postal: cisco Systems, Inc
170 West Tasman
San Jose, CA 95134-1706
Phone: +1 408 526 5260
Email: kzm@cisco.com
"The VLAN Bridge MIB module for managing Virtual
Local Area Networks, as defined by IEEE 802.1Q-1998."
Bell, et al. Standards Track [Page 40]
RFC 2674 Bridge MIB Extensions August 1999
-- revision
REVISION "9908250000Z
