Contents

HH3C-BGP4V2-MIB· 1

About this MIB· 1

MIB file name· 1

Notifications· 1

hh3cBgp4v2Established· 1

hh3cBgp4v2BackwardTransition· 2

 

 

HH3C-BGP4V2-MIB

About this MIB

Use this MIB to obtain MBGP or MP-BGP information.

MIB file name

hh3c-bgp4v2.mib

Notifications

hh3cBgp4v2Established

Basic information

OID	Event	Type	Severity	Recovery notification	Default status
1.3.6.1.4.1.25506.2.183.0.1	A peer session enters Established state	Recovery	Major	N/A (N/A)	ON

 

Notification triggers

This notification is generated when the BGP session to a BGP peer is successfully established.

System impact

The BGP session is correctly established.

Status control

ON

CLI: Use the snmp-agent trap enable bgp [ peer-established ] commands.

OFF

CLI: Use the undo snmp-agent trap enable bgp [ peer-established ] commands.

Object

OID (object name)	Description	Index	Type	Value range
1.3.6.1.4.1.25506.2.183.1.1.1.1  (hh3cBgp4v2PeerRemoteAddr)	Remote IP address of the peer connection.	hh3cBgp4v2PeerRemoteAddr	InetAddressIPv6	OCTET STRING (16|20)
1.3.6.1.4.1.25506.2.183.1.1.1.2  (hh3cBgp4v2PeerLastError)	Error code and subcode for the most recent peer connection error.	hh3cBgp4v2PeerRemoteAddr	DisplayString	OCTET STRING (2)
1.3.6.1.4.1.25506.2.183.1.1.1.3 (hh3cBgp4v2PeerState)	Peer connection state.	hh3cBgp4v2PeerRemoteAddr	INTEGER	idle(1), connect(2), active(3), opensent(4), openconfirm(5), established(6)

 

Recommended action

No action is required.

hh3cBgp4v2BackwardTransition

Basic information

OID	Event	Type	Severity	Recovery notification	Default status
1.3.6.1.4.1.25506.2.183.0.2	The state of a peer changes.	Error	Major	1.3.6.1.4.1.25506.2.183.0.1 (hh3cBgp4v2Established)	ON

 

Notification triggers

This notification is generated when the state of a BGP peer session transitions from an upper level (for example, Established) to a lower level (for example, OpenConfirm). A typical example is that the BFD session is disconnected. Possible reasons for generating this notification are as follows:

Incorrect BGP configuration.

BGP receives a notification because an error event occurs.

BGP message receiving or sending times out.

The BGP peer IP address is unreachable.

An incorrect BGP packet is received.

The directly connected BGP interface goes down.

The number of BGP routes exceeds the maximum number of BGP routes that can be received.

System impact

The device might not have the associated BGP route to guide traffic forwarding, resulting in service interruption.

Status control

ON

CLI: Use the snmp-agent trap enable bgp [ peer-backward-transition ] command.

OFF

CLI: Use the undo snmp-agent trap enable bgp [ peer-backward-transition ] command.

Object

OID (object name)	Description	Index	Type	Value range
1.3.6.1.4.1.25506.2.183.1.1.1.1  (hh3cBgp4v2PeerRemoteAddr)	Remote IP address of the peer connection.	hh3cBgp4v2PeerRemoteAddr	InetAddressIPv6	OCTET STRING (16|20)
1.3.6.1.4.1.25506.2.183.1.1.1.2  (hh3cBgp4v2PeerLastError)	Error code and subcode for the most recent peer connection error.	hh3cBgp4v2PeerRemoteAddr	DisplayString	OCTET STRING (2)
1.3.6.1.4.1.25506.2.183.1.1.1.3 (hh3cBgp4v2PeerState)	Peer connection state.	hh3cBgp4v2PeerRemoteAddr	INTEGER	idle(1), connect(2), active(3), opensent(4), openconfirm(5), established(6)

 

Recommended action

To resolve the issue:

1.Execute the display current-configuration configuration bgp command to identify the settings that affect BGP session state.

  - If a setting that causes BGP session disconnection exists, execute the relevant command to cancel the setting.

  - If BGP uses a loopback interface as the source interface of TCP connections, execute the peer connect-interface or peer source-address command to specify the loopback interface as the source interface for establishing TCP connections.

  - To establish an EBGP session to an indirectly connected peer, make sure the peer ebgp-max-hop command is executed on both ends of the session.

  - If the peer ttl-security command is configured to enable BGP GTSM on the device, the device receives the BGP packets with a TTL in the range from 255 – the configured hop count + 1 to 255.

  - If no settings affect BGP session state, proceed to step 2.

2.Wait for a short period of time to exclude the cause of disconnection by BGP session reset. If the BGP session fails to restore to the Established state within a long period of time, proceed to step 3.

3.Execute the display current-configuration configuration bgp command to check for the configuration of the peer route-limit command, and the BGP/4/BGP_EXCEED_ROUTE_LIMIT log printed by the device.

  - If both the configuration and the log exist, the BGP session is disconnected because excessive BGP routes are received. In this case, verify that the maximum number of routes that can be received configured with the peer route-limit command is appropriate:

If the setting is appropriate, notify the administrator of the BGP peer to reduce the number of BGP routes sent to the local end.

If the setting is inappropriate, increase the maximum number of BGP routes that can be received on the local end.

  - If the configuration or the log does not exist, or neither of them exists, receiving excessive BGP routes is not the cause for the BGP session disconnection. In this case, proceed to step 4.

4.Execute the display bgp peer log-info command. From the command output, identify the BGP session disconnection cause based on the error code or subcode printed in the Notification Error/SubError field.

  - If the error code (Error) is 4, the local end fails to receive any keepalive or update messages from the peer end within the BGP session hold time. This results in BGP session disconnection. If the error code is 5 or 6, the BGP session is disconnected because the TCP connection has an error or the connection is actively disconnected. You can perform troubleshooting by using the following methods:

On the local end, ping the source address used for establishing TCP connections on the BGP peer. If the ping operation fails, execute the display ip routing-table command to identify whether a route is available to the BGP peer. If no routes are available to the BGP peer, troubleshoot IGP route, static route, or direct route settings.

Execute the display memory-threshold command to identify whether the device has reached the memory usage threshold. If the memory usage threshold is reached, proceed to step 5.

Execute the display cpu-usage command to identify whether the CPU usage is too high. If the CPU usage is too high, proceed to step 5.

Execute the display acl all command to identify whether a rule exists that denies port bgp or 179. If such an ACL exists, delete the ACL.

Execute the display interface command to identify whether the output interface associated with the next hop of the route to the BGP peer is up. If the output interface is down, execute the undo shutdown command to bring up the interface in the view of the interface. If the interface fails to be brought up, or the interface is up but the notification persists, proceed to step 5.

  - If the error code (Error) is 1 or 3, the device has received wrong BGP packets. Proceed to step 5.

5.If the issue persists, collect alarm information, configuration data, and the output information from the previous commands, and then contact H3C Support for help.