RFC 6527
Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3)
Definitions of Managed Objects for the Virtual Router Redundancy Protocol Version 3 (VRRPv3) 🎀
okay bestie, so this is RFC 6527 💖 It was written by K. Tata at Nokia and published in March 2012. It's a Standards Track doc, so it's an actual Internet standard, no cap 💅 It also obsoletes RFC 2787, which means it replaces that older one. The ISSN is 2070-1721 ✨
Abstract
okay so this spec defines a portion of the Management Information Base (MIB) for network management with the Simple Network Management Protocol (SNMP) 🦋 The main point is that it defines objects for configuring, monitoring, and controlling routers that use the Virtual Router Redundancy Protocol Version 3 (VRRPv3), for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787 🫶
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741 📚
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6527 🌸
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, because they describe your rights and restrictions for this document ✨ Code Components extracted from 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.
ok and this one is important 👀 this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. so unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. the one exception is formatting it for publication as an RFC, or translating it into languages other than English 🌈
Table of Contents
1. The Internet-Standard Management Framework ......................2
2. Introduction ....................................................3
3. Terminology .....................................................3
4. Relationship to RFC 2787 ........................................3
5. Relation to Interface Group (IF-MIB) ............................3
6. Multi-Stack Implementations .....................................3
7. Interpretation of RFC 5798 ......................................3
8. VRRP MIB Structure and Design ...................................4
9. VRRP Multi-Stack Scenario .......................................4
10. Definitions ....................................................7
11. Security Considerations .......................................27
12. IANA Considerations ...........................................29
13. Normative References ..........................................29
14. Informative References ........................................30
15. Acknowledgments ...............................................311. The Internet-Standard Management Framework ✨
if you want a detailed overview of the docs that describe the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 🧚
so managed objects get accessed through a virtual information store called the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). objects in the MIB are defined using the mechanisms from the Structure of Management Information (SMI). this memo specifies a MIB module that's compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 💅
2. Introduction 🌸
this spec defines a portion of the MIB for SNMP-based network management. specifically, it defines objects for configuring, monitoring, and controlling routers that run the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6, as defined in RFC 5798 [RFC5798] 🦋
3. Terminology 💖
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] 🔥
4. Relationship to RFC 2787 🍓
this document obsoletes RFC 2787 [RFC2787], and it's giving "glow-up" 💫 The major changes reflect changes in the VRRP protocol between RFC 2338 [RFC2338] and RFC 5798 [RFC5798]. this document is also updated to conform to current MIB conventions ✨
5. Relation to Interface Group (IF-MIB) 🎀
so a router can be participating in VRRP on one or more interfaces, which is why ifIndex is used as an index into the tables defined in the VRRP MIB 🦋 This MIB module imports ifIndex from the IF-MIB. at this time, the latest version of the IF-MIB is from RFC 2863 [RFC2863] 📚
6. Multi-Stack Implementations 🧚
this MIB module is designed to support multi-stack implementations that run VRRP over IPv4 and IPv6. the IP version, Virtual Router Identifier (VRID), and ifIndex are used together to uniquely identify rows in a multi-stack implementation 👑
7. Interpretation of RFC 5798 🌈
okay so during the review of this document, it came out that there are different possible interpretations of [RFC5798] 😭 The authors of that document and the VRRP working group couldn't reach consensus on which interpretation is correct. so this document makes the following assumption:
IPv4 and IPv6 virtual routers are treated as two separate logical entities and represented as two separate entries in the vrrpv3OperationsTable. This is required due to the undefined behavior of the protocol in [RFC5798] in a multi-stack scenario.
8. VRRP MIB Structure and Design 💜
this MIB module contains three tables 🫶
- The
vrrpv3OperationsTablecontains objects that define the operational characteristics of a VRRP router. Rows in this table correspond to instances of virtual routers. - The
vrrpv3StatisticsTablecontains the operating statistics for a VRRP router. - The
vrrpv3AssociatedIpAddrTablecontains the addresses of the virtual router(s) that a given VRRP router is backing up.
the tables are indexed on ifIndex, VRID, and the IP version, so together they uniquely identify a VRRP router 🔥
notifications in this MIB module are controlled using the mechanisms defined in [RFC3413] 🧚
Next up is Section 9, the VRRP Multi-Stack Scenario, so stay tuned, bestie 🦋
9. VRRP Multi-Stack Scenario ✨
okay so this section is the fun one 🎀 it walks through how some of the objects in this MIB actually get filled in, with real examples you can picture.
First, a quick cheat sheet so you can read the tables without squinting 👀
KEY:
----
The labels in the following tables and diagrams correspond to the
actual MIB objects as follows:
if = IfIndex
AddrType= vrrpv3OperationsInetAddrType
VrId = vrrpv3OperationsVrId
State = vrrpv3OperationsStatus
Prior = vrrpv3OperationsPriority
IpAddr = vrrpv3OperationsMasterIpAddrThe network in the next figure is hypothetical, but it's giving real-life vibes 💅 There are two VRRP routers, VR1 & VR2, and each one is configured with two virtual routers. Addresses in () are the default gateway for a given host. H1 to H4 are IPv4 hosts, and H5 to H8 are IPv6 hosts. A, B, and C are IPv4 addresses, and X, Y, and Z are IPv6 addresses. In the diagram, "Interface" is used in the context defined in IF-MIB 🦋
+------+ +------+
| VR1 | | VR2 |
| | | |
+------+ +------+
| |
Intf = I1 Intf = I2
IP A | IP X IP B | IP Y
IP C | | IP Z
VRID = 1 | VRID=2 VRID=2 | VRID = 1
| |
----+------+------+-+-------+--------+--------++------+--------+---
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
(IP A) (IP A) (IP B) (IP B) (IP X) (IP X) (IP Y) (IP Y)
| | | | | | | |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
| H1 | | H2 | | H3 | | H4 | | H5 | | H6 | | H7 | | H8 |
+----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+Now for the juicy part, the MIB tables for VR1 🌸 Look at how the same virtual router ID can show up on two different interfaces, and how the IPv4 and IPv6 rows are kept separate. Main character energy, honestly 👑
----- MIB Tables For VRRP Router "VR1": -----
vrrpv3OperationsTable
-------------------
| if | VrId |AddrType| State | Prior |IpAddr| |
+----+------+--------+-------+-------+------+--(..)--+
| I1 | 01 | 1 | M | 255 | A | |
+----+------+--------+-------+-------+------+--(..)--+
| I1 | 01 | 2 | B | 1-254 | Y | |
+----+------+--------+-------+-------+------+--(..)--+
| I1 | 02 | 1 | B | 1-254 | B | |
+----+------+--------+-------+-------+------+--(..)--+
| I1 | 02 | 2 | M | 255 | X | |
+----+------+--------+-------+-------+------+--------+
vrrpv3AssociatedIpAddrTable
-------------------------
| if | VrId | AddrType | IP | RowStat |
+----+------+----------+------+---------+
| I1 | 01 | 1 | A | active |
+----+------+----------+------+---------+
| I1 | 01 | 1 | C | active |
+----+------+----------+------+---------+
| I1 | 01 | 2 | Y | active |
+----+------+----------+------+---------+
| I1 | 01 | 2 | Z | active |
+----+------+----------+------+---------+
| I1 | 02 | 1 | B | active |
+----+------+----------+------+---------+
| I1 | 02 | 2 | X | active |
+----+------+----------+------+---------+And now VR2 💖 Same vibe, just flipped around. Spot who's Master (M) and who's Backup (B) in each row. It's giving mirror energy 🪞
----- MIB Tables For VRRP Router "VR2": -----
vrrpv3OperationsTable
-------------------
| if | VrId |AddrType| State | Prior |IpAddr| |
+----+------+--------+-------+-------+------+--(..)--+
| I2 | 01 | 1 | B | 1-254 | A | |
+----+------+--------+-------+-------|------+--(..)--+
| I2 | 01 | 2 | M | 255 | Y | |
+----+------+--------+-------+-------+------+--(..)--+
| I2 | 02 | 1 | M | 255 | B | |
+----+------+--------+-------+-------+------+--(..)--+
| I2 | 02 | 2 | B | 1-254 | X | |
+----+------+--------+-------+-------+------+--------+
vrrpv3AssociatedIpAddrTable
-------------------------
| if | VrId |AddrType| IP | RowStat |
+----+------+--------+------+---------+
| I2 | 01 | 1 | A | active |
+----+------+--------+------+---------+
| I2 | 01 | 1 | C | active |
+----+------+--------+------+---------+
| I2 | 01 | 2 | Y | active |
+----+------+--------+------+---------+
| I2 | 01 | 2 | Z | active |
+----+------+--------+------+---------+
| I2 | 02 | 1 | B | active |
+----+------+--------+------+---------+
| I2 | 02 | 2 | X | active |
+----+------+--------+------+---------+NOTES:
- For "State": M = Master; B = Backup. In the vrrpv3OperationsTable, a "priority" of 255 indicates that the respective router owns the IP address, e.g., this IP address is native to the router (i.e., "the IP Address Owner"). 🫶
10. Definitions 📜
okay this is the part where the MIB module itself shows up 🤓 It's a whole spec, so read it like a love letter, not a novel 💌
This MIB module makes reference to the following documents [RFC2578], [RFC2579], [RFC2580], [RFC2863], and [RFC4001].
VRRPV3-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, Counter32,
Integer32, mib-2, Unsigned32,
Counter64, TimeTicks
FROM SNMPv2-SMI -- RFC2578
TEXTUAL-CONVENTION, RowStatus,
MacAddress, TruthValue, TimeStamp,
TimeInterval
FROM SNMPv2-TC -- RFC2579
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- RFC2580
ifIndex
FROM IF-MIB -- RFC2863
InetAddressType, InetAddress
FROM INET-ADDRESS-MIB; -- RFC4001
vrrpv3MIB MODULE-IDENTITY
LAST-UPDATED "201202130000Z" -- Feb 13, 2012
ORGANIZATION "IETF VRRP Working Group"
CONTACT-INFO
"WG E-Mail: vrrp@ietf.org
Editor: Kalyan Tata
Nokia
313 Fairchild Dr,
Mountain View, CA 94043
Tata_kalyan@yahoo.com"
DESCRIPTION
"This MIB describes objects used for managing Virtual
Router Redundancy Protocol version 3 (VRRPv3).
Copyright (c) 2012 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).
This version of the MIB module is part of RFC 6527.
Please see the RFC for full legal notices."
REVISION "201202120000Z" -- Feb 13, 2012
DESCRIPTION "Initial version as published in RFC 6527."
::= { mib-2 207 }
-- Textual Conventions
Vrrpv3VrIdTC ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"The value of the Virtual Router Identifier noted as
(VRID) in RFC 5798. This, along with interface index
(ifIndex) and IP version, serves to uniquely identify
a virtual router on a given VRRP router."
REFERENCE "RFC 5798 (Sections 3 and 5.2.3)"
SYNTAX Integer32 (1..255)
-- VRRPv3 MIB Groups
vrrpv3Notifications OBJECT IDENTIFIER ::= { vrrpv3MIB 0 }
vrrpv3Objects OBJECT IDENTIFIER ::= { vrrpv3MIB 1 }
vrrpv3Conformance OBJECT IDENTIFIER ::= { vrrpv3MIB 2 }
-- VRRPv3 MIB Objects
vrrpv3Operations OBJECT IDENTIFIER ::= { vrrpv3Objects 1 }
vrrpv3Statistics OBJECT IDENTIFIER ::= { vrrpv3Objects 2 }
-- VRRPv3 Operations Table
vrrpv3OperationsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Vrrpv3OperationsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Unified Operations table for a VRRP router that
consists of a sequence (i.e., one or more conceptual
rows) of 'vrrpv3OperationsEntry' items each of which
describe the operational characteristics of a virtual
router."
::= { vrrpv3Operations 1 }
vrrpv3OperationsEntry OBJECT-TYPE
SYNTAX Vrrpv3OperationsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the vrrpv3OperationsTable containing the
operational characteristics of a virtual router.
On a VRRP router, a given virtual router is
identified by a combination of ifIndex, VRID, and
the IP version. ifIndex represents an interface of
the router.
A row must be created with vrrpv3OperationsStatus
set to initialize(1) and cannot transition to
backup(2) or master(3) until
vrrpv3OperationsRowStatus is transitioned to
active(1).
The information in this table is persistent and when
written the entity SHOULD save the change to non-
volatile storage."
INDEX { ifIndex, vrrpv3OperationsVrId,
vrrpv3OperationsInetAddrType
}
::= { vrrpv3OperationsTable 1 }
Vrrpv3OperationsEntry ::=
SEQUENCE {
vrrpv3OperationsVrId
Vrrpv3VrIdTC,
vrrpv3OperationsInetAddrType
InetAddressType,
vrrpv3OperationsMasterIpAddr
InetAddress,
vrrpv3OperationsPrimaryIpAddr
InetAddress,
vrrpv3OperationsVirtualMacAddr
MacAddress,
vrrpv3OperationsStatus
INTEGER,
vrrpv3OperationsPriority
Unsigned32,
vrrpv3OperationsAddrCount
Integer32,
vrrpv3OperationsAdvInterval
TimeInterval,
vrrpv3OperationsPreemptMode
TruthValue,
vrrpv3OperationsAcceptMode
TruthValue,
vrrpv3OperationsUpTime
TimeTicks,
vrrpv3OperationsRowStatus
RowStatus
}
vrrpv3OperationsVrId OBJECT-TYPE
SYNTAX Vrrpv3VrIdTC
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object contains the Virtual Router Identifier
(VRID)."
REFERENCE "RFC 4001"
::= { vrrpv3OperationsEntry 1 }
vrrpv3OperationsInetAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The IP address type of Vrrpv3OperationsEntry and
Vrrpv3AssociatedIpAddrEntry. This value determines
the type for vrrpv3OperationsMasterIpAddr,
vrrpv3OperationsPrimaryIpAddr, and
vrrpv3AssociatedIpAddrAddress.
ipv4(1) and ipv6(2) are the only two values supported
in this MIB module."
REFERENCE "RFC 4001"
::= { vrrpv3OperationsEntry 2 }okay so this is where the operations table really starts to shine 💅 each object below is a little piece of the virtual router's life story, and the MIB text itself stays exactly as written ✨
vrrpv3OperationsMasterIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The master router's real IP address. The master router
would set this address to vrrpv3OperationsPrimaryIpAddr
while transitioning to master state. For backup
routers, this is the IP address listed as the source in
the VRRP advertisement last received by this virtual
router."
REFERENCE "RFC 5798"
::= { vrrpv3OperationsEntry 3 }
vrrpv3OperationsPrimaryIpAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"In the case where there is more than one IP
Address (associated IP addresses) for a given
'ifIndex', this object is used to specify the IP
address that will become the
vrrpv3OperationsMasterIpAddr', should the virtual
router transition from backup state to master."
::= { vrrpv3OperationsEntry 4 }
vrrpv3OperationsVirtualMacAddr OBJECT-TYPE
SYNTAX MacAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The virtual MAC address of the virtual router.
Although this object can be derived from the
'vrrpv3OperationsVrId' object, it is defined so that it
is easily obtainable by a management application and
can be included in VRRP-related SNMP notifications."
::= { vrrpv3OperationsEntry 5 }
vrrpv3OperationsStatus OBJECT-TYPE
SYNTAX INTEGER {
initialize(1),
backup(2),
master(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current state of the virtual router. This object
has three defined values:
- 'initialize', which indicates that the
virtual router is waiting for a startup event.
- 'backup', which indicates that the virtual router is
monitoring the availability of the master router.
- 'master', which indicates that the virtual router
is forwarding packets for IP addresses that are
associated with this router."
REFERENCE "RFC 5798"
::= { vrrpv3OperationsEntry 6 }
vrrpv3OperationsPriority OBJECT-TYPE
SYNTAX Unsigned32 (0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the priority to be used for the
virtual router master election process; higher values
imply higher priority.
A priority of '0', although not settable, is sent by
the master router to indicate that this router has
ceased to participate in VRRP, and a backup virtual
router should transition to become a new master.
A priority of 255 is used for the router that owns the
associated IP address(es) for VRRP over IPv4 and hence
is not settable.
Setting the values of this object to 0 or 255 should be
rejected by the agents implementing this MIB module.
For example, an SNMP agent would return 'badValue(3)'
when a user tries to set the values 0 or 255 for this
object."
REFERENCE "RFC 5798, Section 6.1"
DEFVAL { 100 }
::= { vrrpv3OperationsEntry 7 }
vrrpv3OperationsAddrCount OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IP addresses that are associated with
this virtual router. This number is equal to the
number of rows in the vrrpv3AssociatedAddrTable that
correspond to a given ifIndex/VRID/IP version."
REFERENCE "RFC 5798, Section 6.1"
::= { vrrpv3OperationsEntry 8 }
vrrpv3OperationsAdvInterval OBJECT-TYPE
SYNTAX TimeInterval (1..4095)
UNITS "centiseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The time interval, in centiseconds, between sending
advertisement messages. Only the master router sends
VRRP advertisements."
REFERENCE "RFC 5798, Section 6.1"
DEFVAL { 100}
::= { vrrpv3OperationsEntry 9 }
vrrpv3OperationsPreemptMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls whether a higher priority virtual router will
preempt a lower priority master."
REFERENCE "RFC 5798, Section 6.1"
DEFVAL { true }
::= { vrrpv3OperationsEntry 10 }
vrrpv3OperationsAcceptMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Controls whether a virtual router in master state
will accept packets addressed to the address owner's
IPv6 address as its own if it is not the IPv6 address
owner. Default is false(2).
This object is not relevant for rows representing VRRP
over IPv4 and should be set to false(2)."
DEFVAL { false }
::= { vrrpv3OperationsEntry 11 }
vrrpv3OperationsUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the amount of time, in
TimeTicks (hundredth of a second), since this virtual
router (i.e., the 'vrrpv3OperationsStatus')
transitioned out of 'initialize'."
REFERENCE "RFC 5798, Section 6.1"
::= { vrrpv3OperationsEntry 12 }
vrrpv3OperationsRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The RowStatus variable should be used in accordance to
installation and removal conventions for conceptual
rows.
To create a row in this table, a manager sets this
object to either createAndGo(4) or createAndWait(5).
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the
'vrrpv3OperationsRowStatus' column will be read as
notReady(3).
In particular, a newly created row cannot be made
active(1) until (minimally) the corresponding instance
of vrrpv3OperationsInetAddrType, vrrpv3OperationsVrId,
and vrrpv3OperationsPrimaryIpAddr has been set, and
there is at least one active row in the
'vrrpv3AssociatedIpAddrTable' defining an associated
IP address.
notInService(2) should be used to administratively
bring the row down.
A typical order of operation to add a row is:
1. Create a row in vrrpv3OperationsTable with
createAndWait(5).
2. Create one or more corresponding rows in
vrrpv3AssociatedIpAddrTable.
3. Populate the vrrpv3OperationsEntry.
4. Set vrrpv3OperationsRowStatus to active(1).
A typical order of operation to delete an entry is:
1. Set vrrpv3OperationsRowStatus to notInService(2).
2. Set the corresponding rows in
vrrpv3AssociatedIpAddrTable to destroy(6) to delete
the entry.
3. Set vrrpv3OperationsRowStatus to destroy(6) to
delete the entry."
::= { vrrpv3OperationsEntry 13 }
-- VRRP Associated Address Table
vrrpv3AssociatedIpAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF Vrrpv3AssociatedIpAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of addresses associated with each virtual
router."
::= { vrrpv3Operations 2 }
vrrpv3AssociatedIpAddrEntry OBJECT-TYPE
SYNTAX Vrrpv3AssociatedIpAddrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table contains an IP address that is
associated with a virtual router. The number of rows
for a given IP version, VrID, and ifIndex will equal
the number of IP addresses associated (e.g., backed up)
by the virtual router (equivalent to
'vrrpv3OperationsIpAddrCount').
Rows in the table cannot be modified unless the value
of 'vrrpv3OperationsStatus' for the corresponding entry
in the vrrpv3OperationsTable has transitioned to
initialize(1).
The information in this table is persistent and when
written the entity SHOULD save the change to non-
volatile storage."
INDEX { ifIndex, vrrpv3OperationsVrId,
vrrpv3OperationsInetAddrType,
vrrpv3AssociatedIpAddrAddress }
::= { vrrpv3AssociatedIpAddrTable 1 }
Vrrpv3AssociatedIpAddrEntry ::=
SEQUENCE {
vrrpv3AssociatedIpAddrAddress
InetAddress,
vrrpv3AssociatedIpAddrRowStatus
RowStatus
}
vrrpv3AssociatedIpAddrAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (0|4|16))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The assigned IP addresses that a virtual router is
responsible for backing up.
The IP address type is determined by the value of
vrrpv3OperationsInetAddrType in the index of this
row."
REFERENCE "RFC 5798"
::= { vrrpv3AssociatedIpAddrEntry 1 }
vrrpv3AssociatedIpAddrRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to
installation and removal conventions for conceptual
rows. To create a row in this table, a manager sets
this object to either createAndGo(4) or
createAndWait(5). Setting this object to active(1)
results in the addition of an associated address for a
virtual router. Setting this object to notInService(2)
results in administratively bringing down the row.
Destroying the entry or setting it to destroy(6)
removes the associated address from the virtual router.
The use of other values is implementation-dependent.
Implementations should not allow deletion of the last
row corresponding to an active row in
vrrpv3OperationsTable.
Refer to the description of vrrpv3OperationsRowStatus
for typical row creation and deletion scenarios."
::= { vrrpv3AssociatedIpAddrEntry 2 }
-- VRRP Router StatisticsOkay so we're picking up right in the middle of the MIB stats, and bestie, these counters are literally the vibe check for a VRRP router 📊💅 Every counter below tells you how many packets were weird in some way: bad checksum, wrong version, invalid VRID, and so on. You can track the trouble 🕵️♀️
The router-wide counters come first, and they're all Counter64s with a vrrpv3GlobalStatisticsDiscontinuityTime that tells you when they last reset 🌸
vrrpv3RouterChecksumErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets received with an
invalid VRRP checksum value.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3GlobalStatisticsDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.2.8"
::= { vrrpv3Statistics 1 }
vrrpv3RouterVersionErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets received with an
unknown or unsupported version number.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3GlobalStatisticsDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.2.1"
::= { vrrpv3Statistics 2 }
vrrpv3RouterVrIdErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets received with a
VRID that is not valid for any virtual router on this
router.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3GlobalStatisticsDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.2.3"
::= { vrrpv3Statistics 3 }
vrrpv3GlobalStatisticsDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which one of vrrpv3RouterChecksumErrors,
vrrpv3RouterVersionErrors, and vrrpv3RouterVrIdErrors
suffered a discontinuity.
If no such discontinuities have occurred since the last
re-initialization of the local management subsystem,
then this object contains a zero value."
::= { vrrpv3Statistics 4 }Next up is the per-router statistics table, which is where the real tea is ☕🫖 Each entry is about one virtual router, so you get the full story for each one 🦋
-- VRRP Router Statistics Table
vrrpv3StatisticsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Vrrpv3StatisticsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Table of virtual router statistics."
::= { vrrpv3Statistics 5 }
vrrpv3StatisticsEntry OBJECT-TYPE
SYNTAX Vrrpv3StatisticsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the table containing statistics
information about a given virtual router."
AUGMENTS { vrrpv3OperationsEntry }
::= { vrrpv3StatisticsTable 1 }
Vrrpv3StatisticsEntry ::=
SEQUENCE {
vrrpv3StatisticsMasterTransitions
Counter32,
vrrpv3StatisticsNewMasterReason
INTEGER,
vrrpv3StatisticsRcvdAdvertisements
Counter64,
vrrpv3StatisticsAdvIntervalErrors
Counter64,
vrrpv3StatisticsIpTtlErrors
Counter64,
vrrpv3StatisticsProtoErrReason
INTEGER,
vrrpv3StatisticsRcvdPriZeroPackets
Counter64,
vrrpv3StatisticsSentPriZeroPackets
Counter64,
vrrpv3StatisticsRcvdInvalidTypePackets
Counter64,
vrrpv3StatisticsAddressListErrors
Counter64,
vrrpv3StatisticsPacketLengthErrors
Counter64,
vrrpv3StatisticsRowDiscontinuityTime
TimeStamp,
vrrpv3StatisticsRefreshRate
Unsigned32
}
vrrpv3StatisticsMasterTransitions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of times that this virtual router's
state has transitioned to master state.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 1 }
vrrpv3StatisticsNewMasterReason OBJECT-TYPE
SYNTAX INTEGER {
notMaster (0),
priority (1),
preempted (2),
masterNoResponse (3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the reason for the virtual router to
transition to master state. If the virtual router
never transitioned to master state, the value of this
object is notMaster(0). Otherwise, this indicates the
reason this virtual router transitioned to master
state the last time. Used by vrrpv3NewMaster
notification."
::= { vrrpv3StatisticsEntry 2 }
vrrpv3StatisticsRcvdAdvertisements OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP advertisements received by
this virtual router.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 3 }
vrrpv3StatisticsAdvIntervalErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP advertisement packets
received for which the advertisement interval is
different from the vrrpv3OperationsAdvInterval
configured on this virtual router.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 4 }
vrrpv3StatisticsIpTtlErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets received by the
virtual router with IPv4 TTL (for VRRP over IPv4) or
IPv6 Hop Limit (for VRRP over IPv6) not equal to 255.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.1.1.3"
::= { vrrpv3StatisticsEntry 5 }
vrrpv3StatisticsProtoErrReason OBJECT-TYPE
SYNTAX INTEGER {
noError (0),
ipTtlError (1),
versionError (2),
checksumError (3),
vrIdError(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This indicates the reason for the last protocol
error. This SHOULD be set to noError(0) when no
protocol errors are encountered. Used by
vrrpv3ProtoError notification."
::= { vrrpv3StatisticsEntry 6 }
vrrpv3StatisticsRcvdPriZeroPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets received by the
virtual router with a priority of '0'.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.2.4"
::= { vrrpv3StatisticsEntry 7 }
vrrpv3StatisticsSentPriZeroPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of VRRP packets sent by the virtual
router with a priority of '0'.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
REFERENCE "RFC 5798, Section 5.2.4"
::= { vrrpv3StatisticsEntry 8 }
vrrpv3StatisticsRcvdInvalidTypePackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of VRRP packets received by the virtual
router with an invalid value in the 'type' field.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 9 }
vrrpv3StatisticsAddressListErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received for which the
address list does not match the locally configured
list for the virtual router.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 10 }
vrrpv3StatisticsPacketLengthErrors OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets received with a packet
length less than the length of the VRRP header.
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by the value of
vrrpv3StatisticsRowDiscontinuityTime."
::= { vrrpv3StatisticsEntry 11 }
vrrpv3StatisticsRowDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which any one or more of this entry's counters
suffered a discontinuity.We're not done yet, bestie 🫶 The rest of the MIB is coming in the next part 🧚✨
If no such discontinuities have occurred since the last
re-initialization of the local management subsystem,
then this object contains a zero value."
::= { vrrpv3StatisticsEntry 12 }
vrrpv3StatisticsRefreshRate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum reasonable polling interval for this entry.
This object provides an indication of the minimum
amount of time required to update the counters in this
entry."
::= { vrrpv3StatisticsEntry 13 }okay so the refresh rate object is giving "how often should I poll this thing without being annoying" energy 📊✨
-- Notification Definitions
-- Notifications may be controlled using SNMP-NOTIFICATION-MIB
vrrpv3NewMaster NOTIFICATION-TYPE
OBJECTS {
vrrpv3OperationsMasterIpAddr,
vrrpv3StatisticsNewMasterReason
}
STATUS current
DESCRIPTION
"The newMaster notification indicates that the sending
agent has transitioned to master state."
::= { vrrpv3Notifications 1 }
vrrpv3ProtoError NOTIFICATION-TYPE
OBJECTS {
vrrpv3StatisticsProtoErrReason
}
STATUS current
DESCRIPTION
"The notification indicates that the sending agent has
encountered the protocol error indicated by
vrrpv3StatisticsProtoErrReason."
::= { vrrpv3Notifications 2 }Now the notifications 🔔 newMaster is the "I'm the boss now" moment and protoError is the "something went wrong bestie" alert 💀
-- Conformance Information
vrrpv3Compliances OBJECT IDENTIFIER ::= { vrrpv3Conformance 1 }
vrrpv3Groups OBJECT IDENTIFIER ::= { vrrpv3Conformance 2 }
-- Compliance Statements
vrrpv3FullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement"
MODULE -- this module
MANDATORY-GROUPS {
vrrpv3OperationsGroup,
vrrpv3StatisticsGroup,
vrrpv3InfoGroup,
vrrpv3NotificationsGroup
}
OBJECT vrrpv3OperationsPriority
WRITE-SYNTAX Unsigned32 (1..254)
DESCRIPTION "Setable values are from 1 to 254."
::= { vrrpv3Compliances 1 }
vrrpv3ReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB module is implemented without support
for read-create (i.e., in read-only mode), then such
an implementation can claim read-only compliance.
Such a device can then be monitored, but cannot be
configured with this MIB."
MODULE -- this module
MANDATORY-GROUPS {
vrrpv3OperationsGroup,
vrrpv3StatisticsGroup,
vrrpv3StatisticsDiscontinuityGroup,
vrrpv3InfoGroup,
vrrpv3NotificationsGroup
}
OBJECT vrrpv3OperationsPriority
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3OperationsPrimaryIpAddr
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3OperationsAdvInterval
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3OperationsPreemptMode
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3OperationsAcceptMode
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3OperationsRowStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT vrrpv3AssociatedIpAddrRowStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { vrrpv3Compliances 2 }Compliance time 💅 there's a full one and a read-only one, so even a device that can only be watched and not touched can still be compliant 👀
-- Conformance Groups
vrrpv3OperationsGroup OBJECT-GROUP
OBJECTS {
vrrpv3OperationsVirtualMacAddr,
vrrpv3OperationsStatus,
vrrpv3OperationsPriority,
vrrpv3OperationsMasterIpAddr,
vrrpv3OperationsAdvInterval,
vrrpv3OperationsPreemptMode,
vrrpv3OperationsAcceptMode,
vrrpv3OperationsUpTime,
vrrpv3OperationsRowStatus,
vrrpv3OperationsAddrCount,
vrrpv3OperationsPrimaryIpAddr,
vrrpv3AssociatedIpAddrRowStatus
}
STATUS current
DESCRIPTION
"Conformance group for VRRPv3 operations."
::= { vrrpv3Groups 1 }
vrrpv3StatisticsGroup OBJECT-GROUP
OBJECTS {
vrrpv3RouterChecksumErrors,
vrrpv3RouterVersionErrors,
vrrpv3RouterVrIdErrors,
vrrpv3StatisticsMasterTransitions,
vrrpv3StatisticsNewMasterReason,
vrrpv3StatisticsRcvdAdvertisements,
vrrpv3StatisticsAdvIntervalErrors,
vrrpv3StatisticsRcvdPriZeroPackets,
vrrpv3StatisticsSentPriZeroPackets,
vrrpv3StatisticsRcvdInvalidTypePackets,
vrrpv3StatisticsIpTtlErrors,
vrrpv3StatisticsProtoErrReason,
vrrpv3StatisticsAddressListErrors,
vrrpv3StatisticsPacketLengthErrors,
vrrpv3StatisticsRowDiscontinuityTime,
vrrpv3StatisticsRefreshRate
}
STATUS current
DESCRIPTION
"Conformance group for VRRPv3 statistics."
::= { vrrpv3Groups 2 }
vrrpv3StatisticsDiscontinuityGroup OBJECT-GROUP
OBJECTS {
vrrpv3GlobalStatisticsDiscontinuityTime
}
STATUS current
DESCRIPTION
"Objects providing information about counter
discontinuities."
::= { vrrpv3Groups 3 }
vrrpv3InfoGroup OBJECT-GROUP
OBJECTS {
vrrpv3StatisticsProtoErrReason,
vrrpv3StatisticsNewMasterReason
}
STATUS current
DESCRIPTION
"Conformance group for objects contained in VRRPv3
notifications."
::= { vrrpv3Groups 4 }
vrrpv3NotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
vrrpv3NewMaster,
vrrpv3ProtoError
}
STATUS current
DESCRIPTION
"The VRRP MIB Notification Group."
::= { vrrpv3Groups 5 }
END11. Security Considerations 🔐
Okay bestie, this part is serious 😭 A bunch of the objects in this MIB module have a MAX-ACCESS of read-write and/or read-create. Those objects could be seen as sensitive or vulnerable depending on the network. Doing SET operations in a non-secure environment without proper protection can seriously mess with network operations, so be careful 🚨
The objects vrrpv3OperationsPriority, vrrpv3OperationsPrimaryIpAddr, vrrpv3OperationsAdvInterval, vrrpv3OperationsPreemptMode, vrrpv3OperationsAcceptMode, vrrpv3OperationsRowStatus, and vrrpv3AssociatedIpAddrRowStatus all have the read-create attribute. Messing with these can change how a virtual router operates 💀
Here's how that could go wrong:
- An unauthorized change to vrrpv3OperationsPriority can change the priority used in master election. That could make this router become master when it shouldn't, or let some other router win based on preference. It'll wreck the operator's plans, but it only copies the unfortunate failure of multiple routers, and any router that does become master can still do the job 🙄
- Changing vrrpv3OperationsPrimaryIpAddr would make the configured router take on an incorrect IP address if it becomes master. That could be really disruptive to the network 😱
- A malicious change to vrrpv3OperationsAdvInterval could make the configured router flood the network with advertisements when it becomes master. Or the new master might not advertise often enough, so some routers never learn about it 📡
- vrrpv3OperationsPreemptMode controls whether this router will preempt another master router. Setting it the wrong way could, at worst, make one router master against the operator's plans. That router would still be qualified to operate as a master, though 🧚
- Setting vrrpv3OperationsAcceptMode could stop an IPv6-capable VRRP router from accepting packets addressed to the address owner's IPv6 address as its own, even when it isn't the IPv6 address owner. The default for this object is false(2), but an unauthorized change to false could restrict parts of the network 🚫
- The vrrpv3OperationsRowStatus object could be used to disable a virtual router. Other columns could also disrupt operations if they changed, but they can't be changed without changing the RowStatus object first 🔥
SNMP versions before SNMPv3 didn't include adequate security. Even if the network itself is secure (for example by using IPsec), nobody controls who on that secure network gets to access and GET/SET (read/change/create/delete) the objects in this MIB module 🥺
Implementations MUST provide the security features described by the SNMPv3 framework (see [RFC3410]), including 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, deploying 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/operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is properly configured, so that only principals (users) with legitimate rights can GET or SET (change/create/delete) those objects 👑
12. IANA Considerations 🦋
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
vrrpv3MIB { mib-2 207 vrrpv3MIB VRRPV3-MIB }This document obsoletes RFC 2787. Therefore, IANA has deprecated value 68 under 'mib-2', which is assigned to VRRP-MIB 🌸
13. Normative References ✨
okay so these are the normative references, the docs this one leans on hard. no cap, you need them to actually read this spec 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
- [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
14. Informative References 🦋
these ones are the bonus reading. helpful, but the spec doesn't need them to make sense 🌸
- [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, "Virtual Router Redundancy Protocol", RFC 2338, April 1998.
- [RFC2787] Jewell, B. and D. Chuang, "Definitions of Managed Objects for the Virtual Router Redundancy Protocol", RFC 2787, March 2000.
- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
- [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, December 2002.
- [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004.
- [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
- [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
- [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011.
15. Acknowledgments 🫶
the squad that helped make this spec happen 💜 Kripakaran Karlekar and Brain Jewell helped with the design and the early drafts. this spec is based on RFC 2787, which was written by Brian Jewell and David Chuang. the author also wants to thank Bert Wijnen, Dave Thaler, Joan Cucchiara, Mukesh Gupta, Steve Bates, Adrian Farrel, Ben Campbell and Joel M. Halpern for taking the time to review the document and give such valuable guidance ✨
Author's Address 💌
Srinivas Kalyan Tata
Nokia
313 Fairchild Dr.
Mountain View, CA 94043
EMail: Tata_kalyan@yahoo.com📦 where this page comes from
- ietf: rfc6527 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms