INTELCORPORATION-MULTI-FLEX-SERVER-SWITCH-MIB: View SNMP OID List / Download MIB

Switch Module of the Multi-Flex Server

Description.

Maximum number of Power Supplies possible in this chassis.

The number of Power Supplies in the system. (The present number of rows in the switch table.)

ASCII representation of bit string reflecting the presence of the switches with the left most 'bit' being bit 1 and maxSwitches bits being represented. Thus, '10' would express that switch 1 (of 2 switches) are present

Container for Switch specific information as well as all components logically contained within.

Each row describes a Switch in the chassis Note, all switch rows possible for a chassis are present so that the presence field is accessible even when the fan is not.

..

column used to identify a particular Switch.

column used to identify a particular Switch

Device manufacturer

Manufacture date/time

Device Name

Device Part Number

Device Serial Number

Static maximum power generation / consumption (in watts): <0 - Negative numbers indicate device consumes power (in watts) >0 - Positive numbers indicate device generates power (in watts) 0 - Device is passive (does not not consume or generate power) -1 - Maximum power generation/consumption not known or specified

Static Nominal power generation / consumption (in watts): <0 - Negative numbers indicate device consumes power (in watts) >0 - Positive numbers indicate device generates power (in watts) 0 - Device is passive (does not not consume or generate power) -1 - Nominal power generation/consumption not known or specified

Asset Tag # of device

Firmware version on the FRU

Software Version of this Switch

Column used to identify a particular Switch

Column used to express the state of the Fault LED for a particular Switch.

This table is taken directly from the OEM's MIB. However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. Lists the physical or physical-related attributes of ports

For each port, a entry describing attributes which are either physical or are derived from the features of the device hardware

The L2 interface number associated with this port.

The L2 interface number associated with this port, in string format based on the overall hardware architecture of the device (i.e., for monolithic devices just numbers, devices composed of modules (boards, cards) or stackable devices composed of monolithic units in form - , stackable devices in which each unit is composed of modules - -

The media type of this port. Enumeration: 'copper': 1, 'opticfiber': 2, 'combo': 3.

The number of the slot to which this port belongs.

The number of the stack unit to which this port resides in.

On which row (the uppermost being numbered 1 and the highest row number asigned to the lowest row) this port resides within its module.

On which column (the leftmost being numbered 1 and the highest column number asigned to the rightmost column) this this port resides within its module.

Type of connector.

Distance supported by this port. Enumeration: 'not-relevant': 1, 'long': 3, 'short': 2.

This table is taken directly from the IF-MIB (MIB-II). However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. the Interfaces table The Interfaces table contains information on the entity's interfaces. Each sub-layer below the internetwork-layer of a network interface is considered to be an interface. A list of interface entries. The number of entries is given by the value of switchIfNumber.

An entry containing management information applicable to a particular interface.

A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.

A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the interface hardware/software.

The type of interface. Additional values for switchIfType are assigned by the Internet Assigned Numbers Authority (IANA), through updating the syntax of the IANAifType textual convention.

The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface.

An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. If the bandwidth of the interface is greater than the maximum value reportable by this object then this object should report its maximum value (4,294,967,295) and switchIfHighSpeed must be used to report the interace's speed. For a sub-layer which has no concept of bandwidth, this object should be zero.

The interface's address at its protocol sub-layer. For example, for an 802.x interface, this object normally contains a MAC address. The interface's media-specific MIB must define the bit and byte ordering and the format of the value of this object. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length.

The desired state of the interface. The testing(3) state indicates that no operational packets can be passed. When a managed system initializes, all interfaces start with switchIfAdminStatus in the down(2) state. As a result of either explicit management action or per configuration information retained by the managed system, switchIfAdminStatus is then changed to either the up(1) or testing(3) states (or remains in the down(2) state). Enumeration: 'down': 2, 'testing': 3, 'up': 1.

The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. If switchIfAdminStatus is down(2) then switchIfOperStatus should be down(2). If switchIfAdminStatus is changed to up(1) then switchIfOperStatus should change to up(1) if the interface is ready to transmit and receive network traffic; it should change to dormant(5) if the interface is waiting for external actions (such as a serial line waiting for an incoming connection); it should remain in the down(2) state if and only if there is a fault that prevents it from going to the up(1) state; it should remain in the notPresent(6) state if the interface has missing (typically, hardware) components. Enumeration: 'dormant': 5, 'lowerLayerDown': 7, 'unknown': 4, 'testing': 3, 'up': 1, 'down': 2, 'notPresent': 6.

The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value.

The total number of octets received on the interface, including framing characters. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast or broadcast address at this sub-layer. 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 switchIfCounterDiscontinuityTime. This object is deprecated in favour of switchIfInMulticastPkts and switchIfInBroadcastPkts.

The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space. 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 switchIfCounterDiscontinuityTime.

For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character- oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol. 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 switchIfCounterDiscontinuityTime.

For packet-oriented interfaces, the number of packets received via the interface which were discarded because of an unknown or unsupported protocol. For character-oriented or fixed-length interfaces that support protocol multiplexing the number of transmission units received via the interface which were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter will always be 0. 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 switchIfCounterDiscontinuityTime.

The total number of octets transmitted out of the interface, including framing characters. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. 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 switchIfCounterDiscontinuityTime. This object is deprecated in favour of switchIfOutMulticastPkts and switchIfOutBroadcastPkts.

The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space. 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 switchIfCounterDiscontinuityTime.

For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors. 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 switchIfCounterDiscontinuityTime.

The length of the output packet queue (in packets).

A reference to MIB definitions specific to the particular media being used to realize the interface. It is recommended that this value point to an instance of a MIB object in the media-specific MIB, i.e., that this object have the semantics associated with the InstancePointer textual convention defined in RFC 2579. In fact, it is recommended that the media-specific MIB specify what value switchIfSpecific should/can take for values of switchIfType. If no MIB definitions specific to the particular media are available, the value should be set to the OBJECT IDENTIFIER { 0 0 }.

This table is taken directly from the IF-MIB (MIB-II). However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. Extension to the interface table This table replaces the switchIfExtnsTable table. A list of interface entries. The number of entries is given by the value of switchIfNumber. This table contains additional objects for the interface table.

An entry containing additional management information applicable to a particular interface.

The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the switchIfTable together represent a single interface as named by the device, then each will have the same value of switchIfName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of switchIfName for such an interface is the proxied device's local name for it. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. 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 switchIfCounterDiscontinuityTime.

The total number of octets received on the interface, including framing characters. This object is a 64-bit version of switchIfInOctets. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. This object is a 64-bit version of switchIfInUcastPkts. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of switchIfInMulticastPkts. 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 switchIfCounterDiscontinuityTime.

The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. This object is a 64-bit version of switchIfInBroadcastPkts. 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 switchIfCounterDiscontinuityTime.

The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of switchIfOutOctets. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of switchIfOutUcastPkts. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of switchIfOutMulticastPkts. 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 switchIfCounterDiscontinuityTime.

The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of switchIfOutBroadcastPkts. 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 switchIfCounterDiscontinuityTime.

Indicates whether linkUp/linkDown traps should be generated for this interface. By default, this object should have the value enabled(1) for interfaces which do not operate on 'top' of any other interface (as defined in the switchIfStackTable), and disabled(2) otherwise. Enumeration: 'disabled': 2, 'enabled': 1.

An estimate of the interface's current bandwidth in units of 1,000,000 bits per second. If this object reports a value of `n' then the speed of the interface is somewhere in the range of `n-500,000' to `n+499,999'. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. For a sub-layer which has no concept of bandwidth, this object should be zero.

This object has a value of false(2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true(1) when the station accepts all packets/frames transmitted on the media. The value true(1) is only legal on certain types of media. If legal, setting this object to a value of true(1) may require the interface to be reset before becoming effective. The value of switchIfPromiscuousMode does not affect the reception of broadcast and multicast packets/frames by the interface.

This object has the value 'true(1)' if the interface sublayer has a physical connector and the value 'false(2)' otherwise.

This object is an 'alias' name for the interface as specified by a network manager, and provides a non-volatile 'handle' for the interface. On the first instantiation of an interface, the value of switchIfAlias associated with that interface is the zero-length string. As and when a value is written into an instance of switchIfAlias through a network management set operation, then the agent must retain the supplied value in the switchIfAlias instance associated with the same interface for as long as that interface remains instantiated, including across all re- initializations/reboots of the network management system, including those which result in a change of the interface's switchIfIndex value. An example of the value which a network manager might store in this object for a WAN interface is the (Telco's) circuit number/identifier of the interface. Some agents may support write-access only for interfaces having particular values of switchIfType. An agent which supports write access to this object is required to keep the value in non-volatile storage, but it may limit the length of new values depending on how much storage is already occupied by the current values for other interfaces.

The value of sysUpTime on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or Counter64 object contained in the switchIfTable or switchIfXTable. If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value.

This table is taken directly from the RMON-MIB. However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. The Ethernet Statistics Group Implementation of the Ethernet Statistics group is optional. Consult the MODULE-COMPLIANCE macro for the authoritative conformance information for this MIB. The ethernet statistics group contains statistics measured by the probe for each monitored interface on this device. These statistics take the form of free running counters that start from zero when a valid entry is created. This group currently has statistics defined only for Ethernet interfaces. Each switchEtherStatsEntry contains statistics for one Ethernet interface. The probe must create one switchEtherStats entry for each monitored Ethernet interface on the device.

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

The value of this object uniquely identifies this switchEtherStats entry.

This object identifies the source of the data that this switchEtherStats entry is configured to analyze. This source can be any ethernet interface on this device. In order to identify a particular interface, this object shall identify the instance of the switchIfIndex object, defined in RFC 2233 [17], for the desired interface. For example, if an entry were to receive data from interface #1, this object would be set to switchIfIndex.1. The statistics in this group reflect all packets on the local network segment attached to the identified interface. An agent may or may not be able to tell if fundamental changes to the media of the interface have occurred and necessitate an invalidation of this entry. For example, a hot-pluggable ethernet card could be pulled out and replaced by a token-ring card. In such a case, if the agent has such knowledge of the change, it is recommended that it invalidate this entry. This object may not be modified if the associated switchEtherStatsStatus object is equal to valid(1).

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 10-Megabit ethernet utilization. If greater precision is desired, the switchEtherStatsPkts and switchEtherStatsOctets 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 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 switchEtherStatsFragments 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 entity that configured this entry and is therefore using the resources assigned to it.

The status of this switchEtherStats entry.

This table is taken directly from the BRIDGE-MIB. However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. The Forwarding Database for Transparent Bridges 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 switchDot1dTpFdbAddress 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 switchDot1dStaticTable). Implementors are encouraged to assign the port value to this object whenever it is learned even for addresses for which the corresponding value of switchDot1dTpFdbStatus 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 switchDot1dTpFdbPort, nor an entry in the switchDot1dStaticTable) is being used to determine if and how frames addressed to the value of the corresponding instance of switchDot1dTpFdbAddress 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 switchDot1dTpFdbPort was learned, and is being used. self(4) : the value of the corresponding instance of switchDot1dTpFdbAddress represents one of the bridge's addresses. The corresponding instance of switchDot1dTpFdbPort indicates which of the bridge's ports has this address. mgmt(5) : the value of the corresponding instance of switchDot1dTpFdbAddress is also the value of an existing instance of switchDot1dStaticAddress. Enumeration: 'learned': 3, 'other': 1, 'self': 4, 'invalid': 2, 'mgmt': 5.

This table is taken directly from the Q-BRIDGE-MIB. However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]]. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. ------------------------------------------------------------- The Current VLAN Database ------------------------------------------------------------- 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 switchDot1qFdbId values in the switchDot1qFdbTable. This value is allocated automatically by the device whenever the VLAN is created: either dynamically by GVRP, or by management, in switchDot1qVlanStaticTable. Allocation of this value follows the learning constraints defined for this VLAN in switchDot1qLearningConstraintsTable.

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.

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. permanent(2) - this entry, corresponding to an entry in switchDot1qVlanStaticTable, is currently in use and will remain so after the next reset of the device. The port lists for this entry include ports from the equivalent switchDot1qVlanStaticTable entry and ports learnt dynamically. dynamicGvrp(3) - this entry is currently in use and will remain so until removed by GVRP. There is no static entry for this VLAN and it will be removed when the last port leaves the VLAN. Enumeration: 'permanent': 2, 'other': 1, 'dynamicGvrp': 3.

The value of sysUpTime when this VLAN was created.

This table is taken directly from the Q-BRIDGE-MIB. However, it has been slightly modified by adding an extra indice (by switch)[[ and adding a prefix so as not to conflict with the pre-existing namespace]] adding explicitly the dot1dBasePort index that was from the dot1dBasePortTable that this table is to augment. We want to be able to capture the data from all switches within the chassis, thus can't easily incorporate within the main table as data differs by switch and by the chassis, itself. Thus, the main group reflects the chassis, and this table reflects the switches. Otherwise it is identical. ------------------------------------------------------------- The VLAN Port Configuration Table ------------------------------------------------------------- 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 switchDot1dBasePort.

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

The PVID, the VLAN ID assigned to untagged frames or Priority-Tagged frames received on this port.

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

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 switchDot1qGvrpStatus is also enabled for this device. When disabled(2) but switchDot1qGvrpStatus 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.

The total number of failed GVRP registrations, for any reason, on this port.

The Source MAC Address of the last GVRP message received on this port.