BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Description

BGP/2/BACKWARD:OID [oid] The BGP FSM moves from a higher numbered state to a lower numbered state. (BgpPeerRemoteAddr=[ipaddr], InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], InterfaceIndex=[integer], BgpPeerLastError=[octet], BgpPeerState=[integer], BgpPeerUnavaiReason=[gauge], InterfaceName=[octet])

Indicates that this trap was generated when the BGP state machine moved from a higher numbered state, namely, Openconfirm or Established, to a lower numbered state.

Attribute

Alarm ID	Alarm Severity	Alarm Type
1.3.6.1.2.1.15.7.2	Major	communicationsAlarm(2)

Parameters

Name	Meaning
oid	Indicates the MIB object ID of the alarm.
BgpPeerRemoteAddr	Indicates the address of the peer.
InstanceId	Instance ID
Afi	Address family
Safi	Sub-address family
PeerType	Peer type
PeerRemoteAddr	Peer address
InterfaceIndex	Interface index
BgpPeerLastError	Indicates the error code of the BGP Notification when the neighbor relationship is disconnected for the last time. The value is expressed in the format of [ErrorCode][ErrorSubCode]. [ErrorCode] refers to the error code and [ErrorSubCode] refers to the error subcode. Take the integer 35 as an example, figure 3 is the error code and figure 5 is the error subcode. For detailed information about the error code, refer to BGP Error Code. If the value is 0, it indicates that no error occurs.
BgpPeerState	Indicates the status of the BGP peer. 1 Idle: indicates that BGP denies any request of entering. This is the initiatory status of BGP. Upon receiving a Start event, BGP initiates a TCP connection to the remote BGP peer, starts the ConnectRetry Timer with the initial value, detects a TCP connection initiated by the remote BGP peer, and changes its state to Connect. 2 Connect: indicates that BGP performs other actions after the TCP connection is set up. If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent. If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active. If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value, initiates a TCP connection to the remote BGP peer, and stays in the Connect state. 3 Active: indicates that BGP tries to set up TCP connection. This is the intermediate status of BGP. If the TCP connection succeeds, BGP stops the ConnectRetry Timer, sends an Open message to the remote peer, and changes its state to OpenSent. If the ConnectRetry Timer has expired before a TCP connection is established, BGP restarts the timer with the initial value and changes its state to Connect. If BGP initiates a TCP connection with an unknown IP address, the TCP connection fails. When this occurs, BGP restarts the ConnectRetry Timer with the initial value and stays in the Active state. 4 OpenSent: indicates that BGP has sent one Open message to its peer and waits for the other Open message from the peer. If there are no errors in the Open message received, BGP changes its state to OpenConfirm. If there are errors in the Open message received, BGP sends a Notification message to the remote peer and changes its state to Idle. If the TCP connection fails, BGP restarts the ConnectRetry Timer with the initial value, continues to detect a TCP connection initiated by the remote peer, and changes its state to Active. 5 OpenConfirm: indicates that BGP waits for a Notification message or a Keepalive message. If BGP receives a Notification message, or the TCP connection fails, BGP changes its state to Idle. If BGP receives a Keepalive message, BGP changes its state to Established. 6 Established: indicates that BGP peers can exchange Update, Notification and Keepalive packets. If BGP receives an Update or a Keepalive message, its state stays in Established. If BGP receives a Notification message, BGP changes its state to Idle.
BgpPeerUnavaiReason	Cause for the peer disconnection 1 Configuration lead peer down: The configuration causes the peer disconnection. 2 Receive notification: Notification packets are received. 3 Receive error packet: Error packets are received. 4 Hold timer expire: The Hold timer expires. 5 Remote peer not reachable: The remote peer is unreachable. 6 Direct connect-interface down: The directly connected interface is Down. 7 Route limit: The number of routes exceeds the upper limit.
InterfaceName	Interface name

Impact on the System

The BGP neighbor will be disconnected, and the BGP route received from the neighbor will be deleted. The packet forwarding based on the BGP route will fail.

Possible Causes

1. The BGP holdtimer timed out and did not receive the Keepalive packet.

2. BGP received incorrect BGP packets.

3. The BGP neighbor relationship was reset and the neighbor relationship was automatically interrupted.

4. BGP received Notification packets from the neighbor.

Procedure

Run the display bgp peer ipv4-addresses log-info command to check the Error field in the command output. You can view the Error Code and Sub Error Code in the received Notification in the form of [ErrorCode][ErrorSubCode].
- If the error code of the Notification is 1, it indicates that the BGP module receives the packet with incorrect headers. Then, go to Step 23.
- If the error code of the Notification is 2, it indicates that the BGP module receives the incorrect Open packet. Then, go to Step 23.
- If the error code of the Notification is 3, it indicates that the BGP module receives the incorrect Update packet. Then, go to Step 23.
- If the error code of the Notification is 4, it indicates that till the Holdtimer times out, the BGP module does not receive the Keepalive packet. Then, go to Step 4.
- If the error code of the Notification is 5, it indicates that the finite state machine of the BGP module is faulty. Then, go to Step 23.
- If the error code of the Notification is 6, go to Step 2.
If the error code of the Notification is 6, it indicates that BGP automatically closes the connection. Then, you need to run the display bgp peer ipv4-address log-info command to view the Notification field and check whether the Notification is sent by the switch that generates the trap.
- If "Send Notification" is displayed, it indicates that the local switch actively sends the Notification. Then, go to Step 3.
- If "Receive Notification" is displayed, it indicates that the local switch receives the Notification. Then, go to Step 22.
Search for the reset bgp all and reset bgp ipv4-address commands in the user logs to check whether BGP is reset on the local end; or search for the peer ipv4-address enable command to check whether the peer is enabled in other address families on the local, or parameters for the BGP connection are configured.
- If so, it indicates that incorrect configurations cause the trap, and therefore no action is required. Then, go to Step 24.
- If not, go to Step 23.
If the error code is 4, it indicates that the BGP disconnection is caused by the timeout of the Holdtimer. Then, you need to check whether the address of the BGP neighbor can be pinged successfully.
- If so, go to Step 21.
- If not, go to Step 5.
Run the display ip routing-table command to check whether the Destination/Mask field has the route to the peer address.
- If so, go to Step 7.
- If not, go to Step 8.
Run the display acl all command to check whether the switch is configured with the ACL that disables TCP port 179.
- If so, go to Step 9.
- If not, go to Step 10.
Run the display ip interface command to check whether the values of Physical and Protocol fields of the outbound interface are Up.
- If so, go to Step 23.
- If not, go to Step 11.
Check the origin of the route with the BGP peer address.
- If the route is originated from OSPF, go to Step 12.
- If the route is originated from IS-IS, go to Step 13.
- Else, go to Step 23.
Delete the ACL that disables the TCP port 179, and check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.
- If so, go to Step 24.
- If not, go to Step 10.
Check the BGP configuration to see whether loopback interfaces are used to establish BGP peers.
- If so, go to Step 14.
- If not, go to Step 15.
Enter the view of the outbound interface, and run the display this command to check whether the interface is shut down.
- If so, run the undo shutdown command to enable the interface.
- If not, go to Step 22.
Run the display ospf peer command to check whether the OSPF peer relationship is established.
- If so, go to Step 23.
- If not, refer to the solution provided in the case of trap OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange.
Run the display isis peer command to check whether the IS-IS peer relationship is established.
- If so, go to Step 23.
- If not, refer to the solution provided in the case of trap ISIS_1.3.6.1.3.37.2.0.13 isisRejectedAdjacency.
Check whether the peer connect-interface is configured for specifying the source address.
- If so, go to Step 15.
- If not, go to Step 16.
If BGP is the EBGP neighbor relationship and multiple hops exist between EBGP neighbors, check whether the peer ebgp-max-hop is configured.
- If so, go to Step 17.
- If not, go to Step 19.
Configure the peer connect-interface command. The parameter in the command must be the local interface that establishes a connection with the peer. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.
- If so, go to Step 24.
- If not, go to Step 23.
Check whether the peer valid-ttl-hops hops command is configured.
- If so, go to Step 18.
- If not, go to Step 23.
If the peer valid-ttl-hops hops is configured, check whether the TTL of the packet to the peer ranges from [255-hops+1] to 255.
- If so, go to Step 23.
- If not, go to Step 20.
Configure the peer ebgp-max-hop. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.
- If so, go to Step 24.
- If not, go to Step 23.
Changed the value of the peer valid-ttl-hops hops and make it within the range from [255-hops+1] to 255. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.
- If so, go to Step 24.
- If not, go to Step 23.
Run the display cpu-usage command to check whether the CPU usage remains 100% in a period.
- If so, go to Step 23.
- If not, go to Step 6.
Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer switch, the peer is enabled in other address families on the local, and parameters for BGP connection are configured. Then, check whether the trap BGP_1.3.6.1.2.1.15.7.1 bgpEstablished appears later.
- If so, go to Step 24.
- If not, go to Step 23.
Collect alarm information and configuration information, and then contact technical support personnel.
End.

Related Information

BGP_1.3.6.1.2.1.15.7.1 bgpEstablished