No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
MENU
Support Documentation

Log Reference

CloudEngine 8800, 7800, 6800, and 5800 V200R005C00

This document provides the explanations, causes, and recommended actions of logs on the product.

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
BGP/2/PEER_BACKWARDTRANS_NOTIFICATION

BGP/2/PEER_BACKWARDTRANS_NOTIFICATION

Message

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

Description

The BGP peer relationship is interrupted.

Parameters

Parameter Name Parameter Meaning

BgpPeerRemoteAddr

The address of the BGP peer.

NOTE:
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.

BgpPeerLastError

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

BgpPeerState

The status of the BGP peer.

VpnInstance

Name of a VPN instance

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: The BGP peer was disconnected due to BGP configurations.
    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.
    4. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 2: The local device received a Notification message.
    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 4, no Keepalive packet is received after the BGP hold timer expires. Then, go to Step 3.
      • If the value of the Error Code field in the Notification packet is 5, the BGP FSM is incorrect. Then, go to Step 17.
      • If the value of the Error Code field in the Notification packet is 6, the local device initiatively closes the BGP connection. Then, go to Step 2.

    2. Run the display bgp peer ip-address log-info command to check whether the Notification packet is sent by the device that generates the alarm.

      • If the Notification packet is sent by the device that generates the alarm, go to Step 3.
      • If the Notification packet is not sent by the device that generates the alarm, go to Step 4.

    3. Run the ping command to check whether the local device can successfully ping its peer.

      • If the local device pings its peer successfully, go to Step 4.
      • If the local device fails to ping its peer, go to Step 5.

    4. Run the display cpu command to check whether the CPU usage is too high.

      • If the CPU usage is too high, go to Step 17.
      • If the CPU usage is within the normal range, go to Step 6.

    5. Run the display ip routing-table command to check whether the route from the local device to its peer exists in the routing table.

      • If the route from the local device to its peer exists in the routing table, go to Step 7.
      • If the route from the local device to its peer does exist in the routing table, go to Step 8.

    6. Run the display acl command to check whether the device is configured with an ACL used to disable TCP port 179.

      • If the device is configured with such an ACL, delete the ACL.
      • If the device is not configured with such an ACL, go to Step 9.

    7. Run the display interface command to check whether the outbound interface of the route is Up.

      • If the outbound interface of the route is Up, go to Step 17.
      • If the outbound interface of the route is not Up, go to Step 10.

    8. Check the configuration of the local device and the origin of the route from the local device to its peer.

      • If the route is imported from OSPF, go to Step 11.
      • If the route is imported from IS-IS, go to Step 12.

    9. View the BGP configuration of the local device to check whether a loopback interface is used to establish the BGP connection.

      • If a loopback interface is used to establish the BGP connection, go to Step 13.
      • If no loopback interface is used to establish the BGP connection, go to Step 14.

    10. Check whether the shutdown command is run on the directly connected interface.

      • If the shutdown command is run on the interface, run the undo shutdown command on the interface. If the alarm is not cleared, go to Step 13.
      • If the shutdown command is not run on the interface. go to Step 17.

    11. Run the display ospf peercommand to check whether the OSPF peer relationship is established.

      • If the OSPF peer relationship is established, go to Step 17.
      • If no OSPF peer relationship is established, see the precessing steps in OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange.

    12. Run the display isis peer command to check whether the IS-IS peer relationship is established.

      • If the IS-IS peer relationship is established, go to Step 17.
      • If no IS-IS peer relationship is established, see the precessing steps in ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange.

    13. Check whether the source address used for initiating the BGP connection is specified.

      • If the source address is specified, go to Step 14.
      • If no source address is specified, run the peer connect-interface command to configure a source address used for initiating the BGP connection.

    14. If the BGP peer relationship is a multi-hop EBGP peer relationship, check whether the peer ebgp-max-hop command is run.

      • If the peer ebgp-max-hop command is run, go to Step 15.
      • If the peer ebgp-max-hop command is not run, run the peer ebgp-max-hop command.

    15. If the peer valid-ttl-hops hops command is run, check whether the TTL of the packet received from the remote end is within the range [255-hops+1, 255].

      • If the TTL of the packet is within the range, go to Step 16.
      • If the TTL of the packet is beyond the range, run the peer valid-ttl-hops hops command to ensure that the TTL of the packet sent to the remote peer is within the range.

    16. Contact the maintenance engineer responsible for the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in the view of another address family view on the local device, and whether BGP connection parameters are set. If any of the operations is performed, wait for a period of time, and then check whether the alarm is cleared.
    17. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 3: The local device received error packets.
    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.
      • If the value of the Error Code field in the Notification packet is 2, an error Open packet has been received.
      • If the value of the Error Code field in the Notification packet is 3, an error Update packet has been received.

    2. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 4: The BGP hold timer expired.
    1. Run the ping command to check whether the local device can successfully ping its peer.

      • If the local device pings its peer successfully, go to Step 2.
      • If the local device fails to ping its peer, go to Step 3.

    2. Run the display cpu command to check whether the CPU usage is too high.

      • If the CPU usage is too high, go to Step 15.
      • If the CPU usage is within the normal range, go to Step 4.

    3. Run the display ip routing-table command to check whether the route from the local device to its peer exists in the routing table.

      • If the route from the local device to its peer exists in the routing table, go to Step 5.
      • If the route from the local device to its peer does not exist in the routing table, go to Step 6.

    4. Run the display acl command to check whether the device is configured with an ACL used to disable TCP port 179.

      • If the device is configured with such an ACL, delete the ACL.
      • If the device is not configured with such an ACL, go to Step 7.

    5. Run the display interface command to check whether the outbound interface of the route is Up.

      • If the outbound interface of the route is Up, go to Step 15.
      • If the outbound interface of the route is not Up, go to Step 8.

    6. Check the configuration of the local device and the origin of the route from the local device to its peer.

      • If the route is imported from OSPF, go to Step 9.
      • If the route is imported from IS-IS, go to Step 10.

    7. Check the BGP configuration of the local device to check whether a loopback interface is used to establish the BGP connection.

      • If a loopback interface is used to establish the BGP connection, go to Step 11.
      • If no loopback interface is used to establish the BGP connection, go to Step 12.

    8. Check whether the shutdown command is run on the directly connected interface.

      • If the shutdown command is run on the interface, run the undo shutdown command on the interface. If the alarm is not cleared, go to Step 11.
      • If the shutdown command is not run on the interface, go to Step 15.

    9. Run the display ospf peercommand to check whether the OSPF peer relationship is established.

      • If the OSPF peer relationship is established, go to Step 15.
      • If no OSPF peer relationship is established, see the precessing steps in OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange.

    10. Run the display isis peer command to check whether the IS-IS peer relationship is established.

      • If the IS-IS peer relationship is established, go to Step 15.
      • If no IS-IS peer relationship is established, see the precessing steps in ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange.

    11. Check whether the source address used for initiating the BGP connection is specified.

      • If the source address is specified, go to Step 12.
      • If no source address is specified, run the peer connect-interface command to configure a source address used for initiating the BGP connection.

    12. If the BGP peer relationship is a multi-hop EBGP peer relationship, check whether the peer ebgp-max-hop command is run.

      • If the peer ebgp-max-hop command is run, go to Step 13.
      • If the peer ebgp-max-hop command is not run, run the peer ebgp-max-hop command.

    13. If the peer valid-ttl-hops hops command is run, check whether the TTL of the packet received from the remote end is within the range [255-hops+1, 255].

      • If the TTL of the packet is within the range, go to Step 14.
      • If the TTL of the packet is beyond the range, run the peer valid-ttl-hops hops command to ensure that the TTL of the packet sent to the remote peer is within the range.

    14. Contact the maintenance engineer responsible for the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in the view of another address family view on the local device, and whether BGP connection parameters are set. If any of the operations is performed, wait for a period of time, and then check whether the alarm is cleared.
    15. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 5: The BGP peer was unreachable.
    1. Run the ping command to check whether the local device can successfully ping its peer.

      • If the local device pings its peer successfully, go to Step 2.
      • If the local device fails to ping its peer, go to Step 3.

    2. Run the display cpu command to check whether the CPU usage is too high.

      • If the CPU usage is too high, go to Step 15.
      • If the CPU usage is within the normal range, go to Step 4.

    3. Run the display ip routing-table command to check whether the route from the local device to its peer exists in the routing table.

      • If the route from the local device to its peer exists in the routing table, go to Step 5.
      • If the route from the local device to its peer does not exist in the routing table, go to Step 6.

    4. Run the display acl command to check whether the device is configured with an ACL used to disable TCP port 179.

      • If the device is configured with such an ACL, delete the ACL.
      • If the device is not configured with such an ACL, go to Step 7.

    5. Run the display interface command to check whether the outbound interface of the route is Up.

      • If the outbound interface of the route is Up, go to Step 15.
      • If the outbound interface of the route is not Up, go to Step 8.

    6. Check the configuration of the local device and the origin of the route from the local device to its peer.

      • If the route is imported from OSPF, go to Step 9.
      • If the route is imported from IS-IS, go to Step 10.

    7. Check the BGP configuration of the local device to check whether a loopback interface is used to establish the BGP connection.

      • If a loopback interface is used to establish the BGP connection, go to Step 11.
      • If no loopback interface is used to establish the BGP connection, go to Step 12.

    8. Check whether the shutdown command is run on the directly connected interface.

      • If the shutdown command is run on the interface, run the undo shutdown command on the interface. If the alarm is not cleared, go to Step 11.
      • If the shutdown command is not run on the interface, go to Step 15.

    9. Run the display ospf peercommand to check whether the OSPF peer relationship is established.

      • If the OSPF peer relationship is established, go to Step 15.
      • If no OSPF peer relationship is established, see the precessing steps in OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange.

    10. Run the display isis peer command to check whether the IS-IS peer relationship is established.

      • If the IS-IS peer relationship is established, go to Step 15.
      • If no IS-IS peer relationship is established, see the precessing steps in ISIS_1.3.6.1.3.37.2.0.17 isisAdjacencyChange.

    11. Check whether the source address used for initiating the BGP connection is specified.

      • If the source address is specified, go to Step 12.
      • If no source address is specified, run the peer connect-interface command to configure a source address used for initiating the BGP connection.

    12. If the BGP peer relationship is a multi-hop EBGP peer relationship, check whether the peer ebgp-max-hop command is run.

      • If the peer ebgp-max-hop command is run, go to Step 13.
      • If the peer ebgp-max-hop command is not run, run the peer ebgp-max-hop command.

    13. If the peer valid-ttl-hops hops command is run, check whether the TTL of the packet received from the remote end is within the range [255-hops+1, 255].

      • If the TTL of the packet is within the range, go to Step 14.
      • If the TTL of the packet is beyond the range, run the peer valid-ttl-hops hops command to ensure that the TTL of the packet sent to the remote peer is within the range.

    14. Contact the maintenance engineer responsible for the peer device to check whether BGP is reset on the peer device, whether the peer enable command is run in the view of another address family view on the local device, and whether BGP connection parameters are set. If any of the operations is performed, wait for a period of time, and then check whether the alarm is cleared.
    15. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 6: The directly connected BGP interface was disconnected.
    1. Check whether the shutdown command is run on the directly connected interface.
    2. Collect the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
  • Cause 7: The number of BGP routes exceeded the upper threshold.
    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 the alarm information, log information, and configuration information, and then contact technical support personnel technical support personnel.
Translation
简体中文
Download
Updated: 2019-04-20

Document ID: EDOC1100039602

Views: 172218

Downloads: 110

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next
Enterprise APP

Copyright © 2020 Huawei Technologies Co., Ltd. All rights reserved.