BGP/2/bgpBackwardTransition_active: The BGP FSM moves from a higher numbered state to a lower numbered state. (BgpPeerRemoteAddr=[PeerIpv4Ipv6Addr], BgpPeerLastError=[PeerLastError], BgpPeerState=[PeerState], LocalIfName=[LocalIfName], Reason=[Reason], Description=[Description])
The BGP FSM moved from a higher numbered state, namely, Openconfirm or Established, to a lower numbered state.
| Parameter Name | Parameter Meaning |
|---|---|
|
PeerIpv4Ipv6Addr |
Peer address. |
|
PeerLastError |
Error code returned when the peer was disconnected last time. The value of this parameter is displayed in the format of [ErrorCode][ErrorSubCode], where [ErrorCode] indicates an error code and [ErrorSubCode] indicates an error subcode.For example, in the value 35, 3 indicates an error code and 5 indicates an error subcode.The value 0 indicates that no error occurs.For the meanings and possible causes of error codes, see the NOTIFICATION packet in BGP Principles - BGP Packet Format. The NOTIFICATION packet is used to process various errors in the BGP process. |
|
PeerState |
Status of the BGP peer relationship. |
|
LocalIfName |
Local interface name. |
|
Reason |
Reason why the peer relationship is interrupted. - Configuration lead peer down: The configuration causes the peer disconnection. - Receive notification: Notification packets are received. - Receive error packet: Error packets are received. - Hold timer expire: The Hold timer expires. - Remote peer not reachable: The remote peer is unreachable. - Direct connect-interface down: The directly connected interface is Down. - Route limit: The number of routes exceeds the upper limit. |
|
Description |
Description of a neighbor. |
1. Check whether the BGP peer relationship is interrupted because of the improper configurations of the local device. - If the configurations of the local device are improper, go to Step 2. - If the configurations of the local device are proper, go to Step 3. 2. Delete the configurations that cause the interruption of the peer relationship. 3. Check whether the BGP connection is reset. If the BGP connection is reset, wait for a while and then check whether the BGP connection is re-established. - If the BGP connection is not reset, go to Step 4. - If the BGP connection is reset, wait for a while and then check whether the BGP connection is re-established. If the BGP connection is not re-established, go to Step 4. Collect alarm information and configuration information, and then contact technical support personnel.
1. Run the display bgp peer ip-address log-info command to check the notification information when the BGP connection is torn down. - If the value of Error Code in the Notification packet is 4, the BGP Holdtimer expires and no Keepalive packet is received. In this case, go to Step 3. - If the value of Error Code in the Notification packet is 5, an error occurs on the BGP FSM. Go to step 17. - If the value of Error Code in the Notification packet is 6, BGP proactively terminated the connection. In this case, go to Step 2. 2. Run the display bgp peer ip-address log-info command to check whether the notification is sent by the device that generates the alarm. - Yes: Go to Step 3. - If no, go to Step 4. 3. Run the ping command to check whether the IP address of the BGP peer can be pinged. - Yes: Go to Step 4. - If no, go to Step 5. 4. Run the display cpu-usage command to check whether the CPU usage is too high. - Yes: Go to Step 17. - If no, go to Step 6. 5. Run the display ip routing-table command to check whether the BGP peer address routing table exists. - Yes: Go to Step 7. - If no, go to Step 8. 6. Run the display acl command to check whether an ACL is configured to disable TCP port 179. - If yes, delete the ACL that denies TCP port 179. - If no, go to Step 9. 7. Run the display interface command to check whether the outbound interface of the route is Up. - Yes: Go to Step 17. - If not, go to step 10. 8. Check the configuration information for the origin of the route to the BGP peer address. - If the route source is OSPF, go to Step 11. - If the route originates from IS-IS, go to Step 12. 9. Check the BGP configuration to see whether the loopback interface is applied. - Yes: Go to Step 13. - If not, go to step 14. 10. Check whether the shutdown command is run on the interface. - If so, run the undo shutdown command on the interface.If the alarm persists, go to Step 13. - If not, go to Step 17. 11. Run the display ospf peer command to check whether the OSPF peer relationship is established. - Yes: Go to Step 17. - If not, see the procedure for handling the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm. 12. Run the display isis peer command to check whether the IS-IS peer relationship is established. - Yes: Go to Step 17. - If not, see the procedure for handling the ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange alarm. 13. Check whether a source address is specified for the BGP connection. - Yes: Go to Step 14. - If not, run the peer connect-interface command to specify the source address used to initiate a BGP connection. 14. If the BGP peer is an EBGP peer and multiple hops exist between EBGP peers, check whether the peer ebgp-max-hop command is configured. - Yes: Go to Step 15. - If not, run the peer ebgp-max-hop command. 15. If the peer valid-ttl-hops hops command is configured, check whether the TTL of the packet received from the peer is within the range of 255-hops+1 to 255. - Yes: Go to Step 16. - If not, reconfigure the peer valid-ttl-hops hops command to ensure that the TTL of the packets sent to the peer is within the range of 255-hops+1 to 255. 16. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in another address family view on the local device, or whether BGP connection parameters are set.If any of these operations has been performed, wait for a while and then check whether the alarm is cleared.If the alarm persists, go to Step 17. 17. Collect alarm and configuration information, and contact technical support personnel.
1. Run the display bgp peer ip-address log-info command to check the Notification packet sent by the local device when the BGP peer relationship is interrupted. - If the value of the Error Code field in the Notification packet is 1, a packet with an error header has been received. Go to Step 2. - If the value of the Error Code field in the Notification packet is 2, an error Open packet has been received. Go to Step 2. - If the value of the Error Code field in the Notification packet is 3, an error Update packet has been received. Go to Step 2. 2. Collect alarm information and configuration information, and then contact technical support personnel.
1. Run the ping command to check whether the IP address of the BGP peer can be pinged. - If so, go to step 2. - If no, go to Step 3. 2. Run the display cpu-usage command to check whether the CPU usage is too high. - Yes: Go to Step 15. - If no, go to Step 4. 3. Run the display ip routing-table command to check whether the BGP peer address routing table exists. - Yes: Go to Step 5. - If no, go to Step 6. 4. Run the display acl command to check whether an ACL is configured to disable TCP port 179. - If yes, delete the ACL that denies TCP port 179. - If no, go to Step 7. 5. Run the display interface command to check whether the outbound interface of the route is Up. - Yes: Go to Step 15. - If no, go to Step 8. 6. Check the source of the route to the BGP peer address. - If the route source is OSPF, go to Step 9. - If the route originates from IS-IS, go to Step 10. 7. Check the BGP configuration to see whether the loopback interface is applied. - Yes: Go to Step 11. - If no, go to Step 12. 8. Check whether the shutdown command is run on the interface. - Run the undo shutdown command on the interface.If the alarm persists, go to Step 11. - If no, go to Step 15. 9. Run the display ospf peer command to check whether the OSPF peer relationship is established. - Yes: Go to Step 15. - If not, see the procedure for handling the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm. 10. Run the display isis peer command to check whether the IS-IS peer relationship is established. - Yes: Go to Step 15. - If not, see the procedure for handling the ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange alarm. 11. Check whether a source address is specified for the BGP connection. - Yes: Go to Step 12. - If not, run the peer connect-interface command to specify the source address used to initiate a BGP connection. 12. If the BGP peer is an EBGP peer and multiple hops exist between EBGP peers, check whether the peer ebgp-max-hop command is configured. - Yes: Go to Step 13. - If not, run the peer ebgp-max-hop command. 13. If the peer valid-ttl-hops hops command is configured, check whether the TTL of the packet received from the peer is within the range of 255-hops+1 to 255. - Yes: Go to Step 14. - If not, reconfigure the peer valid-ttl-hops hops command to ensure that the TTL of the packets sent to the peer is within the range of 255-hops+1 to 255. 14. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in another address family view on the local device, or whether BGP connection parameters are set.If any of these operations has been performed, wait for a while and then check whether the alarm is cleared.If the alarm persists, go to Step 15. 15. Collect alarm and configuration information, and contact technical support personnel.
1. Run the ping command to check whether the IP address of the BGP peer can be pinged. - If so, go to step 2. - If no, go to Step 3. 2. Run the display cpu-usage command to check whether the CPU usage is too high. - Yes: Go to Step 15. - If no, go to Step 4. 3. Run the display ip routing-table command to check whether the BGP peer address routing table exists. - Yes: Go to Step 5. - If no, go to Step 6. 4. Run the display acl command to check whether an ACL is configured to disable TCP port 179. - If yes, delete the ACL that denies TCP port 179. - If no, go to Step 7. 5. Run the display interface command to check whether the outbound interface of the route is Up. - Yes: Go to Step 15. - If no, go to Step 8. 6. Check the source of the route to the BGP peer address. - If the route source is OSPF, go to Step 9. - If the route originates from IS-IS, go to Step 10. 7. Check the BGP configuration to see whether the loopback interface is applied. - Yes: Go to Step 11. - If no, go to Step 12. 8. Check whether the shutdown command is run on the interface. - Run the undo shutdown command on the interface.If the alarm persists, go to Step 11. - If no, go to Step 15. 9. Run the display ospf peer command to check whether the OSPF peer relationship is established. - Yes: Go to Step 15. - If not, see the procedure for handling the OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange alarm. 10. Run the display isis peer command to check whether the IS-IS peer relationship is established. - Yes: Go to Step 15. - If not, see the procedure for handling the ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange alarm. 11. Check whether a source address is specified for the BGP connection. - Yes: Go to Step 12. - If not, run the peer connect-interface command to specify the source address used to initiate a BGP connection. 12. If the BGP peer is an EBGP peer and multiple hops exist between EBGP peers, check whether the peer ebgp-max-hop command is configured. - Yes: Go to Step 13. - If not, run the peer ebgp-max-hop command. 13. If the peer valid-ttl-hops hops command is configured, check whether the TTL of the packet received from the peer is within the range of 255-hops+1 to 255. - Yes: Go to Step 14. - If not, reconfigure the peer valid-ttl-hops hops command to ensure that the TTL of the packets sent to the peer is within the range of 255-hops+1 to 255. 14. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in another address family view on the local device, or whether BGP connection parameters are set.If any of these operations has been performed, wait for a while and then check whether the alarm is cleared.If the alarm persists, go to Step 15. 15. Collect alarm and configuration information, and contact technical support personnel.
1. Check whether the shutdown command is run on the directly connected interface. 2. Collect alarm information and configuration information, and then contact technical support personnel.
1. Check whether the peer route-limit command is run and whether the number of routes exceeds the upper threshold. - If the command is run and the number of received routes exceeds the upper threshold, go to Step 2. - If the command is not run or the command is run but the number of received routes does not exceed the upper threshold, go to Step 3. 2. Check whether the peer route-limit command is necessary. If the command is necessary, reduce routes to ensure that the number of routes is smaller than the upper threshold. 3. Collect alarm information and configuration information, and then contact technical support personnel.