dot1qConstraintVlan
dot1qConstraintSet
dot1qConstraintType
dot1qConstraintStatus
dot1qConstraintSetDefault
dot1qConstraintTypeDefault
dot1vProtocol IEEE 802.1v Reference:
dot1vProtocolGroupTable 8.6.4 Protocol Group Database,
8.6.2 Protocol Template
dot1vProtocolTemplateFrameType
dot1vProtocolTemplateProtocolValue
dot1vProtocolGroupId 8.6.3 Protocol Group Identifier
dot1vProtocolGroupRowStatus
dot1vProtocolPortTable 8.4.4 VID Set for each Port
dot1vProtocolPortGroupId
dot1vProtocolGroupVid
dot1vProtocolPortRowStatus
The following IEEE 802.1Q management objects have not been included
in the Bridge MIB for the indicated reasons.
IEEE 802.1Q-2003 Operation Disposition
reset bridge (12.4.1.4) not considered useful
reset vlan bridge (12.10.1.5) not considered useful
read forwarding port counters (12.6.1.1)
discard on error details not considered useful
read permanent database (12.7.6.1)
permanent database size not considered useful
number of static filtering count rows in
entries dot1qStaticUnicastTable +
dot1qStaticMulticastTable
number of static VLAN count rows in
registration entries dot1qVlanStaticTable
read filtering entry range use GetNext operation.
(12.7.7.4)
read filtering database (12.7.1.1)
filtering database size not considered useful
number of dynamic group address count rows applicable to each
entries (12.7.1.3) FDB in dot1dTpGroupTable
read garp state (12.9.3.1) not considered useful
notify vlan registration failure not considered useful
(12.10.1.6)
notify learning constraint violation
(12.10.3.10) not considered useful
3.2.2. The dot1qBase Subtree
This subtree contains the objects that are applicable to all bridges
implementing IEEE 802.1Q virtual LANs.
3.2.3. The dot1qTp Subtree
This subtree contains objects that control the operation and report
the status of transparent bridging. This includes management of the
dynamic Filtering Databases for both unicast and multicast
forwarding. This subtree will be implemented by all bridges that
perform destination-address filtering.
3.2.4. The dot1qStatic Subtree
This subtree contains objects that control static configuration
information for transparent bridging. This includes management of
the static entries in the Filtering Databases for both unicast and
multicast forwarding.
3.2.5. The dot1qVlan Subtree
This subtree contains objects that control configuration and report
status of the Virtual LANs known to a bridge. This includes
management of the statically configured VLANs as well as reporting
VLANs discovered by other means (e.g., GARP VLAN Registration
Protocol (GVRP)). It also controls configuration and reports status
of per-port objects relating to VLANs and reports traffic statistics.
It also provides for management of the VLAN Learning Constraints.
3.3. Textual Conventions
Various Working Groups have defined standards-track MIB documents
(for example, [RFC2613] and [RFC3318]), that contain objects and
Textual Conventions to represent a Virtual Local Area Network
Identifier (VLAN-ID) [802.1Q]. New definitions are showing up in
various documents (for example, [RFC4323] and [RFC4149]).
Unfortunately, the result is a set of different definitions for the
same piece of management information. This may lead to confusion and
unnecessary complexity. In order to address this situation, three
new textual conventions are defined in the Q-BRIDGE-MIB, called
VlanIdOrAny, VlanIdOrNone, and VlanIdOrAnyOrNone. These new textual
conventions should be (re)used in MIB modules so that they all
represent a VLAN-ID in the same way.
These textual conventions provide a means to specify MIB objects that
refer to a specific VLAN, to any VLAN, or to no VLAN. For an example
of how these textual conventions might be used, consider a MIB
object, with SYNTAX of VlanIdOrAnyOrNone, that specifies the VLAN on
which to accept incoming packets of a particular protocol. Such an
object would allow the device to be configured to accept packets of
this protocol received with a specific 802.1q tag value, with any
802.1q tag value, or with no 802.1q tag. Note that a MIB object that
is defined using one of these textual conventions should clarify the
meaning of ’any VLAN’ and/or ’no VLAN’ in its DESCRIPTION clause.
3.4. Relationship to Other MIBs
As described above, some IEEE 802.1D management objects have not been
included in this MIB because they overlap with objects in other MIBs
applicable to a bridge implementing this MIB module.
3.4.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 bridging is the device’s sole
functionality or only a subset of the device’s functionality.
Full support for the 802.1D management objects requires that the
SNMPv2-MIB objects sysDescr and sysUpTime be implemented. Note that
compliance to the current SNMPv2-MIB module requires additional
objects and notifications to be implemented as specified in RFC 3418
[RFC3418].
3.4.2. Relationship to the IF-MIB
The IF-MIB, [RFC2863], requires that any MIB that is an adjunct of
the IF-MIB clarify specific areas within the IF-MIB. These areas
were intentionally left vague in the IF-MIB in order to avoid over-
constraining the MIB, thereby precluding management of certain
media-types.
The IF-MIB enumerates several areas that a media-specific MIB must
clarify. Each of these areas is addressed in a following subsection.
The implementor is referred to the IF-MIB in order to understand the
general intent of these areas.
The IF-MIB [RFC2863] defines managed objects for managing network
interfaces. A network interface is considered 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.
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 Extended Bridge MIB is the notion of ports on a
bridge. Each of these ports is associated with one interface of the
’interfaces’ subtree (one row in ifTable), 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 but
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).
Some entities perform other functionality 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 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 performed bridging, all
protocols would be considered bridged, whereas in an entity that
performed IP routing on IP datagrams and only bridged other
protocols, only the non-IP data would be considered bridged.
Thus, this Extended Bridge MIB (and in particular, its counters) is
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.
3.4.2.1. Layering Model
This memo assumes the interpretation of the Interfaces Subtree to be
in accordance with the IF-MIB [RFC2863], which states that the
interfaces table (ifTable) contains information on the managed
resource’s interfaces and that each sub-layer below the internetwork
layer of a network interface is considered an interface.
This document does not make any assumption that within an entity,
VLANs that are instantiated as an entry in dot1qVlanCurrentTable by
either management configuration through dot1qVlanStaticTable or by
dynamic means (e.g., through GVRP) are also represented by an entry
in ifTable.
Where an entity contains higher-layer protocol entities (e.g.,
IP-layer interfaces that transmit and receive traffic to/from a
VLAN), these should be represented in the ifTable as interfaces of
type propVirtual(53). Protocol-specific types such as l3ipxvlan(137)
should not be used here, since there is no implication that the
bridge will perform any protocol filtering before delivering up to
these virtual interfaces.
3.4.2.2. ifStackTable
In addition, the IF-MIB [RFC2863] defines a table ’ifStackTable’ for
describing the relationship between logical interfaces within an
entity. It is anticipated that implementors will use this table to
describe the binding of (for example) IP interfaces to physical
ports, although the presence of VLANs makes the representation less
than perfect for showing connectivity. The ifStackTable cannot
represent the full capability of the IEEE 802.1Q VLAN bridging
standard, since that makes a distinction between VLAN bindings on
’ingress’ to and ’egress’ from a port: these relationships may or may
not be symmetrical whereas Interface MIB Evolution assumes a
symmetrical binding for transmit and receive. This makes it
necessary to define other manageable objects for configuring which
ports are members of which VLANs.
3.4.2.3. ifRcvAddressTable
This table contains all MAC addresses, unicast, multicast, and
broadcast, for which an interface will receive packets and forward
them up to a higher-layer entity for local consumption. Note that
this does not include addresses for data-link layer control protocols
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 that are
accepted for possible forwarding out some other port. This table is
explicitly not intended to provide a bridge address filtering
mechanism.
3.4.3. Relationship to the BRIDGE-MIB
This section defines how objects in the BRIDGE-MIB module
[BRIDGE-MIB] should be represented for devices that implement the
extensions: some of the old objects are less useful in such devices
but must still be implemented for reasons of backwards compatibility.
3.4.3.1. The dot1dBase Subtree
This subtree contains objects that are applicable to all types of
bridges. Interpretation of this subtree is unchanged.
3.4.3.2. The dot1dStp Subtree
This subtree contains the objects that denote the bridge’s state with
respect to the Spanning Tree Protocol. Interpretation of this
subtree is unchanged.
3.4.3.3. The dot1dTp Subtree
This subtree contains objects that describe the entity’s state with
respect to transparent bridging.
In a device operating with a single Filtering Database,
interpretation of this subtree is unchanged.
In a device supporting multiple Filtering Databases, this subtree is
interpreted as follows:
dot1dTpLearnedEntryDiscards
The number of times that *any* of the FDBs became full.
dot1dTpAgingTime
This applies to all Filtering Databases.
dot1dTpFdbTable
Report MAC addresses learned on each port, regardless of which
Filtering Database they have been learned in. If an address has
been learned in multiple databases on a single port, report it
only once. If an address has been learned in multiple databases
on more than one port, report the entry on any one of the valid
ports.
dot1dTpPortTable
This table is port-based and is not affected by multiple
Filtering Databases or multiple VLANs. The counters should
include frames received or transmitted for all VLANs. Note that
equivalent 64-bit port statistics counters, as well as other
objects to represent the upper 32 bits of these counters, are
defined in this document for high-capacity network interfaces.
These have conformance statements to indicate for which speeds
of interface they are required.
3.4.3.4. The dot1dStatic Subtree
This optional subtree contains objects that describe the
configuration of destination-address filtering.
In a device operating with a single Filtering Database,
interpretation of this subtree is unchanged.
In a device supporting multiple Filtering Databases, this subtree is
interpreted as follows:
dot1dStaticTable
Entries read from this table include all static entries from all
of the Filtering Databases. Entries for the same MAC address
and receive port in more than one Filtering Database must appear
only once, since these are the indices of this table. This
table should be implemented as read-only in devices that support
multiple Forwarding Databases. Instead, write access should be
provided through dot1qStaticUnicastTable and
dot1qStaticMulticastTable, as defined in this document.
3.4.3.5. Additions to the BRIDGE-MIB
To supplement the BRIDGE-MIB [BRIDGE-MIB], this module contains:
(1) support for multiple traffic classes and dynamic multicast
filtering as per IEEE 802.1D-1998 [802.1D].
(2) support for bridged Virtual LANs as per IEEE 802.1Q-2003
[802.1Q].
(3) support for 64-bit versions of BRIDGE-MIB [BRIDGE-MIB] port
counters.
4. Definitions for Extended Bridge MIB
P-BRIDGE-MIB DEFINITIONS ::= BEGIN
-- -------------------------------------------------------------
-- MIB for IEEE 802.1p devices
-- -------------------------------------------------------------
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, Counter64
FROM SNMPv2-SMI
TruthValue, TimeInterval, MacAddress, TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
dot1dTp, dot1dTpPort, dot1dBridge,
dot1dBasePortEntry, dot1dBasePort
FROM BRIDGE-MIB;
pBridgeMIB MODULE-IDENTITY
LAST-UPDATED "200601090000Z"
ORGANIZATION "IETF Bridge MIB Working Group"
CONTACT-INFO
"Email: bridge-mib@ietf.org
ietfmibs@ops.ietf.org
David Levi
Postal: Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
USA
Phone: +1 865 686 0432
Email: dlevi@nortel.com
David Harrington
Postal: Effective Software
50 Harding Rd.
Portsmouth, NH 03801
USA
Phone: +1 603 436 8634
Email: ietfdbh@comcast.net
Les Bell
Postal: Hemel Hempstead, Herts. HP2 7YU
UK
Email: elbell@ntlworld.com
Vivian Ngai
Email: vivian_ngai@acm.org
Andrew Smith
Postal: Beijing Harbour Networks
Jiuling Building
21 North Xisanhuan Ave.
Beijing, 100089
PRC
Fax: +1 415 345 1827
Email: ah_smith@acm.org
Paul Langille
Postal: Newbridge Networks
5 Corporate Drive
Andover, MA 01810
USA
Phone: +1 978 691 4665
Email: langille@newbridge.com
Anil Rijhsinghani
Postal: Accton Technology Corporation
5 Mount Royal Ave
Marlboro, MA 01752
USA
Phone:
Email: anil@accton.com
Keith McCloghrie
Postal: Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5260
Email: kzm@cisco.com"
DESCRIPTION
"The Bridge MIB Extension module for managing Priority
and Multicast Filtering, defined by IEEE 802.1D-1998,
including Restricted Group Registration defined by
IEEE 802.1t-2001.
Copyright (C) The Internet Society (2006). This version of
this MIB module is part of RFC 4363; See the RFC itself for
full legal notices."
REVISION "200601090000Z"
DESCRIPTION
"Added dot1dPortRestrictedGroupRegistration.
Deprecated pBridgePortGmrpGroup and pBridgeCompliance
and added pBridgePortGmrpGroup2 and pBridgeCompliance2."
REVISION "199908250000Z"
DESCRIPTION
"The Bridge MIB Extension module for managing Priority
and Multicast Filtering, defined by IEEE 802.1D-1998.
Initial version, published as RFC 2674."
::= { dot1dBridge 6 }
pBridgeMIBObjects OBJECT IDENTIFIER ::= { pBridgeMIB 1 }
-- -------------------------------------------------------------
-- Textual Conventions
-- -------------------------------------------------------------
EnabledStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A simple status value for the object."
SYNTAX INTEGER { enabled(1), disabled(2) }
-- -------------------------------------------------------------
-- subtrees in the P-BRIDGE MIB
-- -------------------------------------------------------------
dot1dExtBase OBJECT IDENTIFIER ::= { pBridgeMIBObjects 1 }
dot1dPriority OBJECT IDENTIFIER ::= { pBridgeMIBObjects 2 }
dot1dGarp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 3 }
dot1dGmrp OBJECT IDENTIFIER ::= { pBridgeMIBObjects 4 }
-- -------------------------------------------------------------
-- the dot1dExtBase subtree
-- -------------------------------------------------------------
dot1dDeviceCapabilities OBJECT-TYPE
SYNTAX BITS {
dot1dExtendedFilteringServices(0),
dot1dTrafficClasses(1),
dot1qStaticEntryIndividualPort(2),
dot1qIVLCapable(3),
dot1qSVLCapable(4),
dot1qHybridCapable(5),
dot1qConfigurablePvidTagging(6),
dot1dLocalVlanCapable(7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the optional parts of IEEE 802.1D and 802.1Q
that are implemented by this device and are manageable
through this MIB. Capabilities that are allowed on a
per-port basis are indicated in dot1dPortCapabilities.
dot1dExtendedFilteringServices(0),
-- can perform filtering of
-- individual multicast addresses
-- controlled by GMRP.
dot1dTrafficClasses(1),
-- can map user priority to
-- multiple traffic classes.
dot1qStaticEntryIndividualPort(2),
-- dot1qStaticUnicastReceivePort &
-- dot1qStaticMulticastReceivePort
-- can represent non-zero entries.
dot1qIVLCapable(3), -- Independent VLAN Learning (IVL).
dot1qSVLCapable(4), -- Shared VLAN Learning (SVL).
dot1qHybridCapable(5),
-- both IVL & SVL simultaneously.
dot1qConfigurablePvidTagging(6),
-- whether the implementation
-- supports the ability to
-- override the default PVID
-- setting and its egress status
-- (VLAN-Tagged or Untagged) on
-- each port.
dot1dLocalVlanCapable(7)
-- can support multiple local
-- bridges, outside of the scope
-- of 802.1Q defined VLANs."
REFERENCE
"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-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value true(1) indicates that Traffic Classes are
enabled on this bridge. When false(2), the bridge
operates with a single priority level for all traffic.
The value of this object MUST be retained across
reinitializations of the management system."
DEFVAL { true }
::= { dot1dExtBase 2 }
dot1dGmrpStatus OBJECT-TYPE
SYNTAX EnabledStatus
MAX-ACCESS read-write
STATUS current