RFC 7784
Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB
RFC 7784: Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB π¦
Okay bestie, this is RFC 7784 from the Internet Engineering Task Force (IETF) πΈ It was written by D. Kumar, S. Salam, and T. Senevirathne, all from Cisco, and it's dated February 2016. It's on the Standards Track, so it's a real Internet standard π Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own, no drama π
Abstract π
So this doc specifies the MIB for the OAM (Operations, Administration, and Maintenance) objects for IETF TRILL (Transparent Interconnection of Lots of Links) π§
Status of This Memo πΈ
Okay so this is an Internet Standards Track document, meaning it's an actual standard and not just a vibe β¨
It came out of the IETF, so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 π
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7784 π
Copyright Notice π
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date it was published. Please read those carefully, because they spell out your rights and restrictions for this document π«Ά Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents ποΈ
1. Introduction ....................................................2
2. The Internet-Standard Management Framework ......................3
3. Conventions .....................................................3
4. Overview ........................................................4
5. Structure of the MIB Module .....................................4
5.1. Textual Conventions ........................................4
5.2. The TRILL OAM MIB Subtree ..................................4
5.3.1. The Notifications Subtree ...........................5
5.3.2. The Table Structures ................................5
5.3.2.1. trillOamMepTable Objects ...................5
5.3.2.2. trillOamMepFlowCfgTable Objects ............6
5.3.2.3. trillOamPtrTable Objects ...................6
5.3.2.4. trillOamMtvrTable Objects ..................6
5.3.2.5. trillOamMepDbTable Objects .................6
6. Relationship to Other MIB Modules ...............................6
6.1. Relationship to the IEEE8021-TC-MIB ........................7
6.2. Relationship to the IEEE8021-CFM-MIB .......................7
6.3. MIB Modules Required for IMPORTS ...........................8
7. Definitions .....................................................8
8. Security Considerations ........................................44
9. IANA Considerations ............................................47
10. References ....................................................47
10.1. Normative References .....................................47
10.2. Informative References ...................................49
Acknowledgments ...................................................50
Authors' Addresses ................................................50
1. Introduction π·
So overall, TRILL OAM meets the requirements given in [RFC6905] β¨ The general framework for TRILL OAM is specified in [RFC7174]. The nitty-gritty Fault Management (FM) solution that follows that framework is in [RFC7455]. And it's lowkey genius: the solution reuses the message format from Ethernet Connectivity Fault Management (CFM) [802.1Q] as the basis for the TRILL OAM message channel π§
This doc builds on the CFM MIB modules from [802.1Q] as the base for the TRILL OAM MIB. It augments the existing tables to add new TRILL managed objects that TRILL needs π It also specifies a brand-new table, with its own managed objects, for TRILL OAM-specific capabilities π
2. The Internet-Standard Management Framework π
If you want the full tea on the documents that describe the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] π
Managed objects live in a virtual information store called the Management Information Base, or MIB ποΈ You usually reach them through the Simple Network Management Protocol (SNMP). Objects get defined using the mechanisms in the Structure of Management Information (SMI). This memo's MIB module is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] π
3. Conventions π¦
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These are serious business, so no vibes-only interpretation π€
Here are the abbreviations that pop up in the doc π§
CCM - Continuity Check Message [802.1Q]
EMS - Element Management System [Q.840.1]
MEP - Maintenance End Point [RFC7174] [802.1Q]
MIP - Maintenance Intermediate Point [RFC7174] [802.1Q]
MP - Maintenance Point [RFC7174]
MTVM - Multi-destination Tree Verification Message [RFC7455]
MTVR - Multi-destination Tree Verification Reply [RFC7455]
NMS - Network Management System [Q.840.1]
PTM - Path Trace Message [RFC7455]
PTR - Path Trace Reply [RFC7455]
4. Overview π
The TRILL OAM MIB module gives you an overall framework for managing TRILL OAM β¨ It leverages the IEEE8021-CFM-MIB and IEEE8021-CFM-V2-MIB modules defined in [802.1Q], and it augments the Maintenance End Point (MEP) and MEP Db entries. It also adds a new table for messages specific to TRILL OAM π«§
5. Structure of the MIB Module ποΈ
Objects in this MIB module are arranged into subtrees. Each subtree is a set of related objects, like little friend groups π― The various subtrees are shown below, supplemented with the required elements of the IEEE8021-CFM-MIB module.
5.1. Textual Conventions
Textual conventions are defined to represent object types relevant to the TRILL OAM MIB π
5.2. The TRILL OAM MIB Subtree
The TRILL OAM MIB tree described below consists of trilloamNotifications (Traps) and trillOamMibObjects. The trilloamNotifications are sent to the management entity whenever a MEP loses or restores contact with its peer flow MEPs π¨
The TRILL OAM MIB per MEP Objects are defined in the trillOamMepTable. The trillOamMepTable augments the dot1agCfmMepEntry (please see Section 6.1) defined in IEEE8021-CFM-MIB. It includes objects that are locally defined for an individual MEP and its associated flow π
TRILL-OAM-MIB
|--trillOamNotifications (trillOamMib 0}
|--trillOamFaultAlarm
|--trillOamMibObjects {trillOamMib 1}
|--trillOamMep {trillOamMibObjects 1}
|--trillOamMepTable {trillOamMep 1} - Local TRLL config
|--trillOamMepFlowCfgTable
|--trillOamPtrTable
|--trillOamMtvrTable
|--trillOamMepDbTable
5.3.1. The Notifications Subtree π
Notifications (fault alarms) are sent to the management entity with the OID of the MEP that detected the fault. They get generated whenever a MEP loses or restores contact with its peer flow MEPs π
5.3.2. The Table Structures π
The TRILL OAM MIB per MEP Objects are defined in the trillOamMepTable. The trillOamMepTable augments the dot1agCfmMepEntry (please see Section 6.1) defined in IEEE8021-CFM-MIB. It includes objects that are locally defined for an individual MEP and its associated flow π
5.3.2.1. trillOamMepTable Objects
This table is an extension of the dot1agCfmMepTable. Rows get automatically added or deleted from this table based on row creation and destruction in the dot1agCfmMepTable π
This table is the local MEP TRILL OAM configuration table. Its primary purpose is to provide local parameters for the TRILL OAM function found in [RFC7455] and instantiated at a MEP π§
5.3.2.2. trillOamMepFlowCfgTable Objects
Each row in this table represents a Flow Configuration Entry for the associated MEP. This table uses four indices. The first three are the indices of the Maintenance Domain, MANET, and MEP tables. The fourth index is the specific Flow Configuration Entry on the selected MEP. Some writable objects in this table only apply in certain cases (as described under each object below), and attempts to write values for them in other cases will be ignored π
5.3.2.3. trillOamPtrTable Objects
Each row in this table represents a Path Trace Reply Entry for the Defined MEP and Transaction. This table uses four indices. The first three identify the MEP, and the fourth index specifies the Transaction Identifier. This Transaction Identifier uniquely identifies the response for a MEP, which can have multiple flows π€οΈ
5.3.2.4. trillOamMtvrTable Objects
This table includes managed objects for the Multi-destination Reply. Each row in the table represents a Multi-destination Reply Entry for the defined MEP and Transaction. This table uses the following five indices: 1) Maintenance Domain, 2) MANET, 3) MEP tables, 4) Transaction Identifier of selected MEP, and 5) receive order of Multi-destination replies π
Some writable objects in this table only apply in certain cases (as described under each object below), and attempts to write a value for them in other cases will be ignored π
5.3.2.5. trillOamMepDbTable Objects
This table is an augmentation of the dot1agCfmMepDbTable, and rows get automatically added or deleted from this table based on row creation and destruction in the dot1agCfmMepDbTable π«Ά
6. Relationship to Other MIB Modules π
The IEEE8021-CFM-MIB [IEEE8021-CFM-MIB] and [LLDP-MIB] contain objects that are relevant to the TRILL OAM MIB. Management objects in these modules are not duplicated here, to reduce overlap as much as possible πΈ From the IEEE8021-CFM-MIB, the following objects are imported:
dot1agCfmMdIndexdot1agCfmMaIndexdot1agCfmMepIdentifierdot1agCfmMepEntrydot1agCfmMepDbEntryDot1agCfmIngressActionFieldValueDot1agCfmEgressActionFieldValueDot1agCfmRemoteMepState
From the [LLDP-MIB], the following objects are imported:
LldpChassisIdLldpChassisIdSubtypeLldpPortId
6.1. Relationship to the IEEE8021-TC-MIB π§©
In TRILL, traffic labeling can be done using either a 12-bit VLAN or a 24-bit Fine-Grained Label (FGL) [RFC7172] π·οΈ
The IEEE8021-TC-MIB definition of IEEE8021ServiceSelectorType includes the following two values:
1representing avlanId, and2representing a 24-bitisid
We have chosen to use value 2 for TRILL's FGL π As such, the TRILL OAM MIB will import IEEE8021ServiceSelectorType, IEEE8021ServiceSelectorValueOrNone, and IEEE8021ServiceSelectorValue from IEEE8021-TC-MIB β¨
6.2. Relationship to the IEEE8021-CFM-MIB
okay so trillOamMepTable basically extends dot1agCfmMepEntry π which means you HAVE to implement IEEE8021-CFM-MIB, because that's the table we're augmenting. Anything in there that doesn't apply to TRILL gets handled by the TRILL implementation backend, and it has to hand back the right default values from IEEE8021-CFM-MIB π«Ά
the TRILL OAM implementation doesn't do the Link Trace Message or Link Trace Reply π bc RFC 7455 swapped them out. unicast traffic uses the Path Trace Message and Reply instead, and multicast traffic uses the Multi-destination Tree verification Message and Reply. the stats for the Link Trace stuff should just default as per IEEE8021-CFM-MIB, no drama β¨
6.3. MIB Modules Required for IMPORTS
this MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IEEE-8021-CFM-MIB, and LLDP-MIB π
7. Definitions β¨
here's the whole MIB module, the big main-character moment π
TRILL-OAM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Counter32,
Unsigned32,
Integer32,
mib-2,
NOTIFICATION-TYPE
FROM SNMPv2-SMI
RowStatus,
TruthValue,
TimeStamp,
MacAddress
FROM SNMPv2-TC
OBJECT-GROUP,
NOTIFICATION-GROUP,
MODULE-COMPLIANCE
FROM SNMPv2-CONF
dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepIdentifier,
dot1agCfmMepEntry,
dot1agCfmMepDbEntry,
Dot1agCfmIngressActionFieldValue,
Dot1agCfmEgressActionFieldValue,
Dot1agCfmRemoteMepState
FROM IEEE8021-CFM-MIB
LldpChassisId,
LldpChassisIdSubtype,
LldpPortId,
LldpPortIdSubtype
FROM LLDP-MIB;
trillOamMib MODULE-IDENTITY
LAST-UPDATED "201601141200Z"
ORGANIZATION "IETF TRILL WG"
CONTACT-INFO
"Email: trill@ietf.org"
DESCRIPTION
"This MIB module contains the management objects for the
management of TRILL Services Operations, Administration
and Maintenance.
Initial version. Published as RFC 7784.
Copyright (c) 2016 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
-------------------------------------------------------------
Abbreviations Used
Term Definition
CFM Connectivity Fault Management
IEEE Institute of Electrical and Electronics
Engineers
IETF Internet Engineering Task Force
ITU-T International Telecommunication Union -
Telecommunication Standardization Bureau
FCOI The Final, Cross-Connect Error, Out-of-band,
and In-band flags from the TRILL OAM Application
Identifier TLV.
LBM Loopback Message
MA Maintenance Association (equivalent to a MEG)
MAC Media Access Control
MD Maintenance Domain (equivalent to an OAM
Domain in Metro Ethernet Forum (MEF) 17)
MEG Maintenance Entity Group (equivalent to a MA)
MEG Level Maintenance Entity Group Level (equivalent to
MD Level)
MEP Maintenance Association End Point
MIB Management Information Base
MIP Maintenance Domain Intermediate Point
MTVM Multi-destination Tree Verification Message
MTVR Multi-destination Tree Verification Reply
OAM Operations, Administration, and Maintenance
On-Demand OAM actions that are initiated via
manual intervention for a limited time to carry
out diagnostics. On-demand OAM can result in
singular or periodic OAM actions during the
diagnostic time interval.
PTM Path Trace Message
PTR Path Trace Reply
RFC Request for Comments
SNMP Simple Network Management Protocol
TLV Type-Length-Value, a method of encoding Objects
TRILL Transparent Interconnection of Lots of Links
VLAN Virtual LAN"
REVISION "201601141200Z"
DESCRIPTION
"Initial version. Published as RFC 7784."
::= { mib-2 238 }
--
-- *****************************************************************
-- Object Definitions in the TRILL OAM MIB Module
-- *****************************************************************
trillOamNotifications OBJECT IDENTIFIER
::= { trillOamMib 0 }
trillOamMibObjects OBJECT IDENTIFIER
::= { trillOamMib 1 }
trillOamMibConformance OBJECT IDENTIFIER
::= { trillOamMib 2 }
-- *****************************************************************
-- Groups in the TRILL OAM MIB Module
-- *****************************************************************
trillOamMep OBJECT IDENTIFIER
::= { trillOamMibObjects 1 }
-- *****************************************************************
-- TRILL OAM MEP Configuration
-- *****************************************************************
trillOamMepTable OBJECT-TYPE
SYNTAX SEQUENCE OF TrillOamMepEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is an extension of the dot1agCfmMepTable and
rows are automatically added or deleted from this table
based upon row creation and destruction of the
dot1agCfmMepTable.
This table represents the local MEP TRILL OAM
configuration table. The primary purpose of this table
is provide local parameters for the TRILL OAM function
found in RFC 7455 and instantiated at a MEP."
REFERENCE "RFC 7455"
::= { trillOamMep 1 }
trillOamMepEntry OBJECT-TYPE
SYNTAX TrillOamMepEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual row of trillOamMepTable."
AUGMENTS { dot1agCfmMepEntry }
::= { trillOamMepTable 1 }
TrillOamMepEntry ::= SEQUENCE {
trillOamMepRName Unsigned32,
trillOamMepNextPtmTId Counter32,
trillOamMepNextMtvmTId Counter32,
trillOamMepPtrIn Counter32,
trillOamMepPtrInOutofOrder Counter32,
trillOamMepPtrOut Counter32,
trillOamMepMtvrIn Counter32,
trillOamMepMtvrInOutofOrder Counter32,
trillOamMepMtvrOut Counter32,
trillOamMepTxLbmDestRName Unsigned32,
trillOamMepTxLbmHC Unsigned32,
trillOamMepTxLbmReplyModeOob TruthValue,
trillOamMepTransmitLbmReplyIp OCTET STRING,
trillOamMepTxLbmFlowEntropy OCTET STRING,
trillOamMepTxPtmDestRName Unsigned32,
trillOamMepTxPtmHC Unsigned32,
trillOamMepTxPtmReplyModeOob TruthValue,
trillOamMepTransmitPtmReplyIp OCTET STRING,
trillOamMepTxPtmFlowEntropy OCTET STRING,
trillOamMepTxPtmStatus TruthValue,
trillOamMepTxPtmResultOK TruthValue,
trillOamMepTxPtmSeqNumber Unsigned32,
trillOamMepTxPtmMessages Integer32,
trillOamMepTxMtvmTree Unsigned32,
trillOamMepTxMtvmHC Unsigned32,
trillOamMepTxMtvmReplyModeOob TruthValue,
trillOamMepTransmitMtvmReplyIp OCTET STRING,
trillOamMepTxMtvmFlowEntropy OCTET STRING,
trillOamMepTxMtvmStatus TruthValue,
trillOamMepTxMtvmResultOK TruthValue,
trillOamMepTxMtvmMessages Integer32,
trillOamMepTxMtvmSeqNumber Unsigned32,
trillOamMepTxMtvmScopeList OCTET STRING,
trillOamMepDiscontinuityTime TimeStamp
}
trillOamMepRName OBJECT-TYPE
SYNTAX Unsigned32 (0..65471)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the RBridge Nickname field
of the TRILL RBridge as defined in RFC 6325,
Section 3.7."
REFERENCE "RFC 7455 and RFC 6325, Section 3.7"
::= { trillOamMepEntry 1 }
trillOamMepNextPtmTId OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Next Sequence Number / Transaction Identifier to be sent in
a Multi-destination message. This Sequence Number can be
zero because it wraps around. Implementation of this
identifier should be should provide a unique code value in
order to identify the Transaction Identifier for a MEP with
multiple flows."
REFERENCE "RFC 7455, Section 10.1.1"
::= { trillOamMepEntry 2 }
trillOamMepNextMtvmTId OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Next Sequence Number / Transaction Identifier to be sent
in a Multi-destination message. This Sequence Number can
be zero because it wraps around. An implementation should
be unique to identify Transaction Identifier for a MEP with
multiple flows."
REFERENCE "RFC 7455, Section 11.2.1"
::= { trillOamMepEntry 3 }
trillOamMepPtrIn OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, in-order Path Trace Replies
received."
REFERENCE "RFC 7455, Section 10"
::= { trillOamMepEntry 4 }
trillOamMepPtrInOutofOrder OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, out-of-order Path Trace Replies
received."
REFERENCE "RFC 7455, Section 10"
::= { trillOamMepEntry 5 }
trillOamMepPtrOut OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, Path Trace Replies
transmitted."
REFERENCE "RFC 7455, Section 10"
::= { trillOamMepEntry 6 }
trillOamMepMtvrIn OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, in-order Multi-destination
Replies received."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 7 }
trillOamMepMtvrInOutofOrder OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, out-of-order Multi-destination
Replies received."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 8 }
Okay so the MIB table keeps going, and the MTVM and PTM knobs are where the real drama is π β¨. Let's go π¦
Starting with the counter for multi-destination replies πΈ
trillOamMepMtvrOut OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Total number of valid, Multi-destination Replies
transmitted."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 9 }
Next up is the Target Destination RBridge Nickname for loopback messages π It's the same field from RFC 6325 that the LBM uses, so it's giving consistency π«Ά
trillOamMepTxLbmDestRName OBJECT-TYPE
SYNTAX Unsigned32 (0..65471)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Target Destination RBridge Nickname field, as
defined in RFC 6325, Section 3.7, to be transmitted."
REFERENCE "RFC 7455 and RFC 6325, Section 3.7"
::= { trillOamMepEntry 10 }
Now the Hop Count for loopback messages, which runs from 1 to 63 π§
trillOamMepTxLbmHC OBJECT-TYPE
SYNTAX Unsigned32(1..63)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Hop Count field to be transmitted."
REFERENCE "RFC 7455, Sections 3 and 9"
::= { trillOamMepEntry 11 }
Okay the reply mode flag is a total mood π TRUE means the reply goes out of band with the out-of-band IP Address TLV, and FALSE means it comes back in band π
trillOamMepTxLbmReplyModeOob OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"True indicates that the Reply to an LBM is out of
band and the out-of-band IP Address TLV is to be
transmitted. False indicates that in-band reply is
transmitted."
REFERENCE "RFC 7455, Section 9.2.1"
::= { trillOamMepEntry 12 }
This is the IP address that goes into that out-of-band TLV π IPv4 is 4 octets and IPv6 is 16, so the size range is 4 to 16 π
trillOamMepTransmitLbmReplyIp OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP address for an out-of-band IP Address TLV
that is to be transmitted. Maximum length for IPv6
is 16 octets and IPv4 is 4 octets."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepEntry 13 }
Now the flow entropy for loopback messages, which is exactly 96 bytes π¦β¨
trillOamMepTxLbmFlowEntropy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (96))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"96-byte Flow Entropy, as defined in RFC 7455, to
be transmitted."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepEntry 14 }
Path Trace time πΈ Same destination nickname again, this time for PTMs π
trillOamMepTxPtmDestRName OBJECT-TYPE
SYNTAX Unsigned32 (0..65471)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Target Destination RBridge Nickname field,
as defined in RFC 6325, Section 3.7, to be transmitted."
REFERENCE "RFC 7455 and RFC 6325, Section 3.7"
::= { trillOamMepEntry 15 }
The PTM Hop Count is also 1 to 63 π§
trillOamMepTxPtmHC OBJECT-TYPE
SYNTAX Unsigned32 (1..63)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Hop Count field to be transmitted."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepEntry 16 }
The PTM reply mode works like the LBM one π TRUE means out of band, FALSE means in band, and the default is FALSE π
trillOamMepTxPtmReplyModeOob OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"True indicates that a Reply to a PTM will be
out of band and the out-of-band IP Address TLV
is to be transmitted. False indicates that an
in-band reply is transmitted."
REFERENCE "RFC 7455, Section 10"
DEFVAL { false }
::= { trillOamMepEntry 17 }
The PTM reply IP is the out-of-band address, and it's 4 to 16 octets again π
trillOamMepTransmitPtmReplyIp OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP address for an out-of-band IP Address TLV
to be transmitted. The maximum length for an
IPv6 address is 16 octets. The maximum length
for an IPv4 address is 4 octets."
REFERENCE "RFC 7455, Sections 3 and 10"
::= { trillOamMepEntry 18 }
PTM flow entropy is 96 bytes too, same as before π¦
trillOamMepTxPtmFlowEntropy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (96))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"96-byte Flow Entropy, as defined in RFC 7455, to be
transmitted."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepEntry 19 }
Okay the PTM Status is the main character of this whole section π It's a flag that gets set to TRUE by the MEP Path Trace Initiator State Machine or a MIB manager when another PTM is being sent. The initiator resets it to FALSE once the last PTM goes out. The PTM works just like the loopback message, except the first one goes out with a Hop Count of 1, and then the Hop Count keeps going up until a response comes back from the destination RBridge or it hits the configured max ππ₯
trillOamMepTxPtmStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A Boolean flag set to TRUE by the MEP Path Trace Initiator
State Machine or a MIB manager to indicate that another PTM
is being transmitted. This is reset to FALSE by the MEP
Initiator State Machine. The PTM managed objects in the MEP
table are used in a manner similar to that described for LBM
transmission in the dot1agCfmMepTable. As per RFC 7455,
Section 10, operation of the Path Trace Message is identical
to the Loopback message except that it is first transmitted
with a TRILL Header Hop Count field value of 1 and then
retransmitted with an incrementing Hop Count until a
response is received from the destination RBridge, or the
Hop Count reaches a configured maximum value. The
trillOamMepTxPtmStatus status is reset to FALSE by
the initiator when the last PTM is transmitted."
REFERENCE "RFC 7455, Section 10"
DEFVAL { false }
::= { trillOamMepEntry 20 }
PTM result OK tells you whether the Path Trace Messages will be sent, or already were πΈ TRUE means yes, FALSE means no, and the default is TRUE β¨
trillOamMepTxPtmResultOK OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the following results of the operation:
- true indicates the Path Trace Message(s) will be
(or has been) sent.
- false indicates the Path Trace Message(s) will not
be sent."
REFERENCE "RFC 7455, Section 10"
DEFVAL { true }
::= { trillOamMepEntry 21 }
The PTM sequence number is the Path Trace Transaction Identifier for the first PTM that gets sent π§ If the result OK flag is FALSE, the value is undefined, so don't rely on it π
trillOamMepTxPtmSeqNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Path Trace Transaction Identifier of the first
PTM (to be) sent. The value returned is
undefined if trillOamMepTxPtmResultOK is false."
REFERENCE "RFC 7455, Section 10"
::= { trillOamMepEntry 22 }
PTM messages is how many Path Trace messages get transmitted, from 1 to 1024 π The RFC says the first one goes out with a Hop Count of 1 and can keep being retransmitted at periodic intervals with a growing Hop Count. That stops when a response comes back or the max is reached, and each of those events counts as one increment of this object π
trillOamMepTxPtmMessages OBJECT-TYPE
SYNTAX Integer32 (1..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of Path Trace messages to be transmitted.
As per RFC 7455, Section 10, the first Path Trace
Message is transmitted with a Hop Count of 1; an
RBridge may continue to retransmit the request at
periodic intervals with an incrementing Hop Count
until a response is received from the destination
RBridge or the Hop Count reaches a configured
maximum value. The event of the Destination
response being received or the Hop Count reaching
its maximum is treated as a single Counter
increment of this object."
REFERENCE "RFC 7455, Section 10"
::= { trillOamMepEntry 23 }
Now we're in multi-destination (MTVM) land π¦ The tree identifier is the Multi-destination Tree ID from RFC 6325 that the MTVM uses π
trillOamMepTxMtvmTree OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Multi-destination Tree identifier, as
defined in RFC 6325, for an MTVM."
::= { trillOamMepEntry 24 }
The MTVM Hop Count is 1 to 63 again π§
trillOamMepTxMtvmHC OBJECT-TYPE
SYNTAX Unsigned32(1..63)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Hop Count field to be transmitted.
"
REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3"
::= { trillOamMepEntry 25 }
The MTVM reply mode follows the same pattern π TRUE means the reply to an MTVM goes out of band, using this out-of-band IP Address TLV as the place to send it. FALSE means it's in band π
trillOamMepTxMtvmReplyModeOob OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"True indicates that the reply to an MTVM is out of
band and this out-of-band IP Address TLV is where the
reply is to be transmitted.
False indicates that an in-band reply is transmitted."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 26 }
And here's the MTVM reply IP for that out-of-band TLV, 4 to 16 octets π
trillOamMepTransmitMtvmReplyIp OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (4..16))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"IP address for an out-of-band IP Address TLV that is
to be transmitted. The maximum length for IPv6 is 16
octets and IPv4 is 4 octets."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 27 }
MTVM flow entropy is 96 bytes π¦
trillOamMepTxMtvmFlowEntropy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (96))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"96-byte Flow Entropy, as defined in RFC 7455, to be
transmitted."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepEntry 28 }
The MTVM Status flag is basically the PTM status, but for multi-destination messages π A MEP Multi-destination Initiator State Machine or a MIB manager sets it to TRUE when another MTVM is being sent, and the initiator resets it to FALSE after the last one goes out. The MTVM works like the loopback message, except the first one goes out with a Hop Count of 1, and then the Hop Count keeps going up until a response comes back or it hits the configured max π
trillOamMepTxMtvmStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A Boolean flag set to TRUE by the MEP Multi-destination
Initiator State Machine or a MIB manager to indicate
that another MTVM is being transmitted.
Reset to FALSE by the MEP Initiator State Machine.
The MTVM-managed objects in the MEP table are used
in a manner similar to that described for LBM
transmission in the dot1agCfmMepTable. As per RFC 7455,
Section 11, operation of the MTVM is
identical to the Loopback message except that it is
first transmitted with a TRILL Header Hop Count
field value of 1 and it is retransmitted incrementing
the Hop Count until a response is received from the
destination RBridge or the Hop Count reaches a
configured maximum value. The trillOamMepTxMtvmStatus
Status is reset to FALSE by the initiator when the last
MTVM is transmitted."
REFERENCE "RFC 7455, Section 11"
DEFVAL { false }
::= { trillOamMepEntry 29 }
MTVM result OK tells you whether the Multi-destination messages will be sent, or already were πΈ TRUE means yes, FALSE means no, and the default is TRUE β¨
trillOamMepTxMtvmResultOK OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Indicates the result of the operation in
the following way:
- true indicates the Multi-destination Message(s) will be
(or has been) sent.
- false indicates the Multi-destination Message(s) will not
be sent."
REFERENCE "RFC 7455, Section 11"
DEFVAL { true }
::= { trillOamMepEntry 30 }
MTVM messages is how many Multi-destination messages get transmitted, from 1 to 1024 π The RBridge sends them at periodic intervals and bumps the session Identification Number each time, until the count runs out π
trillOamMepTxMtvmMessages OBJECT-TYPE
SYNTAX Integer32 (1..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of Multi-destination messages to be transmitted.
The RBridge transmit the Multi-destination message
incrementing the session Identification Number at periodic
interval until this count expires."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 31 }
And last but not least in this part, the MTVM sequence number π It's the Multi-destination Transaction Identifier for the first MTVM that gets sent. If the result OK flag is FALSE, the value is undefined π«Ά
trillOamMepTxMtvmSeqNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Multi-destination Transaction Identifier of the
first MTVM (to be)
sent. The value returned is undefined if
trillOamMepTxMtvmResultOK is false."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 32 }
okay so we're still in the MEP table, and the next objects are the scope list and the discontinuity timestamp π
trillOamMepTxMtvmScopeList OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Multi-destination RBridge Scope list, which
requires 2 octets per RBridge."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMepEntry 33 }
trillOamMepDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Snapshot of the value of the sysUpTime object at the
beginning of the latest period of continuity of the
statistical counters associated with this MEP."
::= { trillOamMepEntry 34 }
-- *****************************************************************
-- TRILL OAM Tx Measurement Configuration Table
-- *****************************************************************
trillOamMepFlowCfgTable OBJECT-TYPE
SYNTAX SEQUENCE OF TrillOamMepFlowCfgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table includes configuration objects and operations
for the TRILL OAM facilities in RFC 7455.
Each row in the table represents a Flow Configuration
Entry for the defined MEP. This table uses four indices.
The first three indices are the indices of the Maintenance
Domain, MANET, and MEP tables. The fourth index is the
specific Flow Configuration Entry on the selected MEP.
Some writable objects in this table are only applicable in
certain cases (as described under each object), and
attempts to write values for them in other cases
will be ignored."
REFERENCE "RFC 7455"
::= { trillOamMep 2 }
trillOamMepFlowCfgEntry OBJECT-TYPE
SYNTAX TrillOamMepFlowCfgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual row of trillOamMepFlowCfgTable."
INDEX {
dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepIdentifier,
trillOamMepFlowCfgIndex
}
::= { trillOamMepFlowCfgTable 1 }
TrillOamMepFlowCfgEntry ::= SEQUENCE {
trillOamMepFlowCfgIndex Unsigned32,
trillOamMepFlowCfgFlowEntropy OCTET STRING,
trillOamMepFlowCfgDestRName Unsigned32,
trillOamMepFlowCfgFlowHC Unsigned32,
trillOamMepFlowCfgRowStatus RowStatus
}
trillOamMepFlowCfgIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index to the TRILL OAM MEP Flow Configuration table,
which indicates the specific flow for the MEP.
The index is never reused for other flow sessions on the
same MEP while this session is active. The index value
keeps increasing until it wraps to 0. This value can also be
used in the flow-identifier TLV RFC 7455."
REFERENCE "RFC 7455"
::= { trillOamMepFlowCfgEntry 1 }
trillOamMepFlowCfgFlowEntropy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (96))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This is 96 bytes of Flow Entropy as described in
TRILL OAM, RFC 7455."
REFERENCE "RFC 7455, Section 3"
::= { trillOamMepFlowCfgEntry 2 }
trillOamMepFlowCfgDestRName OBJECT-TYPE
SYNTAX Unsigned32 (0..65471)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Target Destination RBridge Nickname field, as
defined in RFC 6325, Section 3.7, to be transmitted."
REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3.7"
::= { trillOamMepFlowCfgEntry 3 }
trillOamMepFlowCfgFlowHC OBJECT-TYPE
SYNTAX Unsigned32 (1..63)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Hop Count field to be transmitted."
REFERENCE "RFC 7455, Section 3, and RFC 6325, Section 3.6"
::= { trillOamMepFlowCfgEntry 4 }
trillOamMepFlowCfgRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of the row.
The writable columns in a row cannot be changed if the row
is active. All columns MUST have a valid value before a row
can be activated."
::= { trillOamMepFlowCfgEntry 5 }
-- ******************************************************************
-- TRILL OAM Path Trace Reply Table
-- ******************************************************************
trillOamPtrTable OBJECT-TYPE
SYNTAX SEQUENCE OF TrillOamPtrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table includes Path Trace Reply objects and
operations for the TRILL OAM facilities as described
in RFC 7455.
Each row in the table represents a Path Trace Reply Entry for
the defined MEP and Transaction. This table uses four
indices. The first three indices are the indices of the
Maintenance Domain,
MANET, and MEP tables. The fourth index is the specific
Transaction Identifier on the selected MEP.
Some writable objects in this table are only applicable in
certain cases (as described under each object),
and attempts to
write values for them in other cases will be ignored."
REFERENCE "RFC 7455"
::= { trillOamMep 3 }
trillOamPtrEntry OBJECT-TYPE
SYNTAX TrillOamPtrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual row of trillOamPtrTable."
INDEX {
dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepIdentifier,
trillOamMepPtrTransactionId
}
::= { trillOamPtrTable 1 }
TrillOamPtrEntry ::= SEQUENCE {
trillOamMepPtrTransactionId Unsigned32,
trillOamMepPtrHC Unsigned32,
trillOamMepPtrFlag Unsigned32,
trillOamMepPtrErrorCode Unsigned32,
trillOamMepPtrTerminalMep TruthValue,
trillOamMepPtrLastEgressId Unsigned32,
trillOamMepPtrIngress Dot1agCfmIngressActionFieldValue,
trillOamMepPtrIngressMac MacAddress,
trillOamMepPtrIngressPortIdSubtype LldpPortIdSubtype,
trillOamMepPtrIngressPortId LldpPortId,
trillOamMepPtrEgress Dot1agCfmEgressActionFieldValue,
trillOamMepPtrEgressMac MacAddress,
trillOamMepPtrEgressPortIdSubtype LldpPortIdSubtype,
trillOamMepPtrEgressPortId LldpPortId,
trillOamMepPtrChassisIdSubtype LldpChassisIdSubtype,
trillOamMepPtrChassisId LldpChassisId,
trillOamMepPtrOrganizationSpecificTlv OCTET STRING,
trillOamMepPtrNextHopNicknames OCTET STRING
}
trillOamMepPtrTransactionId OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Sequence Number / Transaction Identifier returned by a
previous transmit path trace message command,
indicating which PTM's response is going to be returned."
REFERENCE "RFC 7455, Section 10"
::= { trillOamPtrEntry 1 }
trillOamMepPtrHC OBJECT-TYPE
SYNTAX Unsigned32 (1..63)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Hop Count field value for a returned PTR."
REFERENCE "RFC 7455"
::= { trillOamPtrEntry 2 }
trillOamMepPtrFlag OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"FCOI (TRILL OAM Message TLV) field value for a
returned PTR."
REFERENCE "RFC 7455, Section 8.4.3"
::= { trillOamPtrEntry 3 }
trillOamMepPtrErrorCode OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Return Code and Return Sub-code value for a returned PTR."
REFERENCE "RFC 7455, Section 8.4.3"
::= { trillOamPtrEntry 4 }
trillOamMepPtrTerminalMep OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A boolean value stating whether the forwarded PTM reached a
MEP enclosing its MA, as returned in the Terminal MEP flag of
the Flags field."
REFERENCE "RFC 7455"
::= { trillOamPtrEntry 5 }
trillOamMepPtrLastEgressId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An Integer field holding the Last Egress Identifier returned
in the PTR Upstream RBridge Nickname TLV of the PTR.
The Last Egress Identifier identifies the Upstream Nickname."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 6 }
trillOamMepPtrIngress OBJECT-TYPE
SYNTAX Dot1agCfmIngressActionFieldValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value returned in the Ingress Action field of the PTR.
The value ingNoTlv(0) indicates that no Reply Ingress TLV was
returned in the PTM."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 7 }
trillOamMepPtrIngressMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"MAC address returned in the ingress MAC address field."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 8 }
trillOamMepPtrIngressPortIdSubtype OBJECT-TYPE
SYNTAX LldpPortIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Ingress Port ID. The format of this object is determined by
the value of the trillOamMepPtrIngressPortIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 9 }
trillOamMepPtrIngressPortId OBJECT-TYPE
SYNTAX LldpPortId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Ingress Port ID. The format of this object is determined by
the value of the trillOamMepPtrIngressPortId object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 10 }
trillOamMepPtrEgress OBJECT-TYPE
SYNTAX Dot1agCfmEgressActionFieldValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value returned in the Egress Action field of the PTR.
The value ingNoTlv(0) indicates that no Reply Egress TLV was
returned in the PTM."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 11 }
okay so the MTVR table is where the multi-destination replies live π¦ each row is one reply, and the five indices keep every reply sorted out so nothing gets mixed up π β¨
trillOamMepPtrEgressMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"MAC address returned in the egress MAC address field."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 12 }
trillOamMepPtrEgressPortIdSubtype OBJECT-TYPE
SYNTAX LldpPortIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Egress Port ID. The format of this object is determined by
the value of the trillOamMepPtrEgressPortIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 13 }
trillOamMepPtrEgressPortId OBJECT-TYPE
SYNTAX LldpPortId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Egress Port ID. The format of this object is determined by
the value of the trillOamMepPtrEgressPortId object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 14 }
trillOamMepPtrChassisIdSubtype OBJECT-TYPE
SYNTAX LldpChassisIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the format of the Chassis ID returned
in the Sender ID TLV of the PTR, if any. This value is
meaningless if the trillOamMepPtrChassisId
has a length of 0."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 15 }
trillOamMepPtrChassisId OBJECT-TYPE
SYNTAX LldpChassisId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Chassis ID returned in the Sender ID TLV of the PTR, if
any. The format of this object is determined by the
value of the trillOamMepPtrChassisIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 16 }
trillOamMepPtrOrganizationSpecificTlv OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0 | 4..1500))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"All organization-specific TLVs returned in the PTR, if
any. Includes all octets including and following the TLV
Length field of each TLV, concatenated together."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 17 }
trillOamMepPtrNextHopNicknames OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0 | 4..1500))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Next hop RBridge List TLV returned in the PTR, if
any. Includes all octets including and following the TLV
Length field of each TLV, concatenated together."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamPtrEntry 18 }
-- ******************************************************************
-- TRILL OAM Multi-destination Reply Table
-- ******************************************************************
trillOamMtvrTable OBJECT-TYPE
SYNTAX SEQUENCE OF TrillOamMtvrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table includes Multi-destination Reply objects and
operations for the TRILL OAM facilities described in
RFC 7455.
Each row in the table represents a Multi-destination Reply
Entry for the defined MEP and Transaction. This table uses
five indices. The first three indices are the indices of the
Maintenance Domain, MANET, and MEP tables. The fourth index
is the specific Transaction Identifier on the selected MEP.
The fifth index is the receive order of Multi-destination
replies.
Some writable objects in this table are only applicable in
certain cases (as described under each object), and attempts
to write values for them in other cases will be ignored."
REFERENCE "RFC 7455"
::= { trillOamMep 4 }
trillOamMtvrEntry OBJECT-TYPE
SYNTAX TrillOamMtvrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual row of trillOamMtvrTable."
INDEX {
dot1agCfmMdIndex,
dot1agCfmMaIndex,
dot1agCfmMepIdentifier,
trillOamMepPtrTransactionId,
trillOamMepMtvrReceiveOrder
}
::= { trillOamMtvrTable 1 }
TrillOamMtvrEntry ::= SEQUENCE {
trillOamMepMtvrTransactionId Unsigned32,
trillOamMepMtvrReceiveOrder Unsigned32,
trillOamMepMtvrFlag Unsigned32,
trillOamMepMtvrErrorCode Unsigned32,
trillOamMepMtvrLastEgressId Unsigned32,
trillOamMepMtvrIngress Dot1agCfmIngressActionFieldValue,
trillOamMepMtvrIngressMac MacAddress,
trillOamMepMtvrIngressPortIdSubtype LldpPortIdSubtype,
trillOamMepMtvrIngressPortId LldpPortId,
trillOamMepMtvrEgress Dot1agCfmEgressActionFieldValue,
trillOamMepMtvrEgressMac MacAddress,
trillOamMepMtvrEgressPortIdSubtype LldpPortIdSubtype,
trillOamMepMtvrEgressPortId LldpPortId,
trillOamMepMtvrChassisIdSubtype LldpChassisIdSubtype,
trillOamMepMtvrChassisId LldpChassisId,
trillOamMepMtvrOrganizationSpecificTlv OCTET STRING,
trillOamMepMtvrNextHopNicknames OCTET STRING,
trillOamMepMtvrReceiverAvailability TruthValue,
trillOamMepMtvrReceiverCount TruthValue
}
trillOamMepMtvrTransactionId OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Sequence Number / Transaction Identifier returned by a
previously transmitted Multi-destination message command
indicating which MTVM's response is going to be returned."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMtvrEntry 1 }
trillOamMepMtvrReceiveOrder OBJECT-TYPE
SYNTAX Unsigned32 (1..4294967295)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index to distinguish among multiple MTVRs with same MTVR
Transaction Identifier field value.
trillOamMepMtvrReceiveOrder is assigned sequentially from 1,
in the order that the Multi-destination Tree Initiator
received the MTVRs."
REFERENCE "RFC 7455, Section 11"
::= { trillOamMtvrEntry 2 }
trillOamMepMtvrFlag OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"FCOI (TRILL OAM Message TLV) field value for a
returned MTVR."
REFERENCE "RFC 7455, Section 8.4.2"
::= { trillOamMtvrEntry 3 }
trillOamMepMtvrErrorCode OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Return Code and Return Sub-code value for a returned MTVR."
REFERENCE "RFC 7455, Section 8.4.2"
::= { trillOamMtvrEntry 4 }
trillOamMepMtvrLastEgressId OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An Integer field holding the Last Egress Identifier returned
in the MTVR Upstream RBridge Nickname TLV of the MTVR. The
Last Egress Identifier identifies the Upstream Nickname."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 5 }
trillOamMepMtvrIngress OBJECT-TYPE
SYNTAX Dot1agCfmIngressActionFieldValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value returned in the Ingress Action field of
the MTVR. The value ingNoTlv(0) indicates that no
Reply Ingress TLV was returned in the MTVM."
REFERENCE "RFC 7455, Section 11.2.3"
::= { trillOamMtvrEntry 6 }
trillOamMepMtvrIngressMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"MAC address returned in the ingress MAC address field."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 7 }
trillOamMepMtvrIngressPortIdSubtype OBJECT-TYPE
SYNTAX LldpPortIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Ingress Port ID. The format of this object is
determined by the value of the
trillOamMepMtvrIngressPortIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 8 }
trillOamMepMtvrIngressPortId OBJECT-TYPE
SYNTAX LldpPortId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Ingress Port ID. The format of this object is determined by
the value of the trillOamMepMtvrIngressPortId object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 9 }
trillOamMepMtvrEgress OBJECT-TYPE
SYNTAX Dot1agCfmEgressActionFieldValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value returned in the Egress Action field of the MTVR.
The value ingNoTlv(0) indicates that no Reply Egress TLV was
returned in the MTVR."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 10 }
trillOamMepMtvrEgressMac OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"MAC address returned in the egress MAC address field."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 11 }
trillOamMepMtvrEgressPortIdSubtype OBJECT-TYPE
SYNTAX LldpPortIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Egress Port ID. The format of this object is determined by
the value of the trillOamMepMtvrEgressPortIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 12 }
trillOamMepMtvrEgressPortId OBJECT-TYPE
SYNTAX LldpPortId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Egress Port ID. The format of this object is determined by
the value of the trillOamMepMtvrEgressPortId object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 13 }
trillOamMepMtvrChassisIdSubtype OBJECT-TYPE
SYNTAX LldpChassisIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object specifies the format of the Chassis ID returned
in the Sender ID TLV of the MTVR, if any. This value is
meaningless if the trillOamMepMtvrChassisId has a
length of 0."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 14 }
Okay bestie, we're still deep in the MIB definitions π§ here's the next chunk, starting with the rest of the MTVR columns β¨
trillOamMepMtvrChassisId OBJECT-TYPE
SYNTAX LldpChassisId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Chassis ID returned in the Sender ID TLV of the MTVR, if
any. The format of this object is determined by the
value of the trillOamMepMtvrChassisIdSubtype object."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 15 }
trillOamMepMtvrOrganizationSpecificTlv OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0 | 4..1500))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"All organization-specific TLVs returned in the MTVR, if
any. Includes all octets including and following the TLV
Length field of each TLV, concatenated together."
REFERENCE "RFC 7455, Section 8.4.1"
::= { trillOamMtvrEntry 16 }
trillOamMepMtvrNextHopNicknames OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0 | 4..1500))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Next hop RBridge List TLV returned in the PTR, if
any. Includes all octets including and following the TLV
Length field of each TLV, concatenated together."
REFERENCE "RFC 7455, Section 8.4.3"
::= { trillOamMtvrEntry 17 }
trillOamMepMtvrReceiverAvailability OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A value of true indicates that the MTVR response contained
Multicast receiver availability TLV."
REFERENCE "RFC 7455, Section 8.4.10"
::= { trillOamMtvrEntry 18 }
trillOamMepMtvrReceiverCount OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the number of multicast receivers available on
the responding RBridge on the VLAN specified by the
diagnostic VLAN."
REFERENCE "RFC 7455, Section 8.4.10"
::= { trillOamMtvrEntry 19 }
-- *****************************************************************
-- TRILL OAM MEP Database Table
-- *****************************************************************
trillOamMepDbTable OBJECT-TYPE
SYNTAX SEQUENCE OF TrillOamMepDbEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table is an extension of the dot1agCfmMepDbTable
and rows are automatically added to or deleted from
this table based upon row creation and destruction of the
dot1agCfmMepDbTable."
REFERENCE
"RFC 7455"
::= { trillOamMep 5 }
trillOamMepDbEntry OBJECT-TYPE
SYNTAX TrillOamMepDbEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The conceptual row of trillOamMepDbTable."
AUGMENTS {
dot1agCfmMepDbEntry
}
::= { trillOamMepDbTable 1 }
TrillOamMepDbEntry ::= SEQUENCE {
trillOamMepDbFlowIndex Unsigned32,
trillOamMepDbFlowEntropy OCTET STRING,
trillOamMepDbFlowState Dot1agCfmRemoteMepState,
trillOamMepDbFlowFailedOkTime TimeStamp,
trillOamMepDbRBridgeName Unsigned32,
trillOamMepDbLastGoodSeqNum Counter32
}
trillOamMepDbFlowIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the flow. If the Flow Identifier TLV
is received, then the index received can also be used."
REFERENCE "RFC 7455"
::= {trillOamMepDbEntry 1 }
trillOamMepDbFlowEntropy OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (96))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"96 byte Flow Entropy."
REFERENCE "RFC 7455, Section 3"
::= {trillOamMepDbEntry 2 }
trillOamMepDbFlowState OBJECT-TYPE
SYNTAX Dot1agCfmRemoteMepState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The operational state of the remote MEP (flow-based)
IFF State machines. State Machine is running now per
flow."
REFERENCE "RFC 7455"
::= {trillOamMepDbEntry 3 }
trillOamMepDbFlowFailedOkTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Time (sysUpTime) at which the Remote MEP flow state
machine last entered either the RMEP_FAILED or RMEP_OK
state."
REFERENCE "RFC 7455"
::= {trillOamMepDbEntry 4 }
trillOamMepDbRBridgeName OBJECT-TYPE
SYNTAX Unsigned32(0..65471)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Remote MEP RBridge Nickname."
REFERENCE "RFC 7455 and RFC 6325, Section 3"
::= {trillOamMepDbEntry 5 }
trillOamMepDbLastGoodSeqNum OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Last Sequence Number received."
REFERENCE "RFC 7455, Section 13.1"
::= {trillOamMepDbEntry 6}
Next up are the notifications, the traps that fire when a MEP loses or restores contact with its peer flow MEPs π¦ this is where the fault alarm lives, so pay attention π
-- ******************************************************************
-- TRILL OAM MIB NOTIFICATIONS (TRAPS)
-- This notification is sent to management entity whenever a
-- MEP loses/restores
-- contact with its peer flow MEPs
-- ******************************************************************
trillOamFaultAlarm NOTIFICATION-TYPE
OBJECTS { trillOamMepDbFlowState }
STATUS current
DESCRIPTION
"A MEP flow has a persistent defect condition.
A notification (fault alarm) is sent to the management
entity with the OID of the flow that has detected the fault.
The management entity receiving the notification can identify
the system from the network source address of the
notification and can identify the flow reporting the defect
by the indices in the OID of the trillOamMepFlowIndex and
trillOamFlowDefect variable in the notification:
dot1agCfmMdIndex - Also the index of the MEP's
Maintenance Domain table entry
(dot1agCfmMdTable).
dot1agCfmMaIndex - Also an index (with the MD table index)
of the MEP's Maintenance Association
network table entry
(dot1agCfmMaNetTable) and (with the MD
table index and component ID) of the
MEP's MA component table entry
(dot1agCfmMaCompTable).
dot1agCfmMepIdentifier - MEP Identifier and final index
into the MEP table (dot1agCfmMepTable).
trillOamMepFlowCfgIndex - Index identifies
indicates the specific flow for
the MEP"
REFERENCE "RFC 7455"
::= { trillOamNotifications 1 }
Last bit of this chunk is the conformance info, the mandatory groups and the flow config and PTR table groups π
-- ******************************************************************
-- TRILL OAM MIB Module - Conformance Information
-- ******************************************************************
trillOamMibCompliances OBJECT IDENTIFIER
::= { trillOamMibConformance 1 }
trillOamMibGroups OBJECT IDENTIFIER
::= { trillOamMibConformance 2 }
-- ******************************************************************
-- TRILL OAM MIB Units of Conformance
-- ******************************************************************
trillOamMepMandatoryGroup OBJECT-GROUP
OBJECTS {
trillOamMepRName,
trillOamMepNextPtmTId,
trillOamMepNextMtvmTId,
trillOamMepPtrIn,
trillOamMepPtrInOutofOrder,
trillOamMepPtrOut,
trillOamMepMtvrIn,
trillOamMepMtvrInOutofOrder,
trillOamMepMtvrOut,
trillOamMepTxLbmDestRName,
trillOamMepTxLbmHC,
trillOamMepTxLbmReplyModeOob,
trillOamMepTransmitLbmReplyIp,
trillOamMepTxLbmFlowEntropy,
trillOamMepTxPtmDestRName,
trillOamMepTxPtmHC,
trillOamMepTxPtmReplyModeOob,
trillOamMepTransmitPtmReplyIp,
trillOamMepTxPtmFlowEntropy,
trillOamMepTxPtmStatus,
trillOamMepTxPtmResultOK,
trillOamMepTxPtmMessages,
trillOamMepTxPtmSeqNumber,
trillOamMepTxMtvmTree,
trillOamMepTxMtvmHC,
trillOamMepTxMtvmReplyModeOob,
trillOamMepTransmitMtvmReplyIp,
trillOamMepTxMtvmFlowEntropy,
trillOamMepTxMtvmStatus,
trillOamMepTxMtvmResultOK,
trillOamMepTxMtvmMessages,
trillOamMepTxMtvmSeqNumber,
trillOamMepTxMtvmScopeList,
trillOamMepDiscontinuityTime
}
STATUS current
DESCRIPTION
"Mandatory objects for the TRILL OAM MEP group."
::= { trillOamMibGroups 1 }
trillOamMepFlowCfgTableGroup OBJECT-GROUP
OBJECTS {
trillOamMepFlowCfgFlowEntropy,
trillOamMepFlowCfgDestRName,
trillOamMepFlowCfgFlowHC,
trillOamMepFlowCfgRowStatus
}
STATUS current
DESCRIPTION
"TRILL OAM MEP Flow Configuration objects group."
::= { trillOamMibGroups 2 }
trillOamPtrTableGroup OBJECT-GROUP
OBJECTS {
trillOamMepPtrHC,
trillOamMepPtrFlag,
trillOamMepPtrErrorCode,
trillOamMepPtrTerminalMep,
trillOamMepPtrLastEgressId,
trillOamMepPtrIngress,
trillOamMepPtrIngressMac,
trillOamMepPtrIngressPortIdSubtype,
trillOamMepPtrIngressPortId,
trillOamMepPtrEgress,
trillOamMepPtrEgressMac,
trillOamMepPtrEgressPortIdSubtype,
trillOamMepPtrEgressPortId,
trillOamMepPtrChassisIdSubtype,
trillOamMepPtrChassisId,
trillOamMepPtrOrganizationSpecificTlv,
trillOamMepPtrNextHopNicknames
}
STATUS current
DESCRIPTION
"TRILL OAM MEP PTR objects group."
::= { trillOamMibGroups 3 }
okay so the MTVR group bundles up every MTVR object, and yes it's giving organized π
trillOamMtvrTableGroup OBJECT-GROUP
OBJECTS {
trillOamMepMtvrFlag,
trillOamMepMtvrErrorCode,
trillOamMepMtvrLastEgressId,
trillOamMepMtvrIngress,
trillOamMepMtvrIngressMac,
trillOamMepMtvrIngressPortIdSubtype,
trillOamMepMtvrIngressPortId,
trillOamMepMtvrEgress,
trillOamMepMtvrEgressMac,
trillOamMepMtvrEgressPortIdSubtype,
trillOamMepMtvrEgressPortId,
trillOamMepMtvrChassisIdSubtype,
trillOamMepMtvrChassisId,
trillOamMepMtvrOrganizationSpecificTlv,
trillOamMepMtvrNextHopNicknames,
trillOamMepMtvrReceiverAvailability,
trillOamMepMtvrReceiverCount
}
STATUS current
DESCRIPTION
"TRILL OAM MEP MTVR objects group."
::= { trillOamMibGroups 4 }
trillOamMepDbGroup OBJECT-GROUP
OBJECTS {
trillOamMepDbFlowIndex,
trillOamMepDbFlowEntropy,
trillOamMepDbFlowState,
trillOamMepDbFlowFailedOkTime,
trillOamMepDbRBridgeName,
trillOamMepDbLastGoodSeqNum
}
STATUS current
DESCRIPTION
"TRILL OAM MEP DB objects group."
::= { trillOamMibGroups 5 }
trillOamNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { trillOamFaultAlarm }
STATUS current
DESCRIPTION
"A collection of objects describing notifications(traps)."
::= { trillOamMibGroups 6 }
Now the compliance bit, where we say which groups an implementation has to have, plus the read-only version for devices you can watch but not touch πβ¨
-- ******************************************************************
-- TRILL OAM MIB Module Compliance Statements
-- ******************************************************************
trillOamMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for the TRILL OAM MIB."
MODULE -- this module
MANDATORY-GROUPS {
trillOamMepMandatoryGroup,
trillOamMepFlowCfgTableGroup,
trillOamPtrTableGroup,
trillOamMtvrTableGroup,
trillOamMepDbGroup,
trillOamNotificationGroup
}
::= { trillOamMibCompliances 1 }
-- Compliance requirement for read-only implementation.
trillOamMibReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Compliance requirement for implementations that only
provide read-only support for TRILL-OAM-MIB.
Such devices can be monitored but cannot be configured
using this MIB module."
MODULE -- this module
MANDATORY-GROUPS {
trillOamMepMandatoryGroup,
trillOamMepFlowCfgTableGroup,
trillOamPtrTableGroup,
trillOamMtvrTableGroup,
trillOamMepDbGroup,
trillOamNotificationGroup
}
-- trillOamMepTable
OBJECT trillOamMepTxLbmDestRName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxLbmHC
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxLbmReplyModeOob
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTransmitLbmReplyIp
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxLbmFlowEntropy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmDestRName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmHC
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmReplyModeOob
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTransmitPtmReplyIp
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmFlowEntropy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmResultOK
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmMessages
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxPtmSeqNumber
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmTree
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmHC
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmReplyModeOob
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTransmitMtvmReplyIp
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmFlowEntropy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmResultOK
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmMessages
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmSeqNumber
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepTxMtvmScopeList
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- trillOamMepFlowCfgTable
OBJECT trillOamMepFlowCfgFlowEntropy
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepFlowCfgDestRName
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepFlowCfgFlowHC
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT trillOamMepFlowCfgRowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { trillOamMibCompliances 2 }
END
8. Security Considerations π
okay bestie, this MIB runs the stuff that actually moves packets around the network π so if somebody messes with it, a ton of end users can lose connectivity. not it π let's go through the risky bits together π
There are a bunch of management objects in this MIB with a MAX-ACCESS clause of read-create π. In some network environments those can be sensitive or vulnerable. Turning on SET operations in a non-secure environment without proper protection basically opens the door for attackers πͺ Here's the breakdown of which tables and objects are sensitive or vulnerable and why:
The following table and objects in the TRILL OAM MIB can be manipulated to interfere with the operation of RBridges by causing CPU use spikes:
trillOamMepTransmitLbmReplyIplets the reply from a Loopback message get sent to an IP address in the TLV. So replies can be aimed at any system to cause denial of service π₯trillOamMepTransmitPtmReplyIplets the reply from a Path Trace message get sent to an IP address in the TLV. Same deal, replies can be aimed at any system to cause denial of service π₯trillOamMepTxPtmMessagesallows the generation of PTMs, and it can be used to make tons of CPU-driven traffic π₯trillOamMepTransmitMtvmReplyIplets a reply from an MTVM get sent to an IP address in the TLV. Replies can be aimed at any system to cause denial of service π₯trillOamMepTxMtvmMessagesallows the generation of MTVMs, and it can be used to make tons of CPU-driven traffic π₯
The following objects in the TRILL OAM MIB are read-create and can be manipulated to interfere with the OAM operations of RBridges. If the number of OAM frames generated in the network is high, this can cause a CPU spike on destination RBridges if control-plane policing is not properly implemented or configured on destination RBridges.
trillOamMepTxLbmHCis used to set the Maximum Hop Count for the LBM. OAM frames don't leak out of the TRILL network, so it has no side effects π§trillOamMepTxLbmReplyModeOobis used to indicate whether the reply is in band or out of band. Its vulnerability is covered undertrillOamMepTransmitLbmReplyIpπ«ΆtrillOamMepTxLbmFlowEntropyis used to indicate the customer flow and find the exact path through the network. Creating valid flows is its whole purpose β¨ If invalid flows get created on a vulnerable system, they'll be dropped in forwarding ποΈtrillOamMepTxLbmDestRNameis read-create, but it's not vulnerable. Invalid-name routes won't be present, and the OAM application rejects them as part of normal processing πtrillOamMepTxPtmHCis used to set the Maximum Hop Count for the PTM. OAM frames don't leak out of the TRILL network, so it has no side effects π§trillOamMepTxPtmReplyModeOobis used to indicate whether the reply is in band or out of band. Its vulnerability is covered undertrillOamMepTransmitPtmReplyIpπ«ΆtrillOamMepTxPtmFlowEntropyis used to indicate the customer flow and find the exact path through the network. Creating valid flows is its intended purpose β¨ If invalid flows get created on vulnerable systems, they'll be dropped in forwarding ποΈtrillOamMepTxPtmDestRNameis read-create, but it's not vulnerable. Invalid-name routes won't be present, and the OAM application rejects them as part of normal processing πtrillOamMepTxPtmStatusis required for normal PTM operation πΈtrillOamMepTxPtmResultOKis required for normal PTM operation πΈtrillOamMepTxPtmSeqNumberis required for normal PTM operation πΈtrillOamMepTxPtmMessagesis required for normal PTM operation πΈtrillOamMepTxMtvmTreeis required for normal MTVM operation πΈtrillOamMepTxMtvmHCis used to set the Maximum Hop Count for the MTVM. OAM frames don't leak out of the TRILL network, so it has no side effect π§trillOamMepTxMtvmReplyModeOobis used to indicate whether the reply is in band or out of band. Its vulnerability is covered as part oftrillOamMepTransmitMtmReplyIpπ«ΆtrillOamMepTxMtvmFlowEntropyis used to indicate the customer flow and find the exact path through the network. Creating valid flows is its intended purpose β¨ If invalid flows get created on vulnerable systems, they'll be dropped in forwarding ποΈtrillOamMepTxMtvmStatusis required for normal MTVM operation πΈtrillOamMepTxMtvmResultOK,trillOamMepTxMtvmMessages,trillOamMepTxMtvmSeqNumber, andtrillOamMepTxMtvmScopeListare required for normal MTVM operation πΈ
trillOamMepTransmitLbmReplyIp, trillOamMepTransmitPtmReplyIp, and trillOamMepTransmitMtvmReplyIp let you set the IP address that reports get sent to. That means they can be used for denial of service against that IP π
Some of the readable objects in this MIB (the ones with a MAX-ACCESS other than not-accessible) can also be sensitive or vulnerable in some environments. So it's really important to control even GET and/or NOTIFY access to them, and maybe even encrypt their values when they're sent over the network via SNMP π For example, Path Trace messages expose the unicast topology of the network, and Multi-destination Tree Verification Messages expose the multicast tree topology. This information should not be available to all users of the network π
SNMP versions before SNMPv3 didn't include adequate security. Even if the network itself is secure (for example, by using IPsec), there's no control over who on that secure network can access and GET or SET (read, change, create, or delete) the objects in this MIB module π€
Implementation should provide the security features described by the SNMPv3 framework (see [RFC3410]). Implementations that claim compliance with the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353] π«§
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security π‘οΈ It's then a customer or operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured so that only the principals (users) with legitimate rights can GET or SET (change, create, or delete) those objects π
9. IANA Considerations π
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER value, which is recorded in the SMI Numbers registry π§Ύ
Descriptor OBJECT IDENTIFIER value
----------------------------------------
trillOamMIB { mib-2 238 }
10. References π¦
10.1. Normative References π
- [802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks", IEEE Std 802.1Q-2011, DOI 10.1109/IEEESTD.2011.6009146.
- [IEEE8021-CFM-MIB] IEEE, "Connectivity Fault Management module for managing IEEE 802.1ag", IEEE 802.1ag, October 2008, <http://www.ieee802.org/1/files/public/MIBs/IEEE8021-CFM-MIB-200810150000Z.txt>.
- [LLDP-MIB] IEEE, "Management Information Base module for LLDP configuration, statistics, local system data and remote systems data components", IEEE 802.1AB, May 2005, <http://www.ieee802.org/1/files/public/MIBs/LLDP-MIB-200505060000Z.txt>.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <http://www.rfc-editor.org/info/rfc2578>.
- [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, <http://www.rfc-editor.org/info/rfc2579>.
- [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, <http://www.rfc-editor.org/info/rfc2580>.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, DOI 10.17487/RFC3414, December 2002, <http://www.rfc-editor.org/info/rfc3414>.
- [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, DOI 10.17487/RFC3826, June 2004, <http://www.rfc-editor.org/info/rfc3826>.
- [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, <http://www.rfc-editor.org/info/rfc5591>.
- [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 2009, <http://www.rfc-editor.org/info/rfc5592>.
- [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
- [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <http://www.rfc-editor.org/info/rfc6353>.
- [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
- [RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
10.2. Informative References π
These are the extra reads that help you understand the bigger picture, but nothing in them is strictly required to implement the spec. πΈ
- [Q.840.1] ITU-T, "Requirements and analysis for NMS-EMS management interface of Ethernet over Transport and Metro Ethernet Network (EoT/MEN)", Recommendation Q.840.1, March 2007. π
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI
10.17487/RFC3410, December 2002,<http://www.rfc-editor.org/info/rfc3410>. π¦ - [RFC6905] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., and R. Watve, "Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL)", RFC 6905, DOI
10.17487/RFC6905, March 2013,<http://www.rfc-editor.org/info/rfc6905>. β¨ - [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI
10.17487/RFC7174, May 2014,<http://www.rfc-editor.org/info/rfc7174>. π
Acknowledgments π«Ά
Big thank you to the whole IETF TRILL WG and the MIB Doctors π©Ί for their comments and suggestions, they were so helpful! π Detailed comments came from Sam Aldrin, Donald Eastlake, Tom Taylor, and Harrie Hazewinkel, and honestly the people who read this stuff line by line are the real heroes ππ .
Authors' Addresses π
The authors, and where you can find them:
Deepak Kumar
Cisco
510 McCarthy Blvd.
Milpitas, CA 95035
United States
Phone : +1 408-853-9760
Email: dekumar@cisco.com
Samer Salam
Cisco
595 Burrard St.
Suite 2123
Vancouver, BC V7X 1J1
Canada
Email: ssalam@cisco.com
Tissa Senevirathne
Consultant
Email: tsenevir@gmail.com
And that's the whole spec, bestie! π§π Go build something iconic with it. β
π¦ where this page comes from
- ietf: rfc7784 2016-02
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms