Extreme BGP4v2 MIB

This MIB supports IPv6 only, for BGP IPv4 sessions please refer the BGP4 MIB RFC 4273.

This MIB supports the BGPIPv6 parameters and it defines the objects as per the IETF draft-15 which helps in demonstrating the BGP routing protocol and to populate the required BGPIPv6 tables and notifications.

Note

Note

Extreme BGP4v2 MIB is VRF-aware.
Table 1. extremeBGP4v2 Peer table

Object group name

OID

Notes

extremeBgp4V2PeerInstance .1.3.6.1.4.1.1916.1.51.1.2.1.1 The routing instance index. Some BGP implementations permit the creation of multiple instances of a BGP routing process. An example includes routers running BGP/MPLS IP Virtual Private Networks Implementations that do not support multiple routing instances should return 1 for this object.
extremeBgp4V2PeerLocalAddrType .1.3.6.1.4.1.1916.1.51.1.2.1.2 The address family of the local end of the peering session.
extremeBgp4V2PeerLocalAddr .1.3.6.1.4.1.1916.1.51.1.2.1.3 The local IPv6 address of this entry's BGP connection.
extremeBgp4V2PeerRemoteAddrType .1.3.6.1.4.1.1916.1.51.1.2.1.4 The address family of the remote end of the peering session.
extremeBgp4V2PeerRemoteAddr .1.3.6.1.4.1.1916.1.51.1.2.1.5 The remote IPV6 address of this entry's BGP peer.
extremeBgp4V2PeerLocalPort .1.3.6.1.4.1.1916.1.51.1.2.1.6 The local port for the TCP connection between the BGP peers.
extremeBgp4V2PeerLocalAs .1.3.6.1.4.1.1916.1.51.1.2.1.7 Some implementations of BGP can represent themselves as multiple ASes. This is the AS that this peering session is representing itself as to the remote peer.
extremeBgp4V2PeerLocalIdentifier .1.3.6.1.4.1.1916.1.51.1.2.1.8 The BGP Identifier of the local system for this peering session. It is REQUIRED that all extremeBgp4V2PeerLocalIdentifier values for the same extremeBgp4V2PeerInstance be identical.
extremeBgp4V2PeerRemotePort .1.3.6.1.4.1.1916.1.51.1.2.1.9 The remote port for the TCP connection between the BGP peers. Note that the objects extremeBgp4V2PeerLocalAddr,extremeBgp4V2PeerLocalPort, extremeBgp4V2PeerRemoteAddr and extremeBgp4V2PeerRemotePort provide the appropriate reference to the standard MIB TCP connection table, or even the ipv6 TCP MIB as in RFC 4022.
extremeBgp4V2PeerRemoteAs .1.3.6.1.4.1.1916.1.51.1.2.1.10 The remote autonomous system number received in the BGP OPEN message
extremeBgp4V2PeerRemoteIdentifier .1.3.6.1.4.1.1916.1.51.1.2.1.11 The BGP Identifier of this entry's remote BGP peer. This entry should be 0:0:0:0:0:0:0:0 unless the extremeBgp4V2PeerState is in the open confirm or the established state.
extremeBgp4V2PeerAdminStatus .1.3.6.1.4.1.1916.1.51.1.2.1.12 Whether the BGP FSM for this remote peer is halted or running. The BGP FSM for a remote peer is halted after processing a Stop event. Likewise, it is in the running state after a Start event. The extremeBgp4V2PeerState will generally be in the idle state when the FSM is halted, although some extensions such as Graceful Restart will leave the peer in the Idle state but with the FSM running.
Note: halted (1), running (2) are supported.
extremeBgp4V2PeerState .1.3.6.1.4.1.1916.1.51.1.2.1.13 The BGP peer connection state.
extremeBgp4V2PeerDescription .1.3.6.1.4.1.1916.1.51.1.2.1.14 A user configured description identifying this peer. When this object is not the empty string, this object SHOULD contain a description that is unique within a given BGP instance for this peer.
Table 2. extremeBGPv2PeerError table
Object group name Object identifier Notes
extremeBgp4V2PeerLastErrorCodeReceived 1.3.6.1.4.1.1916.1.51.1.3.1.1 The last error code received from this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.
extremeBgp4V2PeerLastErrorSubCodeReceived .1.3.6.1.4.1.1916.1.51.1.3.1.2 The last subcode received from this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.
extremeBgp4V2PeerLastErrorReceivedTime .1.3.6.1.4.1.1916.1.51.1.3.1.3 The timestamp that the last NOTIFICATION was received from this peer.
extremeBgp4V2PeerLastErrorReceivedText .1.3.6.1.4.1.1916.1.51.1.3.1.4 This object contains an implementation specific explanation of the error that was reported.
extremeBgp4V2PeerLastErrorCodeSent .1.3.6.1.4.1.1916.1.51.1.3.1.6 The last error code sent to this peer via NOTIFICATIONmessage on this connection. If no error has occurred, this field is zero.
extremeBgp4V2PeerLastErrorSubCodeSent .1.3.6.1.4.1.1916.1.51.1.3.1.7 The last subcode sent to this peer via NOTIFICATIONmessage on this connection. If no error has occurred, this field is zero.
extremeBgp4V2PeerLastErrorSentTime .1.3.6.1.4.1.1916.1.51.1.3.1.8 The timestamp that the last NOTIFICATION was sent to this peer.
extremeBgp4V2PeerLastErrorSentText .1.3.6.1.4.1.1916.1.51.1.3.1.9 This object contains an implementation specific explanation of the error that is being reported.
extremeBgp4V2PeerLastErrorSentData .1.3.6.1.4.1.1916.1.51.1.3.1.10 The last error code's data sent to this peer. As per RFC 2578, some implementations may have limitations dealing with OCTET STRINGS larger than 255. Hence, this data may be truncated.
Table 3. extremeBgp4V2PeerEventTimesTable
Object group name Object identifier Notes
extremeBgp4V2PeerFsmEstablishedTime 1.3.6.1.4.1.1916.1.51.1.4.1.1 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 booted. If the peer has never reached the established state, the value remains zero.
extremeBgp4V2PeerInUpdatesElapsedTime .1.3.6.1.4.1.1916.1.51.1.4.1.2 Elapsed time (in seconds) since the last BGP UPDATEmessage was received from the peer. Each time bgpPeerInUpdates is incremented, the value of this object is set to zero (0)."
Table 4. extremeBgp4V2NlriTable
Object group name Object identifier Notes
extremeBgp4V2NlriIndex .1.3.6.1.4.1.1916.1.51.1.9.1.1 This index allows for multiple instances of a base prefix for a certain AFI-SAFI from a given peer.This is currently useful for two things
  1. Allowing for a peer in future implementations to send more than a single route instance.
  2. Allow for extensions which extend the NLRI field to send the same prefix while utilizing other extension specific information.
An example of this is RFC 3107 - Carrying MPLS labels in BGP.
extremeBgp4V2NlriAfi .1.3.6.1.4.1.1916.1.51.1.9.1.2 The address family of the prefix for this NLRI. Note that the AFI is not necessarily equivalent to the an InetAddressType.
extremeBgp4V2NlriSafi .1.3.6.1.4.1.1916.1.51.1.9.1.3 The subsequent address family of the prefix for this NLRI
extremeBgp4V2NlriPrefixType .1.3.6.1.4.1.1916.1.51.1.9.1.4 The type of the IP address prefix in the Network Layer Reachability Information field. The value of this object is derived from the appropriate value from the extremeBgp4V2NlriAfi field. Where an appropriate InetAddressType is not available, the value of the object must be unknown(0).
extremeBgp4V2NlriPrefix .1.3.6.1.4.1.1916.1.51.1.9.1.5 An IP address prefix in the Network Layer Reachability Information field. This object is an IP address containing the prefix with length specified by extremeBgp4V2NlriPrefixLen. Any bits beyond the length specified by extremeBgp4V2NlriPrefixLen are zeroed.
extremeBgp4V2NlriPrefixLen .1.3.6.1.4.1.1916.1.51.1.9.1.6 Length in bits of the address prefix in the Network Layer Reachability Information field.
extremeBgp4V2NlriBest .1.3.6.1.4.1.1916.1.51.1.9.1.7 An indication of whether or not this route was chosen as the best BGP4 route for this destination.
extremeBgp4V2NlriCalcLocalPref .1.3.6.1.4.1.1916.1.51.1.9.1.8 The degree of preference calculated by the receiving BGP4 speaker for an advertised route. In the case where this prefix is ineligible, the value of this object will be zero (0).
extremeBgp4V2NlriOrigin .1.3.6.1.4.1.1916.1.51.1.9.1.9 The ultimate origin of the path information.
extremeBgp4V2NlriNextHopAddrType .1.3.6.1.4.1.1916.1.51.1.9.1.10 The address family of the address for the border router that should be used to access the destination network.
extremeBgp4V2NlriNextHopAddr .1.3.6.1.4.1.1916.1.51.1.9.1.11 The address of the border router that should be used to access the destination network. This address is the nexthop address received in the UPDATE packet associated with this prefix. Note that for RFC2545 style double nexthops, this object will always contain the global scope nexthop. bgpPathAttrLinkLocalNextHop contains the linklocal scope nexthop, if it is present. In the case a mechanism is developed to use only a link local nexthop, extremeBgp4V2NlriNextHopAddr will contain the link local nexthop.
extremeBgp4V2NlriLinkLocalNextHopAddrType .1.3.6.1.4.1.1916.1.51.1.9.1.12 The address type for IPv6 link local addresses. This is present only when receiving RFC 2545 style double nexthops. This object is optionally present in BGP implementations that do not support IPv6. When no IPv6 link local nexthop is present, the value of this object should be unknown(0).
extremeBgp4V2NlriLinkLocalNextHopAddr .1.3.6.1.4.1.1916.1.51.1.9.1.13 This value contains an IPv6 link local address and is present only when receiving RFC 2545 style double nexthops. This object is optionally present in BGP implementations that do not support IPv6 When no IPv6 link local nexthop is present, the length of this object should be zero.
extremeBgp4V2NlriLocalPrefPresent .1.3.6.1.4.1.1916.1.51.1.9.1.14 This value is true when the LOCAL_PREF value was sent in the UPDATE message.
extremeBgp4V2NlriLocalPref .1.3.6.1.4.1.1916.1.51.1.9.1.15 The originating BGP4 speaker‘s degree of preference for an advertised route.
extremeBgp4V2NlriMedPresent .1.3.6.1.4.1.1916.1.51.1.9.1.16 This value is true when the MED value was sent in the UPDATE message.
extremeBgp4V2NlriMed .1.3.6.1.4.1.1916.1.51.1.9.1.17 This metric is used to discriminate between multiple exit points to an adjacent autonomous system. When the MED value is absent but has a calculated default value, this object will contain the calculated value.
extremeBgp4V2NlriAtomicAggregate 1.3.6.1.4.1.1916.1.51.1.9.1.18 This value is true when the ATOMIC_AGGREGATE Path Attribute is present and indicates that the NLRI MUST NOT be made more specific.
extremeBgp4V2NlriAggregatorPresent .1.3.6.1.4.1.1916.1.51.1.9.1.19 This value is true when the AGGREGATOR path attribute was sent in the UPDATE message.
extremeBgp4V2NlriAggregatorAS 1.3.6.1.4.1.1916.1.51.1.9.1.20 The AS number of the last BGP4 speaker that performed route aggregation. When extremeBgp4V2NlriAggregatorPresent is false, the value of this object should be zero (0).
extremeBgp4V2NlriAggregatorAddr .1.3.6.1.4.1.1916.1.51.1.9.1.21 The IP address of the last BGP4 speaker that performed route aggregation. When extremeBgp4V2NlriAggregatorPresent is false, the value of this object should be a default value.
extremeBgp4V2NlriAsPathCalcLength .1.3.6.1.4.1.1916.1.51.1.9.1.22 This value represents the calculated length of the AS Path according to the rules of the BGP specification. This value is used in route selection.
extremeBgp4V2NlriAsPathString .1.3.6.1.4.1.1916.3.5.1.1.9.1.23 This is a string depicting the autonomous system path to this network which was received from the peer which advertised it. The format of the string is implementation-dependent, and should be designed for operator readability. Note that SnmpAdminString is only capable of representing a maximum of 255 characters. This may lead to the string being truncated in the presence of a large AS Path. It is RECOMMENDED that when this object's contents will be truncated that the final 3 octets be reserved for the ellipses string, '...'. extremeBgp4V2NlriAsPath may give access to the full AS Path.
extremeBgp4V2NlriAsPath .1.3.6.1.4.1.1916.1.51.1.9.1.24 In order to provide a canonicalized form of the BGP-4 AS_PATH along with the human-readable extremeBgp4V2NlriAsPathString, which may be truncated, this object contains the contents of the BGP-4 AS_PATH Path Attribute. This object may be parsed using the rules defined for Four-octet as defined in RFC 4893. The AS_PATH is composed of a sequence of AS Segments. Each AS Segment is represented by a triple: <path segment type, path segment length, path segment value>. The path segment type and path segment length fields are one octet in length each. The path segment type field may be one of the following :
  1. AS_SET (RFC 4721, section 4.3)
  2. AS_SEQUENCE (RFC 4721,section 4.3)
  3. AS_CONFED_SEQUENCE (RFC 3065, section 5)
  4. AS_CONFED_SET (RFC 3065, section 5)
The path segment length field contains the number of ASes(not the number of octets) in the path segment value field. The path segment value field contains one or more AS numbers, each encoded as a 4-octet length field in network byte order. Note that since an SNMP agent may truncate this object to less than its maximum theoretical length of 4072 octets users of this object should be prepared to deal with a truncated and thus malformed AS_PATH. It is RECOMMENDED that when such truncation would occur on the boundary of an encoded AS that the partial AS be discarded from this object and the object's size be adjusted accordingly. Further, it is also RECOMMENDED that when such truncation, either alone or in conjuction with the truncation of a partially encoded AS described previously, would yield an empty path segment value field that the path segment type and path segment length components of the truncated AS_PATH also be discarded and the object's size be adjusted accordingly.
extremeBgp4V2NlriPathAttrUnknown .1.3.6.1.4.1.1916.1.51.1.9.1.25 Path Attributes not understood by this implementation SHOULD be, be presented in this object. Those Path Attributes use the type, length, value encoding documented in RFC 4271, Section 4.3, 'Path Attributes'. Note that since an SNMP agent may truncate this object to less than its maximum theoretical length of 4072 octets users of this object should be prepared to deal with a truncated and thus malformed Path Attribute.
Table 5. extremeBgp4V2Notifications
Object group name Object identifier Notes
extremeBgp4V2EstablishedNotification .1.3.6.1.4.1.1916.1.51.0.1 The BGP Established event is generated when the BGP FSM enters the established state.
extremeBgp4V2BackwardTransitionNotification .1.3.6.1.4.1.1916.1.51.0.2 The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state. Due to the nature of the BGP state machine, an implementation MAY rate limit the generation of this event. An implementation MAY also generate this notification ONLY when the state machine moves out of the established state. An implementation should document its specific behavior.