RFC 2932
IPv4 Multicast Routing MIB
IPv4 Multicast Routing MIB 💖
Okay bestie, this is RFC 2932, and it's a Standards Track doc 🎀 Three authors wrote it: K. McCloghrie from cisco Systems, D. Farinacci from Procket Networks, and D. Thaler from Microsoft. It came out in October 2000 🍓 The title block doesn't list anything it obsoletes or updates, so this one stands on its own ✨
Status of This Memo ✨
Okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want to know where it actually sits in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice 🌸
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract 🌈
This memo defines a piece of the Management Information Base (MIB) for network management protocols used across the Internet community 🧚 Specifically, it describes managed objects for managing IP Multicast Routing for IPv4, and it does this independently of whichever multicast routing protocol is actually running ✨
Table of Contents 🍓
1 Introduction ................................................. 2
2 The SNMP Management Framework ................................ 2
3 Overview ..................................................... 3
4 Definitions .................................................. 4
5 IANA Considerations .......................................... 22
6 Security Considerations ...................................... 22
7 Intellectual Property Notice ................................. 23
8 Acknowledgements ............................................. 23
9 Authors' Addresses ........................................... 24
10 References ................................................... 25
11 Full Copyright Statement ..................................... 271. Introduction ✨
Okay so this MIB is all about the objects you use to manage IP Multicast Routing [16] 💅 It's independent of any specific multicast routing protocol [17-21], and those protocol-specific objects are defined somewhere else 🦋 It also doesn't cover multicast routing for other address families, IPv6 included. Other MIBs might handle that bestie 🫶
2. The SNMP Management Framework 🎀
The SNMP Management Framework is made up of five major components, and honestly it's giving very organized 👑
- 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 it's described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and it's described in STD 15, RFC 1157 [8]. A second version, SNMPv2c, is described in RFC 1901 [9] and RFC 1906 [10], and it is not an Internet standards track protocol 🙈 The third version of the message protocol is called SNMPv3, and it's 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 their 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] 🔥
So managed objects are accessed through a virtual information store called the Management Information Base, or MIB 🧚 Objects in the MIB get defined using the mechanisms in the SMI 💖
This memo specifies a MIB module that is compliant with SMIv2. A MIB that conforms to SMIv1 can be produced through the appropriate translations. The translated MIB must be semantically equivalent, except where objects or events get left out because no translation is possible (for example, use of Counter64). Some machine readable information in SMIv2 gets turned into textual descriptions in SMIv1 during translation. But losing that machine readable information doesn't count as changing the semantics of the MIB, so it's all good ✨
3. Overview 🌸
This MIB module has one scalar and five tables, and each one has its own job 🍓
(1) the IP Multicast Route Table, containing multicast routing information for IP datagrams sent by particular sources to the IP multicast groups known to a router.
(2) the IP Multicast Routing Next Hop Table, containing information on the next-hops for routing IP multicast datagrams. Each entry is one of a list of next-hops on outgoing interfaces for particular sources sending to a particular multicast group address.
(3) the IP Multicast Routing Interface Table, containing multicast routing information specific to interfaces.
(4) the IP Multicast Scope Boundary Table, containing the boundaries configured for multicast scopes [22].
(5) the IP Multicast Scope Name Table, containing human-readable names of multicast scopes.
4. Definitions 💜
Here's the actual MIB module, bestie. It's the heart of the whole thing, so read it slowly 🧚
IPMROUTE-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2,
Integer32, Counter32, Counter64, Gauge32,
IpAddress, TimeTicks FROM SNMPv2-SMI
RowStatus, TEXTUAL-CONVENTION,
TruthValue FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
SnmpAdminString FROM SNMP-FRAMEWORK-MIB
InterfaceIndexOrZero,
InterfaceIndex FROM IF-MIB
IANAipRouteProtocol,
IANAipMRouteProtocol FROM IANA-RTPROTO-MIB;
ipMRouteStdMIB MODULE-IDENTITY
LAST-UPDATED "200009220000Z" -- September 22, 2000
ORGANIZATION "IETF IDMR Working Group"
CONTACT-INFO
" Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com"
DESCRIPTION
"The MIB module for management of IP Multicast routing, but
independent of the specific multicast routing protocol in
use."
REVISION "200009220000Z" -- September 22, 2000
DESCRIPTION
"Initial version, published as RFC 2932."
::= { mib-2 83 }
-- Textual Conventions
LanguageTag ::= TEXTUAL-CONVENTION
DISPLAY-HINT "100a"
STATUS current
DESCRIPTION
"An RFC 1766-style language tag, with all alphabetic
characters converted to lowercase. This restriction is
intended to make the lexical ordering imposed by SNMP useful
when applied to language tags. Note that it is
theoretically possible for a valid language tag to exceed
the allowed length of this syntax, and thus be impossible to
represent with this syntax. Sampling of language tags in
current use on the Internet suggests that this limit does
not pose a serious problem in practice."
SYNTAX OCTET STRING (SIZE (1..100))
-- Top-level structure of the MIB
ipMRouteMIBObjects OBJECT IDENTIFIER ::= { ipMRouteStdMIB 1 }
ipMRoute OBJECT IDENTIFIER ::= { ipMRouteMIBObjects 1 }
-- the IP Multicast Routing MIB-Group
--
-- a collection of objects providing information about
-- IP Multicast Groups
ipMRouteEnable OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The enabled status of IP Multicast routing on this router."
::= { ipMRoute 1 }
ipMRouteEntryCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of rows in the ipMRouteTable. This can be used
to monitor the multicast routing table size."
::= { ipMRoute 7 }
ipMRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing multicast routing
information for IP datagrams sent by particular sources to
the IP multicast groups known to this router."
::= { ipMRoute 2 }
ipMRouteEntry OBJECT-TYPE
SYNTAX IpMRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the multicast routing
information for IP datagrams from a particular source and
addressed to a particular IP multicast group address.
Discontinuities in counters in this entry can be detected by
observing the value of ipMRouteUpTime."
INDEX { ipMRouteGroup,
ipMRouteSource,
ipMRouteSourceMask }
::= { ipMRouteTable 1 }
IpMRouteEntry ::= SEQUENCE {
ipMRouteGroup IpAddress,
ipMRouteSource IpAddress,
ipMRouteSourceMask IpAddress,
ipMRouteUpstreamNeighbor IpAddress,
ipMRouteInIfIndex InterfaceIndexOrZero,
ipMRouteUpTime TimeTicks,
ipMRouteExpiryTime TimeTicks,
ipMRoutePkts Counter32,
ipMRouteDifferentInIfPackets Counter32,
ipMRouteOctets Counter32,
ipMRouteProtocol IANAipMRouteProtocol,
ipMRouteRtProto IANAipRouteProtocol,
ipMRouteRtAddress IpAddress,
ipMRouteRtMask IpAddress,
ipMRouteRtType INTEGER,
ipMRouteHCOctets Counter64
}
ipMRouteGroup OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IP multicast group address for which this entry
contains multicast routing information."
::= { ipMRouteEntry 1 }
ipMRouteSource OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network address which when combined with the
corresponding value of ipMRouteSourceMask identifies the
sources for which this entry contains multicast routing
information."
::= { ipMRouteEntry 2 }
ipMRouteSourceMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network mask which when combined with the corresponding
value of ipMRouteSource identifies the sources for which
this entry contains multicast routing information."
::= { ipMRouteEntry 3 }
ipMRouteUpstreamNeighbor OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The address of the upstream neighbor (e.g., RPF neighbor)
from which IP datagrams from these sources to this multicast
address are received, or 0.0.0.0 if the upstream neighbor is
unknown (e.g., in CBT)."
::= { ipMRouteEntry 4 }Okay so we're picking up right where ipMRouteInIfIndex starts, and this part is giving MIB realness 🧚💜
ipMRouteInIfIndex is literally the incoming interface check, bestie 🎀 Here's the object:
ipMRouteInIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of ifIndex for the interface on which IP
datagrams sent by these sources to this multicast address
are received. A value of 0 indicates that datagrams are not
subject to an incoming interface check, but may be accepted
on multiple interfaces (e.g., in CBT)."
::= { ipMRouteEntry 5 }
ipMRouteUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time since the multicast routing information
represented by this entry was learned by the router."
::= { ipMRouteEntry 6 }
ipMRouteExpiryTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum amount of time remaining before this entry will
be aged out. The value 0 indicates that the entry is not
subject to aging."
::= { ipMRouteEntry 7 }
ipMRoutePkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which this router has received from
these sources and addressed to this multicast group
address."
::= { ipMRouteEntry 8 }
ipMRouteDifferentInIfPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which this router has received from
these sources and addressed to this multicast group address,
which were dropped because they were not received on the
interface indicated by ipMRouteInIfIndex. Packets which are
not subject to an incoming interface check (e.g., using CBT)
are not counted."
::= { ipMRouteEntry 9 }
ipMRouteOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets contained in IP datagrams which were
received from these sources and addressed to this multicast
group address, and which were forwarded by this router."
::= { ipMRouteEntry 10 }
ipMRouteProtocol OBJECT-TYPE
SYNTAX IANAipMRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The multicast routing protocol via which this multicast
forwarding entry was learned."
::= { ipMRouteEntry 11 }
ipMRouteRtProto OBJECT-TYPE
SYNTAX IANAipRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The routing mechanism via which the route used to find the
upstream or parent interface for this multicast forwarding
entry was learned. Inclusion of values for routing
protocols is not intended to imply that those protocols need
be supported."
::= { ipMRouteEntry 12 }
ipMRouteRtAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The address portion of the route used to find the upstream
or parent interface for this multicast forwarding entry."
::= { ipMRouteEntry 13 }
ipMRouteRtMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The mask associated with the route used to find the upstream
or parent interface for this multicast forwarding entry."
::= { ipMRouteEntry 14 }
ipMRouteRtType OBJECT-TYPE
SYNTAX INTEGER {
unicast (1), -- Unicast route used in multicast RIB
multicast (2) -- Multicast route
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The reason the given route was placed in the (logical)
multicast Routing Information Base (RIB). A value of
unicast means that the route would normally be placed only
in the unicast RIB, but was placed in the multicast RIB
(instead or in addition) due to local configuration, such as
when running PIM over RIP. A value of multicast means that
the route was explicitly added to the multicast RIB by the
routing protocol, such as DVMRP or Multiprotocol BGP."
::= { ipMRouteEntry 15 }
ipMRouteHCOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets contained in IP datagrams which were
received from these sources and addressed to this multicast
group address, and which were forwarded by this router.
This object is a 64-bit version of ipMRouteOctets."
::= { ipMRouteEntry 16 }The IP Multicast Routing Next Hop Table ✨
Next up is the next-hop table, which is where the outgoing interfaces live 🦋 Here's how it's set up:
--
-- The IP Multicast Routing Next Hop Table
--
ipMRouteNextHopTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMRouteNextHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on the next-
hops on outgoing interfaces for routing IP multicast
datagrams. Each entry is one of a list of next-hops on
outgoing interfaces for particular sources sending to a
particular multicast group address."
::= { ipMRoute 3 }
ipMRouteNextHopEntry OBJECT-TYPE
SYNTAX IpMRouteNextHopEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the list of next-hops on
outgoing interfaces to which IP multicast datagrams from
particular sources to a IP multicast group address are
routed. Discontinuities in counters in this entry can be
detected by observing the value of ipMRouteUpTime."
INDEX { ipMRouteNextHopGroup, ipMRouteNextHopSource,
ipMRouteNextHopSourceMask, ipMRouteNextHopIfIndex,
ipMRouteNextHopAddress }
::= { ipMRouteNextHopTable 1 }
IpMRouteNextHopEntry ::= SEQUENCE {
ipMRouteNextHopGroup IpAddress,
ipMRouteNextHopSource IpAddress,
ipMRouteNextHopSourceMask IpAddress,
ipMRouteNextHopIfIndex InterfaceIndex,
ipMRouteNextHopAddress IpAddress,
ipMRouteNextHopState INTEGER,
ipMRouteNextHopUpTime TimeTicks,
ipMRouteNextHopExpiryTime TimeTicks,
ipMRouteNextHopClosestMemberHops Integer32,
ipMRouteNextHopProtocol IANAipMRouteProtocol,
ipMRouteNextHopPkts Counter32
}
ipMRouteNextHopGroup OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IP multicast group for which this entry specifies a
next-hop on an outgoing interface."
::= { ipMRouteNextHopEntry 1 }
ipMRouteNextHopSource OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network address which when combined with the
corresponding value of ipMRouteNextHopSourceMask identifies
the sources for which this entry specifies a next-hop on an
outgoing interface."
::= { ipMRouteNextHopEntry 2 }
ipMRouteNextHopSourceMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network mask which when combined with the corresponding
value of ipMRouteNextHopSource identifies the sources for
which this entry specifies a next-hop on an outgoing
interface."
::= { ipMRouteNextHopEntry 3 }
ipMRouteNextHopIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ifIndex value of the interface for the outgoing
interface for this next-hop."
::= { ipMRouteNextHopEntry 4 }
ipMRouteNextHopAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the next-hop specific to this entry. For
most interfaces, this is identical to ipMRouteNextHopGroup.
NBMA interfaces, however, may have multiple next-hop
addresses out a single outgoing interface."
::= { ipMRouteNextHopEntry 5 }
ipMRouteNextHopState OBJECT-TYPE
SYNTAX INTEGER { pruned(1), forwarding(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An indication of whether the outgoing interface and next-
hop represented by this entry is currently being used to
forward IP datagrams. The value 'forwarding' indicates it
is currently being used; the value 'pruned' indicates it is
not."
::= { ipMRouteNextHopEntry 6 }
ipMRouteNextHopUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time since the multicast routing information
represented by this entry was learned by the router."
::= { ipMRouteNextHopEntry 7 }
ipMRouteNextHopExpiryTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum amount of time remaining before this entry will
be aged out. If ipMRouteNextHopState is pruned(1), the
remaining time until the prune expires and the state reverts
to forwarding(2). Otherwise, the remaining time until this
entry is removed from the table. The time remaining may be
copied from ipMRouteExpiryTime if the protocol in use for
this entry does not specify next-hop timers. The value 0
indicates that the entry is not subject to aging."
::= { ipMRouteNextHopEntry 8 }
ipMRouteNextHopClosestMemberHops OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum number of hops between this router and any
member of this IP multicast group reached via this next-hop
on this outgoing interface. Any IP multicast datagrams for
the group which have a TTL less than this number of hops
will not be forwarded to this next-hop."
::= { ipMRouteNextHopEntry 9 }
ipMRouteNextHopProtocol OBJECT-TYPE
SYNTAX IANAipMRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The routing mechanism via which this next-hop was learned."
::= { ipMRouteNextHopEntry 10 }
ipMRouteNextHopPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which have been forwarded using this
route."
::= { ipMRouteNextHopEntry 11 }The Multicast Routing Interface Table 🌈
Last bit of this part: the interface table, which holds the multicast routing info for each interface 💅
--
-- The Multicast Routing Interface Table
--
ipMRouteInterfaceTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMRouteInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing multicast routing
information specific to interfaces."
::= { ipMRoute 4 }
ipMRouteInterfaceEntry OBJECT-TYPE
SYNTAX IpMRouteInterfaceEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the multicast routing
information for a particular interface."
INDEX { ipMRouteInterfaceIfIndex }
::= { ipMRouteInterfaceTable 1 }I've got the whole interface table laid out, bestie 💖 Here's the entry structure and its columns:
IpMRouteInterfaceEntry ::= SEQUENCE {
ipMRouteInterfaceIfIndex InterfaceIndex,
ipMRouteInterfaceTtl Integer32,
ipMRouteInterfaceProtocol IANAipMRouteProtocol,
ipMRouteInterfaceRateLimit Integer32,
ipMRouteInterfaceInMcastOctets Counter32,
ipMRouteInterfaceOutMcastOctets Counter32,
ipMRouteInterfaceHCInMcastOctets Counter64,
ipMRouteInterfaceHCOutMcastOctets Counter64
}Okay so the index is ipMRouteInterfaceIfIndex, which just says which interface the row is about. It's giving clean, and it's not readable directly, which is very on brand 🦋
ipMRouteInterfaceIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The ifIndex value of the interface for which this entry
contains information."
::= { ipMRouteInterfaceEntry 1 }The TTL threshold is next, and it's giving main character energy 👑
ipMRouteInterfaceTtl OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The datagram TTL threshold for the interface. Any IP
multicast datagrams with a TTL less than this threshold will
not be forwarded out the interface. The default value of 0
means all multicast packets are forwarded out the
interface."
::= { ipMRouteInterfaceEntry 2 }So basically, anything with a TTL under the threshold gets filtered out of that interface 💅 The default of 0 means everything goes out, no filter, fr fr 🌸
ipMRouteInterfaceProtocol OBJECT-TYPE
SYNTAX IANAipMRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The routing protocol running on this interface."
::= { ipMRouteInterfaceEntry 3 }This one tells you which routing protocol is running on the interface, read-only, no notes 🧚
ipMRouteInterfaceRateLimit OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The rate-limit, in kilobits per second, of forwarded
multicast traffic on the interface. A rate-limit of 0
indicates that no rate limiting is done."
DEFVAL { 0 }
::= { ipMRouteInterfaceEntry 4 }Rate limit is measured in kilobits per second, and 0 means no limiting at all 🍓 The default is 0 so nothing gets throttled unless you ask for it, which is honestly so iconic 😭
ipMRouteInterfaceInMcastOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets of multicast packets that have arrived
on the interface, including framing characters. This object
is similar to ifInOctets in the Interfaces MIB, except that
only multicast packets are counted."
::= { ipMRouteInterfaceEntry 5 }Inbound multicast octets, counting framing characters, and it's basically the multicast-only cousin of ifInOctets from the Interfaces MIB 🎀
ipMRouteInterfaceOutMcastOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets of multicast packets that have been
sent on the interface."
::= { ipMRouteInterfaceEntry 6 }Same vibe but for outbound, just the multicast packets that were sent out 🦋
ipMRouteInterfaceHCInMcastOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets of multicast packets that have arrived
on the interface, including framing characters. This object
is a 64-bit version of ipMRouteInterfaceInMcastOctets. It
is similar to ifHCInOctets in the Interfaces MIB, except
that only multicast packets are counted."
::= { ipMRouteInterfaceEntry 7 }The HC version is the 64-bit upgrade of the inbound counter, so it's the same info but with way more room before it wraps 🌈 It's the Counter64 glow-up, periodt ✨
ipMRouteInterfaceHCOutMcastOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of octets of multicast packets that have been
sent on the interface. This object is a 64-bit version of
ipMRouteInterfaceOutMcastOctets."
::= { ipMRouteInterfaceEntry 8 }And the outbound 64-bit one is the same glow-up for the outbound counter 💜
The IP Multicast Scope Boundary Table
This part is about the scoped multicast address boundaries, the table that lists where a router's scoped boundaries sit 🫶
--
-- The IP Multicast Scope Boundary Table
--
ipMRouteBoundaryTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMRouteBoundaryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table listing the router's scoped
multicast address boundaries."
::= { ipMRoute 5 }
ipMRouteBoundaryEntry OBJECT-TYPE
SYNTAX IpMRouteBoundaryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the ipMRouteBoundaryTable
representing a scoped boundary."
INDEX { ipMRouteBoundaryIfIndex, ipMRouteBoundaryAddress,
ipMRouteBoundaryAddressMask }
::= { ipMRouteBoundaryTable 1 }The table itself is conceptual, which is just MIB-speak for "it's a rule set, not a physical thing" 🌸 Each row is one scoped boundary, indexed by the interface, the address, and the mask all together 💅
IpMRouteBoundaryEntry ::= SEQUENCE {
ipMRouteBoundaryIfIndex InterfaceIndex,
ipMRouteBoundaryAddress IpAddress,
ipMRouteBoundaryAddressMask IpAddress,
ipMRouteBoundaryStatus RowStatus
}Each row has the interface index, the address, the mask, and a status 🎀
ipMRouteBoundaryIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IfIndex value for the interface to which this boundary
applies. Packets with a destination address in the
associated address/mask range will not be forwarded out this
interface."
::= { ipMRouteBoundaryEntry 1 }This is the interface the boundary applies to. Any packet whose destination is in the matching address and mask range doesn't go out that interface 🙈
ipMRouteBoundaryAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The group address which when combined with the
corresponding value of ipMRouteBoundaryAddressMask
identifies the group range for which the scoped boundary
exists. Scoped addresses must come from the range 239.x.x.x
as specified in RFC 2365."
::= { ipMRouteBoundaryEntry 2 }The address plus the mask gives you the group range, and scoped addresses come from 239.x.x.x as set out in RFC 2365 🦋
ipMRouteBoundaryAddressMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The group address mask which when combined with the
corresponding value of ipMRouteBoundaryAddress identifies
the group range for which the scoped boundary exists."
::= { ipMRouteBoundaryEntry 3 }The mask pairs with that address to pin down the exact group range 🌈
ipMRouteBoundaryStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table."
::= { ipMRouteBoundaryEntry 4 }This is the row status, the thing that lets you create new boundary entries or delete old ones ✨
The IP Multicast Scope Name Table
Next up is the table of scope names, which is basically the friendly labels for multicast scopes 💖
--
-- The IP Multicast Scope Name Table
--
ipMRouteScopeNameTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMRouteScopeNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table listing the multicast scope names."
::= { ipMRoute 6 }
ipMRouteScopeNameEntry OBJECT-TYPE
SYNTAX IpMRouteScopeNameEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the ipMRouteScopeNameTable
representing a multicast scope name."
INDEX { ipMRouteScopeNameAddress,
ipMRouteScopeNameAddressMask,
IMPLIED ipMRouteScopeNameLanguage }
::= { ipMRouteScopeNameTable 1 }Each row is one name for a scope, and it's indexed by the address, the mask, and the language, with the language marked IMPLIED 🧚
IpMRouteScopeNameEntry ::= SEQUENCE {
ipMRouteScopeNameAddress IpAddress,
ipMRouteScopeNameAddressMask IpAddress,
ipMRouteScopeNameLanguage LanguageTag,
ipMRouteScopeNameString SnmpAdminString,
ipMRouteScopeNameDefault TruthValue,
ipMRouteScopeNameStatus RowStatus
}So a scope name row has the address, the mask, the language tag, the name string, a default flag, and a status 🎀
ipMRouteScopeNameAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The group address which when combined with the
corresponding value of ipMRouteScopeNameAddressMask
identifies the group range associated with the multicast
scope. Scoped addresses must come from the range
239.x.x.x."
::= { ipMRouteScopeNameEntry 1 }The address plus the mask gives the group range the name belongs to, and scoped addresses come from 239.x.x.x 🌸
ipMRouteScopeNameAddressMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The group address mask which when combined with the
corresponding value of ipMRouteScopeNameAddress identifies
the group range associated with the multicast scope."
::= { ipMRouteScopeNameEntry 2 }Same deal as before: the mask with the address gives the range 💅
ipMRouteScopeNameLanguage OBJECT-TYPE
SYNTAX LanguageTag
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The RFC 1766-style language tag associated with the scope
name."
::= { ipMRouteScopeNameEntry 3 }The language is an RFC 1766-style tag, so the name can come in different languages 🌈
ipMRouteScopeNameString OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The textual name associated with the multicast scope. The
value of this object should be suitable for displaying to
end-users, such as when allocating a multicast address in
this scope. When no name is specified, the default value of
this object should be the string 239.x.x.x/y with x and y
replaced appropriately to describe the address and mask
length associated with the scope."
::= { ipMRouteScopeNameEntry 4 }This is the human-readable name, and it should be something end users can actually read, like when they're picking an address for a scope 🦋 If nobody names it, the fallback is the 239.x.x.x/y form, with x and y filled in to match the address and mask length 🙈
ipMRouteScopeNameDefault OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"If true, indicates a preference that the name in the
following language should be used by applications if no name
is available in a desired language."
DEFVAL { false }
::= { ipMRouteScopeNameEntry 5 }If this is true, it's a preference saying apps should use this language's name when there's no name in the language they want 🫶 It defaults to false 💜
ipMRouteScopeNameStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table."
::= { ipMRouteScopeNameEntry 6 }And this is the row status again, so you can create or delete scope names 🌸
Conformance Information
Now the conformance bits, which say what a compliant implementation has to support 🎀
-- conformance information
ipMRouteMIBConformance
OBJECT IDENTIFIER ::= { ipMRouteStdMIB 2 }
ipMRouteMIBCompliances
OBJECT IDENTIFIER ::= { ipMRouteMIBConformance 1 }
ipMRouteMIBGroups OBJECT IDENTIFIER ::= { ipMRouteMIBConformance 2 }These are the containers for the conformance stuff: the compliance statements and the groups 🧚
Compliance Statements
-- compliance statements
ipMRouteMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for the IP Multicast MIB."
MODULE -- this module
MANDATORY-GROUPS { ipMRouteMIBBasicGroup,
ipMRouteMIBRouteGroup}
GROUP ipMRouteMIBBoundaryGroup
DESCRIPTION
"This group is mandatory if the router supports
administratively-scoped multicast address boundaries."
OBJECT ipMRouteBoundaryStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ipMRouteScopeNameStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
GROUP ipMRouteMIBHCInterfaceGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
for which the value of the corresponding instance of ifSpeed
is greater than 20,000,000 bits/second."
::= { ipMRouteMIBCompliances 1 }The basic and route groups are the must-haves for compliance 💖 The boundary group only matters if the router does administratively-scoped boundaries 🍓 The boundary and scope-name status objects only need read-only access, so writes aren't required 🙈 And the HC interface group is only mandatory on interfaces where ifSpeed is over 20,000,000 bits/second, so the fast boys have to keep up 🔥
Units of Conformance
-- units of conformance
ipMRouteMIBBasicGroup OBJECT-GROUP
OBJECTS { ipMRouteEnable, ipMRouteEntryCount,
ipMRouteUpstreamNeighbor, ipMRouteInIfIndex,
ipMRouteUpTime, ipMRouteExpiryTime,
ipMRouteNextHopState,
ipMRouteNextHopUpTime,
ipMRouteNextHopExpiryTime,
ipMRouteNextHopProtocol,
ipMRouteNextHopPkts,
ipMRouteInterfaceTtl,
ipMRouteInterfaceProtocol, ipMRouteInterfaceRateLimit,
ipMRouteInterfaceInMcastOctets,
ipMRouteInterfaceOutMcastOctets,
ipMRouteProtocol
}
STATUS current
DESCRIPTION
"A collection of objects to support basic management of IP
Multicast routing."
::= { ipMRouteMIBGroups 1 }The basic group is the big bundle of objects you need for basic IP multicast routing management 🌈 It's the core squad 👑
ipMRouteMIBHopCountGroup OBJECT-GROUP
OBJECTS { ipMRouteNextHopClosestMemberHops }
STATUS current
DESCRIPTION
"A collection of objects to support management of the use of
hop counts in IP Multicast routing."
::= { ipMRouteMIBGroups 2 }And the hop count group is just the one object for managing hop counts in IP multicast routing 🧚
ipMRouteMIBBoundaryGroup OBJECT-GROUP
OBJECTS { ipMRouteBoundaryStatus, ipMRouteScopeNameString,
ipMRouteScopeNameDefault, ipMRouteScopeNameStatus }
STATUS current
DESCRIPTION
"A collection of objects to support management of scoped
multicast address boundaries."
::= { ipMRouteMIBGroups 3 }
ipMRouteMIBPktsOutGroup OBJECT-GROUP
OBJECTS { ipMRouteNextHopPkts }
STATUS current
DESCRIPTION
"A collection of objects to support management of packet
counters for each outgoing interface entry of a route."
::= { ipMRouteMIBGroups 4 }
ipMRouteMIBHCInterfaceGroup OBJECT-GROUP
OBJECTS { ipMRouteInterfaceHCInMcastOctets,
ipMRouteInterfaceHCOutMcastOctets,
ipMRouteHCOctets }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second) network
interfaces."
::= { ipMRouteMIBGroups 5 }
ipMRouteMIBRouteGroup OBJECT-GROUP
OBJECTS { ipMRouteRtProto, ipMRouteRtAddress,
ipMRouteRtMask, ipMRouteRtType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
relationship between multicast routing information, and the
IP Forwarding Table."
::= { ipMRouteMIBGroups 6 }
ipMRouteMIBPktsGroup OBJECT-GROUP
OBJECTS { ipMRoutePkts, ipMRouteDifferentInIfPackets,
ipMRouteOctets }
STATUS current
DESCRIPTION
"A collection of objects to support management of packet
counters for each forwarding entry."
::= { ipMRouteMIBGroups 7 }
END5. IANA Considerations ✨
okay so the textual conventions for ipMRouteRtProto, ipMRouteNextHopProtocol, ipMRouteInterfaceProtocol, and ipMRouteProtocol are imported from the IANA-RTPROTO-MIB 🌸 the whole point of putting them in their own separate MIB module is so new values can be added later WITHOUT having to publish a brand new version of this document. genius, right? 👑 IANA (the Internet Assigned Numbers Authority) is in charge of all Internet numbers, SNMP-related ones included, so IANA is the one who manages the values for these textual conventions. 🫶
the rules for adding or changing the IANA-RTPROTO-MIB live in the DESCRIPTION clause attached to its MODULE-IDENTITY statement. 📖
you can find the current versions of the IANA-RTPROTO-MIB on the IANA home page at: "http://www.iana.org/" 🦋
6. Security Considerations 🔒
okay this section is SERIOUS bestie, so listen up 😭 this MIB has readable objects that show info about multicast routing, including which machines are sending to which groups. 👀 it also has a bunch of objects with a MAX-ACCESS of read-write and/or read-create, like the ones that let an admin configure multicast boundaries. 🚧
reading the stuff you're not supposed to read is kinda innocuous, fr 🙈 but unauthorized access to the write-able objects? that's a whole disaster 💀 it could cause a denial of service, or send packets further than they were ever meant to go (stuff that's only supposed to stay local, escaping 🏃♀️💨). so doing SET operations in a non-secure environment without proper protection can really mess with network operations. not cute. ❌
SNMPv1 by itself is exactly that kind of insecure environment 📉 and even if the network itself is secure (for example by using IPSec), there's still no control over who on that secure network is allowed to access and SET (change/create/delete) the objects in this MIB. 😤
it's recommended that implementers look at the security features provided by the SNMPv3 framework 🔐 specifically, the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] are recommended. ✨
and then it's the customer/user's responsibility to make sure the SNMP entity giving access to this MIB is configured properly, so only the principals (users) with legitimate rights can get at those objects. 🫡 that's a you problem, bestie, not a MIB problem 💅
7. Intellectual Property Notice 📜
okay legal-ish moment, but make it quick ⏱️ the IETF doesn't take a position on whether any intellectual property or other rights claimed about the technology in this document are valid or in scope, and it doesn't say whether any license under those rights is available either. 🤷♀️ it also doesn't claim it has tried to find any such rights.
info on how the IETF handles rights for standards-track and standards-related documents is in BCP-11. 📚 copies of claims of rights made available for publication, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be obtained from the IETF Secretariat. 📬
the IETF also invites anyone interested to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. 🙌 send that info to the IETF Executive Director. 💌
8. Acknowledgements 🫶
this MIB module got updated thanks to feedback from the IETF's Inter-Domain Multicast Routing (IDMR) Working Group. 🌈 shoutout to them, they made it better fr 💖
9. Authors' Addresses 🖋️
the authors, for the record:
Keith McCloghrie
cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: +1 408 526 5260
EMail: kzm@cisco.comDino Farinacci
Procket Networks
3850 North First Street
San Jose, CA 95134
Phone: +1 408-954-7909
Email: dino@procket.comDave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com10. References 📚
the full reading list, every single one 🤓
- [1] Wijnen, B., Harrington, D. and R. Presuhn, "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, STD 58, 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] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [10] 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 (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [13] 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, "SNMPv3 Applications", RFC 2573, April 1999.
- [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [16] Deering, S., "Multicast Routing in a Datagram Internetwork", PhD thesis, Electrical Engineering Dept., Stanford University, December 1991.
- [17] Waitzman, D., Partridge, C. and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
- [18] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
- [19] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Helmy, A. and L. Wei, "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress.
- [20] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
- [21] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing", RFC 2189, September 1997.
- [22] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
11. Full Copyright Statement ⚖️
the legal bit, kept complete because it matters 💖
Copyright (C) The Internet Society (2000). All Rights Reserved.
you're allowed to copy and share this document, and to make derivative works that comment on or explain it or help with implementing it. you can publish and distribute those in whole or in part, without restriction of any kind, as long as the copyright notice and this paragraph are included on all copies and derivative works. ✨ BUT this document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process must be followed), or when it's translated into languages other than English. 🌍
the permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. 🦋
this document and the information in it are provided on an "AS IS" basis 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. 💜 and that's a wrap on RFC 2932, bestie 🎀✨
📦 where this page comes from
- ietf: rfc2932 2000-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms