BGP_1.3.6.1.2.1.15.0.2 bgpBackwardTransNotification

Trap Buffer Description

The BGP FSM moves from a higher numbered state to a lower numbered state. (BgpPeerRemoteAddr=[PeerIpv4Addr], BgpPeerLastError=[PeerLastError], BgpPeerState=[PeerState],VpnInstance=[VpnInstance])

The BGP peer relationship is interrupted.

Trap Attributes

Trap Attribute Description

Alarm or Event

Event

Trap Severity

Critical

Mnemonic Code

PEER_BACKWARDTRANS_NOTIFICATION

Trap OID

1.3.6.1.2.1.15.0.2

MIB

BGP4-MIB

Alarm ID

This is an event trap and does not involve alarm ID.

Alarm Name

This is an event trap and does not involve alarm name.

Alarm Type

This is an event trap and does not involve alarm type.

Raise or Clear

This is an event trap and does not involve alarm generation or clearance.

Match trap

-

Trap Buffer Parameters

Parameter Description

PeerIpv4Addr

The address of the BGP peer. This log is reported to the NMS based on the bgpBackwardTransNotification object in the public MIB (Bgp4-mib.mib). This MIB object applies to IPv4 peers, not to IPv6 peers. As a result, this log is not reported if IPv6 peer status changes. In this case, you need to query the bgpBackwardTransition alarm on the device.

PeerLastError

The value of the Error Code field in the Notification packet generated when the peer relationship was interrupted last time.

PeerState

The status of the BGP peer.

VpnInstance

The name of the VPN instance.

VB Parameters

VB OID VB Name VB Index

1.3.6.1.2.1.15.3.1.7

bgpPeerRemoteAddr

bgpPeerRemoteAddr

1.3.6.1.2.1.15.3.1.14

bgpPeerLastError

bgpPeerRemoteAddr

1.3.6.1.2.1.15.3.1.2

bgpPeerState

bgpPeerRemoteAddr

Impact on the System

The BGP peer relationship is interrupted, the route from the local device to the remote device is unreachable, and BGP forwarding services are interrupted.

Possible Causes

Cause 1: The BGP peer was disconnected due to BGP configurations. Cause 2: The local device received a Notification message. Cause 3: The local device received error packets. Cause 4: The BGP hold timer expired. Cause 5: The BGP peer was unreachable. Cause 6: The directly connected BGP interface was disconnected. Cause 7: The number of BGP routes exceeded the upper threshold.

Procedure

Cause 1: Incorrect configurations caused the BGP peer relationship interruption.

1. Check whether the interruption was caused by improper configuration.

  • If yes, go to Step 2.
  • If no, go to Step 3.

2. Delete the improper configuration to restore the connection.

3. Check whether the BGP connection is reset. Wait for a while and then check whether the connection can be re-established.

4. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 2: Notification packets were received.

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. 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, perform to 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 source is 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.

  • Yes: 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 no, go to the next step. For details, 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 no, go to the next step. For details, 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 establish the 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, run the peer valid-ttl-hops hops command to set the TTL of the packets sent to the peer 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 function is enabled in another address family on the local device, or whether BGP connection parameters are set.

  • If any of the preceding operations has been performed, wait for a while and check whether the alarm is cleared.
  • If the alarm persists, go to Step 17.

17. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 3: BGP received error packets.

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 1, BGP has received a packet with an incorrect header. Go to Step 2.
  • If the value of Error Code in the Notification packet is 2, BGP has received an incorrect Open message. Go to Step 2.
  • If the value of Error Code in the Notification packet is 3, BGP has received an incorrect Update packet. Go to Step 2.

2. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 4: The BGP hold timer expired.

1. Run the ping command to check whether the BGP peer address can be pinged.

  • If yes, 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, perform to 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 configuration information for the origin 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.

  • Yes: 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 no, go to the next step. For details, 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 no, go to the next step. For details, 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 establish the 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, 255.

  • Yes: Go to Step 14.
  • If not, run the peer valid-ttl-hops hops command to set the TTL of the packets sent to the peer within the range of 255-hops+1, 255.

14. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer device, whether the peer function is enabled in another address family on the local device, or whether BGP connection parameters are set.

  • If any of the preceding operations has been performed, wait for a while and check whether the alarm is cleared.

15. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 5: The BGP peer was unreachable.

1. Run the ping command to check whether the IP address of the BGP peer can be pinged.

  • If yes, 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, perform to 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 configuration information for the origin 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.

  • Yes: 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 no, go to the next step. For details, 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 no, go to the next step. For details, 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 establish the 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, 255.

  • Yes: Go to Step 14.
  • If not, run the peer valid-ttl-hops hops command to set the TTL of the packets sent to the peer within the range of 255-hops+1, 255.

14. Contact the maintenance personnel of the peer device to check whether BGP is reset on the peer device, whether the peer function is enabled in another address family on the local device, or whether BGP connection parameters are set.

  • If the preceding operations have been performed, wait for one minute.Wait for a while and check whether the alarm is cleared.

15. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 6: The originally interconnected interfaces were disconnected.

1. Check whether the shutdown command is executed on the interface.

  • If so, run the undo shutdown command on the interface.- If the alarm persists, go to Step 2.
  • If no, go to step 2.

2. Collect log and configuration information, and contact Huawei technical support personnel.

Cause 7: The number of BGP routes exceeded the upper limit.

1. Check whether the peer route-limit command is configured and whether the number of current routes exceeds the upper limit.

  • If yes, go to Step 2.
  • If no, go to Step 3.

2. Check whether the peer route-limit command is necessary.

  • If necessary, reduce the number of routes to ensure that the number of routes is smaller than the upper limit specified by route-limit.
  • If the upper limit is unnecessary, run the undo peer route-limit command to delete it.

3. Collect log and configuration information, and contact Huawei technical support personnel.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >