RFC 2613
Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
RFC 2613: Remote Network Monitoring MIB Extensions for Switched Networks, Version 1.0 🎀
Okay bestie, this one is an Internet standards track doc from the Network Working Group, dated June 1999 📅. The authors are R. Waterman (Allot Networks Inc.), B. Lahaye (Xylan Corp.), D. Romascanu (Lucent Technologies), and S. Waldbusser (INS) 👑. It doesn't list anything it obsoletes or updates, so there's no lineage drama here 🧚.
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. If you want the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.
Copyright Notice 💅
Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸
Abstract 🌈
This memo defines a piece of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets 🫶. It's specifically about objects for managing remote network monitoring devices in switched networks environments 🔥.
Table of Contents 📋
1 The Network Management Framework 2
2 Overview 3
2.1 Remote Network Management Goals 3
2.2 Switched Networks Monitoring 5
2.3 Mechanisms for Monitoring Switched Networks 5
2.3.1 DataSource Objects 6
2.3.2 Copy Port 7
2.3.3 VLAN Monitoring 7
2.4 Relationship to Other MIBs 8
2.4.1 The RMON and RMON 2 MIBs 8
2.4.2 The Interfaces Group MIB 8
2.4.3 The Entity MIB 8
2.4.4 The Bridge MIB 9
2.5 Relationship with IEEE 802.1 Standards 9
3 SMON/RMON Groups 9
3.1 SMON ProbeCapabilities 9
3.2 smonVlanStats 10
3.3 smonPrioStats 10
3.4 dataSourceCaps 10
3.5 portCopyConfig 11
4 Control of Remote Network Monitoring Devices 12
5 Definitions 13
6 References 39
7 Intellectual Property 41
8 Security Considerations 41
9 Authors' Addresses 44
A Full Copyright Statement 441. The Network Management Framework 🧠
Okay so the SNMP Management Framework has five major components 💕:
- An overall architecture, described in RFC 2571 [1]. 🏛️
- Mechanisms for describing and naming objects and events for management purposes. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7]. 📖
- Message protocols for transferring management information. The first version of the SNMP message protocol is SNMPv1, described in STD 15, RFC 1157 [8]. A second version, SNMPv2c, is not an Internet standards track protocol, and it's described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is SNMPv3, described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. 📨
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set is described in RFC 1905 [13]. 🔑
- A set of fundamental applications described in RFC 2573 [14], plus the view-based access control mechanism described in RFC 2575 [15]. 🧚♀️
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🗂️. Objects in the MIB are defined using the mechanisms in the SMI 💅.
This memo specifies a MIB module that is compliant to SMIv2 🎀. A MIB conforming to SMIv1 can be produced through the appropriate translations. The translated MIB must be semantically equivalent, except where objects or events are omitted because no information in SMIv2 gets converted into textual descriptions in SMIv1 during translation 🙈. Even so, that loss of machine-readable information is not considered to change the semantics of the MIB ✨.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [24]. Important stuff, so read it carefully 🫶.
2. Overview 🦋
This document continues the architecture created in the RMON MIB [17] by providing RMON analysis for switched networks, called SMON 💖.
Remote network monitoring devices, often called monitors or probes, are instruments that exist to manage a network 🔍. They're often stand-alone devices and they devote significant internal resources to the sole purpose of managing a network 💪. An organization may employ many of these devices, one per network segment, to manage its internet 🌐. These devices may also be used by a network management service provider to access a client network, which is often geographically remote 🌏.
The objects in this document are meant as an interface between an RMON agent and an RMON management application, and they are not meant for direct manipulation by humans 🙅♀️. Some users may tolerate seeing a few of these objects directly, but few will tolerate the complexity of manually manipulating objects to create rows 😭. These functions should be handled by the management application 💜.
2.1 Remote Network Management Goals 🎯
- Offline Operation
Sometimes a management station won't be in constant contact with its remote monitoring devices 📵. That can be by design, to lower communications costs (especially over a WAN or dialup link), or by accident, when network failures get in the way of communication between the management station and the probe 🌩️.
So this MIB lets a probe be configured to run diagnostics and collect statistics continuously, even when communicating with the management station may not be possible or efficient 🧚. The probe can then try to notify the management station when an exceptional condition happens 🔔. That means that even when the connection between the management station and the probe isn't continuous, fault, performance, and configuration information can keep building up and get sent to the management station in a convenient and efficient way 🎀.
- Proactive Monitoring
The monitor has resources to spare, so it's genuinely helpful for it to keep running diagnostics and logging network performance all the time 🔥. It's always around when a failure starts 👀. It can notify the management station about the failure and store historical statistics about it 📚. The management station can play that history back to dig deeper into the cause of the problem 🕵️♀️.
- Problem Detection and Reporting
The monitor can be configured to recognize conditions, especially error conditions, and keep checking for them nonstop 🚨. When one of those conditions happens, the event may be logged, and management stations may be notified in a number of ways 📣.
- Value Added Data
A remote monitoring device is a network resource dedicated entirely to network management, and it sits right on the monitored part of the network 💎. So it has a real chance to add a lot of value to the data it collects ✨. For example, by highlighting the hosts that generate the most traffic or errors, the probe can hand the management station exactly the info it needs to solve a whole class of problems 🏆.
- Multiple Managers
An organization may have multiple management stations, for different units, for different functions (like engineering and operations), and to provide disaster recovery 🌸. Since environments with multiple management stations are common, the remote network monitoring device has to deal with more than one management station, possibly using its resources concurrently 👑.
2.2 Switched Networks Monitoring 🔀
This document covers how to apply "Remote Technology" to switched networks 💅. Switches today are different from standard shared media, and here's how 💖:
- Data is not, in general, broadcast. This MAY be caused by the switch architecture or by the connection-oriented nature of the data. So monitoring non-broadcast traffic needs to be considered 🙃.
- Monitoring the multiple entry and exit points of a switching device takes a vast amount of resources (memory and CPU), plus aggregating the data into logical packets of information, decided by application needs 🥵.
- Switching includes logical segmentation, such as Virtual LANs (VLANs) 🧩.
- Switching includes packet prioritization 🏃♀️.
- Data across the switch fabric can be in the form of cells. Like RMON, SMON is only concerned with monitoring packets 📦.
Differences like these make monitoring hard 😩. The current RMON and RMON 2 standards don't cover the things that are unique to switches or switched environments 🙈.
To get around the limits of the existing standards, switching equipment vendors have implemented new monitoring mechanisms 🛠️. All of these monitoring strategies are currently proprietary in nature 🔒.
This document provides a framework that can include different switching strategies and allows monitoring operations that stay consistent with the RMON framework 🧚♀️. This MIB is limited to monitoring and control operations aimed at providing monitoring data for RMON probes 💜.
2.3 Mechanisms for Monitoring Switched Networks ⭐
The following mechanisms are used by SMON devices to monitor switched networks 🦋.
2.3.1 DataSource Objects ✨
okay so the RMON MIB standard [17] defines data source objects that point at MIB-II interfaces, identified by instances of ifIndex objects 🦋
the SMON MIB takes that idea and runs with it 💅 other types of objects can be defined as data sources for RMON and/or SMON data. there are three forms of dataSources described:
ifIndex.<I>: traditional RMON dataSources. Called 'port-based' forifType.<I>not equal to 'propVirtual(53)'.<I>is the ifIndex value (see [22]).smonVlanDataSource.<V>: a dataSource of this form refers to a 'Packet-based VLAN' and is called a 'VLAN-based' dataSource.<V>is the VLAN ID as defined by the IEEE 802.1Q standard [19]. The value is between 1 and 4094 inclusive, and it represents an 802.1Q VLAN-ID with global scope within a given bridged domain, as defined by [19]. 🌈entPhysicalEntry.<N>: a dataSource of this form refers to a physical entity within the agent and is called an 'entity-based' dataSource.<N>is the value of the entPhysicalIndex in the entPhysicalTable (see [18]). 🧚
on top of these new dataSource types, SMON adds a new group called dataSourceCapsTable 🎀 which helps an NMS figure out a dataSource's identity and attributes.
the extended data source mechanism in the SMON MIB lets you use external collection points, like the ones defined and supported by the RMON and RMON 2 MIBs, and internal collection points too (e.g. a propVirtual ifTable entry, or an entPhysicalEntry) 🫶 the internal ones can be data sources that MAY be the result of aggregation (e.g. switch-wide), or internal channels of physical entities that an SMON probe is able to monitor.
2.3.2 Copy Port
so switching devices want to support RMON statistics, and a bunch of vendors built a port copy feature to make that happen 🍓 it lets traffic get replicated from switch port to switch port. there are several levels of configuration possible:
- 1 source port to 1 destination port
- N source ports to 1 destination port
- N source ports to M destination ports
the SMON standard gives you a standard MIB interface to control this function 💜
also, this function can apply to devices that have no other SMON or RMON functionality besides copy port 👀 the agent of a device like that would only support the portCopyCaps and the portCopyConfig MIB groups, out of the whole SMON MIB. switch vendors are encouraged to implement this subset of the SMON MIB, because it would let you do standard port copy configuration from the same NMS app that does RMON or SMON. iconic behaviour, honestly ✨
port copy can cause congestion problems on the SMON device. this is more likely to happen when you copy from a port of higher speed to a port of lower speed, or copy from multiple ports to a single port 😭
particular implementations MAY chose to build protection mechanisms that prevent creation of new port copy links when the capacity of the destination port is exceeded 🛡️ the MIB lets implementations (if supported) instrument a destination drop count on port copy, so NMS applications get a sense of the quality of the data presented at the destination port 📊
2.3.3 VLAN Monitoring
VLAN monitoring can be done by using a VLAN-based dataSource and/or by configuring smonVlanIdStats and/or smonPrioStats collections 💖 these functions give you VLAN-ID or user priority distributions per dataSource. VLAN monitoring gives a high-level view of total VLAN usage and relative non-unicast traffic usage, plus a profile of VLAN priority as defined in the 3-bit user_priority field. main character data 📈
NOTE: priority statistics reflect what was parsed from the packet, not what priority, if any, was necessarily granted by the switch. 🙈
2.4 Relationship to Other MIBs
2.4.1 The RMON and RMON 2 MIBs
the Remote Monitoring MIB (RMON) [17] provides several management functions that MAY be directly or indirectly applicable to switched networks 🌸
the port copy mechanisms in the SMON MIB let destination ports become a data source for any RMON statistics. however, an NMS application SHOULD check whether it is in the device capability (portCopyCap) to filter errors from a source to a destination port, and whether this capability is enabled, so it can interpret the copied port traffic correctly 🔍
RMON host and matrix group statistics entries MAY be aggregated by using the extended dataSource capability defined in SMON. RMON 2 groups are extended in a similar way through SMON's dataSource definition 💅
RMON also defines a simple thresholding monitoring mechanism, event-logging and event-notification for any MIB instance. SMON uses the alarms and events groups from RMON without modification 🔔 these groups SHOULD be implemented on SMON devices if a simple thresholding mechanism is desired.
the RMON 2 usrHistory group (user-defined history collection) SHOULD be implemented by an SMON device if a history collection mechanism is desired for smonStats entries 📚
2.4.2 The Interfaces Group MIB
the SMON MIB uses the propVirtual(53) ifType defined in the Interfaces Group MIB [22] to give SMON and RMON new dataSources, like VLANs and internal monitoring points 🦋 NMS applications SHOULD consult the SMON dataSource capabilities group (dataSourceCap) for a description of these virtual interfaces. 🫧
2.4.3 The Entity MIB
the SMON MIB does not mandate Entity MIB [18] support, but it does allow the physical entities defined by this MIB to be used as SMON data sources 🧩 for those cases, support for the entPhysicalTable is required.
2.4.4 The Bridge MIB
one of the important indicators for measuring how well a switching device is doing is the ratio between the number of forwarded frames and the number of dropped frames at the switch port 📉
it's out of scope for this MIB to provide instrumentation information about switching devices 🙅♀️ however, that kind of indication may be part of other MIB modules.
for instance, the Bridge MIB [23] provides those MIB objects for the 802.1 bridges (dot1dTpPortInFrames, dot1dTpPortInDiscards), and switches managed according to the 802.1 bridge model MAY provide this information 💫
2.5 Relationship with IEEE 802.1 Standards
the SMON MIB provides simple statistics per VLAN and per priority level. those two categories matter a lot to managers of switched networks 👑 interoperability for those features is ensured by using the IEEE 802.1 p/Q standards ([19], [20]) defined by the IEEE 802.1 WG. from the SMON MIB point of view, interoperability is ensured by referencing the IEEE definition of VLANs and priority levels for the SMON statistics. ✨
3. SMON Groups 🎀
3.1 SMON ProbeCapabilities
the SMON probeCapabilities BITS object covers the following four capabilities 🌈
smonVlanStats(0): the probe supports thesmonVlanStatsobject group.smonPrioStats(1): the probe supports thesmonPrioStatsobject group.dataSource(2): the probe supports thedataSourceCapsobject group.portCopy(4): the probe supports theportCopyConfigobject group.
3.2 smonVlanStats
the smonVlanStats MIB group includes the control and statistics objects related to 802.1Q VLANs 🌸 specific statistics are supported per 802.1Q virtual LAN. the group gives a high-level view of total VLAN usage and relative non-unicast traffic usage.
how the agent works out the proper default-VLAN for untagged or priority-tagged frames is an implementation-specific matter 🤷♀️
3.3 smonPrioStats
the smonPrioStatsTable gives a distribution based on the user_priority field in the VLAN header 💜
Note that this table merely reports priority as encoded in VLAN headers, not the priority (if any) given the frame for actual switching purposes. 🙈
3.4 dataSourceCaps
the dataSourceCaps MIB group identifies all supported data sources on an SMON device 🔍 an NMS MAY use this table to discover the RMON and Copy Port attributes of each data source.
when the agent restarts, the dataSourceTable, ifTable and entPhysicalTable are initialized for the available data sources 🔄 the agent MAY modify these tables as data sources become known or are removed (e.g. hot swap of interfaces, chassis cards, or the discovery of VLAN usage). it's understood that dataSources representing VLANs may not always be instantiated right away on restart, but rather as VLAN usage is detected by the agent. the agent SHOULD attempt to create dataSource and interface entries for all dataSources as soon as possible ⚡
for each dataSourceCapsEntry representing a VLAN or entPhysicalEntry, the agent MUST create an associated ifEntry with a ifType value of associated dataSourceCapsIfIndex object. 🫶
the reason for all this comes from the fact that, according to [16] and [17], an RMON dataSource MUST be associated with an ifEntry 🧠 specifically, the dataSourceCapsTable lets an agent map Entity MIB physical entities (e.g., switch backplanes) and entire VLANs to ifEntries with ifType "propVirtual(53)". those ifEntry values are used as the actual values in the RMON control table dataSource objects. this means physical entities and VLANs can be treated as RMON data sources, and RMON functions can be applied to that type of data source. ✨👑
3.5 portCopyConfig 🎀
okay so portCopyConfig is the group with all the knobs for the port copy feature on a device 🧚✨. The standard doesn't put a limit on which mode you can use the copy function in, so here are the three modes bestie 💅
Mode 1 -- 1:1 Copy
Okay Mode 1 is the simple one 💖: one dataSource gets copied to one destination dataSource. The agent MAY limit configuration based on ifTypes, ifSpeeds, half-duplex/full-duplex, or agent resources. In this mode, the single instance of the portCopyDestDropEvents object refers to dropped frames on the portCopyDest interface 🦋
Mode 2 -- N:1 Copy
Mode 2 is giving funnel energy 🌊: multiple dataSources get copied into one destination dataSource. The agent MAY limit configuration based on ifTypes, ifSpeeds, half-duplex/full-duplex, portCopyDest over-subscription, or agent resources. In this mode, all N instances of the portCopyDestDropEvents object SHOULD contain the same value, and they refer to dropped frames on the portCopyDest interface 🌸
Mode 3 -- N:M Copy
Mode 3 is the main character of the bunch 👑: multiple dataSources get copied to multiple destination dataSources. The agent MAY limit configuration based on ifTypes, ifSpeeds, half-duplex/full-duplex, portCopyDest over-subscription, or agent resources. Since portCopyDestDropEvents is kept per destination port, all instances of the portCopyDestDropEvents object associated with (indexed by) a given portCopyDest SHOULD have the same value. Basically they get replicated or aliased for each instance tied to a given portCopyDest 🪞
The rows don't have an OwnerString, since multiple rows MAY be part of the same portCopy operation 🫶. The agent is expected to activate or deactivate entries one at a time, based on the rowStatus for the given row. This can lead to unpredictable results in Modes 2 and 3 for applications using the portCopy target traffic, if multiple PDUs are used to fully configure the operation 😭. So it is RECOMMENDED that an entire portCopy operation be configured in one SetRequest PDU if possible 🍓
The portCopyDest object MAY NOT reference an interface associated with a packet-based VLAN (smonVlanDataSource.<V>), but this dataSource type MAY be used as a portCopySource 💀
4. Control of Remote Network Monitoring Devices ✨
Okay so these devices are super complicated, so the functions usually need some user configuration 🧠. A lot of the time, a function needs parameters set up for a data collection operation first, and it can only start once those parameters are fully set up 🌈
Lots of the functional groups in this MIB have one or more control tables where you set things up, plus one or more data tables where the results land 📊. The control tables are typically read/write, and the data tables are typically read-only. The parameters in the control table often describe the resulting data in the data table, so a lot of them can only be changed when the control entry isn't active 🙈. The way to change them is: deactivate the entry, do your SNMP Set operations to modify it, then reactivate it 💅. Deleting the control entry also deletes any associated data entries, which is a super convenient way to reclaim the resources that data was using ✨
Some objects in this MIB can trigger an action on the remote monitoring device 🔥. These objects MAY execute an action as a result of a change in the state of the object. So for those objects, asking to set one to the value it already holds causes no action to happen 🫠
To let multiple managers control things at once, the resources have to be shared between them 🤝. These are usually the memory and computation resources a function needs 🧚
The control mechanisms in this MIB are the same ones defined in the RMON MIB [17], both for control functionality and for how multiple managers interact 💜
5. Definitions
Here comes the actual MIB module, bestie 🌈🦋 Copy it exactly, no notes.
SMON-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32,
Integer32, Counter64
FROM SNMPv2-SMI
RowStatus, TEXTUAL-CONVENTION
FROM SNMPv2-TC
rmon, OwnerString
FROM RMON-MIB
LastCreateTime, DataSource, rmonConformance, probeConfig
FROM RMON2-MIB
InterfaceIndex
FROM IF-MIB
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
switchRMON MODULE-IDENTITY
LAST-UPDATED "9812160000Z"
ORGANIZATION "IETF RMON MIB Working Group"
CONTACT-INFO
"IETF RMONMIB WG Mailing list: rmonmib@cisco.com
Rich Waterman
Allot Networks Inc.
Tel: +1-408-559-0253
Email: rich@allot.com
Bill Lahaye
Xylan Corp.
Tel: +1-800-995-2612
Email: lahaye@ctron.com
Dan Romascanu
Lucent Technologies
Tel: +972-3-645-8414
Email: dromasca@lucent.com
Steven Waldbusser
International Network Services (INS)
Tel: +1-650-318-1251
Email: waldbusser@ins.com"
DESCRIPTION
"The MIB module for managing remote monitoring device
implementations for Switched Networks"
-- revision history
REVISION "9812160000Z" -- 16 Dec 1998 midemight
DESCRIPTION "Initial Version, published as RFC 2613."
::= { rmon 22 }
smonMIBObjects OBJECT IDENTIFIER ::= { switchRMON 1 }
dataSourceCaps OBJECT IDENTIFIER ::= {smonMIBObjects 1}
smonStats OBJECT IDENTIFIER ::= {smonMIBObjects 2}
portCopyConfig OBJECT IDENTIFIER ::= {smonMIBObjects 3}
smonRegistrationPoints OBJECT IDENTIFIER ::= {smonMIBObjects 4}
-- Textual Conventions
--
SmonDataSource ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Identifies the source of the data that the associated function
is configured to analyze. This Textual Convention
extends the DataSource Textual Convention defined by RMON 2
to the following data source types:
- ifIndex.<I>
DataSources of this traditional form are called 'port-based',
but only if ifType.<I> is not equal to 'propVirtual(53)'.
- smonVlanDataSource.<V>
A dataSource of this form refers to a 'Packet-based VLAN'
and is called a 'VLAN-based' dataSource. <V> is the VLAN
ID as defined by the IEEE 802.1Q standard [19]. The
value is between 1 and 4094 inclusive, and it represents
an 802.1Q VLAN-ID with global scope within a given
bridged domain, as defined by [19].
- entPhysicalEntry.<N>
A dataSource of this form refers to a physical entity within
the agent (e.g. entPhysicalClass = backplane(4)) and is called
an 'entity-based' dataSource."
SYNTAX OBJECT IDENTIFIER
-- The smonCapabilities object describes SMON agent capabilities.
smonCapabilities OBJECT-TYPE
SYNTAX BITS {
smonVlanStats(0),
smonPrioStats(1),
dataSource(2),
smonUnusedBit(3),
portCopy(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of the SMON MIB groups supported
by this agent."
::= { probeConfig 15 }
-- dataSourceCaps MIB group - defines SMON data source and port
-- copy capabilities for devices supporting SMON.
-- A NMS application will check this MIB group and retrieve
-- information about the SMON capabilities of the device before
-- applying SMON control operations to the device.
-- dataSourceCapsTable: defines capabilities of RMON data sources
dataSourceCapsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DataSourceCapsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes RMON data sources and port copy
capabilities. An NMS MAY use this table to discover the
identity and attributes of the data sources on a given agent
implementation. Similar to the probeCapabilities object,
actual row-creation operations will succeed or fail based on
the resources available and parameter values used in each
row-creation operation.
Upon restart of the RMON agent, the dataSourceTable, ifTable,
and perhaps entPhysicalTable are initialized for the available
dataSources.
For each dataSourceCapsEntry representing a VLAN or
entPhysicalEntry the agent MUST create an associated ifEntry
with a ifType value of 'propVirtual(53)'. This ifEntry will be
used as the actual value in RMON control table dataSource
objects. The assigned ifIndex value is copied into the
associated dataSourceCapsIfIndex object.
It is understood that dataSources representing VLANs may not
always be instantiated immediately upon restart, but rather as
VLAN usage is detected by the agent. The agent SHOULD attempt
to create dataSource and interface entries for all dataSources
as soon as possible."
::= { dataSourceCaps 1 }
dataSourceCapsEntry OBJECT-TYPE
SYNTAX DataSourceCapsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries per data source containing descriptions of data
source and port copy capabilities. This table is populated by
the SMON agent with one entry for each supported data
source."
INDEX { IMPLIED dataSourceCapsObject }
::= { dataSourceCapsTable 1 }
DataSourceCapsEntry ::= SEQUENCE {
dataSourceCapsObject
SmonDataSource,
dataSourceRmonCaps
BITS,
dataSourceCopyCaps
BITS,
dataSourceCapsIfIndex
InterfaceIndex
}
dataSourceCapsObject OBJECT-TYPE
SYNTAX SmonDataSource
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an object that can be a SMON data source or a
source or a destination for a port copy operation."
::= { dataSourceCapsEntry 1 }
dataSourceRmonCaps OBJECT-TYPE
SYNTAX BITS {
countErrFrames(0),
countAllGoodFrames(1),
countAnyRmonTables(2),
babyGiantsCountAsGood(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" General attributes of the specified dataSource. Note that
these are static attributes, which SHOULD NOT be adjusted
because of current resources or configuration.
- countErrFrames(0)
The agent sets this bit for the dataSource if errored frames
received on this dataSource can actually be monitored by the
agent The agent clears this bit if any errored frames are
not visible to the RMON data collector.
- countAllGoodFrames(1)
The agent sets this bit for the dataSource if all good
frames received on this dataSource can actually be monitored
by the agent. The agent clears this bit if any good frames
are not visible for RMON collection, e.g., the dataSource is
a non-promiscuous interface or an internal switch interface
which may not receive frames which were switched in hardware
or dropped by the bridge forwarding function.Okay bestie, picking up right where the bit flags left off 🦋
- countAnyRmonTables(2)
The agent sets this bit if this dataSource can actually be
used in any of the implemented RMON tables, resources
notwithstanding. The agent clears this bit if this
dataSourceCapsEntry is present simply to identify a
dataSource that may only be used as portCopySource and/or a
portCopyDest, but not the source of an actual RMON data
collection.
- babyGiantsCountAsGood(3)
The agent sets this bit if it can distinguish, for counting
purposes, between true giant frames and frames that exceed
Ethernet maximum frame size 1518 due to VLAN tagging ('baby
giants'). Specifically, this BIT means that frames up to
1522 octets are counted as good.
Agents not capable of detecting 'baby giants' will clear
this bit and will view all frames less than or equal to 1518
octets as 'good frames' and all frames larger than 1518
octets as 'bad frames' for the purpose of counting in the
smonVlanIdStats and smonPrioStats tables.
Agents capable of detecting 'baby giants' SHALL consider
them as 'good frames' for the purpose of counting in the
smonVlanIdStats and smonPrioStats tables."
::= { dataSourceCapsEntry 2 }
dataSourceCopyCaps OBJECT-TYPE
SYNTAX BITS {
copySourcePort(0),
copyDestPort(1),
copySrcTxTraffic(2),
copySrcRxTraffic(3),
countDestDropEvents(4),
copyErrFrames(5),
copyUnalteredFrames(6),
copyAllGoodFrames(7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"PortCopy function capabilities of the specified dataSource.
Note that these are static capabilities, which SHOULD NOT be
adjusted because of current resources or configuration.
- copySourcePort(0)
The agent sets this bit if this dataSource is capable of
acting as a source of a portCopy operation. The agent clears
this bit otherwise.
- copyDestPort(1)
The agent sets this bit if this dataSource is capable of
acting as a destination of a portCopy operation. The agent
clears this bit otherwise.
- copySrcTxTraffic(2)
If the copySourcePort bit is set:
The agent sets this bit if this dataSource is capable of
copying frames transmitted out this portCopy source. The
agent clears this bit otherwise. This function is needed
to support full-duplex ports.
Else:
this bit SHOULD be cleared.
- copySrcRxTraffic(3)
If the copySourcePort bit is set:
The agent sets this bit if this dataSource is capable of
copying frames received on this portCopy source. The agent
clears this bit otherwise. This function is needed to
support full-duplex ports.
Else:
this bit SHOULD be cleared.
- countDestDropEvents(4)
If the copyDestPort bit is set:
The agent sets this bit if it is capable of incrementing
portCopyDestDropEvents, when this dataSource is the
target of a portCopy operation and a frame destined to
this dataSource is dropped (for RMON counting purposes).
Else:
this BIT SHOULD be cleared.
- copyErrFrames(5)
If the copySourcePort bit is set:
The agent sets this bit if it is capable of copying all
errored frames from this portCopy source-port, for
errored frames received on this dataSource.
Else:
this BIT SHOULD be cleared.
- copyUnalteredFrames(6)
If the copySourcePort bit is set:
The agent sets the copyUnalteredFrames bit If it is
capable of copying all frames from this portCopy
source-port without alteration in any way;
Else:
this bit SHOULD be cleared.
- copyAllGoodFrames(7)
If the copySourcePort bit is set:
The agent sets this bit for the dataSource if all good
frames received on this dataSource are normally capable
of being copied by the agent. The agent clears this bit
if any good frames are not visible for the RMON portCopy
operation, e.g., the dataSource is a non-promiscuous
interface or an internal switch interface which may not
receive frames which were switched in hardware or
dropped by the bridge forwarding function.
Else:
this bit SHOULD be cleared."
::= { dataSourceCapsEntry 3 }
dataSourceCapsIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the ifIndex value of the ifEntry
associated with this smonDataSource. The agent MUST create
'propVirtual' ifEntries for each dataSourceCapsEntry of type
VLAN or entPhysicalEntry."
::= { dataSourceCapsEntry 4 }Now the SMON Statistics group, where the VLAN stats live ✨
-- The SMON Statistics MIB Group
-- aggregated statistics for IEEE 802.1Q VLAN environments.
-- VLAN statistics can be gathered by configuring smonVlanIdStats
-- and/or smonPrioStats collections. These functions allow a
-- VLAN-ID or user priority distributions per dataSource,
-- auto-populated by the agent in a manner similar to the RMON
-- hostTable.
-- Only good frames are counted in the tables described in this
-- section.
-- VLAN ID Stats
-- smonVlanStatsControlTable allows configuration of VLAN-ID
-- collections.
smonVlanStatsControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmonVlanStatsControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls the setup of VLAN statistics tables.
The statistics collected represent a distribution based on
the IEEE 802.1Q VLAN-ID (VID), for each good frame attributed
to the data source for the collection."
::= { smonStats 1 }
smonVlanStatsControlEntry OBJECT-TYPE
SYNTAX SmonVlanStatsControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the smonVlanStatsControlTable."
INDEX { smonVlanStatsControlIndex }
::= { smonVlanStatsControlTable 1 }
SmonVlanStatsControlEntry ::= SEQUENCE {
smonVlanStatsControlIndex Integer32,
smonVlanStatsControlDataSource DataSource,
smonVlanStatsControlCreateTime LastCreateTime,
smonVlanStatsControlOwner OwnerString,
smonVlanStatsControlStatus RowStatus
}
smonVlanStatsControlIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique arbitrary index for this smonVlanStatsControlEntry."
::= { smonVlanStatsControlEntry 1 }
smonVlanStatsControlDataSource OBJECT-TYPE
SYNTAX DataSource
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The source of data for this set of VLAN statistics.
This object MAY NOT be modified if the associated
smonVlanStatsControlStatus object is equal to active(1)."
::= { smonVlanStatsControlEntry 2 }
smonVlanStatsControlCreateTime OBJECT-TYPE
SYNTAX LastCreateTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this control entry was last
activated. This object allows to a management station to
detect deletion and recreation cycles between polls."
::= { smonVlanStatsControlEntry 3 }
smonVlanStatsControlOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Administratively assigned named of the owner of this entry.
It usually defines the entity that created this entry and is
therefore using the resources assigned to it, though there is
no enforcement mechanism, nor assurance that rows created are
ever used."
::= { smonVlanStatsControlEntry 4 }
smonVlanStatsControlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row.
An entry MAY NOT exist in the active state unless all
objects in the entry have an appropriate value.
If this object is not equal to active(1), all associated
entries in the smonVlanIdStatsTable SHALL be deleted."
::= { smonVlanStatsControlEntry 5 }
-- The VLAN Statistics Table
smonVlanIdStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmonVlanIdStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains the VLAN statistics data.
The statistics collected represent a distribution based
on the IEEE 802.1Q VLAN-ID (VID), for each good frame
attributed to the data source for the collection.
This function applies the same rules for attributing frames
to VLAN-based collections. RMON VLAN statistics are collected
after the Ingress Rules defined in section 3.13 of the VLAN
Specification [20] are applied.
It is possible that entries in this table will be
garbage-collected, based on agent resources, and VLAN
configuration. Agents are encouraged to support all 4094
index values and not garbage collect this table."
::= { smonStats 2 }
smonVlanIdStatsEntry OBJECT-TYPE
SYNTAX SmonVlanIdStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in smonVlanIdStatsTable."
INDEX { smonVlanStatsControlIndex, smonVlanIdStatsId }
::= { smonVlanIdStatsTable 1 }
SmonVlanIdStatsEntry ::= SEQUENCE {
smonVlanIdStatsId Integer32,
smonVlanIdStatsTotalPkts Counter32,
smonVlanIdStatsTotalOverflowPkts Counter32,
smonVlanIdStatsTotalHCPkts Counter64,
smonVlanIdStatsTotalOctets Counter32,
smonVlanIdStatsTotalOverflowOctets Counter32,
smonVlanIdStatsTotalHCOctets Counter64,
smonVlanIdStatsNUcastPkts Counter32,
smonVlanIdStatsNUcastOverflowPkts Counter32,
smonVlanIdStatsNUcastHCPkts Counter64,
smonVlanIdStatsNUcastOctets Counter32,
smonVlanIdStatsNUcastOverflowOctets Counter32,
smonVlanIdStatsNUcastHCOctets Counter64,
smonVlanIdStatsCreateTime LastCreateTime
}
smonVlanIdStatsId OBJECT-TYPE
SYNTAX Integer32 (1..4094)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique identifier of the VLAN monitored for
this specific statistics collection.
Tagged packets match the VID for the range between 1 and 4094.
An external RMON probe MAY detect VID=0 on an Inter Switch
Link, in which case the packet belongs to a VLAN determined by
the PVID of the ingress port. The VLAN to which such a packet
belongs can be determined only by a RMON probe internal to the
switch."
REFERENCE
"Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q/D10, chapter 3.13"
::= { smonVlanIdStatsEntry 1 }
smonVlanIdStatsTotalPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets counted on this VLAN."
::= { smonVlanIdStatsEntry 2 }okay so the VLAN stats are about to get SO good 💖 here's the overflow and octet counters for each VLAN, plus the creation timestamp 🎀
smonVlanIdStatsTotalOverflowPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated smonVlanIdStatsTotalPkts
counter has overflowed."
::= { smonVlanIdStatsEntry 3 }
smonVlanIdStatsTotalHCPkts OBJECT-TYPE
SYNTAX Counter64
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets counted on this VLAN."
::= { smonVlanIdStatsEntry 4 }
smonVlanIdStatsTotalOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets counted on this VLAN."
::= { smonVlanIdStatsEntry 5 }
smonVlanIdStatsTotalOverflowOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated smonVlanIdStatsTotalOctets
counter has overflowed."
::= { smonVlanIdStatsEntry 6 }
smonVlanIdStatsTotalHCOctets OBJECT-TYPE
SYNTAX Counter64
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets counted on this VLAN."
::= { smonVlanIdStatsEntry 7 }
smonVlanIdStatsNUcastPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of non-unicast packets counted on this
VLAN."
::= { smonVlanIdStatsEntry 8 }
smonVlanIdStatsNUcastOverflowPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated smonVlanIdStatsNUcastPkts
counter has overflowed."
::= { smonVlanIdStatsEntry 9 }
smonVlanIdStatsNUcastHCPkts OBJECT-TYPE
SYNTAX Counter64
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of non-unicast packets counted on
this VLAN."
::= { smonVlanIdStatsEntry 10 }
smonVlanIdStatsNUcastOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of non-unicast octets counted on
this VLAN."
::= { smonVlanIdStatsEntry 11 }
smonVlanIdStatsNUcastOverflowOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated
smonVlanIdStatsNUcastOctets counter has overflowed."
::= { smonVlanIdStatsEntry 12 }
smonVlanIdStatsNUcastHCOctets OBJECT-TYPE
SYNTAX Counter64
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Non-unicast octets counted on
this VLAN."
::= { smonVlanIdStatsEntry 13 }
smonVlanIdStatsCreateTime OBJECT-TYPE
SYNTAX LastCreateTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this entry was last
activated. This object allows to a management station to
detect deletion and recreation cycles between polls."
::= { smonVlanIdStatsEntry 14 }okay now the priority stats 🧚 the control table is where you set up the collections, and the 3-bit user priority from the TCI field is the star of the show ✨
-- smonPrioStatsControlTable
smonPrioStatsControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmonPrioStatsControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Controls the setup of priority statistics tables.
The smonPrioStatsControlTable allows configuration of
collections based on the value of the 3-bit user priority
field encoded in the Tag Control Information (TCI) field
according to [19],[20].
Note that this table merely reports priority as encoded in
the VLAN headers, not the priority (if any) given to the
frame for the actual switching purposes."
::= { smonStats 3 }
smonPrioStatsControlEntry OBJECT-TYPE
SYNTAX SmonPrioStatsControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in the smonPrioStatsControlTable."
INDEX { smonPrioStatsControlIndex }
::= { smonPrioStatsControlTable 1 }
SmonPrioStatsControlEntry ::= SEQUENCE {
smonPrioStatsControlIndex Integer32,
smonPrioStatsControlDataSource DataSource,
smonPrioStatsControlCreateTime LastCreateTime,
smonPrioStatsControlOwner OwnerString,
smonPrioStatsControlStatus RowStatus
}
smonPrioStatsControlIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A unique arbitrary index for this smonPrioStatsControlEntry."
::= { smonPrioStatsControlEntry 1 }
smonPrioStatsControlDataSource OBJECT-TYPE
SYNTAX DataSource
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The source of data for this set of VLAN statistics.
This object MAY NOT be modified if the associated
smonPrioStatsControlStatus object is equal to active(1)."
::= { smonPrioStatsControlEntry 2 }
smonPrioStatsControlCreateTime OBJECT-TYPE
SYNTAX LastCreateTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this entry was created.
This object allows to a management station to
detect deletion and recreation cycles between polls."
::= { smonPrioStatsControlEntry 3 }
smonPrioStatsControlOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Administratively assigned named of the owner of this entry.
It usually defines the entity that created this entry and is
therefore using the resources assigned to it, though there is
no enforcement mechanism, nor assurance that rows created are
ever used."
::= { smonPrioStatsControlEntry 4 }
smonPrioStatsControlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row.
An entry MAY NOT exist in the active state unless all
objects in the entry have an appropriate value.
If this object is not equal to active(1), all associated
entries in the smonPrioStatsTable SHALL be deleted."
::= { smonPrioStatsControlEntry 5 }and now the actual priority statistics table 🌸 the description says there are always at most eight rows per statistical set, so they skipped garbage collection. makes sense tbh 💅
-- The Priority Statistics Table
smonPrioStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF SmonPrioStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains the priority statistics. The collections are based
on the value of the 3-bit user priority field encoded in the
Tag Control Information (TCI) field according to [19], [20].
Note that this table merely reports priority as encoded in
the VLAN headers, not the priority (if any) given to the
frame for the actual switching purposes.
No garbage collection is designed for this table, as there
always are at most eight rows per statistical set, and the
low memory requirements do not justify the implementation of
such a mechanism."
::= { smonStats 4 }
smonPrioStatsEntry OBJECT-TYPE
SYNTAX SmonPrioStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A conceptual row in smonPrioStatsTable."
INDEX { smonPrioStatsControlIndex, smonPrioStatsId }
::= { smonPrioStatsTable 1 }
SmonPrioStatsEntry ::= SEQUENCE {
smonPrioStatsId Integer32,
smonPrioStatsPkts Counter32,
smonPrioStatsOverflowPkts Counter32,
smonPrioStatsHCPkts Counter64,
smonPrioStatsOctets Counter32,
smonPrioStatsOverflowOctets Counter32,
smonPrioStatsHCOctets Counter64
}
smonPrioStatsId OBJECT-TYPE
SYNTAX Integer32 (0..7)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique identifier of the priority level monitored for
this specific statistics collection."
REFERENCE
" Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q/D10, chapter 4.3.2.1"
::= { smonPrioStatsEntry 1 }
smonPrioStatsPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets counted on
this priority level."
::= { smonPrioStatsEntry 2 }
smonPrioStatsOverflowPkts OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated smonPrioStatsPkts
counter has overflowed."
::= { smonPrioStatsEntry 3 }
smonPrioStatsHCPkts OBJECT-TYPE
SYNTAX Counter64
UNITS "packets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets counted on
this priority level."
::= { smonPrioStatsEntry 4 }
smonPrioStatsOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets counted on
this priority level."
::= { smonPrioStatsEntry 5 }
smonPrioStatsOverflowOctets OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times the associated smonPrioStatsOctets
counter has overflowed."
::= { smonPrioStatsEntry 6 }
smonPrioStatsHCOctets OBJECT-TYPE
SYNTAX Counter64
UNITS "octets"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets counted on
this priority level."
::= { smonPrioStatsEntry 7 }last bit for now: the port copy table 🦋 this is where you copy every frame from one port to another so an external RMON probe can watch it. the MUST in here is a big deal, so pay attention bestie 👑
portCopyTable OBJECT-TYPE
SYNTAX SEQUENCE OF PortCopyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" Port Copy provides the ability to copy all frames from a
specified source to specified destination within a switch.
Source and destinations MUST be ifEntries, as defined by [22].
One to one, one to many, many to one and many to many source to
destination relationships may be configured.
Applicable counters on the destination will increment for all
packets transiting the port, be it by normal bridging/switching
or due to packet copy.
Note that this table manages no RMON data collection by itself,
and an agent may possibly implement no RMON objects except
objects related to the port copy operation defined by the
portCopyCompliance conformance macro. That allows for a switch
with no other embedded RMON capability to perform port copy
operations to a destination port at which a different external
RMON probe is connected.
One to one, many to one and one to many source to destination
relationships may be configured.
Each row that exists in this table defines such a
relationship. By disabling a row in this table the port copy
relationship no longer exists.
The number of entries and the types of port copies (1-1,
many-1, 1-many) are implementation specific and could
possibly be dynamic due to changing resource availability.okay bestie, this chunk is all MIB code, so it stays exactly as written 💅🎀
In order to configure a source to destination portCopy
relationship, both source and destination interfaces MUST be
present as an ifEntry in the ifTable and their respective
ifAdminStatus and ifOperStatus values MUST be equal to
'up(1)'. If the value of any of those two objects changes
after the portCopyEntry is activated, portCopyStatus will
transition to 'notReady(3)'.
The capability of an interface to be source or destination of
a port copy operation is described by the 'copySourcePort(0)'
and 'copyDestPort(1)' bits in dataSourceCopyCaps. Those bits
SHOULD be appropriately set by the agent, in order to allow
for a portCopyEntry to be created.
Applicable counters on the destination will increment for all
packets transmitted, be it by normal bridging/switching or
due to packet copy."
::= { portCopyConfig 1 }
portCopyEntry OBJECT-TYPE
SYNTAX PortCopyEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Describes a particular port copy entry."
INDEX { portCopySource, portCopyDest }
::= { portCopyTable 1 }
PortCopyEntry ::= SEQUENCE {
portCopySource
InterfaceIndex,
portCopyDest
InterfaceIndex,
portCopyDestDropEvents
Counter32,
portCopyDirection
INTEGER,
portCopyStatus
RowStatus
}
portCopySource OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ifIndex of the source which will have all packets
redirected to the destination as defined by portCopyDest."
::= { portCopyEntry 1 }
portCopyDest OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines the ifIndex destination for the copy operation."
::= { portCopyEntry 2 }
portCopyDestDropEvents OBJECT-TYPE
SYNTAX Counter32
UNITS "events"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of events in which port copy packets were
dropped by the switch at the destination port 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.
A single dropped event counter is maintained for each
portCopyDest. Thus all instances associated with a given
portCopyDest will have the same portCopyDestDropEvents
value."
::= { portCopyEntry 3 }
portCopyDirection OBJECT-TYPE
SYNTAX INTEGER {
copyRxOnly(1),
copyTxOnly(2),
copyBoth(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object affects the way traffic is copied from a switch
source port, for the indicated port copy operation.
If this object has the value 'copyRxOnly(1)', then only
traffic received on the indicated source port will be copied
to the indicated destination port.
If this object has the value 'copyTxOnly(2)', then only
traffic transmitted out the indicated source port will be
copied to the indicated destination port.
If this object has the value 'copyBoth(3)', then all traffic
received or transmitted on the indicated source port will be
copied to the indicated destination port.
The creation and deletion of instances of this object is
controlled by the portCopyRowStatus object. Note that there
is no guarantee that changes in the value of this object
performed while the associated portCopyRowStatus object is
equal to active will not cause traffic discontinuities in the
packet stream."
DEFVAL { copyBoth }
::= { portCopyEntry 4 }
portCopyStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Defines the status of the port copy entry.
In order to configure a source to destination portCopy
relationship, both source and destination interfaces MUST be
present as an ifEntry in the ifTable and their respective
ifAdminStatus and ifOperStatus values MUST be equal to
'up(1)'. If the value of any of those two objects changes
after the portCopyEntry is activated, portCopyStatus will
transition to 'notReady(3)'.
The capability of an interface to be source or destination of
a port copy operation is described by the 'copySourcePort(0)'
and 'copyDestPort(1)' bits in dataSourceCopyCaps. Those bits
SHOULD be appropriately set by the agent, in order to allow
for a portCopyEntry to be created."
::= { portCopyEntry 5 }
-- smonRegistrationPoints
-- defines a set of OIDs for registration purposes of entities
-- supported by the SMON MIB.
smonVlanDataSource
OBJECT IDENTIFIER ::= { smonRegistrationPoints 1}
-- Defined for use as an SmonDataSource. A single integer parameter
-- is appended to the end of this OID when actually encountered in
-- the dataSourceCapsTable, which represents a positive, non-zero
-- VLAN identifier value.
-- Conformance Macros
smonMIBCompliances OBJECT IDENTIFIER ::= { rmonConformance 3}
smonMIBGroups OBJECT IDENTIFIER ::= { rmonConformance 4}
smonMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for full conformance with the SMON
MIB"
MODULE -- this module
MANDATORY-GROUPS {dataSourceCapsGroup,
smonVlanStatsGroup,
smonPrioStatsGroup,
portCopyConfigGroup,
smonInformationGroup}
GROUP smonHcTo100mbGroup
DESCRIPTION
"This group of VLAN statistics counter are mandatory only for
those network interfaces for which the corresponding ifSpeed
can be greater than 10MB/sec and less than or equal to
100MB/sec."
GROUP smonHc100mbPlusGroup
DESCRIPTION
"This group of VLAN statistics counters are mandatory only for
those network interfaces for which the corresponding ifSpeed
can be more than 100MB/sec. This group of VLAN statistics is
also mandatory for smonDataSources of type VLAN or
entPhysicalEntry."
::= { smonMIBCompliances 1 }
smonMIBVlanStatsCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance with the SMON MIB
with support for VLAN Statistics. Mandatory for a SMON probe
in environment where IEEE 802.1Q bridging is implemented."
MODULE -- this module
MANDATORY-GROUPS {dataSourceCapsGroup,
smonVlanStatsGroup,
smonInformationGroup}
GROUP hcVlanTo100mbGroup
DESCRIPTION
"This group of VLAN statistics counter are mandatory only
for those network interfaces for which the corresponding
ifSpeed can be up to and including 100MB/sec."
GROUP hcVlan100mbPlusGroup
DESCRIPTION
"This group of VLAN statistics counters are mandatory only for
those network interfaces for which the corresponding ifSpeed
is greater than 100MB/sec. This group of VLAN statistics is
also mandatory for smonDataSources of type VLAN or
entPhysicalEntry."
::= { smonMIBCompliances 2 }
smonMIBPrioStatsCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance with the SMON MIB
with support for priority level Statistics. Mandatory for a
SMON probe in a environment where IEEE 802.1p
priority-switching is implemented."
MODULE -- this module
MANDATORY-GROUPS {dataSourceCapsGroup,
smonPrioStatsGroup,
smonInformationGroup}
GROUP hcPrioTo100mbGroup
DESCRIPTION
"This group of VLAN priority statistics counters are mandatory
only for those network interfaces for which the corresponding
ifSpeed can be up to and including 100MB/sec."
GROUP hcPrio100mbPlusGroup
DESCRIPTION
"This group is mandatory only for those network
interfaces for which the corresponding ifSpeed is greater
than 100MB/sec. This group of VLAN priority
statistics is also mandatory for smonDataSources of type
VLAN or entPhysicalEntry"
::= { smonMIBCompliances 3 }
portCopyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Describes the requirements for conformance with the port copy
functionality defined by the SMON MIB"
MODULE -- this module
MANDATORY-GROUPS {dataSourceCapsGroup,
portCopyConfigGroup,
smonInformationGroup}
::= { smonMIBCompliances 4}
dataSourceCapsGroup OBJECT-GROUP
OBJECTS { dataSourceRmonCaps,
dataSourceCopyCaps,
dataSourceCapsIfIndex}
STATUS current
DESCRIPTION
"Defines the objects that describe the capabilities of RMON
data sources."
::= {smonMIBGroups 1 }
smonVlanStatsGroup OBJECT-GROUP
OBJECTS { smonVlanStatsControlDataSource,
smonVlanStatsControlCreateTime,
smonVlanStatsControlOwner,
smonVlanStatsControlStatus,
smonVlanIdStatsTotalPkts,
smonVlanIdStatsTotalOctets,
smonVlanIdStatsNUcastPkts,
smonVlanIdStatsCreateTime}
STATUS current
DESCRIPTION
"Defines the switch monitoring specific statistics - per VLAN
Id on interfaces of 10MB or less."
::= { smonMIBGroups 2 }
smonPrioStatsGroup OBJECT-GROUP
OBJECTS { smonPrioStatsControlDataSource,
smonPrioStatsControlCreateTime,
smonPrioStatsControlOwner,
smonPrioStatsControlStatus,
smonPrioStatsPkts,
smonPrioStatsOctets}
STATUS current
DESCRIPTION
"Defines the switch monitoring specific statistics - per VLAN
Id on interface."
::= { smonMIBGroups 3 }
smonHcTo100mbGroup OBJECT-GROUP
OBJECTS { smonVlanIdStatsTotalOverflowOctets,
smonVlanIdStatsTotalHCOctets,
smonPrioStatsOverflowOctets,
smonPrioStatsHCOctets}
STATUS current
DESCRIPTION
"Defines the additional high capacity statistics needed to be
kept on interfaces with ifSpeed greater than 10MB/sec and
less than or equal to 100MB/sec."
::= { smonMIBGroups 4 } smonHc100mbPlusGroup OBJECT-GROUP
OBJECTS { smonVlanIdStatsTotalOverflowPkts,
smonVlanIdStatsTotalHCPkts,
smonVlanIdStatsTotalOverflowOctets,
smonVlanIdStatsTotalHCOctets,
smonVlanIdStatsNUcastOverflowPkts,
smonVlanIdStatsNUcastHCPkts,
smonPrioStatsOverflowPkts,
smonPrioStatsHCPkts,
smonPrioStatsOverflowOctets,
smonPrioStatsHCOctets}
STATUS current
DESCRIPTION
"Defines the additional high capacity statistics needed to be
kept on interfaces with ifSpeed of more than 100MB/sec. These
statistics MUST also be kept on smonDataSources of type VLAN
or entPhysicalEntry."
::= { smonMIBGroups 5 }
hcVlanTo100mbGroup OBJECT-GROUP
OBJECTS { smonVlanIdStatsTotalOverflowOctets,
smonVlanIdStatsTotalHCOctets}
STATUS current
DESCRIPTION
"Defines the additional high capacity VLAN statistics
needed to be kept on interfaces with ifSpeed greater than
10MB/sec and less than or equal to 100MB/sec."
::= { smonMIBGroups 6 }
hcVlan100mbPlusGroup OBJECT-GROUP
OBJECTS { smonVlanIdStatsTotalOverflowPkts,
smonVlanIdStatsTotalHCPkts,
smonVlanIdStatsTotalOverflowOctets,
smonVlanIdStatsTotalHCOctets,
smonVlanIdStatsNUcastOverflowPkts,
smonVlanIdStatsNUcastHCPkts}
STATUS current
DESCRIPTION
"Defines the additional high capacity VLAN statistics
needed to be kept on interfaces with ifSpeed of more than
100MB/sec. These statistics MUST also be kept on
smonDataSources of type VLAN or entPhysicalEntry."
::= { smonMIBGroups 7 }
hcPrioTo100mbGroup OBJECT-GROUP
OBJECTS { smonPrioStatsOverflowOctets,
smonPrioStatsHCOctets }
STATUS current
DESCRIPTION
"Defines the additional high capacity VLAN priority
statistics needed to be kept on interfaces with
ifSpeed of greater than 10MB/sec and less than or equal
to 100MB/sec."
::= { smonMIBGroups 8 }
hcPrio100mbPlusGroup OBJECT-GROUP
OBJECTS { smonPrioStatsOverflowPkts,
smonPrioStatsHCPkts,
smonPrioStatsOverflowOctets,
smonPrioStatsHCOctets}
STATUS current
DESCRIPTION
"Defines the additional high capacity VLAN priority
statistics needed to be kept on interfaces with
ifSpeed of greater than 100MB/sec. These statistics MUST
also be kept on smonDataSources of type VLAN or
entPhysicalEntry."
::= { smonMIBGroups 9 }
smonVlanStatsExtGroup OBJECT-GROUP
OBJECTS {smonVlanIdStatsNUcastOctets,
smonVlanIdStatsNUcastOverflowOctets,
smonVlanIdStatsNUcastHCOctets}
STATUS current
DESCRIPTION
"Defines the switch monitoring specific statistics for systems
capable of counting non-unicast octets for a given dataSource
(as described in the dataSourceRmonCaps object)."
::= { smonMIBGroups 10 }
smonInformationGroup OBJECT-GROUP
OBJECTS { smonCapabilities }
STATUS current
DESCRIPTION
"An indication of the SMON capabilities supported by this
agent."
::= { smonMIBGroups 11 }
portCopyConfigGroup OBJECT-GROUP
OBJECTS { portCopyDestDropEvents,
portCopyDirection,
portCopyStatus
}
STATUS current
DESCRIPTION
"Defines the control objects for copy port operations."
::= { smonMIBGroups 12 }
END6. References 📚✨
okay so here's the bibliography, bestie 🧚 every single one of these is cited somewhere in the spec, so we keep the full details, no cap 💅
- [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
- [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
- [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
- [12] Blumenthal, U., and B. Wijnen, "User-based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
- [14] Levi, D., Meyer, P., and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
- [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [16] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
- [17] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 1757, February 1995.
- [18] McCloghrie, K. and A. Bierman, "Entity MIB", RFC 2037, October 1996.
- [19] ISO/IEC Final CD 15802-3, ANSI/IEEE Std 802.1D-1998 "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges: Revision (Incorporating IEEE P802.1p: Traffic Class Expediting and Dynamic Multicast Filtering)", March 1998.
- [20] ANSI/IEEE Draft Standard P802.1Q/D10, "IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", March 1998.
- [21] De Graaf, K., Romascanu, D., McMaster, D. and K. McCloghrie, "Definition of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997.
- [22] McCloghrie, K. and F. Kastenholz," The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
- [23] Decker, E. Langille, P., Rijsinghani, A. and K. McCloghrie.. - "Definitions of Managed Objects for Bridges", RFC 1493, July 1993
- [24] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [25] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
7. Intellectual Property 🎀
okay this part is the legal-ish bit, but it's still important 🫶 the IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the tech in this doc are valid or how far they go. it also doesn't say it went looking for any of those rights. if you want the details on how the IETF handles rights for standards-track and standards-related docs, check out BCP-11 📖. copies of any claimed rights that were offered up for publication, any promises of licenses, or what happened when someone tried to get a general license or permission for implementers or users of this spec to use those proprietary rights, can all be obtained from the IETF Secretariat 💌
the IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard to let them know. send that info to the IETF Executive Director 🦋
8. Security Considerations 🔒💀
okay bestie, this part is SERIOUS, so read it like it matters 😭 this MIB has a bunch of management objects with a MAX-ACCESS of read-write and/or read-create. those can be sensitive or vulnerable depending on the network. if SET operations are supported in a non-secure environment without proper protection, that can really mess with network operations 💀
there are also some managed objects in here that might hold sensitive info:
smonCapabilities
dataSourceCapsTable
portCopyTableso it's super important to control even GET access to these, and maybe even encrypt their values when they're sent over the network with SNMP 🔐 not every version of SNMP has features for that kind of secure setup, so keep that in mind 🙈
SNMPv1 on its own is not a secure environment 🚫. even if the network is secure (like if you're using IPSec), there's still no control over who on that secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. wild, right? 😳
it is RECOMMENDED that implementors consider the security features provided by the SNMPv3 framework 💜. specifically, using the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is RECOMMENDED 🌈.
and last but not least, it's a customer or user responsibility to make sure the SNMP entity giving access to an instance of this MIB is properly configured. access should only go to the principals (users) who actually have legitimate rights to GET or SET (change/create/delete) these objects 👑 basically, lock it down, periodt 💅
9. Authors' Addresses 🦋
these are the lovely people who wrote this spec 🧚✨
Richard Waterman Allot Communications 292 E. Main St. Los Gatos, CA. 95030 USA
Phone: +1-408-399-3154 EMail: rich@allot.com
Bill Lahaye Xylan Corporation 26707 W. Agoura Rd. Calabasas, CA 91302 USA
Phone: +1-800-995-2612 EMail bill.lahaye@xylan.com
Dan Romascanu Lucent Technologies Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel
Phone: +972-3-645-8414 EMail: dromasca@lucent.com
Steven Waldbusser International Network Services (INS) 1213 Innsbruck Dr. Sunnyvale, CA 94089
Phone: +1-650-318-1251 EMail: waldbusser@ins.com
A. Full Copyright Statement ✨
Copyright (C) The Internet Society (1999). All Rights Reserved. 💖
okay so this bit is the legal stuff, but it's actually kinda cute 🎀 The gist is: you're totally allowed to copy and share this document, and you can even make derivative works that comment on it or explain it or help people implement it. 🫶 Just keep the copyright notice and this paragraph on all the copies, bestie. 💅
The one thing you can't do is modify the document itself. Like, you can't remove the copyright notice or the references to the Internet Society or other Internet orgs 🙈 The exceptions are if you're developing Internet standards (then the Internet Standards process copyright procedures have to be followed) or if you're translating it into a language other than English 🌈
The permissions here are perpetual, so they won't be revoked by the Internet Society or its successors or assigns. Lowkey iconic, no cap ⭐
And the usual disclaimer: this document and its info are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 Someone's paying the bills so the RFC Editor can keep doing its thing, and that's honestly so sweet 🧚
📦 where this page comes from
- ietf: rfc2613 1999-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms