RFC 1269
Definitions of Managed Objects for the Border Gateway Protocol: Version 3
RFC 1269 💖 Definitions of Managed Objects for the Border Gateway Protocol (Version 3)
okay bestie, the title block first 🎀 this one is from the Network Working Group, written by S. Willis and J. Burruss at Wellfleet Communications Inc., dated October 1991 🦋
its category is an IAB standards track protocol (we'll get to the status stuff in a sec). it doesn't list anything it obsoletes or updates in the header, so there's nothing to chase there ✨
Status of this Memo 📜
this memo is an extension to the SNMP MIB 🧚 it specifies an IAB standards track protocol for the Internet community and asks for discussion and suggestions for improvements 💅 for the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 🌈 and distribution of this memo is unlimited 💜
1. Abstract ✨
this memo defines a chunk of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets 🌸 specifically, it defines objects for managing the Border Gateway Protocol [11,12] 🔥
2. The Network Management Framework 👑
the Internet-standard Network Management Framework has three components, and it's giving full ecosystem 🫶
- RFC 1155 defines the SMI, the mechanisms used for describing and naming objects for management purposes. RFC 1212 defines a more concise description mechanism that's totally consistent with the SMI 💖
- RFC 1156 defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, which is basically MIB-I glowing up based on implementation experience and new operational requirements 🌈
- RFC 1157 defines SNMP, the protocol used for network access to managed objects 🦋
the Framework lets new objects get defined for experimentation and evaluation 🧚
3. Objects 🎀
managed objects get accessed through a virtual information store called the Management Information Base, or MIB 💜 objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] that the SMI defines 🔥 every object has a name, a syntax, and an encoding ✨ the name is an object identifier, an administratively assigned name that specifies an object type 💅 the object type plus an object instance uniquely identifies one specific instantiation of the object 🌸 for human convenience we often use a text string, called the OBJECT DESCRIPTOR, to refer to the object type too 🫶
the syntax of an object type defines the abstract data structure for that type, and ASN.1 is the language used for this 💖 the SMI [3] purposely restricts which ASN.1 constructs can be used, and that's explicitly for simplicity 🙈
the encoding of an object type is simply how that type gets represented using its syntax 🦋 it's implicitly tied to the syntax and encoding, too, meaning how the object type is represented when it's sent over the network 🌈
the SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the extra requirements imposed by SNMP 👑
3.1. Format of Definitions 🧚
Section 5 holds the specification of every object type in this MIB module 💜 the object types are defined using the conventions in the SMI, as amended by the extensions specified in [9,10] ✨
4. Overview 🌸
these objects control and manage a BGP [11,12] implementation 💅
BGP (the Border Gateway Protocol) is an inter-Autonomous System routing protocol 🔥 the main job of a BGP speaking system is to swap network reachability information with other BGP systems 🫶 that info includes the full path of Autonomous Systems that traffic has to transit to reach those networks 🦋
BGP runs over a reliable transport protocol, so it doesn't need to implement its own explicit update fragmentation, retransmission, acknowledgement, or sequencing 🎀 any authentication scheme the transport protocol uses can be used on top of BGP's own authentication mechanisms too 🔐 ngl that's lowkey so convenient 💖
the planned use of BGP on the Internet, covering topology, how BGP and IGPs interact, and enforcing routing policy rules, is laid out in a companion document [12] 🌈
apart from a few system variables, this MIB is split into two tables 🧚
- BGP Peer Table: info about BGP peer connections, like their state and current activity 💜
- BGP Received Path Attribute Table: all attributes received from all peers before local routing policy gets applied 👑 the attributes actually used to determine a route are a subset of this table ✨
5. Definitions 💅
the whole MIB module lives in this block, so here it is in all its glory 🌈
RFC1269-MIB DEFINITIONS ::= BEGIN
IMPORTS
NetworkAddress, IpAddress, Counter
FROM RFC1155-SMI
mib-2
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212
TRAP-TYPE
FROM RFC-1215;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9], and the TRAP-TYPE macro as defined
-- in [10].
bgp OBJECT IDENTIFIER ::= { mib-2 15 }
bgpVersion OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Vector of supported BGP protocol version
numbers. Each peer negotiates the version from
this vector. Versions are identified via the
string of bits contained within this object.
The first octet contains bits 0 to 7, the
second octet contains bits 8 to 15, and so on,
with the most significant bit referring to the
lowest bit number in the octet (e.g., the MSB
of the first octet refers to bit 0). If a bit,
i, is present and set, then the version (i+1)
of the BGP is supported."
::= { bgp 1 }
bgpLocalAs OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local autonomous system number."
::= { bgp 2 }
bgpPeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF BgpPeerEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The bgp peer table."
::= { bgp 3 }
bgpIdentifier OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The BGP Identifier of local system."
::= { bgp 4 }
bgpPeerEntry OBJECT-TYPE
SYNTAX BgpPeerEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a BGP peer connection."
INDEX
{ bgpPeerRemoteAddr }
::= { bgpPeerTable 1 }
BgpPeerEntry ::= SEQUENCE {
bgpPeerIdentifier
IpAddress,
bgpPeerState
INTEGER,
bgpPeerAdminStatus
INTEGER,
bgpPeerNegotiatedVersion
INTEGER,
bgpPeerLocalAddr
IpAddress,
bgpPeerLocalPort
INTEGER,
bgpPeerRemoteAddr
IpAddress,
bgpPeerRemotePort
INTEGER,
bgpPeerRemoteAs
INTEGER,
bgpPeerInUpdates
Counter,
bgpPeerOutUpdates
Counter,
bgpPeerInTotalMessages
Counter,
bgpPeerOutTotalMessages
Counter,
bgpPeerLastError
OCTET STRING
}
bgpPeerIdentifier OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The BGP Identifier of this entry's BGP peer."
::= { bgpPeerEntry 1 }
bgpPeerState OBJECT-TYPE
SYNTAX INTEGER {
idle(1),
connect(2),
active(3),
opensent(4),
openconfirm(5),
established(6)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The bgp peer connection state. "
::= { bgpPeerEntry 2 }
bgpPeerAdminStatus OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The desired state of the BGP connection. A
transition from 'stop' to 'start' will cause
the BGP Start Event to be generated. A
transition from 'start' to 'stop' will cause
the BGP Stop Event to be generated. This
parameter can be used to restart BGP peer
connections. Care should be used in providing
write access to this object without adequate
authentication."
::= { bgpPeerEntry 3 }
bgpPeerNegotiatedVersion OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The negotiated version of BGP running between
the two peers. "
::= { bgpPeerEntry 4 }
bgpPeerLocalAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local IP address of this entry's BGP
connection."
::= { bgpPeerEntry 5 }
bgpPeerLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local port for the TCP connection between
the BGP peers."
::= { bgpPeerEntry 6 }
bgpPeerRemoteAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote IP address of this entry's BGP
peer."
::= { bgpPeerEntry 7 }to be continued... 🦋🎀
bgpPeerRemotePort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote port for the TCP connection between
the BGP peers. Note that the objects
bgpLocalAddr, bgpLocalPort, bgpRemoteAddr and
bgpRemotePort provide the appropriate reference
to the standard MIB TCP connection table."
::= { bgpPeerEntry 8 }
bgpPeerRemoteAs OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote autonomous system number."
::= { bgpPeerEntry 9 }
bgpPeerInUpdates OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of BGP UPDATE messages received on
this connection. This object should be
initialized to zero when the connection is
established."
::= { bgpPeerEntry 10 }
bgpPeerOutUpdates OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of BGP UPDATE messages received on
this connection. This object should be
initialized to zero when the connection is
established."
::= { bgpPeerEntry 11}
bgpPeerInTotalMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of messages received from the
remote peer on this connection. This object
should be initialized to zero when the
connection is established."
::= { bgpPeerEntry 12 }
bgpPeerOutTotalMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of messages transmitted to
the remote peer on this connection. This object
should be initialized to zero when the
connection is established."
::= { bgpPeerEntry 13 }
bgpPeerLastError OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (2))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The last error code and subcode seen by this
peer on this connection. If no error has
occurred, this field is zero. Otherwise, the
first byte of this two byte OCTET STRING
contains the error code; the second contains
the subcode."
::= { bgpPeerEntry 14 }okay so these last few are all about the counters and error info for each peer connection 📊✨ bgpPeerRemotePort is the far end's TCP port, and it's literally giving "go check the TCP table, bestie" because the local and remote address and port objects are your map back to it 🗺️ bgpPeerRemoteAs is the remote AS number, very simple, very iconic 💅 the message counters (bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages, bgpPeerOutTotalMessages) all start at zero when the connection gets established, and they're read-only 🎀 and bgpPeerLastError is a two-byte string where the first byte is the error code and the second is the subcode, with zero meaning no error has happened yet 🙈
bgpRcvdPathAttrTable OBJECT-TYPE
SYNTAX SEQUENCE OF BgpPathAttrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The BGP Received Path Attribute Table contains
information about paths to destination networks
received by all peers."
::= { bgp 5 }
bgpPathAttrEntry OBJECT-TYPE
SYNTAX BgpPathAttrEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a path to a network."
INDEX
{ bgpPathAttrDestNetwork,
bgpPathAttrPeer }
::= { bgpRcvdPathAttrTable 1 }
BgpPathAttrEntry ::= SEQUENCE {
bgpPathAttrPeer
IpAddress,
bgpPathAttrDestNetwork
IpAddress,
bgpPathAttrOrigin
INTEGER,
bgpPathAttrASPath
OCTET STRING,
bgpPathAttrNextHop
IpAddress,
bgpPathAttrInterASMetric
INTEGER
}
bgpPathAttrPeer OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The IP address of the peer where the path
information
was learned."
::= { bgpPathAttrEntry 1 }
bgpPathAttrDestNetwork OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The address of the destination network."
::= { bgpPathAttrEntry 2 }
bgpPathAttrOrigin OBJECT-TYPE
SYNTAX INTEGER {
igp(1),-- networks are interior
egp(2),-- networks learned via EGP
incomplete(3) -- undetermined
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ultimate origin of the path information."
::= { bgpPathAttrEntry 3 }
bgpPathAttrASPath OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The set of ASs that must be traversed to reach
the network. ( This object is probably best
represented as SEQUENCE OF INTEGER. For SMI
compatibility, though, it is represented as
OCTET STRING. Each AS is represented as a pair
of octets according to the following algorithm:
first-byte-of-pair = ASNumber / 256;
second-byte-of-pair = ASNumber & 255;"
::= { bgpPathAttrEntry 4 }
bgpPathAttrNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The address of the border router that should
be used for the destination network."
::= { bgpPathAttrEntry 5 }
bgpPathAttrInterASMetric OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The optional inter-AS metric. If this
attribute has not been provided for this route,
the value for this object is 0."
::= { bgpPathAttrEntry 6 }this part is the path attribute table 🛣️💖 every row is keyed by the peer's IP address and the destination network's address, so you can look up exactly what a peer told you about a route ✨ bgpPathAttrOrigin tells you if the route is interior (igp(1)), learned via EGP (egp(2)), or still undetermined (incomplete(3)) 🌸 the AS path is stored as an OCTET STRING even though it's probably better as a SEQUENCE OF INTEGER, because SMI compatibility, and each AS gets split into two bytes with the division and mask math shown 🧮 bgpPathAttrNextHop is the border router you should use, and if the optional inter-AS metric wasn't provided, that object is just 0 🦋
bgpEstablished TRAP-TYPE
ENTERPRISE { bgp }
VARIABLES { bgpPeerRemoteAddr,
bgpPeerLastError,
bgpPeerState }
DESCRIPTION
"The BGP Established event is generated when
the BGP FSM enters the ESTABLISHED state. "
::= 1
bgpBackwardTransition TRAP-TYPE
ENTERPRISE { bgp }
VARIABLES { bgpPeerRemoteAddr,
bgpPeerLastError,
bgpPeerState }
DESCRIPTION
"The BGPBackwardTransition Event is generated
when the BGP FSM moves from a higher numbered
state to a lower numbered state."
::= 2
ENDand the traps 🔔 bgpEstablished fires when the BGP FSM hits the ESTABLISHED state, and bgpBackwardTransition fires when the FSM drops from a higher numbered state to a lower one 📉 both of them carry the remote address, last error, and peer state as variables, so it's very easy to see what's going on 👑
6. Acknowledgements 🫶
okay so the working group gets a big shoutout 📣 we'd like to thank everyone in the Interconnectivity Working Group, and especially these legends:
- Yakov Rekhter, IBM
- Rob Coltun, University of Maryland
- Guy Almes, Rice University
- Jeff Honig, Cornell Theory Center
- Marshall T. Rose, PSI, Inc.
- Dennis Ferguson, University of Toronto
- Mike Mathis, PSC
7. References 📚
- [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988.
- [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989.
- [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
- [4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990.
- [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
- [6] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, Performance Systems International, March 1991.
- [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.
- [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987.
- [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.
- [10] Rose, M., Editor, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991.
- [11] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.
- [12] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1268, T.J. Watson Research Center, IBM Corp., ANS, October 1991.
8. Security Considerations 🔐
Security issues are not discussed in this memo. 🚨 bestie, I'm being super serious here, this RFC does not cover security at all, so please don't assume it's been handled just because the MIB looks so clean and iconic 💀
Authors' Addresses 💌
Steven Willis
Wellfleet Communications Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: swillis@wellfleet.com
John Burruss
Wellfleet Communications Inc.
15 Crosby Drive
Bedford, MA 01730
Phone: (617) 275-2400
Email: jburruss@wellfleet.com📦 where this page comes from
- ietf: rfc1269 1991-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms