ARISTA-BGP4V2-MIB

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

The value of sysUpTime at the most recent occasion at which this BGP management instance has suffered a discontinuity.

Unsigned32 (1..4294967295)

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.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

The address family of the local end of the peering session.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

The local IP address of this entry's BGP connection. An implementation is required to support IPv4 peering sessions in which case the length of this object is 4. An implementation MAY support IPv6 peering sessions in which case the length of this object is 16. IPv6 link-local peering sessions MAY be supported by this MIB. In this case the length of this object is 20.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

The address family of the remote end of the peering session. An implementation is required to support IPv4 peering sessions in which case the length of this object is 4. An implementation MAY support IPv6 peering sessions in which case the length of this object is 16. IPv6 link-local peering sessions MAY be supported by this MIB. In this case the length of this object is 20.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

The remote IP address of this entry's BGP peer.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

The local port for the TCP connection between the BGP peers.

InetAutonomousSystemNumberRepresents an autonomous system number that identifies an Autonomous System (AS). An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'. IANA maintains the AS number space and has delegated large parts to the regional registries. Autonomous system numbers are currently limited to 16 bits (0..65535). There is, however, work in progress to enlarge the autonomous system number space to 32 bits. Therefore, this textual convention uses an Unsigned32 value without a range restriction in order to support a larger autonomous system number space.Reference: RFC 1771, RFC 1930 · Unsigned32 · hint d

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.

AristaBgp4V2IdentifierTCThe representation of a BGP Identifier. BGP Identifiers are presented in the received network byte order. The BGP Identifier is displayed as if it is an IP address, even if it would be an illegal one.Reference: RFC 4273, Section 4.2 SIZE (4) · OCTET STRING · hint 1d.

Reference: RFC 4271, Section 4.2, 'BGP Identifier'.

The BGP Identifier of the local system for this peering session. It is REQUIRED that all aristaBgp4V2PeerLocalIdentifier values for the same aristaBgp4V2PeerInstance be identical.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

Reference: RFC 2012 - SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2. RFC 4022 - IP Version 6 Management Information Base for the Transmission Control Protocol.

The remote port for the TCP connection between the BGP peers. Note that the objects aristaBgp4V2PeerLocalAddr, aristaBgp4V2PeerLocalPort, aristaBgp4V2PeerRemoteAddr and aristaBgp4V2PeerRemotePort provide the appropriate reference to the standard MIB TCP connection table, or even the ipv6 TCP MIB as in RFC 4022.

InetAutonomousSystemNumberRepresents an autonomous system number that identifies an Autonomous System (AS). An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'. IANA maintains the AS number space and has delegated large parts to the regional registries. Autonomous system numbers are currently limited to 16 bits (0..65535). There is, however, work in progress to enlarge the autonomous system number space to 32 bits. Therefore, this textual convention uses an Unsigned32 value without a range restriction in order to support a larger autonomous system number space.Reference: RFC 1771, RFC 1930 · Unsigned32 · hint d

Reference: RFC 4271, Section 4.2.

The remote autonomous system number received in the BGP OPEN message.

AristaBgp4V2IdentifierTCThe representation of a BGP Identifier. BGP Identifiers are presented in the received network byte order. The BGP Identifier is displayed as if it is an IP address, even if it would be an illegal one.Reference: RFC 4273, Section 4.2 SIZE (4) · OCTET STRING · hint 1d.

Reference: RFC 4271, Section 4.2, 'BGP Identifier'.

The BGP Identifier of this entry's remote BGP peer. This entry should be 0.0.0.0 unless the aristaBgp4V2PeerState is in the openconfirm or the established state.

INTEGER1 = halted2 = running · Integer32

Reference: RFC 4271, Section 8.1.2.

Whether or not 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 aristaBgp4V2PeerState 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.

INTEGER1 = idle2 = connect3 = active4 = opensent5 = openconfirm6 = established · Integer32

Reference: RFC 4271, Section 8.2.2.

The BGP peer connection state.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t

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.

Unsigned32 (0..255)

Reference: RFC 4271, Section 4.5. RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last error code received from this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.

Unsigned32 (0..255)

Reference: RFC 4271, Section 4.5. RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last subcode received from this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

Reference: RFC 4271, Section 4.5.

The timestamp that the last NOTIFICATION was received from this peer.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t

This object contains an implementation specific explanation of the error that was reported.

OCTET STRING SIZE (0..4075)

Reference: RFC 4271, Section 4.5, RFC 2578, Section 7.1.2, RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last error code's data seen by this peer. Per RFC 2578, some implementations may have limitations dealing with OCTET STRINGS larger than 255. Thus, this data may be truncated.

Unsigned32 (0..255)

Reference: RFC 4271, Section 4.5. RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last error code sent to this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.

Unsigned32 (0..255)

Reference: RFC 4271, Section 4.5. RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last subcode sent to this peer via NOTIFICATION message on this connection. If no error has occurred, this field is zero.

TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks

Reference: RFC 4271, Section 4.5.

The timestamp that the last NOTIFICATION was sent to this peer.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t

This object contains an implementation specific explanation of the error that is being reported.

OCTET STRING SIZE (0..4075)

Reference: RFC 4271, Section 4.5, RFC 2578, Section 7.1.2 RFC 4486 optionally supported. RFC 3362, Section 5 optionally supported.

The last error code's data sent to this peer. Per RFC 2578, some implementations may have limitations dealing with OCTET STRINGS larger than 255. Thus, this data may be truncated.

Gauge32 · seconds

Reference: RFC 4271, Section 8.

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.

Gauge32 · seconds

Reference: RFC 4271, Section 4.3. RFC 4271, Section 8.2.2, Established state.

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).

Unsigned32 (1..65535) · seconds

Reference: RFC 4271, Section 8.2.2. This is the value used to initialize the 'ConnectRetryTimer'.

Time interval (in seconds) for the ConnectRetry timer. The suggested value for this timer is 120 seconds.

Unsigned32 (0 | 3..65535) · seconds

Reference: RFC 4271, Section 4.2.

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).

Unsigned32 (0 | 1..21845) · seconds

Reference: RFC 4271, Section 4.4. RFC 4271, Section 10.

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 periodic KEEPALIVE messages are sent to the peer after the BGP connection has been established. The suggested value for this timer is 30 seconds.

Unsigned32 (0..65535) · seconds

Reference: RFC 4271, Section 9.2.1.2. RFC 4271, Section 10.

Time interval (in seconds) for the MinASOriginationInterval timer. The suggested value for this timer is 15 seconds.

Unsigned32 (0..65535) · seconds

Reference: RFC 4271, Section 9.2.1.1. RFC 4271, Section 10.

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.

Unsigned32 (0 | 3..65535) · seconds

Reference: RFC 4271, Section 4.2.

The value of this object is calculated by this BGP Speaker as being; zero (0) - if this was the value sent by the peer and this value is permitted by this BGP Speaker. In this case, no keepalive messages are sent and the Hold Timer is not set. At least three (3). This value is the smaller of the value sent by this peer in the OPEN message and aristaBgp4V2PeerHoldTimeConfigured for this peer. If the peer is not in the established state, the value of this object is zero (0).

Unsigned32 (0 | 1..21845) · seconds

Reference: RFC 4271, Section 4.4.

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 aristaBgp4V2PeerHoldTime, it has the same proportion as what aristaBgp4V2PeerKeepAliveConfigured has when compared with aristaBgp4V2PeerHoldTimeConfigured. If the value of this object is zero (0), it indicates that the KeepAlive timer has not been established with the peer, or, the value of aristaBgp4V2PeerKeepAliveConfigured is zero (0). If the peer is not in the established state, the value of this object is zero (0).

Counter32

The number of BGP UPDATE messages received on this connection.

Counter32

The number of BGP UPDATE messages transmitted on this connection.

Counter32

The total number of messages received from the remote peer on this connection.

Counter32

The total number of messages transmitted to the remote peer on this connection.

Counter32

The total number of times the BGP FSM transitioned into the established state for this peer.

AristaBgp4V2AddressFamilyIdentifierTC1 = ipv42 = ipv6The representation of a BGP AFI. The value of this object should be restricted to be between the values of 0 and 65535.Reference: RFC 4760, Section 3 · Integer32

The AFI index of the per-peer, per prefix counters

AristaBgp4V2SubsequentAddressFamilyIdentifierTC1 = unicast2 = multicast4 = mplsThe representation of a BGP SAFIReference: RFC 4760, Section 3. The value of this object should be restricted to be between the values of 0 and 255. · Integer32

The SAFI index of the per-peer, per prefix counters

Gauge32

Reference: RFC 4271, Sections 3.2 and 9.

The number of prefixes received from a peer and are stored in the Adj-Ribs-In for that peer. Note that this number does not reflect prefixes that have been discarded due to policy.

Gauge32

Reference: RFC 4271, Sections 3.2 and 9.

The number of prefixes for a peer that are installed in the Adj-Ribs-In and are eligible to become active in the Loc-Rib.

Gauge32

Reference: RFC 4271, Sections 3.2 and 9.

The number of prefixes for a peer that are installed in that peer's Adj-Ribs-Out.

Unsigned32 (1..4294967295)

Reference: RFC 3107 - Carrying Label Information in BGP-4.

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.

AristaBgp4V2AddressFamilyIdentifierTC1 = ipv42 = ipv6The representation of a BGP AFI. The value of this object should be restricted to be between the values of 0 and 65535.Reference: RFC 4760, Section 3 · Integer32

Reference: RFC 4760 - Multiprotocol Extensions for BGP-4

The address family of the prefix for this NLRI. Note that the AFI is not necessarily equivalent to the an InetAddressType.

AristaBgp4V2SubsequentAddressFamilyIdentifierTC1 = unicast2 = multicast4 = mplsThe representation of a BGP SAFIReference: RFC 4760, Section 3. The value of this object should be restricted to be between the values of 0 and 255. · Integer32

Reference: RFC 4760 - Multiprotocol Extensions for BGP-4

The subsequent address family of the prefix for this NLRI

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

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 aristaBgp4V2NlriAfi field. Where an appropriate InetAddressType is not available, the value of the object must be unknown(0).

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

Reference: RFC 4271, Section 4.3.

An IP address prefix in the Network Layer Reachability Information field. This object is an IP address containing the prefix with length specified by aristaBgp4V2NlriPrefixLen. Any bits beyond the length specified by aristaBgp4V2NlriPrefixLen are zeroed. An implementation is required to support IPv4 prefixes. In this case, the object length is (0..4). An implementation MAY support IPv6 prefixes. In this case, the object length is (0..16)

InetAddressPrefixLengthDenotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0. An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength textual convention, if they appear in the same logical row. InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value for the InetAddressType 'dns(16)' is 0. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply. The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress. (0..2040) · Unsigned32 · hint d

Length in bits of the address prefix in the Network Layer Reachability Information field.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Reference: RFC 4271, Section 9.1.2.

An indication of whether or not this route was chosen as the best BGP4 route for this destination.

Unsigned32

Reference: RFC 4271, Section 9.1.1

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).

INTEGER1 = igp2 = egp3 = incomplete · Integer32

Reference: RFC 4271, Section 4.3. RFC 4271, Section 5.1.1.

The ultimate origin of the path information.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

The address family of the address for the border router that should be used to access the destination network.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (4..20) · OCTET STRING

Reference: RFC 4271, Section 4.3, RFC 4271, Section 5.1.3, RFC 2545, Section 3.

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 will contain the linklocal scope nexthop, if it is present. In the case a mechanism is developed to use only a link local nexthop, aristaBgp4V2NlriNextHopAddr will contain the link local nexthop.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Reference: RFC 2545, Section 3.

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).

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

Reference: RFC 2545, Section 3.

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.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This value is true when the LOCAL_PREF value was sent in the UPDATE message.

Unsigned32

Reference: RFC 4271, Section 4.3. RFC 4271, Section 5.1.5.

The originating BGP4 speakers degree of preference for an advertised route.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This value is true when the MED value was sent in the UPDATE message.

Unsigned32

Reference: RFC 4271, Section 4.3. RFC 4271, Section 5.1.4.

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.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

Reference: RFC 4271, Sections 5.1.6 and 9.1.4.

This value is true when the ATOMIC_AGGREGATE Path Attribute is present and indicates that the NLRI MUST NOT be made more specific.

TruthValue1 = true2 = falseRepresents a boolean value. · Integer32

This value is true when the AGGREGATOR path attribute was sent in the UPDATE message.

InetAutonomousSystemNumberRepresents an autonomous system number that identifies an Autonomous System (AS). An AS is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes'. IANA maintains the AS number space and has delegated large parts to the regional registries. Autonomous system numbers are currently limited to 16 bits (0..65535). There is, however, work in progress to enlarge the autonomous system number space to 32 bits. Therefore, this textual convention uses an Unsigned32 value without a range restriction in order to support a larger autonomous system number space.Reference: RFC 1771, RFC 1930 · Unsigned32 · hint d

Reference: RFC 4271, Section 5.1.7. RFC 4271, Section 9.2.2.2.

The AS number of the last BGP4 speaker that performed route aggregation. When aristaBgp4V2NlriAggregatorPresent is false, the value of this object should be zero (0).

AristaBgp4V2IdentifierTCThe representation of a BGP Identifier. BGP Identifiers are presented in the received network byte order. The BGP Identifier is displayed as if it is an IP address, even if it would be an illegal one.Reference: RFC 4273, Section 4.2 SIZE (4) · OCTET STRING · hint 1d.

Reference: RFC 4271, Section 5.1.7. RFC 4271, Section 9.2.2.2.

The IP address of the last BGP4 speaker that performed route aggregation. When aristaBgp4V2NlriAggregatorPresent is false, the value of this object should be 0.0.0.0

Unsigned32

Reference: RFC 4271, Section 9.1.2.2.a

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.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t

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, '...'. aristaBgp4V2NlriAsPath may give access to the full AS Path.

OCTET STRING SIZE (2..4072)

Reference: RFC 4271, Section 4.3. RFC 5065, Section 5. RFC 4893.

In order to provide a canonicalized form of the BGP-4 AS_PATH along with the human-readable aristaBgp4V2NlriAsPathString, 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 ASes as defined in RFC 4893. RFC 4271, Section 4.3, 'Path Attributes: b) AS_PATH' as amended by RFC 5065, Section 3 defines the general format of the AS_PATH path attribute and its code points. In brief, 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: 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.

OCTET STRING SIZE (0..4072)

Reference: RFC 4271, Section 4.3.

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.

Unsigned32 (1..4294967295)

Certain extensions to BGP permit multiple instance of a per afi, per safi prefix to be advertised to a peer. This object allows the enumeration of them.

RowPointerRepresents a pointer to a conceptual row. The value is the name of the instance of the first accessible columnar object in the conceptual row. For example, ifIndex.3 would point to the 3rd row in the ifTable (note that if ifIndex were not-accessible, then ifDescr.3 would be used instead). · OBJECT IDENTIFIER

Reference: RFC 4271, Section 9.2.

This object points to the route in the aristaBgp4V2NlriTable that corresponds to the entry in the peer's Adj-Rib-Out. Outgoing route maps are not reflected at this point as those are part of the Update-Send process.