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).
L3VPN Troubleshooting

L3VPN Troubleshooting

This chapter describes common causes of L3VPN faults and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs.

L3VPN 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-101 shows the troubleshooting flowchart.

Figure 4-101 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

Translation
Download
Updated: 2019-06-11

Document ID: EDOC1000175918

Views: 14082

Downloads: 257

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