GBNDeviceSWAPI-MIB: View SNMP OID List / Download MIB

SWAPI for Switch End Driver 100Mb/s and 1000Mb/s Management.

Swapi dot1d support objects.

Swapi RMON support objects.

Swapi MAU support objects.

Swapi Dot1p dependent support objects.

Swapi Dot1Q dependent support objects.

Swapi RFC1643 dependent support objects.

Swapi architectural dependent support objects.

The compliance statement for s module.

A table that contains generic information about every port that is associated with this bridge. Transparent, source-route, and srt ports are included.

A list of information for each port of the bridge.

The port number of the port for which this entry contains bridge management information.

The value of the instance of the ifIndex object, defined in MIB-II, for the interface corresponding to this port.

The number of frames discarded by this port due to an excessive size. It is incremented by both transparent and source route bridges.

A table that contains port-specific information for the Spanning Tree Protocol.

A list of information maintained by every port about the Spanning Tree Protocol state for that port.

The port number of the port for which this entry contains Spanning Tree Protocol management information.

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 which are disabled (see dot1dStpPortEnable), this object will have a value of disabled(1). Enumeration: 'listening': 3, 'disabled': 1, 'broken': 6, 'learning': 4, 'forwarding': 5, 'blocking': 2.

The enabled/disabled status of the port. Enumeration: 'disabled': 2, 'enabled': 1.

The total number of Forwarding Database entries, which have been or would have been learnt, but have been discarded due to a lack of space to store them in the Forwarding Database. If this counter is increasing, it indicates that the Forwarding Database is regularly becoming full (a condition which 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.

The timeout period in seconds for aging out dynamically learned forwarding information. 802.1D-1990 recommends a default of 300 seconds.

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.

Information about a specific unicast MAC address for which the bridge has some forwarding and/or filtering information.

A unicast MAC address for which the bridge has forwarding and/or filtering information.

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).

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 not 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. Enumeration: 'learned': 3, 'other': 1, 'self': 4, 'invalid': 2, 'mgmt': 5.

A list of Ethernet statistics entries.

A collection of statistics kept for a particular Ethernet interface. As an example, an instance of the etherStatsPkts object might be named etherStatsPkts.1

The value of this object uniquely identifies this etherStats entry. Defined as a single port via the MIB-II ifIndex.

The total number of events in which packets were dropped by the probe due to lack of resources. Note that this number is not necessarily the number of packets dropped; it is just the number of times this condition has been detected.

The total number of octets of data (including those in bad packets) received on the network (excluding framing bits but including FCS octets). This object can be used as a reasonable estimate of ethernet utilization. If greater precision is desired, the etherStatsPkts and etherStatsOctets objects should be sampled before and after a common interval. The differences in the sampled values are Pkts and Octets, respectively, and the number of seconds in the interval is Interval. These values are used to calculate the Utilization as follows: Pkts * (9.6 + 6.4) + (Octets * .8) Utilization = ------------------------------------- Interval * 10,000 The result of this equation is the value Utilization which is the percent utilization of the ethernet segment on a scale of 0 to 100 percent.

The total number of packets (including bad packets, broadcast packets, and multicast packets) received.

The total number of good packets received that were directed to the broadcast address. Note that this does not include multicast packets.

The total number of good packets received that were directed to a multicast address. Note that this number does not include packets directed to the broadcast address.

The total number of packets received that had a length (excluding framing bits, but including FCS octets) of between 64 and 1518 octets, inclusive, but but had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error).

The total number of packets received that were less than 64 octets long (excluding framing bits, but including FCS octets) and were otherwise well formed.

The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets) and were otherwise well formed.

The total number of packets received that were less than 64 octets in length (excluding framing bits but including FCS octets) and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that it is entirely normal for etherStatsFragments to increment. This is because it counts both runts (which are normal occurrences due to collisions) and noise hits.

The total number of packets received that were longer than 1518 octets (excluding framing bits, but including FCS octets), and had either a bad Frame Check Sequence (FCS) with an integral number of octets (FCS Error) or a bad FCS with a non-integral number of octets (Alignment Error). Note that this definition of jabber is different than the definition in IEEE-802.3 section 8.2.1.5 (10BASE5) and section 10.3.1.4 (10BASE2). These documents define jabber as the condition where any packet exceeds 20 ms. The allowed range to detect jabber is between 20 ms and 150 ms.

The best estimate of the total number of collisions on this Ethernet segment. The value returned will depend on the location of the RMON probe. Section 8.2.1.3 (10BASE-5) and section 10.3.1.3 (10BASE-2) of IEEE standard 802.3 states that a station must detect a collision, in the receive mode, if three or more stations are transmitting simultaneously. A repeater port must detect a collision when two or more stations are transmitting simultaneously. Thus a probe placed on a repeater port could record more collisions than a probe connected to a station on the same segment would. Probe location plays a much smaller role when considering 10BASE-T. 14.2.1.4 (10BASE-T) of IEEE standard 802.3 defines a collision as the simultaneous presence of signals on the DO and RD circuits (transmitting and receiving at the same time). A 10BASE-T station can only detect collisions when it is transmitting. Thus probes placed on a station and a repeater, should report the same number of collisions. Note also that an RMON probe inside a repeater should ideally report collisions between the repeater and one or more other hosts (transmit collisions as defined by IEEE 802.3k) plus receiver collisions observed on any coax segments to which the repeater is connected.

The total number of packets (including bad packets) received that were 64 octets in length (excluding framing bits but including FCS octets).

The total number of packets (including bad packets) received that were between 65 and 127 octets in length inclusive (excluding framing bits but including FCS octets).

The total number of packets (including bad packets) received that were between 128 and 255 octets in length inclusive (excluding framing bits but including FCS octets).

The total number of packets (including bad packets) received that were between 256 and 511 octets in length inclusive (excluding framing bits but including FCS octets).

The total number of packets (including bad packets) received that were between 512 and 1023 octets in length inclusive (excluding framing bits but including FCS octets).

The total number of packets (including bad packets) received that were between 1024 and 1518 octets in length inclusive (excluding framing bits but including FCS octets).

The total number of MAC control frames received.

The total number of pause frames received.

The total number of pause frames transmitted.

The total number of IPMC packets bridged.

The total number of IPMC packets routed.

The total number of IPMC dropped packets for this port in the ingress.

The total number of IPMC dropped packets for this port in the egress.

The ingress packet rate of this port.

The ingress octet rate of this port.

The egress packet rate of this port.

The egress octet rate of this port.

Table of descriptive and status information about MAU(s) attached to an interface.

An entry in the table, containing information about a single MAU.

This variable uniquely identifies the MAU described by this entry from among other MAUs connected to the same interface (sIfMauIfIndex).

This object identifies the 10 or 100 Mb/s baseband or broadband MAU type. An initial set of MAU types are defined above. The assignment of OBJECT IDENTIFIERs to new types of MAUs is managed by the IANA. If the MAU type is unknown, the object identifier unknownMauType OBJECT IDENTIFIER ::= { 0 0 } is returned. Note that unknownMauType is a syntactically valid object identifier, and any conformant implementation of ASN.1 and the BER must be able to generate and recognize this value. This object represents the operational type of the MAU, as determined by either (1) the result of the auto-negotiation function or (2) if auto- negotiation is not enabled or is not implemented for this MAU, by the value of the object sIfMauDefaultType. In case (2), a set to the object sIfMauDefaultType will force the MAU into the new operating mode.

If the MAU is a link or fiber type (FOIRL, 10BASE-T, 10BASE-F) then this is equivalent to the link test fail state/low light function. For an AUI or a coax (including broadband) MAU this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP. The value other(1) is returned if the mediaAvailable state is not one of 2 through 11. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. At power-up or following a reset, the value of this attribute will be unknown for AUI, coax, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission then loopback will be detected. The value of this attribute will only change during non-collided transmissions for AUI, coax, and 10BASE-FP MAUs. For 100Mbps and 1000Mbps MAUs, the enumerations match the states within the respective link integrity state diagrams, fig 32-16, 23-12 and 24-15 of sections 32, 23 and 24 of [2]. Any MAU which implements management of auto-negotiation will map remote fault indication to remote fault. The value available(3) indicates that the link, light, or loopback is normal. The value notAvailable(4) indicates link loss, low light, or no loopback. The value remoteFault(5) indicates that a fault has been detected at the remote end of the link. This value applies to 10BASE-FB, 100BASE-T4 Far End Fault Indication and non-specified remote faults from a system running auto-negotiation. The values remoteJabber(7), remoteLinkLoss(8), and remoteTest(9) SHOULD be used instead of remoteFault(5) where the reason for remote fault is identified in the remote signaling protocol. The value invalidSignal(6) indicates that an invalid signal has been received from the other end of the link. InvalidSignal(6) applies only to MAUs of type 10BASE-FB. Where an IEEE Std 802.3u-1995 clause 22 MII is present, a logic one in the remote fault bit (reference section 22.2.4.2.8 of that document) maps to the value remoteFault(5), and a logic zero in the link status bit (reference section 22.2.4.2.10 of that document) maps to the value notAvailable(4). The value notAvailable(4) takes precedence over the value remoteFault(5). Any MAU that implements management of clause 37 Auto-Negotiation will map the received RF1 and RF2 bit values for Offline to offline(10), Link Failure to remoteFault(5) and Auto-Negotiation Error to autoNegError(11). Enumeration: 'available': 3, 'remoteJabber': 7, 'invalidSignal': 6, 'autoNegError': 11, 'unknown': 2, 'remoteTest': 9, 'other': 1, 'remoteFault': 5, 'notAvailable': 4, 'offline': 10, 'remoteLinkLoss': 8.

The value other(1) is returned if the jabber state is not 2, 3, or 4. The agent must always return other(1) for MAU type dot3MauTypeAUI. The value unknown(2) is returned when the MAU's true state is unknown; for example, when it is being initialized. If the MAU is not jabbering the agent returns noJabber(3). This is the 'normal' state. If the MAU is in jabber state the agent returns the jabbering(4) value. Enumeration: 'unknown': 2, 'other': 1, 'noJabber': 3, 'jabbering': 4.

This object identifies the default administrative 10 or 100 Mb/s baseband MAU type, to be used in conjunction with the operational MAU type denoted by sIfMauType. The set of possible values for this object is the same as the set defined for the sIfMauType object. This object represents the administratively- configured type of the MAU. If auto-negotiation is not enabled or is not implemented for this MAU, the value of this object determines the operational type of the MAU. In this case, a set to this object will force the MAU into the specified operating mode. If auto-negotiation is implemented and enabled for this MAU, the operational type of the MAU is determined by auto-negotiation, and the value of this object denotes the type to which the MAU will automatically revert if/when auto-negotiation is later disabled. NOTE TO IMPLEMENTORS: It may be necessary to provide for underlying hardware implementations which do not follow the exact behavior specified above. In particular, when sIfMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation must ensure that the operational type of the MAU (as reported by sIfMauType) correctly transitions to the value specified by this object, rather than continuing to operate at the value earlier determined by the auto-negotiation function.

Configuration and status objects for the auto- negotiation function of MAUs attached to interfaces.

An entry in the table, containing configuration and status information for the auto-negotiation function of a particular MAU.

Setting this object to enabled(1) will cause the interface which has the auto-negotiation signaling ability to be enabled. If the value of this object is disabled(2) then the interface will act as it would if it had no auto-negotiation signaling. Under these conditions, an IEEE 802.3 MAU will immediately be forced to the state indicated by the value of the object sIfMauDefaultType. NOTE TO IMPLEMENTORS: When sIfMauAutoNegAdminStatus transitions from enabled to disabled, the agent implementation must ensure that the operational type of the MAU (as reported by sIfMauType) correctly transitions to the value specified by the sIfMauDefaultType object, rather than continuing to operate at the value earlier determined by the auto-negotiation function. Enumeration: 'disabled': 2, 'enabled': 1.

If the value of this object is set to restart(1) then this will force auto-negotiation to begin link renegotiation. If auto-negotiation signaling is disabled, a write to this object has no effect. Setting the value of this object to norestart(2) has no effect. Enumeration: 'norestart': 2, 'restart': 1.

A value that uniquely identifies the set of capabilities advertised by the local auto-negotiation entity. Capabilities in this object that are not available in ifMauAutoNegCapability cannot be enabled. Bits: 'b100baseT4': 3, 'b100baseT2': 6, 'b1000baseX': 12, 'b1000baseTFD': 15, 'bOther': 0, 'b100baseT2FD': 7, 'b10baseTFD': 2, 'b100baseTX': 4, 'bFdxSPause': 10, 'b1000baseXFD': 13, 'bFdxBPause': 11, 'b100baseTXFD': 5, 'bFdxAPause': 9, 'b1000baseT': 14, 'bFdxPause': 8, 'b10baseT': 1.

A value that uniquely identifies the set of capabilities received from the remote auto-negotiation entity. Note that interfaces that support this MIB may be attached to remote auto-negotiation entities which have capabilities beyond the scope of this MIB. Bits: 'b100baseT4': 3, 'b100baseT2': 6, 'b1000baseX': 12, 'b1000baseTFD': 15, 'bOther': 0, 'b100baseT2FD': 7, 'b10baseTFD': 2, 'b100baseTX': 4, 'bFdxSPause': 10, 'b1000baseXFD': 13, 'bFdxBPause': 11, 'b100baseTXFD': 5, 'bFdxAPause': 9, 'b1000baseT': 14, 'bFdxPause': 8, 'b10baseT': 1.

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 sDot1dPortCapabilities. Bits: 'sDot1dExtendedFilteringServices': 0, 'dot1qConfigurablePvidTagging': 6, 'sDot1dTrafficClasses': 1, 'dot1qSVLCapable': 4, 'dot1qIVLCapable': 3, 'sDot1dLocalVlanCapable': 7, 'dot1qStaticEntryIndividualPort': 2, 'dot1qHybridCapable': 5.

DURABLE: { true } 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.

DURABLE: { enable } The administrative status requested by management for GMRP. The value enabled(1) indicates that GMRP should be enabled on this device, in all VLANs, on all ports for which it has not been specifically disabled. When disabled(2), GMRP is disabled, in all VLANs, on all ports and all GMRP packets will be forwarded transparently. This object affects both Applicant and Registrar state machines. A transition from disabled(2) to enabled(1) will cause a reset of all GMRP state machines on all ports.

A table that contains capabilities information about every port that is associated with this bridge.

A set of capabilities information about this port indexed by sDot1dBasePort.

Indicates the parts of IEEE 802.1D and 802.1Q that are optional on a per-port basis that are implemented by this device and are manageable through this MIB. Bits: 'dot1qIngressFiltering': 2, 'dot1qDot1qTagging': 0, 'dot1qConfigurableAcceptableFrameTypes': 1.

A table that contains information about every port that is associated with this transparent bridge.

A list of Default User Priorities for each port of a transparent bridge. This is indexed by sDot1dBasePort.

DURABLE: { 0:all } The default ingress User Priority for this port. This only has effect on media, such as Ethernet, that do not support native User Priority.

The number of egress traffic classes supported on this port. This object may optionally be read-only.

this port trust or untrust tag priority.1 for trust, 2 for untrust

A list of Regenerated User Priorities for each received User Priority on each port of a bridge. The Regenerated User Priority value may be used to index the Traffic Class Table for each input port. This only has effect on media that support native User Priority. The default values for Regenerated User Priorities are the same as the User Priorities.

A mapping of incoming User Priority to a Regenerated User Priority.

The User Priority for a frame received on this port.

The Regenerated User Priority the incoming User Priority is mapped to for this port.

A table mapping evaluated User Priority to Traffic Class, for forwarding by the bridge. Traffic class is a number in the range (0..(sDot1dPortNumTrafficClasses-1)).

User Priority to Traffic Class mapping.

The Priority value determined for the received frame. This value is equivalent to the priority indicated in the tagged frame received, or one of the evaluated priorities, determined according to the media-type. For untagged frames received from Ethernet media, this value is equal to the sDot1dPortDefaultUserPriority value for the ingress port. For untagged frames received from non-Ethernet media, this value is equal to the sDot1dRegenUserPriority value for the ingress port and media-specific user priority.

DURABLE: { 0:all } The Traffic Class the received frame is mapped to.

A table mapping Regenerated User Priority to Outbound Access Priority. This is a fixed mapping for all port types, with two options for 802.5 Token Ring.

Regenerated User Priority to Outbound Access Priority mapping.

The Outbound Access Priority the received frame is mapped to.

A table of weight of queue .

Table entry of weight of queue.

Queue of class

Weight of queue

Priority out of queue

Enable/Disable Priority out of queue Enumeration: 'disabled': 2, 'enabled': 1.

A table of GMRP control and status information about every bridge port. Augments the sDot1dBasePortTable.

GMRP control and status information for a bridge port.

The administrative state of GMRP operation on this port. The value enabled(1) indicates that GMRP is enabled on this port in all VLANs as long as sDot1dGmrpStatus is also enabled(1). A value of disabled(2) indicates that GMRP is disabled on this port in all VLANs: any GMRP packets received will be silently discarded and no GMRP registrations will be propagated from other ports. Setting this to a value of enabled(1) will be stored by the agent but will only take effect on the GMRP protocol operation if sDot1dGmrpStatus also indicates the value enabled(1). This object affects all GMRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will cause a reset of all GMRP state machines on this port.

The maximum number of IEEE 802.1Q VLANs that this device supports.

The administrative status requested by management for GVRP. The value enabled(1) indicates that GVRP should be enabled on this device, on all ports for which it has not been specifically disabled. When disabled(2), GVRP is disabled on all ports and all GVRP packets will be forwarded transparently. This object affects all GVRP Applicant and Registrar state machines. A transition from disabled(2) to enabled(1) will cause a reset of all GVRP state machines on all ports.

A table that contains configuration and control information for each Filtering Database currently operating on this device. Entries in this table appear automatically when VLANs are assigned FDB IDs in the dot1qVlanCurrentTable.

Information about a specific Filtering Database.

The identity of this Filtering Database.

The current number of dynamic entries in this Filtering Database.

A table that contains information about unicast entries for which the device has forwarding and/or filtering information. This information is used by the transparent bridging function in determining how to propagate a received frame.

Information about a specific unicast MAC address for which the device has some forwarding and/or filtering information.

A unicast MAC address for which the device has forwarding and/or filtering information.

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 dot1qTpFdbAddress has been seen. A value of '0' indicates that the port number has not been learned but that the device does have some forwarding/filtering information about this address (e.g. in the dot1qStaticUnicastTable). Implementors are encouraged to assign the port value to this object whenever it is learned even for addresses for which the corresponding value of dot1qTpFdbStatus is not learned(3).

The status of this entry. The meanings of the values are: other(1) - none of the following. This may include the case where some other MIB object (not the corresponding instance of dot1qTpFdbPort, nor an entry in the dot1qStaticUnicastTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1qTpFdbAddress 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 dot1qTpFdbPort was learned and is being used. self(4) - the value of the corresponding instance of dot1qTpFdbAddress represents one of the device's addresses. The corresponding instance of dot1qTpFdbPort indicates which of the device's ports has this address. mgmt(5) - the value of the corresponding instance of dot1qTpFdbAddress is also the value of an existing instance of dot1qStaticAddress. Enumeration: 'learned': 3, 'other': 1, 'self': 4, 'invalid': 2, 'mgmt': 5.

A table containing forwarding information for each VLAN, specifying the set of ports to which forwarding of multicast group-addressed frames for which there is no more specific forwarding information applies. This is configured statically by management and determined dynamically by GMRP. An entry appears in this table for all VLANs that are currently instantiated.

Forwarding information for a VLAN, specifying the set of ports to which all multicasts for which there is no more specific forwarding information shall be forwarded. This is configured statically by management or dynamically by GMRP.

The complete set of ports in this VLAN to which multicast group-addressed frames for which there is no more specific forwarding information will be forwarded. This includes ports for which this need has been determined dynamically by GMRP, or configured statically by management.

A table containing filtering information for Unicast MAC addresses for each Filtering Database, configured into the device by (local or network) management specifying the set of ports to which frames received from specific ports and containing specific unicast destination addresses are allowed to be forwarded. A 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 addresses only.

Filtering information configured into the device by (local or network) management specifying the set of ports to which frames received from a specific port and containing a specific unicast destination address are allowed to be forwarded.

The destination MAC address in a frame to which this entry's filtering information applies. This object must take the value of a unicast address.

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 device for which there is no other applicable entry.

The set of ports for which a frame with a specific unicast address will be flooded in the event that it has not been learned. It also specifies the set of ports a specific unicast address may be dynamically learnt on. The dot1qTpFdbTable will have an equivalent entry with a dot1qTpFdbPort value of '0' until this address has been learnt, when it will be updated with the port the address has been seen on. This only applies to ports that are members of the VLAN, defined by dot1qVlanCurrentEgressPorts. The default value of this object is a string of ones of appropriate length.

A table containing filtering information for Multicast and Broadcast MAC addresses for each VLAN, configured into the device by (local or network) management specifying the set of ports to which frames received from specific ports and containing specific Multicast and Broadcast destination addresses are allowed to be forwarded. A 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 Multicast and Broadcast addresses only.

Filtering information configured into the device by (local or network) management specifying the set of ports to which frames received from this specific port for this VLAN and containing this Multicast or Broadcast destination address are allowed to be forwarded.

The destination MAC address in a frame to which this entry's filtering information applies. This object must take the value of a Multicast or Broadcast address.

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 device for which there is no other applicable entry.

The set of ports to which frames received from a specific port and destined for a specific Multicast or Broadcast MAC address must be forwarded, regardless of any dynamic information e.g. from GMRP. A port may not be added in this set if it is already a member of the set of ports in dot1qStaticMulticastForbiddenEgressPorts. The default value of this object is a string of ones of appropriate length.

This object indicates the status of this entry. other(1) - this entry is currently in use but the conditions under which it will remain so differ from 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. Enumeration: 'permanent': 3, 'deleteOnTimeout': 5, 'other': 1, 'deleteOnReset': 4, 'invalid': 2.

A table containing current configuration information for each VLAN currently configured into the device by (local or network) management, or dynamically created as a result of GVRP requests received.

Information for a VLAN configured into the device by (local or network) management, or dynamically created as a result of GVRP requests received.

A TimeFilter for this entry. See the TimeFilter textual convention to see how this works.

The VLAN-ID or other identifier refering to this VLAN.

The Filtering Database used by this VLAN. This is one of the dot1qFdbId values in the sDot1qFdbTable. This value is allocated automatically by the device whenever the VLAN is created: either dynamically by GVRP, or by management, in dot1qVlanStaticTable. Allocation of this value follows the learning constraints defined for this VLAN in dot1qLearningConstraintsTable.

The set of ports which are transmitting traffic for this VLAN as either tagged or untagged frames.

The set of ports which are transmitting traffic for this VLAN as untagged frames.

A table containing static configuration information for each VLAN configured into the device by (local or network) management. All entries are permanent and will be restored after the device is reset.

Static information for a VLAN configured into the device by (local or network) management.

The set of ports which are permanently assigned to the egress list for this VLAN by management. Changes to a bit in this object affect the per-port per-VLAN Registrar control for Registration Fixed for the relevant GVRP state machine on each port. A port may not be added in this set if it is already a member of the set of ports in sDot1qVlanForbiddenEgressPorts. The default value of this object is a string of zeros of appropriate length, indicating not fixed.

The set of ports which should transmit egress packets for this VLAN as untagged. The default value of this object for the default VLAN (sDot1qVlanIndex = 1) is a string of appropriate length including all ports. There is no specified default for other VLANs. If a device agent cannot support the set of ports being set then it will reject the set operation with an error. An example might be if a manager attempts to set more than one VLAN to be untagged on egress where the device does not support this IEEE 802.1Q option.

This object indicates the status of this entry.

A table containing per port control and status information for VLAN configuration in the device.

Information controlling VLAN configuration for a port on the device. This is indexed by sDot1dBasePort.

DURABLE: { 1:all } The PVID, the VLAN ID assigned to untagged frames or Prority-Tagged frames received on this port.

DURABLE: { 1:all } When this is admitOnlyVlanTagged(2) the device will discard untagged frames or Priority-Tagged frames received on this port. When admitAll(1), untagged frames or Prority-Tagged frames received on this port will be accepted and assigned to the PVID for this port. This control does not affect VLAN independent BPDU frames, such as GVRP and STP. It does affect VLAN dependent BPDU frames, such as GMRP. Enumeration: 'admitAll': 1, 'admitOnlyVlanTagged': 2.

DURABLE: { 2:all } When this is true(1) the device will discard incoming frames for VLANs which do not include this Port in its Member set. When false(2), the port will accept all incoming frames. This control does not affect VLAN independent BPDU frames, such as GVRP and STP. It does affect VLAN dependent BPDU frames, such as GMRP.

The state of GVRP operation on this port. The value enabled(1) indicates that GVRP is enabled on this port, as long as dot1qGvrpStatus is also enabled for this device. When disabled(2) but dot1qGvrpStatus is still enabled for the device, GVRP is disabled on this port: any GVRP packets received will be silently discarded and no GVRP registrations will be propagated from other ports. This object affects all GVRP Applicant and Registrar state machines on this port. A transition from disabled(2) to enabled(1) will cause a reset of all GVRP state machines on this port.

Statistics for a collection of ethernet-like interfaces attached to a particular system.

Statistics for a particular interface to an ethernet-like medium.

An index value that uniquely identifies an interface to an ethernet-like medium. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.

A count of frames received on a particular interface that are not an integral number of octets in length and do not pass the FCS check. The count represented by an instance of this object is incremented when the alignmentError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions obtain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC.

A count of frames received on a particular interface that are an integral number of octets in length but do not pass the FCS check. The count represented by an instance of this object is incremented when the frameCheckError status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions obtain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC.

A count of successfully transmitted frames on a particular interface for which transmission is inhibited by exactly one collision. A frame that is counted by an instance of this object is also counted by the corresponding instance of either the ifOutUcastPkts, ifOutMulticastPkts, or ifOutBroadcastPkts, and is not counted by the corresponding instance of the sDot3StatsMultipleCollisionFrames object.

A count of successfully transmitted frames on a particular interface for which transmission is inhibited by more than one collision. A frame that is counted by an instance of this object is also counted by the corresponding instance of either the ifOutUcastPkts, ifOutMulticastPkts, or ifOutBroadcastPkts, and is not counted by the corresponding instance of the sDot3StatsSingleCollisionFrames object.

A count of times that the SQE TEST ERROR message is generated by the PLS sublayer for a particular interface. The SQE TEST ERROR message is defined in section 7.2.2.2.4 of ANSI/IEEE 802.3-1985 and its generation is described in section 7.2.4.6 of the same document.

A count of frames for which the first transmission attempt on a particular interface is delayed because the medium is busy. The count represented by an instance of this object does not include frames involved in collisions.

The number of times that a collision is detected on a particular interface later than 512 bit-times into the transmission of a packet. Five hundred and twelve bit-times corresponds to 51.2 microseconds on a 10 Mbit/s system. A (late) collision included in a count represented by an instance of this object is also considered as a (generic) collision for purposes of other collision-related statistics.

A count of frames for which transmission on a particular interface fails due to excessive collisions.

A count of frames for which transmission on a particular interface fails due to an internal MAC sublayer transmit error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the sDot3StatsLateCollisions object, the sDot3StatsExcessiveCollisions object, or the sDot3StatsCarrierSenseErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of transmission errors on a particular interface that are not otherwise counted.

The number of times that the carrier sense condition was lost or never asserted when attempting to transmit a frame on a particular interface. The count represented by an instance of this object is incremented at most once per transmission attempt, even if the carrier sense condition fluctuates during a transmission attempt.

A count of frames received on a particular interface that exceed the maximum permitted frame size. The count represented by an instance of this object is incremented when the frameTooLong status is returned by the MAC service to the LLC (or other MAC user). Received frames for which multiple error conditions obtain are, according to the conventions of IEEE 802.3 Layer Management, counted exclusively according to the error status presented to the LLC.

A count of frames for which reception on a particular interface fails due to an internal MAC sublayer receive error. A frame is only counted by an instance of this object if it is not counted by the corresponding instance of either the sDot3StatsFrameTooLongs object, the sDot3StatsAlignmentErrors object, or the sDot3StatsFCSErrors object. The precise meaning of the count represented by an instance of this object is implementation- specific. In particular, an instance of this object may represent a count of receive errors on a particular interface that are not otherwise counted.

This object contains an OBJECT IDENTIFIER which identifies the chipset used to realize the interface. Ethernet-like interfaces are typically built out of several different chips. The MIB implementor is presented with a decision of which chip to identify via this object. The implementor should identify the chip which is usually called the Medium Access Control chip. If no such chip is easily identifiable, the implementor should identify the chip which actually gathers the transmit and receive statistics and error indications. This would allow a manager station to correlate the statistics and the chip generating them, giving it the ability to take into account any known anomalies in the chip.

For an interface operating at 100 Mb/s, the number of times there was an invalid data symbol when a valid carrier was present. For an interface operating in half-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle (a carrier event) for a period of time equal to or greater than slotTime, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' or 'carrier extend error' on the GMII. For an interface operating in full-duplex mode at 1000 Mb/s, the number of times the receiving media is non-idle a carrier event) for a period of time equal to or greater than minFrameSize, and during which there was at least one occurrence of an event that causes the PHY to indicate 'Data reception error' on the GMII. The count represented by an instance of this object is incremented at most once per carrier event, even if multiple symbol errors occur during the carrier event. This count does not increment if a collision is present. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.

The current mode of operation of the MAC entity. 'unknown' indicates that the current duplex mode could not be determined. Management control of the duplex mode is accomplished through the MAU MIB. When an interface does not support autonegotiation, or when autonegotiation is not enabled, the duplex mode is controlled using ifMauDefaultType. When autonegotiation is supported and enabled, duplex mode is controlled using ifMauAutoNegAdvertisedBits. In either case, the currently operating duplex mode is reflected both in this object and in ifMauType. Note that this object provides redundant information with ifMauType. Normally, redundant objects are discouraged. However, in this instance, it allows a management application to determine the duplex status of an interface without having to know every possible value of ifMauType. This was felt to be sufficiently valuable to justify the redundancy. Enumeration: 'unknown': 1, 'fullDuplex': 3, 'halfDuplex': 2.

802.1x status

A list of interface entries. The number of entries is given by the value of ifNumber.

An interface entry containing objects at the subnetwork layer and below for a particular interface.

A unique value, uses linear port number with holes.

The number of octets transmitted from the interface. This number does not include octets in error.

The number of packets transmitted from the interface. This number does not include packets in error.

The number of octets received on the interface. This number does not include octets in error.

The number of packets received on the interface. This number does not include packets in error.