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

ME60 Troubleshooting Guide V1.0 (VRPv8)

This document provides the maintenance guide of the device, including daily maintenance, emergence maintenance, and typical troubleshooting.
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 Troubleshooting

BGP Troubleshooting

This chapter describes common BGP faults and provides troubleshooting procedures, troubleshooting cases, and FAQs.

For details about BGP, see HUAWEI ME60 Feature Description - IP Routing.

The BGP Peer Relationship Fails to Be Established

This section describes how to troubleshoot the BGP peer relationship establishment failure.

Common Causes

Common causes are as follows:

  • BGP packets fail to be forwarded.

  • An ACL is configured, and the packets carrying TCP port 179 are discarded.

  • The peer router ID conflicts with the local router ID.

  • The peer AS number is incorrect.

  • Loopback interfaces are used to establish the BGP peer relationship, but the peer connect-interface command is not configured.

  • Loopback interfaces are used to establish the EBGP peer relationship, but the peer ebgp-max-hop command is not configured.

  • The configurations of the peer valid-ttl-hops command are incorrect.

  • The number of routes sent by the peer exceeds the upper limit specified using the peer route-limit command.

  • The peer ignore command is configured on the peer.

  • Address families on both ends do not match.

Troubleshooting Flowchart

Figure 4-66 shows the troubleshooting flowchart.

Figure 4-66 Flowchart for troubleshooting the BGP peer relationship establishment failure

Troubleshooting Procedure

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Run the ping command to check whether the BGP peer can be pinged.
    • If the BGP peer can be pinged, there are available routes between them, and the link between the two ends is normal. In this case, go to Step 2.

      NOTE:

      Run the ping -a source-ip-address -s packetsize host or ping ipv6 -a source-ipv6-address -s byte-number destination-ipv6-address command to detect the connectivity of the devices. By specifying the source IP or IPv6 address is specified in this command, you can check whether the two devices have available routes to each other. By specifying the size of a Ping packet, you can check whether large Ping packets can be normally transmitted over the link.

    • If the ping operation fails, see The Ping Operation Fails.
  2. Check whether ACL rules are configured to filter out the packets carrying TCP port 179.

    Run the display acl all command on the two devices to check whether ACL rules are configured to filter out the packets carrying TCP port 179.

    <HUAWEI> display acl all
    Advanced ACL 3001, 2 rules
    ACL's step is 5
    ACL's match-order is config
      rule 5 deny tcp source-port eq bgp
      rule 10 deny tcp destination-port eq bgp

    • If ACL rules are configured to filter out the packets carrying TCP port 179, run the undo rule rule-id destination-port and undo rule rule-id source-port commands to delete such rules.

    • If no such ACL rules are configured, go to Step 3.

  3. Check that the peer router ID does not conflict with the local router ID.

    Check whether the peer router ID conflicts with the local router ID. For example, if the IPv4 unicast peer relationship fails to be established, run the display bgp peer command to check whether the peer router ID conflicts with the local router ID. An example is as follows:

    <HUAWEI> display bgp peer
     BGP local router ID : 1.1.1.1
     Local AS number : 65001
     Total number of peers : 12                Peers in established state : 4
    
      Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
      8.9.0.8         4         100     1601     1443     0 23:21:56 Established   10000
      9.10.0.10       4         200     1565     1799     0 23:15:30 Established    9999
    NOTE:
    For other address families:
    • Run the display bgp vpnv4 all peer command to check information about all VPNv4 peers.
    • Run the display bgp ipv6 peer command to check information about IPv6 peers.
    • Run the display bgp vpnv6 all peer command to check information about all VPNv6 peers.

    • If the peer router ID conflicts with the local router ID, run the router id command in the BGP view to change either of the two router IDs so that the router IDs are different. In most cases, the IP address of a loopback interface is used as the local router ID.

    • If the peer router ID does not conflict with the local router ID, go to Step 4.

  4. Check that the peer AS number is configured correctly.

    Run the display bgp peer command on each device to check whether the displayed peer AS number is the same as the remote AS number. For example, if the IPv4 unicast peer relationship fails to be established, run the display bgp peer command to check whether the displayed peer AS number is the same as the remote AS number. An example is as follows:

    <HUAWEI> display bgp peer
     BGP local router ID : 223.5.0.109
     Local AS number : 41976
     Total number of peers : 12                Peers in established state : 4
    
      Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
      8.9.0.8         4         100     1601     1443     0 23:21:56 Established   10000
      9.10.0.10       4         200     1565     1799     0 23:15:30 Established    9999

    • If the peer AS number is configured incorrectly, change it to the remote AS number.

    • If the peer AS number is configured correctly, go to Step 5.

  5. Check whether BGP configurations affect the establishment of the BGP peer relationship.

    Run the display current-configuration configuration bgp command to check the following BGP configurations.

    Item

    Remarks

    peer connect-interface { interface-type interface-number | ipv4-source-address }

    If two devices use loopback interfaces to establish the BGP peer relationship, run the peer connect-interface command to specify the loopback interface as the source interface to send BGP packets or specify an IP address as the source IP address to establish the BGP connection.

    peer ebgp-max-hop hop-count

    When two directly connected devices use loopback interfaces to establish the EBGP peer relationship or two indirectly connected devices establish the EBGP peer relationship, run the peer ebgp-max-hop command to specify the maximum number of hops between the two devices.

    • When two directly connected devices use loopback interfaces to establish the EBGP peer relationship, the hop count can be any number greater than 1.

    • When two indirectly connected devices establish the EBGP peer relationship, specify the number of hops according to the actual situation.

    peer valid-ttl-hops hops

    If the peer valid-ttl-hops hops command is configured, check whether the value of hops is within the valid TTL range [255 - hops + 1, 255]. hops specifies the number of hops between the devices on both ends. The hop count between the two directly connected devices is 1.

    NOTE:

    The peer valid-ttl-hops command must be configured on the devices on both ends.

    peer route-limit limit

    If the peer route-limit limit command is configured, check whether the number of routes sent by the peer exceeds the upper limit specified by limit. If the upper limit is exceeded, reduce the number of routes to be sent by the peer, and run the reset bgp ip-address command to re-establish the BGP peer relationship.

    peer ignore

    If the peer ignore command is configured on the peer, the peer does not establish a BGP peer relationship with the local device. To establish the BGP peer relationship between the peer and the local device, run the undo peer ignore command on the peer.

    Address family capability

    Check whether the address family capabilities of the devices on both ends match by checking the configuration file. For example, to establish the BGP VPNv4 peer relationship, the peer enable command must be configured in the BGP-VPNv4 address families of both devices. If the peer enable command is configured on one device only, the BGP peer relationship on the other device is displayed as No neg.

  6. Please contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

Relevant Alarms

BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Relevant Logs

None

BGP Public Network Traffic Is Interrupted

This section describes how to troubleshoot the BGP public network traffic interruption.

Common Causes

Common causes are as follows:

  • Routes are inactive because their next hops are unreachable.

  • Routes fail to be advertised or received because the routing policies are configured incorrectly.

  • The received routes are dropped because there is an upper limit on the number of routes on the device.

Troubleshooting Flowchart

Figure 4-67 shows the troubleshooting flowchart.

Figure 4-67 Flowchart for troubleshooting the BGP public network traffic interruption

Troubleshooting Procedure

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that the next hop of the target route is reachable.

    Run the display bgp routing-table network { mask | mask-length } command on the local device that sends routes to check whether the target route is active and has been sent to a peer. network specifies the prefix of the target route.

    The target route 10.0.0.0/8 is used as an example. The command output shows that this route is valid and optimal and sent to the peer at 3.3.3.3. The original next hop and recursive next hop of this route are 1.1.1.1 and 172.16.1.1, respectively.

    <HUAWEI> display bgp routing-table 10.0.0.0 8
    
     BGP local router ID : 10.1.1.1
     Local AS number : 100
     Paths:   1 available, 1 best, 1 select
     BGP routing table entry information of 10.0.0.0/8:
     From: 1.1.1.1 (192.168.1.1)
     Route Duration: 4d21h29m39s
     Relay IP Nexthop: 172.16.1.1
     Relay IP Out-Interface: GigabitEthernet1/0/2
     Original nexthop: 1.1.1.1
     Qos information : 0x0
     AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
     Aggregator: AS 100, Aggregator ID 192.168.1.1
     Advertised to such 1 peers:
        3.3.3.3

    • If the target route is inactive, check whether there is a route to the original next hop in the IP routing table. If no route to the original next hop exists, the BGP route is not advertised because its next hop is unreachable. Determine why there is no route to the original next hop. In most cases, this fault is caused because of IGP or static route problems.

    • If the target route is active and optimal but there is no information indicating that this route has been sent to a peer, perform Step 2 to check the export policy applied to the local device.

    • Run the display bgp routing-table network { mask | mask-length } command on the peer to check whether it has received the target route.

      • If the peer has received the target route, perform Step 1 again to check whether the next hop of the target route is reachable and optimal.

      • If the peer has not received the target route, perform Step 2 to check the import policy applied to the peer.

    NOTE:

    In BGP4+ networking, run the display bgp routing-table ipv6-address prefix-length command to check whether the target route is received.

  2. Check that the routing policies are configured correctly.

    Run the display current-configuration configuration bgp command on the local device and the peer to check whether the export and import policies are configured.

    <HUAWEI> display current-configuration configuration bgp
    #
    bgp 100
     peer 1.1.1.1 as-number 100
     #
     ipv4-family unicast
      undo synchronization
      filter-policy ip-prefix aaa import
      filter-policy ip-prefix aaa export
      peer 1.1.1.1 enable
      peer 1.1.1.1 filter-policy acl-name acl-name import
      peer 1.1.1.1 filter-policy acl-name acl-name export
      peer 1.1.1.1 as-path-filter 1 import
      peer 1.1.1.1 as-path-filter 1 export
      peer 1.1.1.1 ip-prefix prefix-name import
      peer 1.1.1.1 ip-prefix prefix-name export
      peer 1.1.1.1 route-policy policy-name import
      peer 1.1.1.1 route-policy policy-name export
     #
     ipv4-family vpnv4
      policy vpn-target
      peer 1.1.1.1 enable
    #
    return

    • If export and import policies are configured on the two devices, check whether the route is filtered out by these policies. For detailed configurations of a routing policy, see HUAWEI ME60 Configuration Guide - IP Routing.

    • If no export and import policies are configured on the two devices, go to Step 3.

  3. Check that the number of routes is lower than the upper limit.

    Run the display current-configuration configuration bgp | include peer destination-address command on the remote peer to check whether an upper limit is configured on the number of routes to be received from its peer.

    For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded after the remote peer receives five routes from its peer at 1.1.1.1.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
     peer 1.1.1.1 as-number 100
     peer 1.1.1.1 route-limit 5 alert-only
      peer 1.1.1.1 enable

    If a peer is added to a peer group, there may be no configurations of the upper limit in the command output.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
     peer 1.1.1.1 as-number 100
     peer 1.1.1.1 group IBGP
      peer 1.1.1.1 enable
      peer 1.1.1.1 group IBGP

    In this case, run the display current-configuration configuration bgp | include peer group-name command to check the configurations of this peer group.

    <HUAWEI> display current-configuration configuration bgp | include peer IBGP
     peer IBGP route-limit 5 alert-only
      peer IBGP enable

    If the alarm BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed is generated when traffic is interrupted, the route is dropped because the number of routes received from the peer exceeds the upper limit. In this situation, increase the upper limit.

    NOTE:

    Changing the upper limit on the number of routes to be received from a peer may interrupt the BGP peer relationship. Therefore, configuring route summarization to reduce the number of routes to be sent is recommended.

  4. Please contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

Relevant Alarms

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed

Relevant Logs

None

BGP Private Network Traffic Is Interrupted

This section describes how to troubleshoot the BGP private network traffic interruption.

Common Causes

Common causes are as follows:

  • Routes are inactive because their next hops are unreachable.

  • Routes fail to be advertised or received because the routing policies are configured incorrectly.

  • Private network routes fail to be advertised because the number of labels exceeds the upper limit.

  • Routes are inactive because they fail to recurse to a tunnel.

  • Routes fail to be added to the VPN routing table because the configured import route-target (RT) and export RT do not match.

  • The received routes are dropped because there is an upper limit on the number of routes on the device.

Troubleshooting Flowchart

Figure 4-68 shows the troubleshooting flowchart.

Figure 4-68 Flowchart for troubleshooting the BGP private network traffic interruption

Troubleshooting Procedure

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that the next hop of the target route is reachable.

    Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address [ mask | mask-length ] command on the local PE that sends routes to check whether the target route exists. ipv4-address specifies the prefix of the target route.

    • If the target route does not exist, check whether the route of a CE is advertised to the local PE.

    • If the target route exists, check whether it is active. The target route 1.1.1.1/32 is used in the following example:

    The following command output shows that this route is valid and optimal. The original next hop and recursive next hop of this route are 3.3.3.3 and 20.1.1.2, respectively.

    <HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
    
     BGP local router ID : 20.1.1.2
     Local AS number : 100
     Paths:   1 available, 1 best, 1 select
     BGP routing table entry information of 1.1.1.1/32:
     From: 20.1.1.1 (1.1.1.1)
     Route Duration: 00h00m03s
     Relay IP Nexthop: 20.1.1.2
     Relay IP Out-Interface: Pos1/0/0
     Original nexthop: 3.3.3.3
     Qos information : 0x0
     AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
     Not advertised to any peer yet

    • If the target route is inactive, check whether there is a route to the original next hop in the IP routing table. If no route to the original next hop exists, the BGP route is not advertised because its next hop is unreachable. Determine why there is no route to the original next hop.

    • If the target route is valid and optimal but there is no information indicating that this route is sent to the remote PE, perform Step 2 to check the export policy applied to the local PE.

    • Run the display bgp vpnv4 all routing-table ipv4-address { mask | mask-length } command on the remote PE to check whether it has received the target route.

      • If the remote PE has received the target route, perform Step 1 again to check whether the next hop of the route is reachable and optimal.

      • If the remote PE has not received the target route, perform Step 2 to check the import policy of the remote PE.

  2. Check that the routing policies are configured correctly.

    Run the display current-configuration configuration bgp command on the local and remote PEs to check whether the import and export policies are configured.

    NOTE:

    Check configurations of the peers in the BGP-VPNv4 address family or BGP-VPN instance address family only because the private network traffic is interrupted in this troubleshooting case.

    <HUAWEI> display current-configuration configuration bgp
    #
    bgp 100
     peer 1.1.1.1 as-number 200
     #
     ipv4-family unicast
      undo synchronization
      peer 1.1.1.1 enable
     #
     ipv6-family unicast
      undo synchronization
     #
     ipv4-family vpnv4
      policy vpn-target
      peer 1.1.1.1 enable
      peer 1.1.1.1 filter-policy acl-name acl-name import
      peer 1.1.1.1 filter-policy acl-name acl-name export
      peer 1.1.1.1 as-path-filter 1 import
      peer 1.1.1.1 as-path-filter 1 export
      peer 1.1.1.1 ip-prefix prefix-name import
      peer 1.1.1.1 ip-prefix prefix-name export
      peer 1.1.1.1 route-policy policy-name import
      peer 1.1.1.1 route-policy policy-name export
     #
     ipv4-family vpn-instance vpna
      peer 10.1.1.1 as-number 300
      peer 10.1.1.1 filter-policy acl-name acl-name import
      peer 10.1.1.1 filter-policy acl-name acl-name export
      peer 10.1.1.1 as-path-filter 1 import
      peer 10.1.1.1 as-path-filter 1 export
      peer 10.1.1.1 ip-prefix prefix-name import
      peer 10.1.1.1 ip-prefix prefix-name export
      peer 10.1.1.1 route-policy policy-name import
      peer 10.1.1.1 route-policy policy-name export
    #
    return

    • If the import and export policies are configured on the two devices, check whether the target route fails to be transmitted because it is filtered out by these policies. For detailed configurations of a routing policy, see HUAWEI ME60 Configuration Guide - IP Routing.

    • If no import and export policies are configured on the two devices, go to Step 3.

  3. Check that the route recurses to a tunnel.

    Run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command on the remote PE to check whether the target route recurses to a tunnel.

    The target route 50.1.1.2/32 is used as an example. If the Relay Tunnel Out-Interface field is in the command output, this route has recursed to a tunnel.

    <HUAWEI> dis bgp vpnv4 all routing-table 50.1.1.2
    BGP local router ID : 2.2.2.2
     Local AS number : 100
     
     Total routes of Route Distinguisher(1:2): 1
     BGP routing table entry information of 50.1.1.2/32:
     Label information (Received/Applied): 13316/NULL
     From: 1.1.1.1 (1.1.1.1)
     Route Duration: 00h00m08s
     Relay IP Nexthop: 20.1.1.1
     Relay IP Out-Interface: Pos1/0/0
     Relay Tunnel Out-Interface: Pos1/0/0
      Original nexthop: 1.1.1.1
     Qos information : 0x0
     Ext-Community:RT <1 : 1>
     AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, pre 255     
     Not advertised to any peer yet
     
     Total routes of vpn-instance vpna: 1
     BGP routing table entry information of 50.1.1.2/32:
     Label information (Received/Applied): 13316/NULL
     From: 1.1.1.1 (1.1.1.1)
     Route Duration: 00h00m07s
      Original nexthop: 1.1.1.1
     Qos information : 0x0
     Ext-Community:RT <1 : 1>
     AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255
     Not advertised to any peer yet

    • If the target route fails to recurse to a tunnel, check whether an associated tunnel exists or the tunnel configurations are correct. For details, see HUAWEI ME60 Troubleshooting - MPLS.

    • If the target route has recursed to a tunnel, go to Step 4.

  4. Check whether the route fails to be added to the VPN routing table because the configured import RT and export RT do not match.

    Run the display current-configuration configuration vpn-instance command on the local and remote PEs to check whether the route fails to be added to the VPN routing table of the remote PE after being sent to the remote PE because the export RT of the local VPN instance does not match the import RT of the remote VPN instance.

    export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT.

    <HUAWEI> display current-configuration configuration vpn-instance
    #
    ip vpn-instance vpna
     route-distinguisher 1:1
     apply-label per-instance
     vpn-target 1:1 export-extcommunity
     vpn-target 1:1 import-extcommunity
    ip vpn-instance vpnb
     route-distinguisher 1:2
     vpn-target 1:1 export-extcommunity
     vpn-target 1:1 import-extcommunity
    #
    return
    • If the export RT of the local VPN instance does not match the import RT of the remote VPN instance, change either of them so that they are the same.

    • If the export RT of the local VPN instance matches the import RT of the remote VPN instance, go to Step 5.

  5. Check that the number of labels is lower than the upper limit.

    Check whether MPLS is enabled on the local PE. If MPLS has been enabled, run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command to check whether the target route has obtained a VPN label.

    If no information is displayed in Label information in the command output, the labels may have run out. As a result, the target route fails to obtain a label and cannot be advertised to the peer.

    <HUAWEI> display bgp vpnv4 all routing-table 100.1.1.1
    
     BGP local router ID : 10.1.1.2
     Local AS number : 100
     
     Total routes of Route Distinguisher(1:1): 1
     BGP routing table entry information of 100.1.1.0/24:
     Imported route.
     Label information (Received/Applied): NULL/13312
     From: 0.0.0.0 (0.0.0.0)
     Route Duration: 00h21m24s
     Direct Out-interface: NULL0
     Original nexthop: 0.0.0.0
     Qos information : 0x0
     Ext-Community:RT <1 : 1>
     AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre 255
     Advertised to such 1 peers:
        1.1.1.1
     
     Total routes of vpn-instance vpna: 1
     BGP routing table entry information of 100.1.1.0/24:
     Imported route.
     From: 0.0.0.0 (0.0.0.0)
     Route Duration: 00h21m24s
     Direct Out-interface: NULL0
     Original nexthop: 0.0.0.0
     Qos information : 0x0
     AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, select, pre 60
     Not advertised to any peer yet
    
    • If the labels have run out, run the apply-label per-instance command in the VPN instance view to configure the device to assign one label to each instance to save labels or configure route summarization to reduce the number of routes.

    • If the labels have not run out, go to Step 6.

  6. Check that the number of routes is lower than the upper limit.

    Run the display current-configuration configuration bgp | include peer destination-address command or the display current-configuration configuration bgp | include peer group-name command on the remote PE to check whether an upper limit is configured on the number of routes to be received from the local PE.

    For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded after the remote PE receives five routes from the local PE at 1.1.1.1.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
     peer 1.1.1.1 as-number 100
     peer 1.1.1.1 route-limit 5 alert-only
      peer 1.1.1.1 enable

    If a peer is added to a peer group, there may be no configurations of the upper limit in the command output.

    <HUAWEI> display current-configuration configuration bgp | include peer 1.1.1.1
     peer 1.1.1.1 as-number 100
     peer 1.1.1.1 group IBGP
      peer 1.1.1.1 enable
      peer 1.1.1.1 group IBGP

    In this case, run the display current-configuration configuration bgp | include peer group-name command to check the configurations of this peer group.

    <HUAWEI> display current-configuration configuration bgp | include peer IBGP
     peer IBGP route-limit 5 alert-only
      peer IBGP enable

    If the alarm BGP_1.3.6.1.4.1.2011.5.25.177.1.3.6 hwBgpPeerRouteExceed is generated when traffic is interrupted, the target route is dropped because the number of routes received has exceeded the upper limit. In this situation, increase the upper limit.

    NOTE:

    Changing the upper limit on the number of routes to be received from a peer may interrupt the BGP peer relationship. Therefore, configuring route summarization to reduce the number of routes to be sent is recommended.

  7. Please contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

Relevant Alarms

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed

Relevant Logs

None

The Local BGP Peer (Route Sender) Fails to Receive ORFs from the Remote Peer (Route Receiver)

This section describes how to troubleshoot the failure of the local BGP peer (route sender) in receiving ORFs from the remote peer (route receiver).

Common Causes

Common causes are as follows:

  • The IPv4 BGP peer relationship cannot be established.
  • The BGP ORF capability fails to be negotiated.
  • No import IP-prefix policy is configured on the remote peer.
  • No prefix list corresponding to the import IP-prefix policy is configured on the remote peer.
Troubleshooting Flowchart

After the BGP ORF feature is configured, the local end cannot receive ORF information from the peer end. Then the display bgp peer ipv4-address orf ip-prefix command is run, but no IP prefix information is displayed.

The troubleshooting roadmap is as follows:
  • Check that a BGP peer relationship has been set up.
  • Check that the BGP ORF capability has been negotiated successfully.
  • Check that an import IP-prefix policy is configured on the remote peer.
  • Check that a prefix list corresponding to the import IP-prefix policy is configured on the remote peer.

Figure 4-69 shows the troubleshooting flowchart.

Figure 4-69 Flowchart for troubleshooting the failure of the local BGP peer in receiving ORFs from the remote peer

Troubleshooting Procedure

NOTE:

Commands can be run in one of two modes: immediate validation mode or two-phase validation mode.

  • In immediate validation mode, the configurations take effect immediately after a command is run.
  • In two-phase validation mode, the configurations do not take effect until after the commit command is run.

Unless otherwise specified, this troubleshooting guide defaults to the immediate validation mode.

Save the results of each troubleshooting step. If the fault persists after following this procedure, Huawei will need these results for further troubleshooting.

Procedure

  1. Check that a BGP peer relationship has been set up.

    Run the display bgp peer command to check whether the BGP peer relationship is in the Established state.

  2. Check that the BGP ORF function is enabled on BGP peers and that the peers succeed in negotiating the BGP ORF capability.

    Run the display current-configuration configuration bgp command on the BGP peers to check whether the peer ipv4-address capability-advertise orf ip-prefix command is configured in the IPv4 unicast address family view.

    <HUAWEI> display current-configuration configuration bgp
    #
    bgp 100
    peer 7.1.1.1 as-number 100
    #
     ipv4-family unicast
      undo synchronization
      peer 7.1.1.1 ip-prefix in import
      peer 7.1.1.1 capability-advertise orf ip-prefix both
    #                              
    
    NOTE:

    BGP ORF has three modes: send, receive, and both. In send mode, a device can send ORFs; in receive mode, a device can receive ORFs; in both mode, a device can send and receive ORFs. To enable the local device to receive ORF IP-prefix information, configure both or receive mode on the local device and both or send mode on its peer.

    • If the BGP ORF function is not enabled on one peer, run the peer ipv4-address capability-advertise orf ip-prefix command in the BGP IPv4 unicast address family view to enable BGP ORF. If both or receive is specified when you configure the local peer, both or send must be specified when you configure the remote peer.

      <HUAWEI> system-view
      [~HUAWEI] bgp 100
      [~HUAWEI-bgp] ipv4-family unicast
      [~HUAWEI-bgp-af-ipv4] peer 7.1.1.1 capability-advertise orf ip-prefix both

      If BGP ORF is enabled on both BGP peers, run the display bgp peer ipv4-address verbose command after a BGP peer relationship is re-established to check whether the BGP ORF capability has been negotiated successfully. The command output shows the ORF capabilities on both the local and remote peers.

      <HUAWEI> display bgp peer 7.1.1.1 verbose | include Address-Prefix
               Support Address-Prefix: IPv4-UNC address-family, rfc-compatible, both            
      Enable Address-Prefix: IPv4-UNC address-family, rfc-compatible, both
      NOTE:

      In this command output, the first line shows the ORF capability of the remote peer, and the second line shows the ORF capability configured on the local peer. The ORF capability supported by non-Huawei devices may be different from that defined in the relevant standard. To enable a Huawei device to communicate with a non-Huawei device, ensure that the same compatibility mode is configured on the two devices.

    • If the BGP ORF function is enabled on both BGP peers and they succeed in negotiating the BGP ORF capability, go to 3.

  3. Check that an import IP-prefix policy is configured on the remote peer.

    Run the display current-configuration configuration bgp command on the remote peer to check whether the peer ipv4-address ip-prefix ip-prefix-name import command is configured in the IPv4 unicast address family view.

    <HUAWEI> display current-configuration configuration bgp
    #
    bgp 100
    peer 7.1.1.1 as-number 100
    #
     ipv4-family unicast
      undo synchronization
      peer 7.1.1.1 ip-prefix in import
      peer 7.1.1.1 capability-advertise orf ip-prefix both
    #      
    

    • If no import IP-prefix policy is configured on the remote peer, run the peer ipv4-address ip-prefix ip-prefix-name import command in the BGP IPv4 unicast address family view to configure an import IP-prefix policy.

      <HUAWEI> system-view
      [~HUAWEI] bgp 100
      [~HUAWEI-bgp] ipv4-family unicast
      [~HUAWEI-bgp-af-ipv4] peer 7.1.1.1 ip-prefix in import
    • If an import IP-prefix policy has been configured on the remote peer but the local peer still cannot receive ORF IP-prefix information from the remote peer, go to 4.

  4. Check that the prefix list corresponding to the import IP-prefix policy is configured on the remote peer.

    Run the display ip ip-prefix ip-prefix-name command on the remote peer to check whether the prefix list corresponding to the import IP-prefix policy is configured.

    <HUAWEI> display ip ip-prefix in

    If the prefix list corresponding to the import IP-prefix policy is not configured, run the ip ip-prefix ip-prefix-name index index-number permit ipv4-address mask-length command in the system view to configure a prefix list.

    <HUAWEI> system-view
    [~HUAWEI] ip ip-prefix in index 10 permit 10.1.1.0 24

    After completing this configuration, run the display ip ip-prefix ip-prefix-name command on the remote peer to check whether the prefix list corresponding to the import IP-prefix policy is configured.

    <HUAWEI> display ip ip-prefix in
    Prefix-list in
    Permitted 0
    Denied 0
            index: 10               permit  10.1.1.0/24

    This output shows that the prefix list in has been successfully configured. After completing these steps, if the local peer still cannot receive ORFs from the remote peer, go to 5.

  5. Please contact technical support personnel and provide the following information:

    • Results of this troubleshooting procedure
    • Configuration, log, and alarm files

Relevant Alarms and Logs

Relevant Alarms

BGP_1.3.6.1.2.1.15.7.2 bgpBackwardTransition

Relevant Logs

BGP/6/BGP_PEER_STATE_CHG

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 13873

Downloads: 257

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next