summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4273.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4273.txt')
-rw-r--r--doc/rfc/rfc4273.txt1795
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc4273.txt b/doc/rfc/rfc4273.txt
new file mode 100644
index 0000000..3d24b46
--- /dev/null
+++ b/doc/rfc/rfc4273.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group J. Haas, Ed.
+Request for Comments: 4273 S. Hares, Ed.
+Obsoletes: 1269, 1657 NextHop Technologies
+Category: Standards Track January 2006
+
+
+ Definitions of Managed Objects for BGP-4
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community
+ In particular, it describes managed objects used for managing the
+ Border Gateway Protocol Version 4 or lower.
+
+ The origin of this memo is from RFC 1269 "Definitions of Managed
+ Objects for the Border Gateway Protocol (Version 3)", which was
+ updated to support BGP-4 in RFC 1657. This memo fixes errors
+ introduced when the MIB module was converted to use the SMIv2
+ language. This memo also updates references to the current SNMP
+ framework documents.
+
+ This memo is intended to document deployed implementations of this
+ MIB module in a historical context, to provide clarifications of some
+ items, and to note errors where the MIB module fails to fully
+ represent the BGP protocol. Work is currently in progress to replace
+ this MIB module with a new one representing the current state of the
+ BGP protocol and its extensions.
+
+ This document obsoletes RFC 1269 and RFC 1657.
+
+
+
+
+
+
+
+
+
+Haas & Hares Standards Track [Page 1]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. The Internet-Standard Management Framework ......................2
+ 3. Overview ........................................................2
+ 4. Definitions .....................................................3
+ 5. Security Considerations ........................................28
+ 6. Acknowledgements ...............................................30
+ 7. Normative References ...........................................31
+
+1. Introduction
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ In particular, it describes managed objects used for managing the
+ Border Gateway Protocol Version 4 or lower [BGP4, BGP4APP].
+
+ This memo obsoletes RFC 1657 and RFC 1269.
+
+2. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ 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 defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+3. Overview
+
+ These objects are used to control and manage a BGP-4 implementation.
+
+ Apart from a few system-wide scalar objects, this MIB is broken into
+ three tables: the BGP Peer Table, the BGP Received Path Attribute
+ Table, and the BGP-4 Received Path Attribute Table. The BGP Peer
+ Table contains information about state and current activity of
+ connections with the BGP peers. The BGP Received Path Attribute
+ Table contains path attributes received from all peers running BGP
+ version 3 or less. The BGP-4 Received Path Attribute Table contains
+ path attributes received from all BGP-4 peers. The actual attributes
+ used in determining a route are a subset of the received attribute
+ tables after local routing policy has been applied.
+
+
+
+Haas & Hares Standards Track [Page 2]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+4. Definitions
+
+ BGP4-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+ IpAddress, Integer32, Counter32, Gauge32, mib-2
+ FROM SNMPv2-SMI
+ MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
+ FROM SNMPv2-CONF;
+
+ bgp MODULE-IDENTITY
+ LAST-UPDATED "200601110000Z"
+ ORGANIZATION "IETF IDR Working Group"
+ CONTACT-INFO "E-mail: idr@ietf.org
+
+ Jeffrey Haas, Susan Hares (Editors)
+ NextHop Technologies
+ 825 Victors Way
+ Suite 100
+ Ann Arbor, MI 48108-2738
+ Tel: +1 734 222-1600
+ Fax: +1 734 222-1602
+ E-mail: jhaas@nexthop.com
+ skh@nexthop.com"
+
+ DESCRIPTION
+ "The MIB module for the BGP-4 protocol.
+
+ Copyright (C) The Internet Society (2006). This
+ version of this MIB module is part of RFC 4273;
+ see the RFC itself for full legal notices."
+
+ REVISION "200601110000Z"
+ DESCRIPTION
+ "Changes from RFC 1657:
+
+ 1) Fixed the definitions of the notifications
+ to make them equivalent to their initial
+ definition in RFC 1269.
+ 2) Added compliance and conformance info.
+ 3) Updated information for the values of
+ bgpPeerNegotiatedVersion, bgp4PathAttrLocalPref,
+ bgp4PathAttrCalcLocalPref,
+ bgp4PathAttrMultiExitDisc,
+ bgp4PathAttrASPathSegement.
+ 4) Added additional clarification comments where
+ needed.
+
+
+
+Haas & Hares Standards Track [Page 3]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ 5) Noted where objects do not fully reflect
+ the protocol as Known Issues.
+ 6) Updated the DESCRIPTION for the
+ bgp4PathAttrAtomicAggregate object.
+ 7) The following objects have had their DESCRIPTION
+ clause modified to remove the text that suggested
+ (using 'should' verb) initializing the counter
+ to zero on a transition to the established state:
+ bgpPeerInUpdates, bgpPeerOutUpdates,
+ bgpPeerInTotalMessages, bgpPeerOutTotalMessages
+ Those implementations that still do this are
+ still compliant with this new wording.
+ Applications should not assume counters have
+ started at zero.
+
+ Published as RFC 4273."
+
+ REVISION "199405050000Z"
+ DESCRIPTION
+ "Translated to SMIv2 and published as RFC 1657."
+
+ REVISION "199110261839Z"
+ DESCRIPTION
+ "Initial version, published as RFC 1269."
+ ::= { mib-2 15 }
+
+ bgpVersion OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (1..255))
+ MAX-ACCESS read-only
+ STATUS current
+ 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."
+ REFERENCE
+ "RFC 4271, Section 4.2."
+ ::= { bgp 1 }
+
+ bgpLocalAs OBJECT-TYPE
+
+
+
+Haas & Hares Standards Track [Page 4]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The local autonomous system number."
+ REFERENCE
+ "RFC 4271, Section 4.2, 'My Autonomous System'."
+ ::= { bgp 2 }
+
+ -- BGP Peer table. This table contains, one entry per
+ -- BGP peer, information about the BGP peer.
+
+ bgpPeerTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF BgpPeerEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "BGP peer table. This table contains,
+ one entry per BGP peer, information about the
+ connections with BGP peers."
+ ::= { bgp 3 }
+
+ bgpPeerEntry OBJECT-TYPE
+ SYNTAX BgpPeerEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Entry containing information about the
+ connection with a BGP peer."
+ INDEX { bgpPeerRemoteAddr }
+ ::= { bgpPeerTable 1 }
+
+ BgpPeerEntry ::= SEQUENCE {
+ bgpPeerIdentifier
+ IpAddress,
+ bgpPeerState
+ INTEGER,
+ bgpPeerAdminStatus
+ INTEGER,
+ bgpPeerNegotiatedVersion
+ Integer32,
+ bgpPeerLocalAddr
+ IpAddress,
+ bgpPeerLocalPort
+ Integer32,
+ bgpPeerRemoteAddr
+ IpAddress,
+ bgpPeerRemotePort
+
+
+
+Haas & Hares Standards Track [Page 5]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ Integer32,
+ bgpPeerRemoteAs
+ Integer32,
+ bgpPeerInUpdates
+ Counter32,
+ bgpPeerOutUpdates
+ Counter32,
+ bgpPeerInTotalMessages
+ Counter32,
+ bgpPeerOutTotalMessages
+ Counter32,
+ bgpPeerLastError
+ OCTET STRING,
+ bgpPeerFsmEstablishedTransitions
+ Counter32,
+ bgpPeerFsmEstablishedTime
+ Gauge32,
+ bgpPeerConnectRetryInterval
+ Integer32,
+ bgpPeerHoldTime
+ Integer32,
+ bgpPeerKeepAlive
+ Integer32,
+ bgpPeerHoldTimeConfigured
+ Integer32,
+ bgpPeerKeepAliveConfigured
+ Integer32,
+ bgpPeerMinASOriginationInterval
+ Integer32,
+ bgpPeerMinRouteAdvertisementInterval
+ Integer32,
+ bgpPeerInUpdateElapsedTime
+ Gauge32
+ }
+
+ bgpPeerIdentifier OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The BGP Identifier of this entry's BGP peer.
+ This entry MUST be 0.0.0.0 unless the
+ bgpPeerState is in the openconfirm or the
+ established state."
+ REFERENCE
+ "RFC 4271, Section 4.2, 'BGP Identifier'."
+ ::= { bgpPeerEntry 1 }
+
+
+
+
+Haas & Hares Standards Track [Page 6]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ bgpPeerState OBJECT-TYPE
+ SYNTAX INTEGER {
+ idle(1),
+ connect(2),
+ active(3),
+ opensent(4),
+ openconfirm(5),
+ established(6)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The BGP peer connection state."
+ REFERENCE
+ "RFC 4271, Section 8.2.2."
+ ::= { bgpPeerEntry 2 }
+
+ bgpPeerAdminStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ stop(1),
+ start(2)
+ }
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "The desired state of the BGP connection.
+ A transition from 'stop' to 'start' will cause
+ the BGP Manual Start Event to be generated.
+ A transition from 'start' to 'stop' will cause
+ the BGP Manual 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."
+ REFERENCE
+ "RFC 4271, Section 8.1.2."
+ ::= { bgpPeerEntry 3 }
+
+ bgpPeerNegotiatedVersion OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The negotiated version of BGP running between
+ the two peers.
+
+ This entry MUST be zero (0) unless the
+ bgpPeerState is in the openconfirm or the
+
+
+
+Haas & Hares Standards Track [Page 7]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ established state.
+
+ Note that legal values for this object are
+ between 0 and 255."
+ REFERENCE
+ "RFC 4271, Section 4.2.
+ RFC 4271, Section 7."
+ ::= { bgpPeerEntry 4 }
+
+ bgpPeerLocalAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The local IP address of this entry's BGP
+ connection."
+ ::= { bgpPeerEntry 5 }
+
+ bgpPeerLocalPort OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The local port for the TCP connection between
+ the BGP peers."
+ ::= { bgpPeerEntry 6 }
+
+ bgpPeerRemoteAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The remote IP address of this entry's BGP
+ peer."
+ ::= { bgpPeerEntry 7 }
+
+ bgpPeerRemotePort OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The remote port for the TCP connection
+ between the BGP peers. Note that the
+ objects bgpPeerLocalAddr,
+ bgpPeerLocalPort, bgpPeerRemoteAddr, and
+ bgpPeerRemotePort provide the appropriate
+ reference to the standard MIB TCP
+ connection table."
+
+
+
+Haas & Hares Standards Track [Page 8]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ ::= { bgpPeerEntry 8 }
+
+ bgpPeerRemoteAs OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The remote autonomous system number received in
+ the BGP OPEN message."
+ REFERENCE
+ "RFC 4271, Section 4.2."
+ ::= { bgpPeerEntry 9 }
+
+ bgpPeerInUpdates OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of BGP UPDATE messages
+ received on this connection."
+ REFERENCE
+ "RFC 4271, Section 4.3."
+ ::= { bgpPeerEntry 10 }
+
+ bgpPeerOutUpdates OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of BGP UPDATE messages
+ transmitted on this connection."
+ REFERENCE
+ "RFC 4271, Section 4.3."
+ ::= { bgpPeerEntry 11 }
+
+ bgpPeerInTotalMessages OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of messages received
+ from the remote peer on this connection."
+ REFERENCE
+ "RFC 4271, Section 4."
+ ::= { bgpPeerEntry 12 }
+
+ bgpPeerOutTotalMessages OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Haas & Hares Standards Track [Page 9]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of messages transmitted to
+ the remote peer on this connection."
+ REFERENCE
+ "RFC 4271, Section 4."
+ ::= { bgpPeerEntry 13 }
+
+ bgpPeerLastError OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (2))
+ MAX-ACCESS read-only
+ STATUS current
+ 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, and the second byte
+ contains the subcode."
+ REFERENCE
+ "RFC 4271, Section 4.5."
+ ::= { bgpPeerEntry 14 }
+
+ bgpPeerFsmEstablishedTransitions OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The total number of times the BGP FSM
+ transitioned into the established state
+ for this peer."
+ REFERENCE
+ "RFC 4271, Section 8."
+ ::= { bgpPeerEntry 15 }
+
+ bgpPeerFsmEstablishedTime OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This timer indicates how long (in
+ seconds) this peer has been in the
+ established state or how long
+ since this peer was last in the
+ established state. It is set to zero when
+ a new peer is configured or when the router is
+
+
+
+Haas & Hares Standards Track [Page 10]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ booted."
+ REFERENCE
+ "RFC 4271, Section 8."
+ ::= { bgpPeerEntry 16 }
+
+ bgpPeerConnectRetryInterval OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the
+ ConnectRetry timer. The suggested value
+ for this timer is 120 seconds."
+ REFERENCE
+ "RFC 4271, Section 8.2.2. This is the value used
+ to initialize the 'ConnectRetryTimer'."
+ ::= { bgpPeerEntry 17 }
+
+ bgpPeerHoldTime OBJECT-TYPE
+ SYNTAX Integer32 ( 0 | 3..65535 )
+ UNITS "seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the Hold
+ Timer established with the peer. The
+ value of this object is calculated by this
+ BGP speaker, using the smaller of the
+ values in bgpPeerHoldTimeConfigured and the
+ Hold Time received in the OPEN message.
+
+ This value must be at least three seconds
+ if it is not zero (0).
+
+ If the Hold Timer has not been established
+ with the peer this object MUST have a value
+ of zero (0).
+
+ If the bgpPeerHoldTimeConfigured object has
+ a value of (0), then this object MUST have a
+ value of (0)."
+ REFERENCE
+ "RFC 4271, Section 4.2."
+ ::= { bgpPeerEntry 18 }
+
+ bgpPeerKeepAlive OBJECT-TYPE
+ SYNTAX Integer32 ( 0 | 1..21845 )
+
+
+
+Haas & Hares Standards Track [Page 11]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ UNITS "seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the KeepAlive
+ timer established with the peer. The value
+ of this object is calculated by this BGP
+ speaker such that, when compared with
+ bgpPeerHoldTime, it has the same proportion
+ that bgpPeerKeepAliveConfigured has,
+ compared with bgpPeerHoldTimeConfigured.
+
+ If the KeepAlive timer has not been established
+ with the peer, this object MUST have a value
+ of zero (0).
+
+ If the of bgpPeerKeepAliveConfigured object
+ has a value of (0), then this object MUST have
+ a value of (0)."
+ REFERENCE
+ "RFC 4271, Section 4.4."
+ ::= { bgpPeerEntry 19 }
+
+ bgpPeerHoldTimeConfigured OBJECT-TYPE
+ SYNTAX Integer32 ( 0 | 3..65535 )
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the Hold Time
+ configured for this BGP speaker with this
+ peer. This value is placed in an OPEN
+ message sent to this peer by this BGP
+ speaker, and is compared with the Hold
+ Time field in an OPEN message received
+ from the peer when determining the Hold
+ Time (bgpPeerHoldTime) with the peer.
+ This value must not be less than three
+ seconds if it is not zero (0). If it is
+ zero (0), the Hold Time is NOT to be
+ established with the peer. The suggested
+ value for this timer is 90 seconds."
+ REFERENCE
+ "RFC 4271, Section 4.2.
+ RFC 4271, Section 10."
+ ::= { bgpPeerEntry 20 }
+
+ bgpPeerKeepAliveConfigured OBJECT-TYPE
+
+
+
+Haas & Hares Standards Track [Page 12]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ SYNTAX Integer32 ( 0 | 1..21845 )
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the
+ KeepAlive timer configured for this BGP
+ speaker with this peer. The value of this
+ object will only determine the
+ KEEPALIVE messages' frequency relative to
+ the value specified in
+ bgpPeerHoldTimeConfigured; the actual
+ time interval for the KEEPALIVE messages is
+ indicated by bgpPeerKeepAlive. A
+ reasonable maximum value for this timer
+ would be one third of that of
+ bgpPeerHoldTimeConfigured.
+ If the value of this object is zero (0),
+ no periodical KEEPALIVE messages are sent
+ to the peer after the BGP connection has
+ been established. The suggested value for
+ this timer is 30 seconds."
+ REFERENCE
+ "RFC 4271, Section 4.4.
+ RFC 4271, Section 10."
+ ::= { bgpPeerEntry 21 }
+
+ bgpPeerMinASOriginationInterval OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "Time interval (in seconds) for the
+ MinASOriginationInterval timer.
+ The suggested value for this timer is 15
+ seconds."
+ REFERENCE
+ "RFC 4271, Section 9.2.1.2.
+ RFC 4271, Section 10."
+ ::= { bgpPeerEntry 22 }
+
+ bgpPeerMinRouteAdvertisementInterval OBJECT-TYPE
+ SYNTAX Integer32 (1..65535)
+ UNITS "seconds"
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+
+
+
+Haas & Hares Standards Track [Page 13]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ "Time interval (in seconds) for the
+ MinRouteAdvertisementInterval timer.
+ The suggested value for this timer is 30
+ seconds for EBGP connections and 5
+ seconds for IBGP connections."
+ REFERENCE
+ "RFC 4271, Section 9.2.1.1.
+ RFC 4271, Section 10."
+ ::= { bgpPeerEntry 23 }
+
+ bgpPeerInUpdateElapsedTime OBJECT-TYPE
+ SYNTAX Gauge32
+ UNITS "seconds"
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Elapsed time (in seconds) since the last BGP
+ UPDATE message was received from the peer.
+ Each time bgpPeerInUpdates is incremented,
+ the value of this object is set to zero (0)."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 8.2.2, Established state."
+ ::= { bgpPeerEntry 24 }
+
+ bgpIdentifier OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The BGP Identifier of the local system."
+ REFERENCE
+ "RFC 4271, Section 4.2."
+ ::= { bgp 4 }
+
+ -- BGP Received Path Attribute Table. This table contains
+ -- one entry per path to a network, and path attributes
+ -- received from all peers running BGP version 3 or less.
+ -- This table is obsolete, having been replaced in
+ -- functionality by the bgp4PathAttrTable.
+
+ bgpRcvdPathAttrTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF BgpPathAttrEntry
+ MAX-ACCESS not-accessible
+ STATUS obsolete
+ DESCRIPTION
+ "The BGP Received Path Attribute Table
+ contains information about paths to
+
+
+
+Haas & Hares Standards Track [Page 14]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ destination networks, received from all
+ peers running BGP version 3 or less."
+ ::= { bgp 5 }
+
+ bgpPathAttrEntry OBJECT-TYPE
+ SYNTAX BgpPathAttrEntry
+ MAX-ACCESS not-accessible
+ STATUS obsolete
+ 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
+ Integer32
+ }
+
+ bgpPathAttrPeer OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The IP address of the peer where the path
+ information was learned."
+ ::= { bgpPathAttrEntry 1 }
+
+ bgpPathAttrDestNetwork OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The address of the destination network."
+ REFERENCE
+ "RFC 1267, Section 4.3."
+ ::= { bgpPathAttrEntry 2 }
+
+
+
+
+Haas & Hares Standards Track [Page 15]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ bgpPathAttrOrigin OBJECT-TYPE
+ SYNTAX INTEGER {
+ igp(1),-- networks are interior
+ egp(2),-- networks learned via the
+ -- EGP protocol
+ incomplete(3) -- networks that
+ -- are learned by some other
+ -- means
+ }
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The ultimate origin of the path information."
+ REFERENCE
+ "RFC 1267, Section 4.3.
+ RFC 1267, Section 5."
+ ::= { bgpPathAttrEntry 3 }
+
+ bgpPathAttrASPath OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (2..255))
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The set of ASes 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;"
+ REFERENCE
+ "RFC 1267, Section 4.3.
+ RFC 1267, Section 5."
+ ::= { bgpPathAttrEntry 4 }
+
+ bgpPathAttrNextHop OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The address of the border router that should
+ be used for the destination network."
+ REFERENCE
+ "RFC 1267, Section 4.3.
+ RFC 1267, Section 5."
+ ::= { bgpPathAttrEntry 5 }
+
+
+
+Haas & Hares Standards Track [Page 16]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ bgpPathAttrInterASMetric OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS obsolete
+ DESCRIPTION
+ "The optional inter-AS metric. If this
+ attribute has not been provided for this route,
+ the value for this object is 0."
+ REFERENCE
+ "RFC 1267, Section 4.3.
+ RFC 1267, Section 5."
+ ::= { bgpPathAttrEntry 6 }
+
+ -- BGP-4 Received Path Attribute Table. This table
+ -- contains one entry per path to a network, and path
+ -- attributes received from all peers running BGP-4.
+
+ bgp4PathAttrTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF Bgp4PathAttrEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The BGP-4 Received Path Attribute Table
+ contains information about paths to
+ destination networks, received from all
+ BGP4 peers."
+ ::= { bgp 6 }
+
+ bgp4PathAttrEntry OBJECT-TYPE
+ SYNTAX Bgp4PathAttrEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Information about a path to a network."
+ INDEX { bgp4PathAttrIpAddrPrefix,
+ bgp4PathAttrIpAddrPrefixLen,
+ bgp4PathAttrPeer }
+ ::= { bgp4PathAttrTable 1 }
+
+ Bgp4PathAttrEntry ::= SEQUENCE {
+ bgp4PathAttrPeer
+ IpAddress,
+ bgp4PathAttrIpAddrPrefixLen
+ Integer32,
+ bgp4PathAttrIpAddrPrefix
+ IpAddress,
+ bgp4PathAttrOrigin
+ INTEGER,
+
+
+
+Haas & Hares Standards Track [Page 17]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ bgp4PathAttrASPathSegment
+ OCTET STRING,
+ bgp4PathAttrNextHop
+ IpAddress,
+ bgp4PathAttrMultiExitDisc
+ Integer32,
+ bgp4PathAttrLocalPref
+ Integer32,
+ bgp4PathAttrAtomicAggregate
+ INTEGER,
+ bgp4PathAttrAggregatorAS
+ Integer32,
+ bgp4PathAttrAggregatorAddr
+ IpAddress,
+ bgp4PathAttrCalcLocalPref
+ Integer32,
+ bgp4PathAttrBest
+ INTEGER,
+ bgp4PathAttrUnknown
+ OCTET STRING
+ }
+
+ bgp4PathAttrPeer OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The IP address of the peer where the path
+ information was learned."
+ ::= { bgp4PathAttrEntry 1 }
+
+ bgp4PathAttrIpAddrPrefixLen OBJECT-TYPE
+ SYNTAX Integer32 (0..32)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Length in bits of the IP address prefix in
+ the Network Layer Reachability
+ Information field."
+ ::= { bgp4PathAttrEntry 2 }
+
+ bgp4PathAttrIpAddrPrefix OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "An IP address prefix in the Network Layer
+ Reachability Information field. This object
+
+
+
+Haas & Hares Standards Track [Page 18]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ is an IP address containing the prefix with
+ length specified by
+ bgp4PathAttrIpAddrPrefixLen.
+ Any bits beyond the length specified by
+ bgp4PathAttrIpAddrPrefixLen are zeroed."
+ REFERENCE
+ "RFC 4271, Section 4.3."
+ ::= { bgp4PathAttrEntry 3 }
+
+ bgp4PathAttrOrigin OBJECT-TYPE
+ SYNTAX INTEGER {
+ igp(1),-- networks are interior
+ egp(2),-- networks learned via the
+ -- EGP protocol
+ incomplete(3) -- networks that
+ -- are learned by some other
+ -- means
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The ultimate origin of the path
+ information."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 5.1.1."
+ ::= { bgp4PathAttrEntry 4 }
+
+ bgp4PathAttrASPathSegment OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE (2..255))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The sequence of AS path segments. Each AS
+ path segment is represented by a triple
+ <type, length, value>.
+
+ The type is a 1-octet field that has two
+ possible values:
+ 1 AS_SET: unordered set of ASes that a
+ route in the UPDATE message
+ has traversed
+
+ 2 AS_SEQUENCE: ordered set of ASes that
+ a route in the UPDATE message
+ has traversed.
+
+ The length is a 1-octet field containing the
+
+
+
+Haas & Hares Standards Track [Page 19]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ number of ASes in the value field.
+
+ The value field contains one or more AS
+ numbers. Each AS is represented in the octet
+ string as a pair of octets according to the
+ following algorithm:
+
+ first-byte-of-pair = ASNumber / 256;
+ second-byte-of-pair = ASNumber & 255;
+
+ Known Issues:
+ o BGP Confederations will result in
+ a type of either 3 or 4.
+ o An AS Path may be longer than 255 octets.
+ This may result in this object containing
+ a truncated AS Path."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 5.1.2."
+ ::= { bgp4PathAttrEntry 5 }
+
+ bgp4PathAttrNextHop OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The address of the border router that
+ should be used for the destination
+ network. This address is the NEXT_HOP
+ address received in the UPDATE packet."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 5.1.3."
+ ::= { bgp4PathAttrEntry 6 }
+
+ bgp4PathAttrMultiExitDisc OBJECT-TYPE
+ SYNTAX Integer32 (-1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "This metric is used to discriminate
+ between multiple exit points to an
+ adjacent autonomous system. A value of -1
+ indicates the absence of this attribute.
+
+ Known Issues:
+ o The BGP-4 specification uses an
+ unsigned 32 bit number. Thus, this
+
+
+
+Haas & Hares Standards Track [Page 20]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ object cannot represent the full
+ range of the protocol."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 5.1.4."
+ ::= { bgp4PathAttrEntry 7 }
+
+ bgp4PathAttrLocalPref OBJECT-TYPE
+ SYNTAX Integer32 (-1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The originating BGP4 speaker's degree of
+ preference for an advertised route. A
+ value of -1 indicates the absence of this
+ attribute.
+
+ Known Issues:
+ o The BGP-4 specification uses an
+ unsigned 32 bit number and thus this
+ object cannot represent the full
+ range of the protocol."
+ REFERENCE
+ "RFC 4271, Section 4.3.
+ RFC 4271, Section 5.1.5."
+ ::= { bgp4PathAttrEntry 8 }
+
+ bgp4PathAttrAtomicAggregate OBJECT-TYPE
+ SYNTAX INTEGER {
+ lessSpecificRouteNotSelected(1),
+ -- Typo corrected from RFC 1657
+ lessSpecificRouteSelected(2)
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "If the ATOMIC_AGGREGATE attribute is present
+ in the Path Attributes then this object MUST
+ have a value of 'lessSpecificRouteNotSelected'.
+
+ If the ATOMIC_AGGREGATE attribute is missing
+ in the Path Attributes then this object MUST
+ have a value of 'lessSpecificRouteSelected'.
+
+ Note that ATOMIC_AGGREGATE is now a primarily
+ informational attribute."
+ REFERENCE
+ "RFC 4271, Sections 5.1.6 and 9.1.4."
+
+
+
+Haas & Hares Standards Track [Page 21]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ ::= { bgp4PathAttrEntry 9 }
+
+ bgp4PathAttrAggregatorAS OBJECT-TYPE
+ SYNTAX Integer32 (0..65535)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The AS number of the last BGP4 speaker that
+ performed route aggregation. A value of
+ zero (0) indicates the absence of this
+ attribute.
+
+ Note that propagation of AS of zero is illegal
+ in the Internet."
+ REFERENCE
+ "RFC 4271, Section 5.1.7.
+ RFC 4271, Section 9.2.2.2."
+ ::= { bgp4PathAttrEntry 10 }
+
+ bgp4PathAttrAggregatorAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The IP address of the last BGP4 speaker
+ that performed route aggregation. A
+ value of 0.0.0.0 indicates the absence
+ of this attribute."
+ REFERENCE
+ "RFC 4271, Section 5.1.7.
+ RFC 4271, Section 9.2.2.2."
+ ::= { bgp4PathAttrEntry 11 }
+
+ bgp4PathAttrCalcLocalPref OBJECT-TYPE
+ SYNTAX Integer32 (-1..2147483647)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The degree of preference calculated by the
+ receiving BGP4 speaker for an advertised
+ route. A value of -1 indicates the
+ absence of this attribute.
+
+ Known Issues:
+ o The BGP-4 specification uses an
+ unsigned 32 bit number and thus this
+ object cannot represent the full
+ range of the protocol."
+
+
+
+Haas & Hares Standards Track [Page 22]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ REFERENCE
+ "RFC 4271, Section 9.1.1."
+ ::= { bgp4PathAttrEntry 12 }
+
+ bgp4PathAttrBest OBJECT-TYPE
+ SYNTAX INTEGER {
+ false(1),-- not chosen as best route
+ true(2) -- chosen as best route
+ }
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "An indication of whether this route
+ was chosen as the best BGP4 route for this
+ destination."
+ REFERENCE
+ "RFC 4271, Section 9.1.2."
+ ::= { bgp4PathAttrEntry 13 }
+
+ bgp4PathAttrUnknown OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE(0..255))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "One or more path attributes not understood by
+ this BGP4 speaker.
+
+ Path attributes are recorded in the Update Path
+ attribute format of type, length, value.
+
+ Size zero (0) indicates the absence of such
+ attributes.
+
+ Octets beyond the maximum size, if any, are not
+ recorded by this object.
+
+ Known Issues:
+ o Attributes understood by this speaker, but not
+ represented in this MIB, are unavailable to
+ the agent."
+ REFERENCE
+ "RFC 4271, Section 5."
+ ::= { bgp4PathAttrEntry 14 }
+
+ -- Traps.
+ -- Note that in RFC 1657, bgpTraps was incorrectly
+ -- assigned a value of { bgp 7 } and each of the
+ -- traps had the bgpPeerRemoteAddr object inappropriately
+
+
+
+Haas & Hares Standards Track [Page 23]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ -- removed from their OBJECTS clause. The following
+ -- definitions restore the semantics of the traps as
+ -- they were initially defined in RFC 1269.
+
+ bgpNotification OBJECT IDENTIFIER ::= { bgp 0 }
+
+ bgpEstablishedNotification NOTIFICATION-TYPE
+ OBJECTS { bgpPeerRemoteAddr,
+ bgpPeerLastError,
+ bgpPeerState }
+ STATUS current
+ DESCRIPTION
+ "The bgpEstablishedNotification event is generated
+ when the BGP FSM enters the established state.
+
+ This Notification replaces the bgpEstablished
+ Notification."
+ ::= { bgpNotification 1 }
+
+ bgpBackwardTransNotification NOTIFICATION-TYPE
+ OBJECTS { bgpPeerRemoteAddr,
+ bgpPeerLastError,
+ bgpPeerState }
+ STATUS current
+ DESCRIPTION
+ "The bgpBackwardTransNotification event is
+ generated when the BGP FSM moves from a higher
+ numbered state to a lower numbered state.
+
+ This Notification replaces the
+ bgpBackwardsTransition Notification."
+ ::= { bgpNotification 2 }
+
+ -- { bgp 7 } is deprecated. Do not allocate new objects or
+ -- notifications underneath this branch.
+
+ bgpTraps OBJECT IDENTIFIER ::= { bgp 7 } -- deprecated
+
+ bgpEstablished NOTIFICATION-TYPE
+ OBJECTS { bgpPeerLastError,
+ bgpPeerState }
+ STATUS deprecated
+ DESCRIPTION
+ "The bgpEstablished event is generated when
+ the BGP FSM enters the established state.
+
+ This Notification has been replaced by the
+ bgpEstablishedNotification Notification."
+
+
+
+Haas & Hares Standards Track [Page 24]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ ::= { bgpTraps 1 }
+
+ bgpBackwardTransition NOTIFICATION-TYPE
+ OBJECTS { bgpPeerLastError,
+ bgpPeerState }
+ STATUS deprecated
+ DESCRIPTION
+ "The bgpBackwardTransition event is generated
+ when the BGP FSM moves from a higher numbered
+ state to a lower numbered state.
+
+ This Notification has been replaced by the
+ bgpBackwardTransNotification Notification."
+ ::= { bgpTraps 2 }
+
+ -- Conformance information
+
+ bgp4MIBConformance OBJECT IDENTIFIER
+ ::= { bgp 8 }
+ bgp4MIBCompliances OBJECT IDENTIFIER
+ ::= { bgp4MIBConformance 1 }
+ bgp4MIBGroups OBJECT IDENTIFIER
+ ::= { bgp4MIBConformance 2 }
+
+ -- Compliance statements
+
+ bgp4MIBCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "The compliance statement for entities which
+ implement the BGP4 mib."
+ MODULE -- this module
+ MANDATORY-GROUPS { bgp4MIBGlobalsGroup,
+ bgp4MIBPeerGroup,
+ bgp4MIBPathAttrGroup }
+ GROUP bgp4MIBNotificationGroup
+ DESCRIPTION
+ "Implementation of BGP Notifications are
+ completely optional in this MIB."
+ ::= { bgp4MIBCompliances 1 }
+
+ bgp4MIBDeprecatedCompliances MODULE-COMPLIANCE
+ STATUS deprecated
+ DESCRIPTION
+ "The compliance statement documenting deprecated
+ objects in the BGP4 mib."
+ MODULE -- this module
+ GROUP bgp4MIBTrapGroup
+
+
+
+Haas & Hares Standards Track [Page 25]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ DESCRIPTION
+ "Group containing TRAP objects that were
+ improperly converted from SMIv1 in RFC 1657.
+ The proper semantics have been restored
+ with the objects in bgp4MIBNotificationGroup."
+ ::= { bgp4MIBCompliances 2 }
+
+ bgp4MIBObsoleteCompliances MODULE-COMPLIANCE
+ STATUS obsolete
+ DESCRIPTION
+ "The compliance statement documenting obsolete
+ objects in the BGP4 mib."
+ MODULE -- this module
+ GROUP bgpRcvdPathAttrGroup
+ DESCRIPTION
+ "Group containing objects relevant to BGP-3
+ and earlier objects."
+ ::= { bgp4MIBCompliances 3 }
+
+ -- Units of conformance
+
+ bgp4MIBGlobalsGroup OBJECT-GROUP
+ OBJECTS { bgpVersion,
+ bgpLocalAs,
+ bgpIdentifier }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects providing
+ information on global BGP state."
+ ::= { bgp4MIBGroups 1 }
+
+ bgp4MIBPeerGroup OBJECT-GROUP
+ OBJECTS { bgpPeerIdentifier,
+ bgpPeerState,
+ bgpPeerAdminStatus,
+ bgpPeerNegotiatedVersion,
+ bgpPeerLocalAddr,
+ bgpPeerLocalPort,
+ bgpPeerRemoteAddr,
+ bgpPeerRemotePort,
+ bgpPeerRemoteAs,
+ bgpPeerInUpdates,
+ bgpPeerOutUpdates,
+ bgpPeerInTotalMessages,
+ bgpPeerOutTotalMessages,
+ bgpPeerLastError,
+ bgpPeerFsmEstablishedTransitions,
+ bgpPeerFsmEstablishedTime,
+
+
+
+Haas & Hares Standards Track [Page 26]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ bgpPeerConnectRetryInterval,
+ bgpPeerHoldTime,
+ bgpPeerKeepAlive,
+ bgpPeerHoldTimeConfigured,
+ bgpPeerKeepAliveConfigured,
+ bgpPeerMinASOriginationInterval,
+ bgpPeerMinRouteAdvertisementInterval,
+ bgpPeerInUpdateElapsedTime }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects for managing
+ BGP peers."
+ ::= { bgp4MIBGroups 2 }
+
+ bgpRcvdPathAttrGroup OBJECT-GROUP
+ OBJECTS { bgpPathAttrPeer,
+ bgpPathAttrDestNetwork,
+ bgpPathAttrOrigin,
+ bgpPathAttrASPath,
+ bgpPathAttrNextHop,
+ bgpPathAttrInterASMetric }
+ STATUS obsolete
+ DESCRIPTION
+ "A collection of objects for managing BGP-3 and
+ earlier path entries.
+
+ This conformance group, like BGP-3, is obsolete."
+ ::= { bgp4MIBGroups 3 }
+
+ bgp4MIBPathAttrGroup OBJECT-GROUP
+ OBJECTS { bgp4PathAttrPeer,
+ bgp4PathAttrIpAddrPrefixLen,
+ bgp4PathAttrIpAddrPrefix,
+ bgp4PathAttrOrigin,
+ bgp4PathAttrASPathSegment,
+ bgp4PathAttrNextHop,
+ bgp4PathAttrMultiExitDisc,
+ bgp4PathAttrLocalPref,
+ bgp4PathAttrAtomicAggregate,
+ bgp4PathAttrAggregatorAS,
+ bgp4PathAttrAggregatorAddr,
+ bgp4PathAttrCalcLocalPref,
+ bgp4PathAttrBest,
+ bgp4PathAttrUnknown }
+ STATUS current
+ DESCRIPTION
+ "A collection of objects for managing
+ BGP path entries."
+
+
+
+Haas & Hares Standards Track [Page 27]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ ::= { bgp4MIBGroups 4 }
+
+ bgp4MIBTrapGroup NOTIFICATION-GROUP
+ NOTIFICATIONS { bgpEstablished,
+ bgpBackwardTransition }
+ STATUS deprecated
+ DESCRIPTION
+ "A collection of notifications for signaling
+ changes in BGP peer relationships.
+
+ Obsoleted by bgp4MIBNotificationGroup"
+ ::= { bgp4MIBGroups 5 }
+
+ bgp4MIBNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS { bgpEstablishedNotification,
+ bgpBackwardTransNotification }
+ STATUS current
+ DESCRIPTION
+ "A collection of notifications for signaling
+ changes in BGP peer relationships.
+
+ Obsoletes bgp4MIBTrapGroup."
+ ::= { bgp4MIBGroups 6 }
+
+ END
+
+5. Security Considerations
+
+ This MIB relates to a system providing inter-domain routing. As
+ such, improper manipulation of the objects represented by this MIB
+ may result in denial of service to a large number of end-users.
+
+ There are several management objects defined in this MIB that have a
+ MAX-ACCESS clause of read-write and/or read-create. Such objects
+ should be considered sensitive or vulnerable in most network
+ environments. The support for SET operations in a non-secure
+ environment without proper protection can have a negative effect on
+ network operations. These objects include:
+
+ o bgpPeerAdminStatus
+
+ Improper change of bgpPeerAdminStatus, from start to stop, can
+ cause significant disruption of the connectivity to those
+ portions of the Internet reached via the applicable remote BGP
+ peer.
+
+
+
+
+
+
+Haas & Hares Standards Track [Page 28]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ o bgpPeerConnectRetryInterval
+
+ Improper change of this object can cause connections to be
+ disrupted for extremely long time periods when otherwise they
+ would be restored in a relatively short period of time.
+
+ o bgpPeerHoldTimeConfigured, bgpPeerKeepAliveConfigured
+
+ Misconfiguration of these objects can make BGP sessions more
+ fragile and less resilient to denial of service attacks on the
+ inter-domain routing system.
+
+ o bgpPeerMinASOriginationInterval,
+ bgpPeerMinRouteAdvertisementInterval
+
+ Misconfiguration of these objects may adversely affect global
+ Internet convergence of the routes advertised by this BGP
+ speaker. This may result in long-lived routing loops and
+ blackholes for the portions of the Internet that utilize these
+ routes.
+
+ There are a number of managed objects in this MIB that contain
+ sensitive information regarding the operation of a network. For
+ example, a BGP peer's local and remote addresses might be sensitive
+ for ISPs who want to keep interface addresses on routers confidential
+ in order to prevent router addresses used for a denial of service
+ attack or spoofing.
+
+ Therefore, it is important in most environments to control read
+ access to these objects and possibly to even encrypt the values of
+ these object when sending them over the network via SNMP.
+
+ SNMP versions prior to SNMPv3 did not include adequate security.
+ Even if the network itself is secure (for example by using IPsec),
+ even then, there is no control as to who on the secure network is
+ allowed to access and GET/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ It is RECOMMENDED that implementers consider the security features as
+ provided by the SNMPv3 framework (see [RFC3410], section 8),
+ including full support for the SNMPv3 cryptographic mechanisms (for
+ authentication and privacy).
+
+ Further, deployment of SNMP versions prior to SNMPv3 is NOT
+ RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
+ enable cryptographic security. It is then a customer/operator
+ responsibility to ensure that the SNMP entity giving access to an
+ instance of this MIB module is properly configured to give access to
+
+
+
+Haas & Hares Standards Track [Page 29]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+ the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change/create/delete) them.
+
+6. Acknowledgements
+
+ We would like to acknowledge the assistance of all the members of the
+ Inter-Domain Routing Working Group, and particularly the following
+ individuals:
+
+ Yakov Rekhter, Juniper Networks
+ Rob Coltun, Redback
+ Guy Almes, Internet2
+ Jeff Honig, BSDi
+ Marshall T. Rose, Dover Beach Consulting, Inc.
+ Dennis Ferguson, Juniper Networks
+ Matt Mathis, PSC
+ John Krawczyk, Bay Networks
+ Curtis Villamizar, Avici
+ Dave LeRoy, Pencom Systems
+ Paul Traina, Juniper Networks
+ Andrew Partan, MFN
+ Robert Snyder, Cisco Systems
+ Dimitry Haskin, Nortel
+ Peder Chr Norgaard, Telebit Communications A/S
+ Joel Halpern, CTO Longitude Systems, Inc.
+ Nick Thille, RedBack Networks
+ Bert Wijnen, Lucent
+ Shane Wright, NextHop Technologies
+ Mike McFadden, Riverstone Networks, Inc.
+ Jon Saperia, JDS Consulting, Inc.
+ Wayne Tackabury, Gold Wire Technology, Inc.
+ Bill Fenner, AT&T Research
+ RJ Atkinson, Extreme Networks
+ Dan Romascanu, Avaya
+ Mathew Richardson, NextHop Technologies
+
+ The origin of this document is from RFC 1269 "Definitions of Managed
+ Objects for the Border Gateway Protocol (Version 3)" written by Steve
+ Willis and John Burruss, which was updated by John Chu to support
+ BGP-4 in RFC 1657. The editors wish to acknowledge the fine work of
+ these original authors.
+
+
+
+
+
+
+
+
+
+
+Haas & Hares Standards Track [Page 30]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+7. Normative References
+
+ [BGP4] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border
+ Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [BGP4APP] Rekhter, Y. and P. Gross, "Application of the Border
+ Gateway Protocol in the Internet", RFC 1772, March 1995.
+
+ [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.
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+Editors' Addresses
+
+ Jeffrey Haas
+ NextHop Technologies
+ 825 Victor's Way, Suite 100
+ Ann Arbor, MI 48103
+
+ Phone: +1 734 222-1600
+ Fax: +1 734 222-1602
+ EMail: jhaas@nexthop.com
+
+
+ Susan Hares
+ NextHop Technologies
+ 825 Victor's Way, Suite 100
+ Ann Arbor, MI 48103
+
+ Phone: +1 734 222-1600
+ Fax: +1 734 222-1602
+ EMail: skh@nexthop.com
+
+
+
+
+
+
+
+Haas & Hares Standards Track [Page 31]
+
+RFC 4273 BGP4-MIB January 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Haas & Hares Standards Track [Page 32]
+