Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
HUAWEI NetEngine5000E Core Router V800R002C01 Troubleshooting - VPN Issue 01 Date 2011-10-15 HUAWEI TECHNOLOGIES CO., LTD. Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd. Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders. Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied. Huawei Technologies Co., Ltd. Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: http://www.huawei.com Email: [email protected] Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. i HUAWEI NetEngine5000E Core Router Troubleshooting - VPN About This Document About This Document Intended Audience This document describes the troubleshooting workflow and methods for HUAWEI NetEngine5000E. This document describes the troubleshooting of HUAWEI NetEngine5000E with various services, including information collection methods, common processing flows, common troubleshooting methods, and troubleshooting cases. This document is intended for: l System maintenance engineers l Commissioning engineers l Network monitoring engineers Related Versions (Optional) The following table lists the product versions related to this document. Product Name Version HUAWEI NetEngine5000E Core Router V800R002C01 Symbol Conventions The symbols that may be found in this document are defined as follows. Symbol Description Alerts you to a high risk hazard that could, if not avoided, result in serious injury or death. Alerts you to a medium or low risk hazard that could, if not avoided, result in moderate or minor injury. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. ii HUAWEI NetEngine5000E Core Router Troubleshooting - VPN Symbol About This Document Description Alerts you to a potentially hazardous situation that could, if not avoided, result in equipment damage, data loss, performance deterioration, or unanticipated results. Provides a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points in the main text. Command Conventions (Optional) The command conventions that may be found in this document are defined as follows. Convention Description Boldface The keywords of a command line are in boldface. Italic Command arguments are in italics. [] Items (keywords or arguments) in brackets [ ] are optional. { x | y | ... } Optional items are grouped in braces and separated by vertical bars. One item is selected. [ x | y | ... ] Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. { x | y | ... }* Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected. [ x | y | ... ]* Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected. &<1-n> The parameter before the & sign can be repeated 1 to n times. # A line starting with the # sign is comments. Change History Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues. Changes in Issue 01 (2011-10-15) The initial commercial release. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. iii HUAWEI NetEngine5000E Core Router Troubleshooting - VPN Contents Contents About This Document.....................................................................................................................ii 1 L3VPN Troubleshooting..............................................................................................................1 1.1 L3VPN Traffic Is Interrupted.............................................................................................................................2 1.1.1 Common Causes........................................................................................................................................2 1.1.2 Troubleshooting Flowchart........................................................................................................................2 1.1.3 Troubleshooting Procedure........................................................................................................................4 1.1.4 Relevant Alarms and Logs........................................................................................................................8 1.2 Related Troubleshooting Cases..........................................................................................................................8 1.2.1 VPNs Configured with the Same VPN Target Cannot Communicate......................................................8 1.2.2 Ping Between the PEs on a VPN Fails....................................................................................................11 1.2.3 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option B Setup Because the Mask of the Loopback Address on an Intermediate Router Is Incorrect..............................................................................12 1.2.4 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR...................14 1.2.5 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE............................16 1.2.6 CEs Cannot Ping Through Each Other....................................................................................................18 1.2.7 Failed to transmit Large Packets of the Private Network........................................................................19 1.2.8 PE Fails to Ping Through the Remote CE Network Segment.................................................................20 1.2.9 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down ..........................................................................................................................................................................21 1.2.10 CE Cannot Access Some Web Servers Due to the MTU Configuration...............................................27 1.2.11 The RR Fails to Reflect VPN Routes....................................................................................................29 1.2.12 CE1 Cannot Register with CE2 Because the Number of Routes of the VPN Instance Exceeds the Maximum Limit................................................................................................................................................30 1.2.13 VPNv4 Routes on a PE Cannot Take Effect.........................................................................................32 1.2.14 MPLS VPN Convergence Is Slow.........................................................................................................35 1.2.15 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity Command Is Not Configured.............................................................................................................................................36 1.2.16 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not a 32-bit Mask....................................................................................................................................................37 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. iv HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1 L3VPN Troubleshooting About This Chapter This chapter describes common causes of L3VPN faults and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs. 1.1 L3VPN Traffic Is Interrupted This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that BGP private network traffic is interrupted. 1.2 Related Troubleshooting Cases Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 1 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1.1 L3VPN Traffic Is Interrupted This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that BGP private network traffic is interrupted. 1.1.1 Common Causes This fault is commonly caused by one of the following causes: l Routes are inactive because their next hops are unreachable. l Routes fail to be advertised or received because routing policies are configured incorrectly. l Private network routes fail to be advertised because the number of labels exceeds the upper limit. l Routes are inactive because they fail to be iterated to a tunnel. l Routes fail to be added to the VPN routing table because the configured import route-target (RT) and export RT do not match. l The received routes are dropped because there is an upper limit on the number of routes on the device. 1.1.2 Troubleshooting Flowchart BGP private network traffic is interrupted after the BGP protocol is configured. Figure 1-1 shows the troubleshooting flowchart. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 2 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Figure 1-1 Troubleshooting flowchart for interruption of BGP private network traffic The BGP private network traffic is interrupted Is the next Hop of the VPN route reachable? No Ensure that the next hop is reachable Is fault rectified? Yes No Yes Is the routing policy is configured correctly? No Correctly configure the routing policy Is fault rectified? Yes No Yes Does the number of labels exceed the upper limit Yes Reduce the number of routes or configure the device to assign a label to each instance Is fault rectified? Yes No No Is the tunnel Iterated successfully? No Ensure that the tunnel exists Is fault rectified? Yes No Yes Does the export RT match the import RT? No Ensure that they match Is fault rectified? Yes No Yes Does the number of routes exceed the upper limit? Yes Reduce the number of routes or increase the upper limit of routes Yes No No Seek technical support Issue 01 (2011-10-15) Is fault rectified? Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. End 3 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1.1.3 Troubleshooting Procedure NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Procedure Step 1 Check that next hops of routes are reachable. Run the display bgp vpnv4 vpn-instance vpn-instance-name routing-table ipv4-address [ mask | mask-length ] command on the PE that sends routes (that is, the local PE) to check whether the target route exists. ipv4-address specifies the prefix of the target route. l If the target route does not exist, check whether the route of a CE is advertised to the local PE. l If the target route exists, check whether it is active. The following is an example: Assume that the target route is a route to 1.1.1.1/32. The following command output shows that this route is valid and best. The original next hop and iterated 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 l If the target route is inactive, check whether there is a route to the original next hop in the IP routing table. If there is no route to the original next hop, it indicates that the BGP route is not advertised because its next hop is unreachable. Then, find out why there is no route to the original next hop (this fault is generally associated with IGP or static routes). l If the target route is valid and best but there is no information indicating that this route is sent to the remote PE, perform Step 2 to check the outbound policy applied to the local PE. l 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 whether this route is selected. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 4 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting – If the remote PE has not received the target route, perform Step 2 to check the inbound policy of the remote PE. Step 2 Check that routing policies are configured correctly. Run the display current-configuration configuration bgp command on the local PE and remote PE to check whether inbound and outbound policies are configured. NOTE You only need to focus on peers of the BGP-VPNv4 address family or BGP-VPN instance address family in this troubleshooting case because the private network traffic is interrupted. <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 l If inbound and outbound policies are configured on the two devices, check whether the target route fails to be transmitted because it is filtered by these policies. For detailed configurations of a routing policy, see the HUAWEI NetEngine5000E Configuration Guide - IP Routing. l If inbound and outbound policies are not configured on the two devices, go to Step 3. Step 3 Check that routes can be iterated 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 can be iterated to a tunnel. Assume that the target route is a route to 50.1.1.2/32. If the Relay Tunnel Name field in the command output are not empty, it indicates that this route can be iterated 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 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 5 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 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 Name: ldp 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 Relay Tunnel Name: ldp 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 l If the target route fails to be iterated to a tunnel, check whether the associated tunnel exists or whether the tunnel configurations are correct. For details, see the HUAWEI NetEngine5000E Troubleshooting - MPLS. l If the target route can be iterated to a tunnel, go to Step 4. Step 4 Check whether routes fail 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 PE and remote PE to check whether routes fail 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 l If the export RT of the local VPN instance does not match the import RT of the remote VPN instance, configure matching VPN-targets in the VPN instance. l If the export RT of the local VPN instance matches the import RT of the remote VPN instance, go to Step 5. Step 5 Check that the number of labels is lower than the upper limit. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 6 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Check whether MPLS is enabled on the local PE. Then, run the display bgp vpnv4 all routingtable ipv4-address [ mask | mask-length ] command to check whether the target route is assigned a VPN label. If there is no Label information field in the command output, it indicates that labels may be insufficient. As a result, the target route is not assigned a label and is not 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 l If labels are insufficient, run the apply-label per-instance command in the VPN instance view to configure the device to assign one label to each instance so as to save labels. You can also configure route summarization to reduce the number of routes. l If labels are sufficient, go to Step 6. Step 6 Check that the number of routes is lower than the upper limit. Run the display current-configuration configuration bgp | include peer destinationaddress command or the display current-configuration configuration bgp | include peer group-name command on the remote PE to check whether the upper limit on the number of routes to be received is configured on the remote 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 the peer is added to a peer group, there may be no configurations about 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 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 7 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting peer 1.1.1.1 enable peer 1.1.1.1 group IBGP In this case, you need to run the display current-configuration configuration bgp | include peer group-name command to check 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 BGPCOMM_0x08790002 hwBgpPeerRouteNumberExceed is generated when traffic is interrupted, it indicates that the target route is dropped because the number of routes received has exceeded the upper limit. Then, you need to increase the upper limit. NOTE Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peer relationship. Therefore, it is recommended to reduce the number of sent routes by configuring route summarization on the local device. Step 7 Collect the following information and contact Huawei technical support personnel. l Results of the preceding troubleshooting procedure l Configuration files, log files, and alarm files of the devices ----End 1.1.4 Relevant Alarms and Logs Relevant Alarms BGPCOMM_0x08790001 hwBgpPeerRouteNumberThresholdExceed Relevant Logs None 1.2 Related Troubleshooting Cases 1.2.1 VPNs Configured with the Same VPN Target Cannot Communicate On a BGP/MPLS VPN network, VPNs can communicate after being configured with the same VPN target. If two VPNs configured with the same VPN target are bound to the same IP address, as described in this case, the two VPNs cannot communicate. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 8 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom As shown in Figure 1-2, BGP/MPLS VPN services are deployed on the network. CE1 and CE3 belong to VPN-A, and CE2 belongs to VPN-B. VPN-A and VPN-B are configured with the same VPN target to ensure that they can communicate with each other. After the configurations, CE1 can ping the IP address 4.4.4.9 in VPN-A successfully, but CE2 fails to ping the IP address 4.4.4.9 in VPN-A. This indicates that the communications between VPN-A and VPN-B fail. Figure 1-2 Networking diagram of BGP/MPLS VPN AS: 65430 AS: 65410 VPN-A VPN-A Loopback1 4.4.4.9/32 CE1 GE1/0/0 GE1/0/0 Loopback1 2.2.2.9/32 GE1/0/0 PE1 Loopback1 1.1.1.9/32 GE2/0/0 CE3 POS2/0/0 PE2 172.2.1.1/24 POS1/0/0 172.1.1.2/24 POS3/0/0 172.1.1.1/24 GE1/0/0 P POS3/0/0 172.2.1.2/24 Loopback1 3.3.3.9/32 MPLS backbone AS: 100 GE1/0/0 CE2 VPN-B AS: 65420 Fault Analysis 1. Issue 01 (2011-10-15) Run the display bgp peer or display bgp vpnv4 all peer command on PE1. You can find that the BGP peer relationship between PE1 and PE2 is in the Established state. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 9 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 2. Sequentially run the display mpls ldp session command on PE1, P, and PE2. You can find that the Status field in the command output is displayed as Operational, indicating that the LDP sessions between PE1 and P and between P and PE2 have been established. 3. Run the display ip vpn-instance verbose command on PE1 and PE2. You can find that the VPN targets of VPN-A and VPN-B are the same. 4. Sequentially run the display mpls ldp lsp command on PE1, P, and PE2 to check information about label allocation. You can find that public network labels and VPN labels are allocated to all the nodes along the LSP between PE1 and PE2. 5. Run the display ip interface brief command on the PEs to check IP addresses assigned to the interfaces. You can find that VPN-B and VPN-A are bound to the same IP address. <PE1> display ip interface brief ...... Interface ...... Gigabitethernet1/0/0 Gigabitethernet2/0/0 ...... IP Address/Mask Physical Protocol 10.1.1.2/30 10.1.1.2/30 up up up up In the process of route cross on the PEs, VPN-B only selects the local direct route instead of the BGP route destined for VPN-A. In addition, no prompt will be displayed when you bind VPNs to the same IP address. After the binding, the VPNs fail to communicate with each other. Procedure Step 1 On PE1 and CE2, run the system-view command to enter the system view. Step 2 Run the interface interface-type interface-name command to enter the interface view. Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the interface. NOTE Bind VPN-A and VPN-B to different IP addresses. Step 4 Run the quit command to quit the interface view. Step 5 Run the bgp as-number command to enter the BGP view. Step 6 Run the ipv4-family vpn-instance vpn-instance-name command to enter the BGP VPN instance view. Note that you do not need to perform this step on CE2. Step 7 Run the undo peer ipv4-address command to delete the original BGP peer. Step 8 Run the peer ipv4-address as-number as-number command to configure a new BGP peer. After the preceding configurations, CE2 can ping CE3 successfully. The fault is cleared. ----End Summary A PE can learn routes of different VPNs from the local CE. If the next hop of a route with this type is reachable or can be iterated, the PE matches the route with the Import VPN target of another VPN instance. If the match operation succeeds, the PE adds the route to the routing table of the VPN instance. This process is called route cross. In this troubleshooting case, IP addresses to which two VPNs are bound are the same. As a result, the route exchanged between the VPNs is not preferentially selected. Therefore, although the Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 10 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting VPN targets of these VPNs are matched, the VPN cannot communicate with each other. To rectify the fault, ensure that the VPNs are bound to different IP addresses. 1.2.2 Ping Between the PEs on a VPN Fails NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom On the BGP/MPLS VPN network shown in Figure 1-3, VPN routes fail to be exchanged between PE1 and PE2, and both PEs cannot ping each other successfully. Two loopback interfaces are configured on each PE. Loopback 1 interfaces on the two PEs are assigned public IP addresses, 1.1.1.1/32 and 1.1.1.2/32, respectively. Loopback 2 interfaces on the two PEs are bound to the VPN instance named test and assigned private network IP addresses, 10.1.1.1/24 and 10.1.1.2/24, respectively. Figure 1-3 Networking diagram of BGP/MPLS VPN Loopback 1 Loopback 1 PE1 Loopback 2 PE2 P1 Loopback 2 Fault Analysis 1. Run the display ip routing-table command on PE1 and PE2 to check whether both PEs have routes destined for each other's loopback1 interfaces. You can find that both PEs have such routes. 2. Run the display mpls ldp peer command on P1, and you can find that P1 establishes the LDP peer relationships, with PeerID being 1.1.1.1 and 1.1.1.2. Run the display mpls lsp command on P1, and you can find that P1 establishes LSPs with FECs being 1.1.1.1 and 1.1.1.2. 3. Run the display bgp peer command on P1 to check BGP peer relationships. You can find that P1 establishes IBGP peer relationships with 1.1.1.1 and 1.1.1.2, as indicated by Established in the command output. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 11 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 4. Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peer relationships. You can find that P1 establishes VPNv4 peer relationships with 1.1.1.1 and 1.1.1.2, indicating that VPN routes can be properly advertised. 5. After the preceding steps, run the display ip routing-table vpn-instance command on PE1 and PE2 to check the routes in the VRF, and you can find only one route destined for each other's loopback2 interfaces, that is, 10.1.1.0/24 Direct with a 24-bit mask instead of a 32bit mask. This indicates that both loopback2 interfaces are on the same network segment, which is obviously incorrect. In fact, both PEs have received the VPN routes (BGP routes) destined for each other's loopback2 interfaces. The received VPN routes, however, are on the same network segment as that of the route 10.1.1.0/24 Direct. In this case, both PEs consider that the received VPN routes are the same as 10.1.1.0/24 Direct, and therefore import only 10.1.1.0/24 Direct to their VPN routing tables because the direct route has a higher preference than the BGP route. As a result, both VPN routing tables do not contain the BGP routes, and the PEs cannot ping each other successfully. Procedure Step 1 On PE1 and PE2, run the system-view command to enter the system view. Step 2 Run the interface loopback loopback-number command to enter the loopback interface view. Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the loopback interface. NOTE Change the mask length of the loopback address to 32 bits. After the preceding configurations, the PEs can ping each other successfully. The fault is cleared. ----End Summary If two routes of different protocols are destined for the same network segment, the device only adds the one with a higher preference to the routing table. 1.2.3 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option B Setup Because the Mask of the Loopback Address on an Intermediate Router Is Incorrect NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 12 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Fault Symptom As shown in Figure 1-4. The Inter-AS VPN Option B is Setup, and the EBGP peer relationship is established between PE2 and CE2. It is found that CE2 can learn the route to 2.2.2.5 from CE1, but CE1 cannot learn the route to 1.1.1.5 from CE2. Figure 1-4 Networking diagram of inter-AS VPN Option B mode Loopback0 1.1.1.2/32 AS 100 Loopback0 1.1.1.1/32 ASBR1 Loopback0 1.1.1.3/32 AS 200 Loopback0 1.1.1.4/32 ASBR2 PE2 PE1 CE1 Loopback0 2.2.2.5/32 AS 300 CE2 AS 300 Loopback0 1.1.1.5/32 Fault Analysis NOTE In normal situations, routes are learnt in a bidirectional manner. With inter-AS VPN Option B, VPN routes are saved on intermediate ASBRs. To locate the fault, you need to check BGP VPNv4 routes on devices along the path to the device where the route to 1.1.1.5 is lost. 1. Run the display bgp vpnv4 all routing-table command sequentially on PE2, ASBR2, ASBR1, and PE1 to identify the device on which the VPNv4 route to 1.1.1.5 is lost. You can find that all the devices have this route, but PE1 does not take this route as an optimal route. 2. Run the display current-configuration command on ASBR1. You can find that the IP address of Loopback0 on ASBR1 is configured as 1.1.1.2 255.255.255.252. LDP labels are allocated only to host routes with a 32-bit mask by default. Loopback0 on ASBR1 has an IP address with a 30-bit mask and therefore it is not assigned an LDP label and the corresponding LSPs cannot be established. When PE1 learns a VPNv4 route, it checks whether the corresponding LSP is valid. If the LSP is not fully established because of incomplete label allocation, the VPNv4 route cannot be added to the VPN routing table. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 13 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Procedure Step 1 Run the system-view command to enter the system view. Step 2 Run the interface loopback loopback-number command to enter the loopback interface view. Step 3 Run the ip address ip-address { mask | mask-length } command to assign an IP address to the loopback interface. NOTE Change the mask length of the loopback address to 32 bits. Step 4 Run the return command to return to the user view. Step 5 Run the reset mpls ldp command to reset MPLS LDP. After the preceding configurations, run the display ip routing-table vpn-instance vpn-instancename command, and you can find that the routing table of vpna contains the route to 1.1.1.5. Run the ping -vpn-instance vpn-instance-name -a source-ip-address command on PE1. You can find the ping operation succeeds. The fault is cleared. ----End Summary When LDP is used to establish LSPs, LDP labels are allocated only to the host routes with a 32bit mask by default. If the corresponding route is not a host route, the LDP labels cannot be correctly allocates and the LSP cannot be established. 1.2.4 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom As shown in Figure 1-5, the same VPN instance, vpna, is configured on PE1, PE2, PE3, and PE4. To improve network reliability, double RRs are selected from Ps in the same AS for the VPN instance. In this manner, the two RRs back up each other and respectively reflect public network routes and VPNv4 routes. After the configurations, PE1 and PE2 cannot learn routes from PE3 and PE4, and PE3 and PE4 cannot learn routes from PE1 and PE2. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 14 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Figure 1-5 Networking diagram of the VPN with double RRs RR2 RR1 PE1 PE2 PE3 PE4 Fault Analysis 1. Check whether a routing policy that limits route advertisement is configured on the RRs. Run the display route-policy command on RR1 and RR2, and you can find that no RR is configured with a routing policy that restricts route reflection and reception. 2. Check whether route conflict occurs. Run the display ip routing-table vpn-instance vpna command on the PEs, and you can find that there is no route conflict in vpna. 3. Check whether the RRs are incorrectly configured. Run the display currentconfiguration command on the RRs to view BGP configurations. You can find that one RR is configured with the policy vpn-target command in the BGP-VPNv4 address family view.The policy vpn-target command is used to enable the VPN-Target filtering function for received VPNv4 routes. Only the VPNv4 route whose Export VPN target attribute matches the local Import VPN target attribute can be added to the routing table. The RR is not configured with the VPN instance vpna; as a result, the RR does not receive the routes with the VPN target as vpna. l Solution 1: Disable the VPN-Target filtering function for received VPNv4 routes on the RR. Procedure l Issue 01 (2011-10-15) 1. Run the system-view command to enter the system view. 2. Run the bgp as-number command to enter the BGP view. 3. Run the ipv4-family vpnv4 command to enter the BGP-VPNv4 address family view. 4. Run the undo policy vpn-target command to cancel VPN target filtering for VPNv4 routes. In this manner, all VPNv4 routes can be received. 5. After the preceding configurations, run the display ip routing-table command on PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4. Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2. The fault is thus rectified. Solution 2: Configure the VPN instance vpna on the RR. 1. Run the system-view command to enter the system view. 2. Run the ip vpn-instance vpn-instance-name command to create the VPN instance vpna. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 15 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 3. 1 L3VPN Troubleshooting Run the vpn-target vpn-target command to associate the VPN target with vpna. NOTE Note: vpn-target must be the same as that of vpna configured on the PEs. 4. After the preceding configurations, run the display ip routing-table command on PE1 and PE2. You can find that the two PEs have routes destined for PE3 and PE4. Similarly, you can find that PE3 and PE4 have routes destined for PE1 and PE2. The fault is thus rectified. ----End Summary The policy vpn-target command needs to be used with caution. 1.2.5 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom Figure 1-6 Networking diagram of BGP/MPLS IPv6 VPN Loopback0 1.1.1.1/32 Loopback0 Loopback0 2.2.2.2/32 3.3.3.3/32 GE1/0/0 GE1/0/0 12.1.1.2/30 23.1.1.2/30 PE2 GE1/0/0 GE2/0/0 12.1.1.1/30 GE2/0/0 P 23.1.1.1/30 10:2:1::22/64 GE1/0/0 10:2:1::21/64 PE1 GE2/0/0 10:1:1::12/64 GE1/0/0 10:1:1::11/64 CE1 CE2 The configuration in Figure 1-6 is as follows: l Issue 01 (2011-10-15) EBGP runs on the PEs and the CEs. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 16 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting l An IBGP adjacency is established between PE1 and PE2 to transmit VPNv6 routing information that contains inner labels. l An arbitrary IGP runs on PE1, the P, and PE2 to transmit routing information about the public network. l MPLS and MPLS LDP are enabled on PE1, the P, and PE2 After the configuration is complete, PE1 can receive private network routes from CE1, but PE2 and CE2 cannot do that. Fault Analysis 1. Run the display bgp vpnv6 all peer command on each PE. The command output shows that the BGP peer relationship is in the Established state, which indicates that the peer relationship is set up. 2. Run the display bgp vpnv6 all routing-table peer ipv4-address received-routes command on PE2. The command output shows that PE2 has received the VPNv6 route sent from PE1. 3. Run the display bgp vpnv6 vpn-instance vpn-instance-name routing-table ipv6address [ mask-length ] command on PE2 to view information about the tunnel to which the specified route is iterated. If the Relay token is 0x0, it indicates that the route to ip-address does not find the associated tunnel. The cause is that the setup of LSP for the next hop of the route fails. <PE2> display bgp vpnv6 vpn-instance vpna routing-table 66::66 128 BGP local router ID : 3.3.3.3 Local AS number : 100 Paths: 1 available, 0 best, 0 select BGP routing table entry information of 66::66/128 Label information (Received/Applied): 105472/NULL From: 1.1.1.1 (1.1.1.1) Route Duration: 00h02m17s Relay Tunnel Out-Interface: Relay token: 0x0 Original nexthop: ::FFFF:1.1.1.1 Qos information : 0x0 Ext-Community:RT <1 : 1> AS-path 65420, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255 Not advertised to any peer yet 4. Check whether there is an LSP to the next hop (1.1.1.1). <PE2> display mpls lsp include 1.1.1.1 32 If the display is blank, it indicates that there is no LSP to 1.1.1.1, and the LSP tunnel is not established successfully. 5. Check whether MPLS LDP is enabled on the interfaces between PE1 and P, and on the interfaces between P and PE2. [~PE1] interface gigabitethernet 1/0/0 [~PE1-GigabitEthernet1/0/0] display this # interface GigabitEthernet1/0/0 ip address 12.1.1.1 255.255.255.252 mpls # The preceding display shows that MPLS LDP is not enabled in the interface view. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 17 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Procedure Step 1 Run the interface gigabitethernet 1/0/0 command on PE2 to enter the interface view. Step 2 Run the mpls ldp command in the interface view to enable LDP on the interface. ----End Summary To transfer the traffic of private network across the public network, a public network tunnel is required. If the setup of a public network tunnel fails, the possible reason is that MPLS LDP is not enabled on the interface, or an LDP session is not established. As a result, the PE does not choose the private network route sent from the peer PE as the optimal route. 1.2.6 CEs Cannot Ping Through Each Other NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 1-7. CE1 and CE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2. Figure 1-7 Networking diagram of BGP/MPLS IPv6 VPN Loopback 1 Loopback 1 PE1 PE2 P1 CE1 Issue 01 (2011-10-15) P2 CE2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 18 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Fault Analysis NOTE Take the configuration of PE2 as an example. The configuration of PE1 is similar to that of PE2, and is not mentioned here. 1. Run the display bgp vpnv6 all peer command on PE2 to check the IBGP peer relationship between PE2 and PE1. You can find that the IBGP peer relationship is not set up successfully. 2. Check the BGP configuration. You can find that the loopback interface is not specified as the outbound interface of the local IBGP peer session by using the peer peer-ip-address connect-interface loopback interface-number command when the two PEs set up the IBGP connection. If the outbound interface is not specified for the local IBGP session, the outbound interface of the data stream is the outbound interface of the session by default.The IBGP peer relationship between PEs is usually set up by using the loopback interface addresses with each having a 32-bit mask, and the source interface through which BGP packets are sent is also set to the loopback interface. Procedure Step 1 Run the interface loopback interface-number in the system view. Step 2 Run the ip address ip-address 32 command to configure an IP address for the loopback interface. Step 3 Run the quit command to return to the system view. Step 4 Run the bgp as-number command to display the BGP view. Step 5 Run the peer peer-ip-address connect-interface loopback interface-number command to specify the loopback interface as the outbound interface to the IBGP peer session. On the local CE, ping the remote CE. If the ping succeeds, it indicates that the fault is rectified. ----End Summary Specify the local loopback interface as the outbound interface of the local IBGP session when configuring PE peers. 1.2.7 Failed to transmit Large Packets of the Private Network Fault Symptom When the Huawei device networks with devices from other vendors deploy Layer 3 MPLS IPv6 VPN service by using the Ethernet interface, it is found that the packet larger than 1492 bytes cannot be transmitted between private network users. Users cannot access certain websites or download files through FTP. Run the ping command, and find that the ping fails when the payload of the specified ICMP is larger than 1464 bytes. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 19 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Fault Analysis 1. The default MTU of an Ethernet interface is 1500 bytes. When forwarding data, MPLS IPv6 VPN inserts a 4-byte or 8-byte MPLS packet header between the IP header and the Layer 2 frame header. That is, a 4-byte label is added during the forwarding between the penultimate hop and the tail-end hop; a 8-byte label is added in data forwarding between other P devices. 2. The link layer does not know the MPLS processing. By default, the link layer still receives data packets with the maximum size of 1500 bytes. Then, packets of 1492 to 1500 bytes is too long after the MPLS packet header is added to the packets. Consequently, the link layer cannot receive them, and data forwarding is adversely affected. Procedure Step 1 Adjust the MTU value of the physical interfaces on other vendors' devices. The MTU value should be at least 1508 bytes. Step 2 By default, an Ethernet interface on the Huawei device can send and receive large frames. No adjustment is required on the Huawei device. ----End Summary When large packets cannot be received, check whether the MTU of the inbound interface is too small. 1.2.8 PE Fails to Ping Through the Remote CE Network Segment Fault Symptom Figure 1-8 Networking diagram of BGP/MPLS IPv6 VPN vpn1 Site1 CE1 vpn1 Backbone GE1/0/0 10::1:1:1/64 GE1/0/0 10::3:1:1/64 PE1 GE2/0/0 10::2:1:1/64 P Site3 CE3 PE2 CE2 Site2 vpn1 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 20 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting As shown in Figure 1-8, after binding multiple private network interfaces to the same VPN, run the ping ipv6 10::3:1:1 command on CE1 and CE2. CE1 and CE2 can ping through the remote network segment where CE3 resides. Run the ping ipv6 vpn-instance vpn1 10::3:1:1 command on PE1. PE1, however, cannot ping though the network segment where CE3 resides. Fault Analysis Multiple private network interfaces on the ingress node (a PE) are bound to the same VPN instance. When the PE pings or traces the remote CE network segment, the source address of the ICMP packet is the lowest private network address that is Up on the local PE; if the remote CE does not import the private network address, the ICMPv6 packet cannot return. Therefore, to ping through the remote CE segment by using the ping ipv6 vpn-instance vpninstance-name dest-ipv6-address command, ensure that the remote CE has all the Up private network addresses of the local PE. If the source IP address is specified as a private network address in the Up state on the local PE by using the ping command, and the private network address is imported to the remote CE, the PE can ping through the remote CE network segment. Procedure Step 1 Ensure that the remote CE has all the private network addresses in the Up state that belong to the local PE. Step 2 Run the import-route direct command in BGP VPN instance view of the local PE. Ensure that all private routes on the local PE can be advertised through MP-BGP. You can also replace the ping ipv6 vpn-instance vpn-instance-name dest-ip-address command with the ping ipv6 -a source-ipv6-address vpn-instance vpn-instance-name dest-ipv6-address command. ----End Summary When you ping the remote CE network segment from the local CE, it is recommended to specify the source address of the ping packet; otherwise, the ping may fail. 1.2.9 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 21 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Fault Symptom On the network shown in Figure 1-9, Router A, Router B, and Router C run IS-IS and are configured with L3VPN services. After the configurations, services between Router A and Router C flap. Figure 1-9 Networking diagram of frequent route flapping caused by alternation between Up and Down of a physical interface RouterA GE1/0/0 RouterB GE1/0/0 RouterC Fault Analysis 1. Run the display ip routing-table 1.1.1.1 commands on Router A to view the route type. It is found that routes are generated by IS-IS and LDP over TE is configured. Route Flags: R - relay, D - download for forwarding -----------------------------------------------------------------------------Routing Table : _public_ Summary Count : 1 Destination/Mask Proto Pre 1.1.1.1/32 ISIS 15 Route Entry Count: 1 Destination/Mask Nexthop 1.1.1.1/32 1.1.1.2 2. Cost 10 Flags NextHop D Interface 1.1.1.2 Flag TimeStamp DGHU t[17635149] Tunnel1/0/1 Interface Tun1/0/1 Run the display isis lsdb verbose command to view the IS-IS neighborship of the device. It is found that the IS-IS neighbor relationship is established for a long time and is stable. This indicates that the IS-IS neighbor relationship is normal. Database information for ISIS(100) ---------------------------------Level-2 Link State Database LSPID Seq Num Checksum Holdtime OL 0000.0255.0239.00-00 0x00003038 0xd401 867 INTF ADDR 1.1.1.1 Router ID 1.1.1.1 3. TunnelID 0x1008e Length ATT/P/ 367 0/0/0 Run the display isis lsdb 0000.0255.0239.00-00 command to check whether the specific LSP changes. Database information for ISIS(100) ---------------------------------Level-2 Link State Database Seq Num Checksum Holdtime LSPID Length ATT/P/ OL -----------------------------------------------------------------------------0000.0255.0239.00-00 0x00003038 0xd401 831 367 0/0/0 *(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 22 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Database information for ISIS(100) ---------------------------------Level-2 Link State Database Seq Num Checksum Holdtime LSPID Length ATT/P/ OL -----------------------------------------------------------------------------0000.0255.0239.00-00 0x00003038 0xd401 829 367 0/0/0 *(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended), ATT-Attached, P-Partition, OL-Overload According to the preceding information, the LSP is normal with the length and hold-time parameters unchanged. Therefore, route flapping is not caused by IS-IS. 4. Run the display mpls lsp include 1.1.1.1 32 command to check whether the TE tunnel flapping occurs. It is found that the LSP to the IP address does not flap. The LDP LSP is Up for a short time, which indicates that the LDP LSP flaps. As a result, route flapping occurs. -----------------------------------------------------------------------------LSP Information: RSVP LSP ------------------------------------------------------------------------------ Issue 01 (2011-10-15) No SessionID IngressLsrID LocalLspID Tunnel-Interface Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token LsrType Bypass In Use Bypass Tunnel Id BypassTunnel Mpls-Mtu TimeStamp Bfd-State : : : : : : : : : : : : : : : : : : : : 1 12 1.1.1.3 32778 Tunnel1/0/2 1.1.1.1/32 1.1.2.1 65542 65686 GigabitEthernet2/0/0 GigabitEthernet3/0/0 2123 0x700bef8 Transit Not Exists 0x0 Tunnel Index[---] 1600 309526sec --- No SessionID IngressLsrID LocalLspID Tunnel-Interface Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token LsrType Bypass In Use Bypass Tunnel Id BypassTunnel Mpls-Mtu TimeStamp Bfd-State : : : : : : : : : : : : : : : : : : : : 2 12 1.1.1.2 1 Tunnel1/0/2 1.1.1.1/32 1.1.2.1 NULL 65817 ---------GigabitEthernet3/0/0 2181 0x700bf18 Ingress Not Exists 0x0 Tunnel Index[---] 1600 309524sec --- No SessionID : : 3 12 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 23 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting IngressLsrID : 1.1.1.2 LocalLspID : 32773 Tunnel-Interface : Tunnel1/0/2 Fec : 1.1.1.1/32 Nexthop : 1.1.2.2 In-Label : NULL Out-Label : 65581 In-Interface : ---------Out-Interface : GigabitEthernet2/0/0 LspIndex : 2827 Token : 0x80094a9 LsrType : Ingress Bypass In Use : Not Exists Bypass Tunnel Id : 0x0 BypassTunnel : Tunnel Index[---] Mpls-Mtu : 1600 TimeStamp : 1825411sec Bfd-State : -------------------------------------------------------------------------------LSP Information: LDP LSP -----------------------------------------------------------------------------No : 4 VrfIndex : Fec : 1.1.1.1/32 Nexthop : 1.1.1.2 In-Label : 1102 Out-Label : 3 In-Interface : ---------Out-Interface : Tunnel1/0/2 LspIndex : 72894 Token : 0x1008f FrrToken : 0x0 LsrType : Transit Outgoing token : 0x0 Label Operation : SWAP Mpls-Mtu : -----TimeStamp : 10sec Bfd-State : --No VrfIndex Fec Nexthop In-Label Out-Label In-Interface Out-Interface LspIndex Token FrrToken LsrType Outgoing token Label Operation Mpls-Mtu TimeStamp Bfd-State 5. : : : : : : : : : : : : : : : : : 5 1.1.1.1/32 1.1.1.2 NULL 3 ---------Tunnel1/0/2 72897 0x1008e 0x0 Ingress 0x0 PUSH -----10sec --- Run the display mpls ldp session command to view the status of the LDP neighbor. It is found that the LDP neighbor is flapping. LDP Session(s) in Public Network -----------------------------------------------------------------------------Peer-ID Status LAM SsnRole SsnAge KA-Sent/Rcv -----------------------------------------------------------------------------...... 1.1.1.1:0 Operational DU Passive 000:00:00 20492/20493 Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 24 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting ...... -----------------------------------------------------------------------------TOTAL: 36 session(s) Found. LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM 6. Run the display mpls ldp peer command to view information about the LDP peer. The command output shows two LDP peers, namely, a remote LDP peer and a local LDP peer. LDP Peer Information in Public network -----------------------------------------------------------------------------Peer-ID Transport-Address Discovery-Source -----------------------------------------------------------------------------1.1.1.1:0 1.1.1.1 Remote Peer : otb-to-trg -----------------------------------------------------------------------------TOTAL: 36 Peer(s) Found. LDP Peer Information in Public network -----------------------------------------------------------------------------Peer-ID Transport-Address Discovery-Source -----------------------------------------------------------------------------1.1.1.1:0 1.1.1.1 GigabitEthernet1/0/0 -----------------------------------------------------------------------------TOTAL: 36 Peer(s) Found. 7. Run the display interface gigabitethernet1/0/0 command to view the status of the interface. It is found that the interface frequently alternates between Up and Down. As a result, route flapping occurs. GigabitEthernet1/0/0 current state : UP Line protocol current state : DOWN Description:10G_Link_to-TRG_Through_ODF 23/24 Route Port,The Maximum Transmit Unit is 1500 Internet protocol processing : disabled IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7b2e5 The Vendor PN is SXP3101SV-H12 BW: 10G, Transceiver Mode: SingleMode WaveLength: 1550nm, Transmission Distance: 40km Rx Power: -4.50dBm, Tx Power: 1.14dBm Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and Send Enable Last physical up time : 2010-05-20 21:33:42 Last physical down time : 2010-05-20 21:31:58 Statistics last cleared:2010-04-25 02:10:55 Last 300 seconds input rate: 0 bits/sec, 0 packets/sec Last 300 seconds output rate: 0 bits/sec, 0 packets/sec Input: 486833280327643 bytes, 720675974914 packets Output: 66656626810850 bytes, 400094354049 packets Input: Unicast: 720675171257 packets, Multicast: 797735 packets Broadcast: 5922 packets, JumboOctets: 38836146308 packets CRC: 688 packets, Symbol: 200 packets Overrun: 0 packets InRangeLength: 0 packets LongPacket: 0 packets, Jabber: 0 packets, Fragment: 3 packets, Undersized Frame: 0 packets RxPause: 0 packets Output: Unicast: 400093379625 packets, Multicast: 973669 packets Broadcast: 755 packets, JumboOctets: 1138327781 packets System: 0 packets, Overruns: 0 packets TxPause: 0 packets Unknown Vlan: 0 packets GigabitEthernet1/0/0 current state : UP Line protocol current state : DOWN Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 25 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Description:10G_Link_to-TRG_Through_ODF 23/24 Route Port,The Maximum Transmit Unit is 1500 Internet protocol processing : disabled IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0018-82d7b2e5 The Vendor PN is SXP3101SV-H12 BW: 10G, Transceiver Mode: SingleMode WaveLength: 1550nm, Transmission Distance: 40km Rx Power: -4.50dBm, Tx Power: 1.14dBm Loopback:none, LAN full-duplex mode, Pause Flowcontrol:Receive Enable and Send Enable Last physical up time : 2010-05-20 21:33:45 Last physical down time : 2010-05-20 21:31:43 Statistics last cleared:2010-04-25 02:10:55 Last 300 seconds input rate: 0 bits/sec, 0 packets/sec Last 300 seconds output rate: 0 bits/sec, 0 packets/sec Input: 486833280327643 bytes, 720675974914 packets Output: 66656626810850 bytes, 400094354049 packets Input: Unicast: 720675171257 packets, Multicast: 797735 packets Broadcast: 5922 packets, JumboOctets: 38836146308 packets CRC: 688 packets, Symbol: 200 packets Overrun: 0 packets InRangeLength: 0 packets LongPacket: 0 packets, Jabber: 0 packets, Fragment: 3 packets, Undersized Frame: 0 packets RxPause: 0 packets Output: Unicast: 400093379625 packets, Multicast: 973669 packets Broadcast: 755 packets, JumboOctets: 1138327781 packets System: 0 packets, Overruns: 0 packets TxPause: 0 packets Unknown Vlan: 0 packets Procedure Step 1 Run the system-view command on Router A to enter the system view. Step 2 Run the interface interface-type interface-number command on Router A to enter the interface view. Step 3 Run the shutdown command on Router A. Packets are transmitted from Router A through Router C to Router B instead of from Router A to Router B. Then, services are running normally. After the preceding operations, packets are not directly sent from Router A to Router B. Instead, packets from Router A pass through Router C to reach Router B. The fault is rectified and services become normal. ----End Summary When route flapping occurs, you need to check the route type, and then check whether the relevant protocols flap. If the protocols do not flap, you need to check whether IP address collision occurs. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 26 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1.2.10 CE Cannot Access Some Web Servers Due to the MTU Configuration Fault Symptom On the network shown in Figure 1-10, BGP/MPLS VPN is configured on the PEs. CE1, Web server A, and Web server B are in the same VPN. PE3 and Web server A are connected through a firewall. After the configuration is complete, the CE cannot access some Web servers. Figure 1-10 Networking diagram of the CE failing to access some Web servers CE2 Web Server B PE2 PE1 P Switch PE3 Firewall Web Server A CE3 CE1 Fault Analysis 1. Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP peer relationships are set up between the PEs and between the PE and CE and are in the Established state. 2. Run the ping -vpn-instance vpn-instance-name command on PE1, PE2, and PE3. The accessed CEs can be pinged successfully from the PEs. 3. Run the display current-configuration configuration vpn-instance vpn-instance-name command on PE1, PE2, and PE3 to view the configurations of the VPN instances. It is found that the VPN instances on the PEs are configured correctly and the import VPN target on one PE matches the export VPN target on another PE. 4. Capture packets on an interface of the PE. It is found that the length of an IP packet sent from the Web server is 1496 bytes and the IP packet cannot be fragmented. The length of the packet becomes 1504 bytes (1496+8(length of double MPLS labels)) after the packet enters the MPLS network. 5. Run the display mpls lsp verbose command on PE1, PE2, and the P to view the MTU of MPLS packets on an interface. It is found that the MTU value for MPLS packets on the P Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 27 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting is 1500. As the MPLS packets are longer than 1504 bytes, they are discarded on the PE or P. Procedure Step 1 Run the system-view command on the P to enter the system view. Step 2 Run the interface interface-type interface-number command to enter the interface view of the interface connecting the P to the PE. Step 3 Run the mtu mtu command to reconfigure the MTU value on the interface. Step 4 Run the mpls mtu 1600 command to re-configure the MTU value for MPLS packets on the interface. NOTE The relationship between the MPLS MTU on an interface and the interface MTU is as follows: l If the MPLS MTU is not configured on the interface, the MTU on the interface is used. l If the MTU of the MPLS packets is set, the MPLS MTU is compared with the MTU on the interface and the smaller one is adopted. Step 5 Run the commit command to commit the configuration. After the preceding operations, it is found that CE1 can access Web server A and Web server B. The fault is rectified. ----End Summary The cause of this troubleshooting case is as follows: l The packet sent from the Web server cannot be fragmented, and the packet length exceeds the MPLS MTU on the P after two MPLS labels are added. As a result, the packet is discarded on the P. l The Firewall prevents ICMP packets, causing the path MTU discovery mechanism to be invalid. The basic principle of the path MTU discovery mechanism is as follows: 1. The source initially adopts the MTU on the fist hop interface as the MTU of the path to the destination and sets the value of the Don't Fragment (DF) bit in all IP packets sent to the destination to 1. 2. When a device along the path receives the packet and forwards the packet on an outbound interface, the device discovers that the packet length exceeds the MTU on the outbound interface and the value of the DF bit is 1. In this case, the device discards the packet and responds with an ICMP unreachable packet (type=3, code=4, fragment needed but don'tfragment bit set) to the source. 3. After receiving the ICMP unreachable packet, the source decreases the path MTU value and re-sends the IP packet. This problem is caused by an incorrect MTU value. To resolve the problem, re-configure the MTU. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 28 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1.2.11 The RR Fails to Reflect VPN Routes Fault Symptom On the network shown in Figure 1-11, an Route Reflector (RR) is configured to optimize BGP/ MPLS VPN services. CE1 and CE2 are in the same VPN. After the configuration is complete, it is found that the RR can learn a VPNv4 route advertised by PE1 but PE2 fails to learn this route. Figure 1-11 Networking diagram of the RR failing to reflect VPN routes Route Reflector PE1 (Client1) CE1 PE2 (Client2) CE2 Fault Analysis 1. Run the display current-configuration configuration bgp command on the RR and PEs. It is found that route reflection relationships are correctly set up between the RR and two PEs. 2. Run the display bgp vpnv4 all peer command on the RR. It is found that the IBGP peer relationships between the RR and the PEs are in the Established state ( BGP current state: Established, Up for 00:21:15). 3. Run the display ip extcommunity-filter command on the RR to view information about the extended community attribute filter. Extended Community filter Number 1 deny rt : 100:1 permit rt : 200:1 The output of the display ip extcommunity-filter command indicates that the routes with the RT being 100:1 are filtered out. 4. Run the display ip vpn-instance verbose command on PE1 to view detailed information about all VPN instances. Total VPN-Instances configured : 1 VPN-Instance Name and ID : a, 1 Create date : 2010/06/23 20:18:40 UTC+08:00 DST Up time : 0 days, 00 hours, 02 minutes and 27 seconds Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 29 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Route Distinguisher : 1:1 Export VPN Targets : 100:1 Import VPN Targets : 111:1 Label Policy : label per route Import Route Policy : p1 Export Route Policy : p2 The diffserv-mode Information is : uniform The ttl-mode Information is : pipe The VPN QoS configuration information : based on VPN CIR: 10000000 PIR: 10000000 QoS-profile name: profile1 Tunnel Policy : tnlpolicy1 Description : This is a VPN for company1. Maximum Routes Limit : 100 Log Interval : 5 Interfaces : GigabitEthernet1/0/0 The output of the display ip vpn-instance verbose command indicates that the packets with the Export VPN Targets field being 100:1 are filtered out on the RR. As a result, the RR does not reflect routes to PE2. Procedure Step 1 Run the system-view command on the RR to enter the system view. Step 2 Run the ip extcommunity-filter 1 permit rt 100:1 command on the RR to make the Export RT on PE1 and the RT of the extended community filter on the RR the same. Step 3 Run the bgp as-number command on the RR to enter the BGP view. Step 4 Run the ipv4-family vpnv4 command on the RR to enter the BGP-VPNv4 address family view. Step 5 Run the undo rr-filter command on the RR to delete the original reflection policy of the RR. Step 6 Run the rr-filter 1 command on the RR to specify a new reflection policy for the RR. After the preceding operations, PE2 can learn the VPNv4 routes advertised by PE1. The fault is rectified. ----End Summary When configuring an RR, ensure that the Import VPN target and Export VPN target match the RTs on PE1 and PE2. To minimize the impact of incorrect configurations, you can run the undo policy vpn-target command to permit all VPNv4 routes. 1.2.12 CE1 Cannot Register with CE2 Because the Number of Routes of the VPN Instance Exceeds the Maximum Limit Fault Symptom On the network shown in Figure 1-12, the PE is configured with BGP/MPLS VPN services, which are classified into signaling VPN services and media VPN services. CE1 is an Access Gateway (AG) device; CE2 is a Softswitch device (Soft3000); CE1 and CE2 are in the same VPN. After the configuration is complete, it is found that CE1 cannot register with CE2. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 30 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Figure 1-12 Networking diagram of an AG device failing to register with a Softswitch device PE1 CE1 P PE2 CE2 Fault Analysis 1. Run the display bgp vpnv4 all peer command on PE1 and PE2. It is found that the BGP peer relationships between the PEs and between the PEs and CEs are in the Established state. 2. Run the ping -vpn-instance vpn-instance-name command on PE1 and PE2. It is found that the PEs can ping the corresponding CEs successfully. 3. Run the display ip routing-table vpn-instance vpn-instance-name command on PE1 and PE2. It is found that PE1 and PE2 have VPN instance routes that are destined for each other. 4. Run the display bgp vpnv4 all routing-table 10.1.1.1 command on PE1 to view the information about the BGP routes to the network segment 10.1.1.1/24. It is found that there are two routes in the signaling VPN and no route in the VPN instance. Total routes of Route Distinguisher(65029:2995): 2 BGP routing table entry information of 10.1.1.1/24: Label information (Received/Applied): 589826/NULL From: 11.1.1.1 (11.1.1.1) Original nexthop: 12.1.1.1 Ext-Community: <65029 : 2995> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, pre 255 Originator: 12.1.1.1 Cluster list: 11.1.1.1 Not advertised to any peer yet BGP routing table entry information of 172.16.7.20/30: Label information (Received/Applied): 589826/NULL From: 11.1.1.2 (11.1.1.2) Original nexthop: 12.1.1.1 Ext-Community: <65029 : 2995> AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, pre 255 Originator: 12.1.1.1 Cluster list: 11.1.1.2 Not advertised to any peer yet Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 31 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 5. 1 L3VPN Troubleshooting Run the display current-configuration configuration vpn-instance vpn-instance-name command on PE1 to view the configurations of the VPN instance. It is found that route restriction is configured in the signaling VPN of PE1. ip vpn-instance ngn-signal route-distinguisher 65029:2995 apply-label per-instance routing-table limit 100 80 vpn-target 65029:2995 export-extcommunity vpn-target 65029:2995 import-extcommunity 6. Run the display ip routing-table vpn-instance vpn-instance-name statistics command on PE1 to view the statistics on the routes of the VPN instance. It is found that the number of the routes of the VPN instance exceeds the threshold of route restriction. Proto DIRECT STATIC RIP OSPF IS-IS BGP Total total routes 10 1 0 8 0 81 100 original routes 10 1 0 8 0 81 100 active routes 10 1 0 6 0 34 51 original active 10 1 0 6 0 34 51 added routes 10 2 0 13 0 0 25 deleted routes 0 1 0 5 0 0 6 freed routes 0 1 0 5 0 0 6 The number of actual VPN instance routes exceeds the threshold of route restriction. Therefore, new VPN instance routes from PE2 cannot be added to the VPN routing table on PE1. As a result, the AG cannot register with the softswitch. Procedure Step 1 Run the system-view command on PE1 to enter the system view. Step 2 Run the ip vpn-instance vpn-instance-name command on PE1 to enter the VPN instance view. Step 3 Run the prefix limit 200 80 command on PE1 to re-configure the maximum number of routes supported by the current VPN instance. After the preceding operations, CE2 can be pinged successfully from CE1, and CE1 can register with CE2. The fault is rectified. ----End Summary If the maximum number of routes supported by the VPN instance is configured, you need to check whether the actual routes in an VPN instance exceeds the configured upper threshold. 1.2.13 VPNv4 Routes on a PE Cannot Take Effect Fault Symptom On the network shown in Figure 1-13, three PEs are configured with BGP/MPLS VPN services. Traffic from a CE is balanced between PE1 and PE2. PE2 is connected to PE1, and PE1 is connected to PE3 over a Metropolitan Area Network (MAN). After the configurations, PE1 learns the route to the network segment 10.1.2.0, and the BGP VPNv4 routing table of PE2 contains this route entry, but the VPN instance routing table of PE2 does not. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 32 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Figure 1-13 Networking diagram of the case where VPNv4 routes on a PE cannot take effect PE3 10.1.2.1/24 MAN 10.1.1.1/24 10.1.1.2/24 PE1 PE2 CE Fault Analysis 1. Run the display bgp vpnv4 all routing-table command on PE2 to view BGP VPNv4 routes. PE2 has learned the route to the network segment 10.1.2.0 but the route is not optimal. Network *> 1.1.1.0/24 export * 1.1.1.2/32 export *i 10.1.2.0/24 2. NextHop 1.1.1.1 MED 0 1.1.1.1 0 10.1.1.1 100 LocPrf PrefVal Community 0 no0 0 nono-export Run the display ip routing-table vpn-instance vpn1 10.1.2.0 verbose command on PE2 to view the routing table of the VPN instance. Routing Table : vpn1 Summary Count : 1 Destination: 10.1.2.0/24 Protocol: 0 Preference: 0 NextHop: NULL0 RelayNextHop: 10.1.1.1 Issue 01 (2011-10-15) BGP Process ID: 255 Cost: 10.1.1.1 Interface: 0.0.0.0 Neighbour: Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 33 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN Label: 109568 1 L3VPN Troubleshooting Tunnel ID: 0x0 SecTunnel ID: 0x0 BkNextHop: 0.0.0.0 BkInterface: BkLabel: NULL 0x0 Tunnel ID: SecTunnel ID: 0x0 State: Inactive Adv WaitQ Age: 22h35m37s The preceding routing information shows that the outbound interface of the next hop is Null0, and thus packets are discarded. If VPNv4 routes are used to forward traffic, LSP labels of the public network will be added to the routes. Before adding a VPNv4 route to the routing table of a VPN instance, the system checks whether the route contains a corresponding LSP label of the public network. If no such LSP label corresponding to the VPNv4 route exists, the route will not be added to the routing table. 3. Run the display mpls lsp command on PE2. No route to 10.1.1.1 is displayed, indicating that no neighbor relationship has been established between PE1 and PE2. Procedure Step 1 Run the system-view command on PE1 to enter the system view. Step 2 Run the mpls command to enable MPLS and enter the MPLS view. Step 3 Run the quit command to return to the system view. Step 4 Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view. Step 5 (Optional) Run the lsr-id lsr-id command to set the LSR ID for the LDP instance. Step 6 Run the quit command to return to the system view. Step 7 Run the interface interface-type interface-number command to enter the view of the interface connecting PE1 to the peer. Step 8 Run the mpls command to enable MPLS on this interface. Step 9 Run the mpls ldp command to enable LDP on this interface. Perform all the preceding operations on PE2. After the operations, PE1 will have learned the route to the network segment 10.1.2.0 and both the BGP VPNv4 routing table of PE2 and the routing table of the VPN instance have routes to the network segment 10.1.2.0. The fault is rectified. ----End Summary If VPNv4 routes are used to forward traffic, LSP labels of the public network will be added to the routes. Before adding a VPNv4 route to the routing table of a VPN instance, the system checks whether the route contains a corresponding LSP label of the public network. If there is no such LSP label corresponding to the VPNv4 route, the route will not be added to the routing table. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 34 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting 1.2.14 MPLS VPN Convergence Is Slow Fault Symptom The protocols of IS-IS and BGP and MPLS VPN services are configured on six PE devices. All the PEs use the same RD; PE1 and PE2 serve as RRs. The router ID of PE1 is smaller than that of PE2; the router ID of PE3 is smaller than that of PE4; the router ID of PE5 is smaller than that of PE6. The two CEs belong to the same VPN. Figure 1-14 Typical Network Diagram for MPLS VPN PE1 PE3 PE2 PE4 PE5 CE1 PE6 CE2 After PE3 is restarted, PE5 and PE6 have to wait for 2 minutes before learning the route to the segment where CE1 resides. Fault Analysis PE5 and PE6 learn two equal-cost MPLS VPN routes to CE1 through PE3 and PE4. IGP selects the route passing through PE3 as the optimal route to CE1 because the router ID of PE3 is smaller than that of PE4. After PE3 is restarted, the two RRs (PE1 and PE2) forward another route to the segment where CE1 resides to PE5 and PE6 when confirming that they cannot establish BGP neighbor relationships with PE3. After IGP convergence is complete, MPLS VPN convergence starts. MPLS VPN convergence is rather slow because its time depends on the number of routing entries in the routing tables of the routers. Usually, MPLS VPN convergence takes about 2 minutes. Procedure Step 1 Run the system-view command on PE3 to enter the system view. Step 2 Run the ip vpn-instance vpn-access command to enter the view of the corresponding VPN instance. Step 3 Run the route-distinguisher 22:1 command to change the RD for the VPN instance on PE3 to be different from that on the other PEs. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 35 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting After the configuration, PE5 and PE6 learn two MPLS VPN routes with different next hops to CE1 through PE3 and PE4. One of the routes is active, and the other is inactive. When PE3 is restarted again, the active route is removed from the MPLS VPN routing table. In this case, the inactive route quickly switches to be an active route without waiting for the finding of a reachable IGP route. Therefore, the convergence speed is rather quick. The fault is rectified. ----End Summary MPLS VPN convergence may become slow due to slow IGP convergence. In this case, you can set different RDs on PEs to configure two MPLS VPN routes for backup or alternatively configure VPN FRR to rectify the fault. 1.2.15 One-way Audio Occurs Between the CEs Because the vpntarget import-extcommunity Command Is Not Configured Fault Symptom On the network shown in Figure 1-15, each CE (UMG) is dual-homed to two PEs. The PEs on the network belong to different planes: l PE1 and PE2 belong to plane A. l PE3 and PE4 belong to plane B. In normal situations, the traffic between the CEs, which are in the same VPN, is transmitted on plane B. Different VPN instances are configured on the PEs to separately carry signaling traffic and media traffic between the CEs. When the configuration is complete, call tests are conducted. In the first try, one-way audio occurs: Voices from Phone1 can be heard on Phone2, but voices from Phone2 cannot be heard on Phone1. In the second try, voices can be heard on both phones. Figure 1-15 Networking diagram of one-way audio between the CEs CE 1 (UMG1) Network PE 1 PE 2 CE 2 (UMG2) Plane A Plane B PE 4 PE 3 Network Phone1 Issue 01 (2011-10-15) Phone2 Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 36 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Fault Analysis 1. Calls can be successfully set up between the CEs, it indicates that the problem is not on the VPN instance bearing signaling traffic but on the VPN instance bearing media traffic between the CEs. 2. Run the display current-configuration configuration vpn-instance command on PE3 to check the configurations of the VPN instance bearing media traffic. You can find that the vpn-target import-extcommunity command is not configured. As a result, PE3 does not receive the VPN route that is used to transmit media traffic from PE4. So, the media traffic from CE2 is not sent to CE1. That is the reason why there is oneway audio from Phone1 to Phone2 in the first call try. On the CE side, media traffic is sent to both the PEs to which the CE is dual-homed. In the first call, media traffic is transmitted on plane B. Once the transmission on plane B has problems (that is, one CE does not receive the traffic from the other CE), media traffic enters plane A for transmission in the next dial-up. That is the reason why voices can be heard on both Phone1 and Phone2 in the second call try. Procedure Step 1 Run the system-view command to enter the system view on PE3. Step 2 Run the ip vpn-instance vpn-instance-name command to enter the view of the VPN instance that carries the media traffic between the CEs. Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command to configure VPNtarget of the extended community attribute to receive the routing information that carries the specified VPN-target. When the configuration is complete, the audio communication between Phone1 and Phone2 is normal in call tests. ----End Summary In the application of BGP/MPLS VPN on the Next Generation Network (NGN), different VPN instances are used to separately bear signaling traffic and media traffic. If a fault occurs, first determine based on the fault symptom whether it is due to the VPN instance bearing signaling traffic or the VPN instance bearing media traffic. In addition, VPN-target has no default value. Therefore, you need to manually configure VPNtarget when creating a VPN instance. You can specify "both", "export", or "import" to associate a VPN instance with one or more VPN-targets. By default, "both" is used. 1.2.16 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not a 32-bit Mask Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 37 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting NOTE After commands are configured to troubleshoot faults, pay attention to the configuration validation mode to ensure that the configurations take effect. Unless otherwise specified, this manual defaults to the immediate validation mode. l In immediate validation mode, configurations take effect after commands are input and the Enter key is pressed. l In two-phase validation mode, after commands are configured, the commit command needs to be run to commit the configurations. Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correct the fault, you will have a record of your actions to provide Huawei technical support personnel. Fault Symptom On the network shown in Figure 1-16, BGP/MPLS IP VPN services and OSPF are configured on the two PEs and the P. A loopback interface is created on each PE and bound to a VPN instance named vpn1. The IP address of the loopback interface on PE1 is 1.1.1.1; the IP address of the loopback interface on PE2 is 1.1.1.2. When the configuration is complete, the two PEs cannot exchange private network routes, and the ping between them fails. Figure 1-16 Networking diagram for the failure in exchanging private network routes between PEs Loopback1 PE 1 Loopback1 GE1/0/1 GE1/0/2 GE1/0/2 GE1/0/1 PE 2 P Fault Analysis 1. Run the display ospf peer command on each PE, and you can view that the neighbor status is Full. Run the display ip routing-table command on each PE, and you can view that each PE has learned the route to Loopback1 on the peer PE. 2. Run the display mpls ldp session command on the P. The command output shows that the LDP peer relationship between the P and PE is in the Operational state, meaning that the LDP peer relationship has been established. 3. Run the display mpls lsp command on both PEs to check label allocation. You can find that the PEs have LSPs to each other. 4. Run the display this command in the BGP-VPNv4 address family view on each PE. You can find that the peer ipv4-address enable command has been configured. Run the display bgp vpnv4 all peer command on each PE. You can find that the BGP peer relationships are established between the PEs and between the PE and CE. 5. Run the display ip routing-table vpn-instance vpn1 command on each PE to check the VPN routing table. A route, 1.1.1.0/24 direct, with Loopback1 being the outbound interface, is found in the routing table. The mask of the route is a 24-bit value rather than a 32-bit value. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 38 HUAWEI NetEngine5000E Core Router Troubleshooting - VPN 1 L3VPN Troubleshooting Take the display on PE1 as an example. Destination/Mask 1.1.1.0/24 6. Proto Pre Direct 0 Cost 0 Flags NextHop D 1.1.1.1 Interface LoopBack1 Run the display ip interface brief command on each PE. You can find that a 24-bit mask (not a 32-bit mask) is configured for the IP address of Loopback1. Take the display on PE1 as an example. Interface LoopBack1 IP Address/Mask 1.1.1.1/24 Physical up Protocol up(s) In this manner, the IP addresses of loopback interfaces on the two PEs belong to the same network segment (1.1.1.0/24). In fact, the PEs have learned private network routes from each other. On each PE, the learned private network route and local Loopback1, however, belong to the same network segment. Then, there are two routes to Loopback1 on the peer PE: One is a direct route; the other is a BGP route. In this case, the PE places the direct route in its routing table, and there are no private network routes in the VPN routing table. As a result, Loopback1 on the peer PE fails to be pinged. Procedure Step 1 Run the system-view command on PE1 and PE2 to enter the system view. Step 2 Run the interface loopback1 command on PE1 and PE2 to enter the view of Loopback1 bound to the VPN instance. Step 3 Run the ip address ip-address { mask | mask-length } command on PE1 and PE2 to configure an IP address with a 32-bit mask on each PE. When the configuration is complete, the PEs can successfully ping Loopback1 on each other, and the fault is rectified. ----End Summary When configuring BGP/MPLS IP VPN services, ensure that the IP addresses of the interfaces bound to the same VPN instance but residing on different PEs belong to different network segments. Issue 01 (2011-10-15) Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd. 39