📄 rfc1657.txt
字号:
Network Working Group S. Willis
Request for Comments: 1657 J. Burruss
Category: Standards Track Wellfleet Communications Inc.
J. Chu, Editor
IBM Corp.
July 1994
Definitions of Managed Objects for the Fourth Version of the
Border Gateway Protocol (BGP-4) using SMIv2
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.
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 [1, 2].
2. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
RFC 1442 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management.
STD 17, RFC 1213 defines MIB-II, the core set of managed objects
forthe Internet suite of protocols.
RFC 1445 which defines the administrative and other architectural
aspects of the framework.
RFC 1448 which defines the protocol used for network access to
managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
Willis, Burruss & Chu [Page 1]
RFC 1657 BGP-4 MIB July 1994
3. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we
often use a textual string, termed the descriptor, to refer to the
object type.
4. 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 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.
5. Definitions
BGP4-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
IpAddress, Integer32, Counter32, Gauge32
FROM SNMPv2-SMI
mib-2
FROM RFC1213-MIB;
bgp MODULE-IDENTITY
LAST-UPDATED "9405050000Z"
ORGANIZATION "IETF BGP Working Group"
CONTACT-INFO
" John Chu (Editor)
Postal: IBM Corp.
P.O.Box 218
Yorktown Heights, NY 10598
US
Willis, Burruss & Chu [Page 2]
RFC 1657 BGP-4 MIB July 1994
Tel: +1 914 945 3156
Fax: +1 914 945 2141
E-mail: jychu@watson.ibm.com"
DESCRIPTION
"The MIB module for BGP-4."
::= { 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."
::= { bgp 1 }
bgpLocalAs OBJECT-TYPE
SYNTAX INTEGER (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local autonomous system number."
::= { 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 }
Willis, Burruss & Chu [Page 3]
RFC 1657 BGP-4 MIB July 1994
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
INTEGER,
bgpPeerRemoteAddr
IpAddress,
bgpPeerRemotePort
INTEGER,
bgpPeerRemoteAs
INTEGER,
bgpPeerInUpdates
Counter32,
bgpPeerOutUpdates
Counter32,
bgpPeerInTotalMessages
Counter32,
bgpPeerOutTotalMessages
Counter32,
bgpPeerLastError
OCTET STRING,
bgpPeerFsmEstablishedTransitions
Counter32,
bgpPeerFsmEstablishedTime
Gauge32,
bgpPeerConnectRetryInterval
INTEGER,
bgpPeerHoldTime
INTEGER,
bgpPeerKeepAlive
Willis, Burruss & Chu [Page 4]
RFC 1657 BGP-4 MIB July 1994
INTEGER,
bgpPeerHoldTimeConfigured
INTEGER,
bgpPeerKeepAliveConfigured
INTEGER,
bgpPeerMinASOriginationInterval
INTEGER,
bgpPeerMinRouteAdvertisementInterval
INTEGER,
bgpPeerInUpdateElapsedTime
Gauge32
}
bgpPeerIdentifier OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
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)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The BGP peer connection state."
::= { 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 Start Event to be generated.
Willis, Burruss & Chu [Page 5]
RFC 1657 BGP-4 MIB July 1994
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -