Troubleshooting HUAWEI VPN

HUAWEI NetEngine80E/40E RouterV600R003C00

Troubleshooting - VPN

Issue 02Date 2011-09-10

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 writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied. Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.comEmail: [email protected]

Issue 02 (2011-09-10) Huawei Proprietary and ConfidentialCopyright Huawei Technologies Co., Ltd.

i

About This Document

PurposeNOTE

l This document takes interface numbers and link types of the NE40E-X8 as an example. In workingsituations, the actual interface numbers and link types may be different from those used in thisdocument.

l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called LineProcessing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). Onthe NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functionsof LPUs and SFUs to exchange and forward packets.

This document describes how to troubleshoot the services of the HUAWEI NetEngine80E/40E in terms of common faults and causes, troubleshooting cases, and FAQs.This document describes the procedure and method for troubleshooting for the HUAWEINetEngine80E/40E.

Related VersionsThe following table lists the product versions related to this document.

Product Name VersionHUAWEI NetEngine80E/40ERouter

V600R003C00

Intended AudienceThis document is intended for:l System maintenance engineersl Commissioning engineersl Network monitoring engineers

HUAWEI NetEngine80E/40E RouterTroubleshooting - VPN About This Document


ii

Symbol ConventionsThe symbols that may be found in this document are defined as follows.

Symbol Description

DANGERIndicates a hazard with a high level of risk, which if notavoided, will result in death or serious injury.

WARNINGIndicates a hazard with a medium or low level of risk, whichif not avoided, could result in minor or moderate injury.

CAUTIONIndicates a potentially hazardous situation, which if notavoided, could result in equipment damage, data loss,performance degradation, or unexpected results.

TIP Indicates a tip that may help you solve a problem or savetime.

NOTE Provides additional information to emphasize or supplementimportant points of the main text.

Command ConventionsThe command conventions that may be found in this document are defined as follows.

Convention DescriptionBoldface 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 allitems can be selected.

[ x | y | ... ]* Optional items are grouped in brackets and separated byvertical bars. Several items or no item can be selected.

& The parameter before the & sign can be repeated 1 to n times.# A line starting with the # sign is comments.



iii

Change HistoryChanges between document issues are cumulative. The latest document issue contains all thechanges made in earlier issues.

Changes in Issue 02 (2011-09-10)The second commercial release. There is no update compared with the previous issue.

Changes in Issue 01 (2011-05-30)Initial field trial release.



iv

Contents

About This Document.....................................................................................................................ii1 L3VPN Troubleshooting..............................................................................................................1

1.1 BGP Private Network Traffic Is Interrupted......................................................................................................21.1.1 Common Causes........................................................................................................................................21.1.2 Troubleshooting Flowchart........................................................................................................................21.1.3 Troubleshooting Procedure........................................................................................................................31.1.4 Relevant Alarms and Logs........................................................................................................................8

1.2 Related Troubleshooting Cases..........................................................................................................................81.2.1 VPNs Configured with the Same VPN Target Cannot Communicate......................................................91.2.2 Ping Between the PEs on a VPN Fails....................................................................................................111.2.3 Communications Between the VPN and the Public Network Fail on a Device......................................121.2.4 VPN Services Are Interrupted Because the Link Between an ABR and a BAS Fails in a Full-meshedNSSA................................................................................................................................................................181.2.5 A Routing Loop Occurs After a Sham Link Is Established Between PEs..............................................201.2.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN Option B Setup Because the Mask of theLoopback Address on an Intermediate Router Is Incorrect..............................................................................231.2.7 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR..................241.2.8 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE............................261.2.9 CEs Cannot Ping Through Each Other....................................................................................................281.2.10 Failed to transmit Large Packets of the Private Network......................................................................291.2.11 PE Fails to Ping Through the Remote CE Network Segment...............................................................301.2.12 CEs in the Inter-AS IPv6 VPN Option C Fail to Communicate with Each Other................................311.2.13 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down..........................................................................................................................................................................321.2.14 CE Cannot Access Some Web Servers Due to the MTU Configuration...............................................371.2.15 The RR Fails to Reflect VPN Routes....................................................................................................391.2.16 CE1 Cannot Register with CE2 Because the Maximum Number of Routes Exceed the Upper Threshold..........................................................................................................................................................................411.2.17 Users Attached to a CE Cannot Access the Internet After BGP/MPLS IP VPN Services Are Deployed..........................................................................................................................................................................431.2.18 VPNv4 Routes on a PE Cannot Take Effect.........................................................................................451.2.19 MPLS VPN Convergence Is Slow.........................................................................................................471.2.20 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity CommandIs Not Configured.............................................................................................................................................48

HUAWEI NetEngine80E/40E RouterTroubleshooting - VPN Contents


v

1.2.21 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Nota 32-bit Mask....................................................................................................................................................501.2.22 Some MPLS VPN Services on a Device Become Abnormal After the Service Cutover......................52

2 VPLS Troubleshooting...............................................................................................................562.1 VSI of Martini VPLS Cannot Go Up...............................................................................................................57

2.1.1 Common Causes......................................................................................................................................572.1.2 Troubleshooting Flowchart......................................................................................................................572.1.3 Troubleshooting Procedure......................................................................................................................592.1.4 Relevant Alarms and Logs......................................................................................................................61

2.2 VSI of Kompella VPLS Cannot Go Up............................................................................................................622.2.1 Common Causes......................................................................................................................................622.2.2 Troubleshooting Flowchart......................................................................................................................622.2.3 Troubleshooting Procedure......................................................................................................................642.2.4 Relevant Alarms and Logs......................................................................................................................66

2.3 VSI Goes Up Only on One End........................................................................................................................662.3.1 Common Causes......................................................................................................................................662.3.2 Troubleshooting Flowchart......................................................................................................................662.3.3 Troubleshooting Procedure......................................................................................................................672.3.4 Relevant Alarms and Logs......................................................................................................................68

2.4 A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella VPLS Network................................................................................................................................................................................68


2.5 Related Troubleshooting Cases........................................................................................................................722.5.1 VPLS Services Fail..................................................................................................................................722.5.2 VSIs Cannot Be Up in LDP Signaling Mode..........................................................................................742.5.3 Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are Up..........................762.5.4 VSIs Cannot Be Up in BGP Signaling Mode..........................................................................................772.5.5 PEs Cannot Interwork Though VSIs Are Up..........................................................................................79

3 VLL Troubleshooting.................................................................................................................813.1 The VC of Martini VLL Cannot Be Up...........................................................................................................82


3.2 The VC of Kompella VLL Cannot Be Up........................................................................................................873.2.1 Common Causes......................................................................................................................................873.2.2 Troubleshooting Flowchart......................................................................................................................873.2.3 Troubleshooting Procedure......................................................................................................................893.2.4 Relevant Alarms and Logs......................................................................................................................92



vi

3.3 A PW of Kompella VLL Cannot Be Up When the AC Interfaces at Both Ends of the PW Are Ethernet Sub-Interfaces and Adopt the tagged Encapsulation Type............................................................................................92

3.3.1 Common Causes......................................................................................................................................923.3.2 Troubleshooting Procedure......................................................................................................................923.3.3 Relevant Alarms and Logs......................................................................................................................93

3.4 The VC Cannot Be Up When a Huawei Device Communicates with a Non-Huawei Device Through KompellaVLL........................................................................................................................................................................93

3.4.1 Common Causes......................................................................................................................................933.4.2 Troubleshooting Procedure......................................................................................................................943.4.3 Relevant Alarms and Logs......................................................................................................................94

3.5 Related Troubleshooting Cases........................................................................................................................943.5.1 VC Under the Interface Is Missing After the Link Layer Protocol Changes..........................................953.5.2 Both the Session and the AC Are Up, But the VC Cannot Be Up..........................................................973.5.3 Ethernet and ATM are interconnected and the VC Is Up, But the Ping Between CEs Fails................1013.5.4 CEs Cannot Communicate by Using the Accessing Mode of VLAN...................................................1033.5.5 CEs Cannot Access Each Other Though the Static VC Is Up...............................................................1033.5.6 Large Packets Are Lost in the Transmission Between CEs at Both Ends of L2VPN...........................1053.5.7 Failed to Establish the MPLS LDP Session Between PEs When Using RIP-1 in the L2VPN BackboneNetwork..........................................................................................................................................................105

4 PWE3 Troubleshooting.............................................................................................................1084.1 The PW Cannot Be Up...................................................................................................................................109

4.1.1 Common Causes....................................................................................................................................1094.1.2 Troubleshooting Flowchart....................................................................................................................1094.1.3 Troubleshooting Procedure....................................................................................................................1114.1.4 Relevant Alarms and Logs....................................................................................................................114

4.2 Related Troubleshooting Cases......................................................................................................................1144.2.1 PW Attributes Cannot Be Changed by Using the reset pw Command.................................................1144.2.2 VPN Services Between Two PEs Are Unavailable...............................................................................1174.2.3 Failed to Establish OSPF Neighborhood Between CEs........................................................................119

5 L2VPN IP RAN Troubleshooting...........................................................................................1215.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS+ L3VPN/IP..........................................................................................................................................................122


5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/Secondary PWSwitchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN)..............................................125




vii

5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS + L3VPN..............................................................................................................................................................................129


5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy + APS 1:1 Mode withTDM/ATM Base Stations.....................................................................................................................................132


5.5 Trouble Cases.................................................................................................................................................1345.5.1 Too Many Packets Are Lost Because ignore-standby-state Is Not Configured in the peer Command........................................................................................................................................................................1345.5.2 Traffic Is Interrupted After Primary/Secondary PW Switchover on a BTB IP RAN - PWE3 + (VSI + IP)........................................................................................................................................................................135



viii

1 L3VPN TroubleshootingAbout This Chapter

This chapter describes common causes of L3VPN faults and provides the correspondingtroubleshooting flowcharts, troubleshooting procedures, alarms, and logs.1.1 BGP Private Network Traffic Is Interrupted1.2 Related Troubleshooting Cases

HUAWEI NetEngine80E/40E RouterTroubleshooting - VPN 1 L3VPN Troubleshooting


1

1.1 BGP Private Network Traffic Is Interrupted1.1.1 Common Causes

This troubleshooting case describes how to clear the fault that BGP private network routes isinterrupted when the BGP peer relationship is normal.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 FlowchartBGP private network traffic is interrupted after the BGP protocol is configured.Figure 1-1 shows the troubleshooting flowchart.



2

Figure 1-1 Troubleshooting flowchart for interruption of BGP private network traffic

The BGP private network traffic is interrupted

Ensure that the tunnel exists

No

No

Yes

Yes

Yes

Yes

No

No

Yes

YesNo

Correctly configure the routing policy

NoYes

No Yes

Yes

Ensure that they match

No

Yes

No Yes

Seek technical support

Reduce the number of routes or increase the upper limit of routes

Reduce the number of routes or configure the device to assign a label

to each instance

Yes

No

No

Ensure that the next hop is reachable

End

Is the next hop of the VPN route reachable?

Is the routing policy is configured correctly?

Does the Number of labels exceed the

upper limit?

Is the tunnel iterated successfully?

Does the export RT match the import RT?

Does the number of routes exceed the upper

limit?

Is fault rectified?

Is fault rectified?

Is fault rectified?

Is fault rectified?

Is fault rectified?

No

Is fault rectified?

1.1.3 Troubleshooting ProcedureNOTE

Saving the results of each troubleshooting step is recommended. If your troubleshooting fails to correctthe fault, you will have a record of your actions to provide Huawei technical support personnel.



3

ProcedureStep 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 checkwhether 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 thatthis route is active and selected. The original next hop and iterated next hop of this route are3.3.3.3 and 20.1.1.2 respectively. 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 theIP routing table. If there is no route to the original next hop, it indicates that the BGP routeis not advertised because its next hop is unreachable. Then, find out why there is no routeto the original next hop (this fault is generally associated with IGP or static routes).

l If the target route is active but not selected, check whether there is a route with a higherprotocol preference in the IP routing table. If there is a route with a higher protocolpreference, consider whether or not to import it into BGP or adjust its protocol preference.If there is no route with a higher protocol preference, contact Huawei technical supportpersonnel.

NOTE

In the BGP routing table, multiple routes may have the same prefix. But only one of these routes canbe selected, and only the selected route is added to the IP routing table and sent to the peer. Whenan optimal route needs to be selected from among BGP routes and other protocol routes, the routewith the highest protocol preference is selected.

l If the target route is active and selected but there is no information indicating that this routeis sent to the remote PE, perform Step 2 to check the outbound policy applied to the localPE.

Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on theremote PE to check whether it has received the target route.l 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.l If the remote PE has not received the target route, perform Step 2 to check the inbound

policy of the remote PE.



4

Step 2 Check that routing policies are configured correctly.Run the display current-configuration configuration bgp command on the local PE andremote 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 familyin this troubleshooting case because the private network traffic is interrupted.

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 # 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#returnl 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 detailedconfigurations of a routing policy, see the HUAWEI NetEngine80E/40E ConfigurationGuide - 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 onthe 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 Out-Interface fieldand Relay token field in the command output are not empty, it indicates that this route can beiterated to a tunnel. dis bgp vpnv4 all routing-table 50.1.1.2BGP 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)



5

Route Duration: 00h00m08s Relay IP Nexthop: 20.1.1.1 Relay IP Out-Interface: Pos1/0/0 Relay Tunnel Out-Interface: Pos1/0/0 Relay token: 0x1002 Original nexthop: 1.1.1.1 Qos information : 0x0 Ext-Community:RT 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 Out-Interface: Pos1/0/0 Relay token: 0x1002 Original nexthop: 1.1.1.1 Qos information : 0x0 Ext-Community:RT AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal, best, select, active, pre 255 Not advertised to any peer yetl If the target route fails to be iterated to a tunnel, run the display ip vpn-instance

verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field isnot displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy isconfigured for the VPN instance. If the VPN instance selects an MPLS-TE tunnel, a tunnelpolicy must be configured. The value of the Tunnel Policy Name field indicates the tunnelpolicy of the VPN instance. You can view details of the tunnel policy by running the displaythis command in the corresponding tunnel policy view.[HUAWEI-tunnel-policy-p1] display this#tunnel-policy p1 tunnel select-seq cr-lsp load-balance-number 1#

NOTEIf the tunnel binding destination dest-ip-address te { tunnel interface-number } command isconfigured in the tunnel policy view, you also need to configure the mpls te reserved-for-bindingcommand in the tunnel interface view.

If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down orTE Tunnel Is Down to locate the fault and ensure that the tunnel goes Up.

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 PEand remote PE to check whether routes fail to be added to the VPN routing table of the remotePE after being sent to the remote PE because the export RT of the local VPN instance does notmatch the import RT of the remote VPN instance.export-extcommunity indicates an export RT, and import-extcommunity indicates an import RT. 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



6

ip vpn-instance vpnb route-distinguisher 1:2 vpn-target 1:1 export-extcommunity vpn-target 1:1 import-extcommunity#returnl 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.

Check whether MPLS is enabled on the local PE. Then, run the display bgp vpnv4 all routing-table ipv4-address [ mask | mask-length ] command to check whether the target route is assigneda VPN label.If there is no Label information field in the command output, it indicates that labels may beinsufficient. As a result, the target route is not assigned a label and is not advertised to the peer. 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 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 yetl 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. Youcan 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.

If the peer is added to the peer group, run the display current-configuration configurationbgp | include peer destination-address command or the display current-configurationconfiguration bgp | include peer group-name command on the remote PE to check whetherthe upper limit on the number of routes to be received is configured on the remote PE.



7

For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recordedafter the remote PE receives five routes from the local PE at 1.1.1.1. 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 thecommand output. 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, you need to run the display current-configuration configuration bgp | includepeer group-name command to check configurations of this peer group. display current-configuration configuration bgp | include peer IBGP peer IBGP route-limit 5 alert-only peer IBGP enable

If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, it indicatesthat the target route is dropped because the number of routes received has exceeded the upperlimit. 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 peerrelationship. Therefore, it is recommended to reduce the number of sent routes by configuring routesummarization on the local device.

Step 7 Collect the following information and contact Huawei technical support personnel.l Results of the preceding troubleshooting procedurel Configuration files, log files, and alarm files of the devices

----End

1.1.4 Relevant Alarms and Logs

Relevant AlarmsBGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed

Relevant LogsBGP/3/ROUTPRIX_EXCEED

1.2 Related Troubleshooting Cases



8

1.2.1 VPNs Configured with the Same VPN Target CannotCommunicateFault Symptom

As shown in Figure 1-2, BGP/MPLS VPN services are deployed on the network. CE1 and CE3belong to VPN-A, and CE2 belongs to VPN-B. VPN-A and VPN-B are configured with thesame 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 CE2fails to ping the IP address 4.4.4.9 in VPN-A. This indicates that the communications betweenVPN-A and VPN-B fail.

Figure 1-2 Networking diagram of BGP/MPLS VPN

PE1

P

AS: 65430VPN-A

CE3

GE1/0/0

AS: 65420VPN-B

CE2

AS: 65410VPN-A

CE1

GE1/0/0

GE1/0/0

POS3/0/0172.1.1.1/24

POS2/0/0172.2.1.1/24

AS: 100

PE2Loopback11.1.1.9/32

Loopback13.3.3.9/32

GE1/0/0

GE2/0/0

POS1/0/0172.1.1.2/24

POS3/0/0172.2.1.2/24

MPLS backbone

Loopback12.2.2.9/32

GE1/0/0

Loopback14.4.4.9/32

Fault Analysis1. 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.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 theLDP 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 thatthe VPN targets of VPN-A and VPN-B are the same.



9

4. Sequentially run the display mpls ldp lsp command on PE1, P, and PE2 to checkinformation about label allocation. You can find that public network labels and VPN labelsare 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 tothe interfaces. You can find that VPN-B and VPN-A are bound to the same IP address.[PE1] display ip interface brief......Interface IP Address/Mask Physical Protocol......Gigabitethernet1/0/0 10.1.1.2/30 up upGigabitethernet2/0/0 10.1.1.2/30 up up......

In the process of route cross on the PEs, VPN-B only selects the local direct route insteadof the BGP route destined for VPN-A. In addition, no prompt will be displayed when youbind VPNs to the same IP address. After the binding, the VPNs fail to communicate witheach other.

ProcedureStep 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

SummaryA PE can learn routes of different VPNs from the local CE. If the next hop of a route with thistype is reachable or can be iterated, the PE matches the route with the Import VPN target ofanother VPN instance. If the match operation succeeds, the PE adds the route to the routing tableof 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 theVPN targets of these VPNs are matched, the VPN cannot communicate with each other. Torectify the fault, ensure that the VPNs are bound to different IP addresses.



10

1.2.2 Ping Between the PEs on a VPN FailsFault Symptom

On the BGP/MPLS VPN network shown in Figure 1-3, VPN routes fail to be exchanged betweenPE1 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 areassigned public IP addresses, 1.1.1.1/32 and 1.1.1.2/32, respectively. Loopback 2 interfaces onthe 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

PE1 PE2P1

Loopback 1 Loopback 1


Fault Analysis1. 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 havesuch routes.

2. Run the display mpls ldp peer command on P1, and you can find that P1 establishes theLDP sessions, with PeerID being 1.1.1.1 and 1.1.1.2. Run the display mpls lsp commandon 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 PE1 or PE2 to check BGP peer relationships. Youcan find that PE1 or PE2 establishes IBGP peer relationships with 1.1.1.2 or 1.1.1.1, asindicated by Established in the command output.

4. Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peerrelationships. You can find that PE1 or PE2 establishes VPNv4 peer relationships with1.1.1.2 or 1.1.1.1, indicating that VPN routes can be properly advertised.

5. After the preceding steps, run the display ip routing-table vpn-instance command on PE1and PE2 to check the routes in the VRF, and you can find only one route destined for eachother's loopback2 interfaces, that is, 10.1.1.0/24 Direct with a 24-bit mask instead of a 32-bit mask.This indicates that both loopback2 interfaces are on the same network segment, which isobviously incorrect. In fact, both PEs have received the VPN routes (BGP routes) destinedfor each other's loopback2 interfaces. The received VPN routes, however, are on the samenetwork segment as that of the route 10.1.1.0/24 Direct. In this case, both PEs considerthat the received VPN routes are the same as 10.1.1.0/24 Direct, and therefore import only10.1.1.0/24 Direct to their VPN routing tables because the direct route has a higherpreference than the BGP route. As a result, both VPN routing tables do not contain the BGProutes, and the PEs cannot ping each other successfully.



11

ProcedureStep 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

SummaryIf two routes of different protocols are destined for the same network segment, the device onlyadds the one with a higher preference to the routing table.

1.2.3 Communications Between the VPN and the Public NetworkFail on a DeviceFault Symptom

As shown in Figure 1-4, the network is divided into two areas, Area-A and Area-B. Each areahas two PEs, which are configured with VRRP for the application system and Internet services,as shown by the dotted blue line.After the function of the communications between the VPN and the public network is enabledon PEs in each area, you can find that the communications fail in Area-B but succeed in Area-A. Service models of the two areas are the same; the only difference is that two switches areplaced in Area-A to transparently transmit Layer 2 services between the PEs and the server.

NOTE

The servers in Area-A and Area-B respectively have two interfaces. One functions as the master and theother the backup. The backup interface is in the inactive state and does not respond to any protocol packet.



12

Figure 1-4 Networking diagram of communications failure between the VPN and the publicnetwork on a device

Inte rnetInte rnetInte rnetInte rnet

Trunk

WAN

Area-A

Area-B

A-PE2A-PE1

B-PE1 B-PE2

Inte rnetInte rnetInte rnetInte rnet

Server10.1.1.1/27

VRRP for server

VRRP for Internet

VRRP for Internet

Trunk Trunk

Server10.1.4.1/27

Trunk(slot 2)

Trunk(slot 2)

VRRP for server

VLAN10 VLAN10

GE1/0/1VLANIF10

GE1/0/1VLANIF10

GE1/0/2

VLANIF20

GE1/0/2VLANIF20

VLAN20

GE1/0/1VLANIF11

GE1/0/1VLANIF11GE1/0/2VLANIF21 G

E1/0/2

VLANIF

21

GE1/0/110.1.2.1/27

VLAN21GE1/0/110.1.5.1/27

10.1.3.1/27

10.1.6.1/27



13

NOTE

All IP addresses are configured as 10.X.X.X in the two areas. IP addresses bound to the VPN are consideredas IP addresses of the VPN.

Fault AnalysisCommunications between the VPN and the public network can be easily implemented. You cananalyze the fault in the following steps.1. Run the display current-configuration command to check configurations of the PEs. You

can find that the PEs are correctly configured.Details are shown in Table 1-1.

Table 1-1 Key configurations of the PEsA-PE1 A-PE2 B-PE1 B-PE2

Routeconfiguration

# ip route-static 10.1.1.0 255.255.255.224 Vlanif10 10.1.1.10 ip route-static vpn-instance Media 10.1.3.0 255.255.255.224 10.1.2.1 public#

# ip route-static 10.1.1.0 255.255.255.224 Vlanif10 10.1.1.1 ip route-static vpn-instance Media 10.1.3.0 255.255.255.224 10.1.2.1 public#

# ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.11.4.10 ip route-static vpn-instance Media 10.1.6.0 255.255.255.224 10.1.5.1 public#

# ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.11.4.10 ip route-static vpn-instance Media 10.1.6.0 255.255.255.224 10.1.5.1 public#

VLANIF10

#interface Vlanif10 ip binding vpn-instance Media ip address 10.1.1.2 255.255.255.224 vrrp vrid 10 virtual-ip 10.1.1.10 vrrp vrid 10 priority 120#

#interface Vlanif10 ip binding vpn-instance Media ip address 10.1.1.3 255.255.255.224 vrrp vrid 10 virtual-ip 10.1.1.10#

- -

VLANIF20

#interface Vlanif20 ip address 10.1.2.2 255.255.255.224 vrrp vrid 20 virtual-ip 10.1.2.10 vrrp vrid 20 priority 120#

#interface Vlanif20 ip address 10.1.2.3 255.255.255.224 vrrp vrid 20 virtual-ip 10.1.2.10#

- -



14

A-PE1 A-PE2 B-PE1 B-PE2VLANIF11

- - #interface Vlanif11 ip binding vpn-instance Media ip address 10.1.4.2 255.255.255.224 vrrp vrid 11 virtual-ip 10.1.4.10 vrrp vrid 11 priority 120#

#interface Vlanif11 ip binding vpn-instance Media ip address 10.1.4.3 255.255.255.224 vrrp vrid 11 virtual-ip 10.1.4.10#

VLANIF21

- - #interface Vlanif21 ip address 10.1.5.2 255.255.255.224 vrrp vrid 21 virtual-ip 10.1.5.10 vrrp vrid 21 priority 120#

#interface Vlanif21 ip address 10.1.5.3 255.255.255.224 vrrp vrid 21 virtual-ip 10.1.5.10#

You can find that configurations of Area-A and Area-B are similar. Because devices inArea-A function normally, you can conclude that the configuration principle for Area-B iscorrect.

2. Run the display ip routing-table command on B-PE2 to check the route destined for10.1.4.1. You can find that the route is a network segment route, with the outgoing interfaceas VLANIF11, and B-PE2 selects a member interface of VLAN 11, that is, GE 1/0/1, asthe actual outgoing interface.

3. Run the display arp slot 1 command to check ARP entries of GE 1/0/1. You can find thatthere is no ARP entry for 10.1.4.1.

4. Run the display arp slot 2 command to check ARP entries of the interface board in slot 2.You can find that the outgoing interface of the ARP entry for 10.1.4.1 is an Eth-Trunk (theEth-Trunk connects B-PE1 and B-PE2 and transmits VRRP protocol packets). After thepreceding steps, you can conclude that the missing of the ARP entry leads to the failure ofthe communications between the VPN and the public network (to be specific, from thepublic network to the VPN).

5. The cause for the missing of the ARP entry on the interface board in slot 1 is shown asfollows:(1) The static route of B-PE2 is a network segment route, with the outgoing interface

being VLANIF11. As a result, the specific host route cannot be obtained in the publicnetwork.

(2) When a device in the public network needs to access 10.1.4.1, B-PE2 finds that theoutgoing interface is VLANIF11. Because the static route (ip route-static 10.1.4.0255.255.255.224 vpn-instance Media 10.1.4.10) is configured, B-PE2 randomly



15

selects a member interface of VLANIF11 as the outgoing interface (in thistroubleshooting case, the selected member interface is GE1/0/1), and sends ARPrequests and learns corresponding ARP entries through the member interface.

(3) The server 10.1.4.1 has two interfaces (master and backup). The master interface isin the Active state and connects to B-PE1, and the backup interface is in the Inactivestate and connects to B-PE2. The backup interface does not process any protocolpacket. Therefore, after the server 10.1.4.1 receives an ARP request from B-PE2through the backup interface, the application system does not response to this ARPrequest. In this case, although the interface of B-PE2, that is, GE 1/0/1, is directlyconnected to 10.1.4.1, it cannot receive the ARP response from 10.1.4.1, andconsequently no corresponding ARP entry can be generated on GE 1/0/1. Since theARP entry is missing, communications from the public network to the VPN fail.

(4) The ARP response of the server 10.1.4.1 can only be sent to GE 1/0/1 of B-PE1 throughthe master interface. The master interface is added to VLAN 11, and the Eth-Trunkof B-PE1 is also added to VLAN 11; therefore, the ARP response is sent to B-PE2through the Eth-Trunk. As a result, when checking the ARP entries of the interfaceboard in slot 2 on B-PE2, you can find that the outgoing interface of the ARP entryfor 10.1.4.1 is the Eth-trunk, as shown in Figure 1-5.



16

Figure 1-5 Networking diagram of ARP request and response

InternetInternetInternetInternet

Trunk

WAN

Area-A

Area-B

A-PE2A-PE1

B-PE1 B-PE2

InternetInternetInternetInternet

Server10.1.1.1/27

Trunk Trunk

Server10.1.4.1/27

Trunk(slot 2) VLAN 11

Trunk(slot 2)

VLAN10 VLAN10

GE1/0/1VLANIF10

GE1/0/1VLANIF10

GE1/0/2

VLANIF20

GE1/0/2VLANIF20

VLAN20

GE1/0/1VLANIF11

GE1/0/1VLANIF11GE1/0/2VLANIF21

GE1/0/2

VLANIF21

GE1/0/110.1.2.1/27

VLAN21GE1/0/110.1.5.1/27

10.1.3.1/27

10.1.6.1/27

Active Inactive

Active Inactive

ARP request

ARP reply



17

The cause for the successful communications between the VPN and the public networkin Area-A is that switches are placed in Area-A to transparently transmit Layer 2services, as shown in Figure 1-5.

Usually, after learning an ARP entry, a VLANIF interface generates a 32-bit host route forselecting the outgoing interface. If a PE is configured with a static route, the VLANIF interfacehas to randomly selects an outgoing interface, and cannot correctly generate a 32-bit host route.To sum up, in this troubleshooting case, after a static network segment route is configured onB-PE2, B-PE2 randomly selects a member interface of the outgoing interface (VLANIF11) toforward packets. If the member interface is incorrectly selected, the communications betweenthe VPN and the public network fail. In the troubleshooting case, the ARP entry learning processis normal; therefore, the fault is caused by the configuration of the static network segment route.

ProcedureStep 1 Run the system-view command on B-PE2 to enter the system view.Step 2 Run the undo ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.1.4.10

command on B-PE2 to delete the static route for communications between the VPN and thepublic network.

Step 3 Run the ip route-static 10.1.4.1 255.255.255.255 vpn-instance Media 10.1.4.1 command onB-PE2 to reconfigure the static route for communications between the VPN and the publicnetwork.After the preceding configuration, you can find that communications between the VPN and thepublic network are implemented. The fault is thus rectified.

----End

SummaryWhen configuring the function of communications between the VPN and the public network,you can only configure a 32-bit host route if a VLANIF interface functions as the outgoinginterface, instead of a network segment route. Otherwise, a member interface of the VLANIFinterface is randomly selected as the outgoing interface, and the preceding fault occurs.

1.2.4 VPN Services Are Interrupted Because the Link Between anABR and a BAS Fails in a Full-meshed NSSAFault Symptom

As shown in Figure 1-6, ABR1, ABR2, BAS1, and BAS2 form a full-meshed network. Allrouters run OSPF, and the AS is divided into two areas, area 0 and area 1. Area 0 functions asthe backbone area, consisting of ABR1 and ABR2. Area 1 is configured as an NSSA, consistingof two ABRs and two BASs.All links are configured with MPLS LDP to transmit MPLS L3VPN services. Considering thelimited capability of the BASs, an upper limit on LSPs is set on the BASs and the BASs areconfigured not to function as transit nodes.When the link between ABR1 and BAS1 fails, VPN services between them are interrupted.



18

Figure 1-6 Networking diagram of the OSPF NSSALoopback01.1.1.1/32

Loopback02.2.2.2/32

Area1NSSA

ABR1 ABR2

BAS1 BAS2

Area0

Loopback03.3.3.3/32

Loopback04.4.4.4/32

Fault Analysis1. Run the display ospf routing command on ABR1 to check OSPF routing information. You

can find that Loopback0 of ABR1 is added to area 0. The rule for selecting OSPF routesdefines that intra-area OSPF routes are preferentially selected. Therefore, the IGP path fromABR1 to BAS1 is ABR1 -> BAS2 -> ABR2 -> BAS1.

2. Run the display mpls ldp lsp command on BAS2 to check information about labelallocation. You can find that the incoming/outgoing label (In/OutLabel) of the LSP isNULL/**, indicating that BAS2 does not allocate a label to the previous hop ABR1. Thisis because BAS2 does not function as a transit node to allocate a label to Loopback0 ofABR1. BAS2 cannot receive the public network label from ABR1 and therefore VPNservices are interrupted.

ProcedureStep 1 Run the system-view command to enter the system view.

Create separate sub-interfaces on ABR1 and ABR2, assign IP addresses to the two sub-interfaces, and add the sub-interfaces to area 1 (an NSSA).

Step 2 Run the interface interface-type interface-number.subinterface-number command to create asub-interface.

Step 3 Run the ip address command to assign an IP address to the sub-interface.Step 4 Run the quit command to return to the system view.Step 5 Run the ospf process-id command to enter the OSPF view.Step 6 Run the area area-id command to enter the view of OSPF area 1.Step 7 Run the network ip-address wildcard-mask command to add the sub-interfaces to area 1.Step 8 Run the nssa command to configure area 1 as an NSSA.



19

After the preceding configurations, ABR1 can ping BAS1 successfully. The fault is cleared.----End

SummaryLoopback interfaces should be added to the correct area.

1.2.5 A Routing Loop Occurs After a Sham Link Is EstablishedBetween PEsFault Symptom

As shown in Figure 1-7, OSPF runs on the network, and CE1 and CE2 respectively access PE1and PE2. A sham link is established between PE3 and PE4 to transmit LSAs.PE1 and PE2 arenot connected through Layer 3 interfaces. On CEs, GE1/0/0 is configured to belong to area 0,and GE2/0/0 is configured to belong to area 1. The cost of the link between CE2 and PE2 is setlarger, ensuring that the traffic is preferentially transmitted through the link between CE1 andPE1. Other links adopt the default cost value. VRRP runs on GE2/0/0 of CE2, with CE1 as theVRRP gateway.In the preceding networking, it is found that devices on the network segment 10.1.1.0/24 canaccess PE3 and PE1, but cannot access PE4 and PE2, and devices on the office network canaccess PE4, PE2, PE3, and PE1.

Figure 1-7 Networking diagram of the OSPF sham link

PE3 PE4

PE2

GE2/0/020.1.2.1/30Cost 1GE1/0/0

20.1.2.9/30Cost 1

GE2/0/020.1.2.6/24

Cost 1

GE2/0/0172.17.1.1/24

PE1

GE1/0/020.1.2.5/30

Cost 10

Area1

GE2/0/0172.16.1.1/24GE1/0/0

20.1.2.13/30Cost 10

GE1/0/010.1.2.17/30Cost 20

CE1 CE2

Cost 1

sham link

GE2/0/010.1.1.2/24Cost 20

GE2/0/010.1.1.1/24Cost 10

ExitNetwork

Office

ExitNetwork

Office

Fault AnalysisThe possible causes are as follows:



20

l A firewall exists on the network and packets are filtered by the firewall.l A link fault occurs on the network.l The routing planning is improper.l A device fails.Sequentially check whether the preceding faults exist, and you can find the following:1. No firewall exists on the network.2. The ping operation succeeds on all direct links of the network, indicating that these links

are in the normal state.3. Run the tracert [ -a source-ip-address ] host command to determine the gateways through

which the packets sent from a device on the network segment 10.1.1.0/24 to CE2. You canfind that a loop is formed between PE2 and PE4. Theoretically, OSPF is a loop-freeprotocol. Why does the loop occur?

4. Run the display ip routing-table command to view routing information about PE2. Youcan find that the next hop of the route destined for the network segment 10.1.1.0/24 is PE4,and the cost is 32. In addition, you can find that the cost of the link between PE2 and CE2is 20. In this case, why does PE2 preferentially select the route with CE2 as the next hop?

5. Run the ping [ -a source-ip-address ] host command to check the connectivity betweenPE2 and CE2, and you can find that the ping operation succeeds and the link is normal.Run the display ospf peer command to check information about the OSPF peerrelationships in each OSPF area. You can find that all OSPF peer relationships (includingthe OSPF peer relationship between PE2 and CE2) are in the full state.

6. Run the display ospf lsdb command to check the OSPF LSDB on PE2, and you can findthat the LSDB contains the LSAs that are advertised by CE1 and CE2 and destined for10.1.1.0/24. The LSA advertised by CE2 has the metric of 20; the metric value, however,only indicates the cost of CE2 to reach 10.1.1.0/24, instead of the cost of PE2 to reach10.1.1.0/24. After being added with the cost value between CE2 and PE2, that is, 20, thecost of PE2 to reach 10.1.1.0/24 is 40 (20+20), which is larger than the cost of the path PE2-> PE4 -> PE3 -> PE1 -> CE1, that is, 32 (10+1+1+10+10).Similarly, you can find that the cost of the path PE4 -> PE3 -> PE1 -> CE1, that is, 22, issmaller than the cost of the path PE4 -> PE2 -> CE2, that is 41. In this case, PE4 must selectPE3, instead of CE2, as the next hop.

7. Run the display ospf lsdb command to check the OSPF LSDB on PE4. You can find theLSA that is advertised by CE1 and destined for 10.1.1.0/24. Nevertheless, run the displayip routing-table 10.1.1.0 24 verbose command on PE4, and you can find two routesdestined for 10.1.1.0/24. One is an OSPF route in the active state, with the next hop beingPE2, and the other is a BGP route in the inactive state, with the next hop being PE2.The cause for the route PE4 -> PE3 -> PE1 -> CE1 not being selected is that the sham linkis established between PE3 and PE4, and the route learnt from the sham link is consideredas a BGP route. The preference of BGP routes is 255, whereas the preference of OSPFroutes is 10. Therefore, PE4 preferentially selects the route learnt from PE2.To sum up, the sham link is handled specially on PEs, and the type of the route learnt fromthe sham link is BGP, leading to the routing loop between PE2 and PE4 on the network.

Procedurel Solution 1:

1. Run the system-view command to enter the system view.



21

2. Run the bgp command to enter the BGP view.3. Run the ipv4-family unicast command to enter the IPv4 unicast address family view.4. Run the preference { external internal local | route-policy route-policy-name }

command to modify the BGP preference on PE4, enabling PE4 to preferentially selectthe route learnt from the sham link.

NOTE

This solution eliminates the existing loop, but cannot prevent loops if the networking is changed.l Solution 2:

1. Run the system-view command to enter the system view.2. Run the ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name

command to enter the OSPF view.3. Run the area area-id command to enter the OSPF area view.4. Run the sham-link source-ip-address destination-ip-address [ smart-discover ]

[ simple [ [ plain ] plain-text | cipher cipher-text ] | { md5 | hmac-md5 } [ key-id{ plain plain-text | [ cipher ] cipher-text } ] | authentication-null ] [ cost cost ]command to modify the cost of the sham link on PE4, disabling PE2 frompreferentially learning the route from PE4 and thus eliminating the loop.

NOTE

Similar to solution 1, solution 2 cannot prevent loops if the networking is changed.l Solution 3:

1. This solution is to add a VPN route between PE3 and PE4, which fundamentallyprevents loops.

NOTE

This solution actually takes PEs as MCEs and does not use MPLS VPN, which is inconvenient forMPLS domain expansion.

l Solution 4:This solution is to optimize the existing OAM network. The specific measure is to set upa Layer 3 link between PE1 and PE2 and add this link to area 0. This solution can not onlysolve the current problem, but also prevent the traffic on the network (such as the trafficbetween CE1 and PE2) from being transmitted between the PEs. Details are as follows:1. Run the system-view command to enter the system view.2. Run the ospf process-id command to enter the OSPF view.3. Run the area 0 command to enter the view of OSPF area 0.4. Run the network ip-address wildcard-mask command to add the Layer 3 link to area

0.l

NOTE

You can adopt the second solution at the beginning because this solution causes less network change.Later, you can adopt the fourth solution to completely solve the problem.You can change the cost of the sham link to 100 on PE3 and PE4, and on PE2, change the next hop of theroute destined for 10.1.1.0/24 to 10.1.2.17/30. After the preceding change, devices on the network segment10.1.1.0/24 can access CE2, PE2, and PE4. Devices on other network segments can also access CE2, PE2,and PE4.

----End



22

SummaryIt is recommended that the sham link be avoided in network planning to prevent routing loops.

1.2.6 VPN Routes Are Incorrectly Learnt in an Inter-AS VPN OptionB Setup Because the Mask of the Loopback Address on anIntermediate Router Is IncorrectFault Symptom

As shown in Figure 1-8. The Inter-AS VPN Option B is Setup, and the EBGP peer relationshipis established between PE2 and CE2. It is found that CE2 can learn the route to 2.2.2.5 fromCE1, but CE1 cannot learn the route to 1.1.1.5 from CE2.

Figure 1-8 Networking diagram of inter-AS VPN Option B mode

ASBR2

AS 200

ASBR1

AS 100

Loopback01.1.1.1/32

Loopback01.1.1.2/32

Loopback01.1.1.3/32

Loopback01.1.1.4/32

AS 300Loopback01.1.1.5/32

PE1 PE2

CE2

AS 300Loopback02.2.2.5/32

CE1

Fault AnalysisNOTE

In normal situations, routes are learnt in a bidirectional manner. With inter-AS VPN Option B, VPN routesare saved on intermediate ASBRs. To locate the fault, you need to check BGP VPNv4 routes on devicesalong 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. Youcan find that all the devices have this route, but PE1 does not take this route as an optimalroute.



23

2. Run the display current-configuration command on ASBR1. You can find that the IPaddress of Loopback0 on ASBR1 is configured as 1.1.1.2 255.255.255.252. LDP labels areallocated only to host routes with a 32-bit mask by default. Loopback0 on ASBR1 has anIP address with a 30-bit mask and therefore it is not assigned an LDP label and thecorresponding LSPs cannot be established. When PE1 learns a VPNv4 route, it checkswhether the corresponding LSP is valid. If the LSP is not fully established because ofincomplete label allocation, the VPNv4 route cannot be added to the VPN routing table.

ProcedureStep 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.NOTEChange the mask length of the loopback address to 32 bits.

Step 4 Run the reset mpls ldp vpn-instance vpn-instance-name command to reset vpna. In this manner,all interfaces, peers, sessions, LSPs, and CR-LSPs of vpna are deleted and re-created.After the preceding configurations, run the display ip routing-table vpn-instance vpn-instance-name 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. Youcan find the ping operation succeeds. The fault is cleared.----End

SummaryWhen LDP is used to establish LSPs, LDP labels are allocated only to the host routes with a 32-bit mask by default. If the corresponding route is not a host route, the LDP labels cannot becorrectly allocates and the LSP cannot be established.

1.2.7 PEs Cannot Learn Routes After the policy vpn-targetCommand Is Configured on an RRFault Symptom

As shown in Figure 1-9, the same VPN instance, vpna, is configured on PE1, PE2, PE3, andPE4. To improve network reliability, double RRs are selected from Ps in the same AS for theVPN instance. In this manner, the two RRs back up each other and respectively reflect publicnetwork routes and VPNv4 routes. After the configurations, PE1 and PE2 cannot learn routesfrom PE3 and PE4, and PE3 and PE4 cannot learn routes from PE1 and PE2.



24

Figure 1-9 Networking diagram of the VPN with double RRsRR1

PE1 PE2

RR2

PE3 PE4

Fault Analysis1. 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 isconfigured with a routing policy that restricts route reflection and reception.

2. Check whether route conflict occurs. Run the display ip routing-table vpn-instancevpna 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 current-configuration command on the RRs to view BGP configurations. You can find that oneRR is configured with the policy vpn-target command in the BGP-VPNv4 address familyview.The policy vpn-target command is used to enable the VPN-Target filtering functionfor received VPNv4 routes. Only the VPNv4 route whose Export VPN target attributematches the local Import VPN target attribute can be added to the routing table. The RR isnot configured with the VPN instance vpna; as a result, the RR does not receive the routeswith the VPN target as vpna.

Procedurel Solution 1: Disable the VPN-Target filtering function for received VPNv4 routes on the

RR.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.After the preceding configurations, run the display ip routing-table command onPE1 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. Thefault is thus rectified.

l 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.



25

3. Run the vpn-target vpn-target command to associate the VPN target with vpna.NOTE

The vpn-target must be the same as that of vpna configured on the PEs.

After the preceding configurations, run the display ip routing-table command onPE1 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. Thefault is thus rectified.

----End

SummaryThe policy vpn-target command needs to be used with caution.

1.2.8 VPN Routing Table on the PE Does Not Contain Any RouteSent from the Peer PEFault Symptom

Figure 1-10 Networking diagram of BGP/MPLS IPv6 VPN

PE1 PE2P

CE1 CE2

Loopback01.1.1.1/32

Loopback02.2.2.2/32

Loopback03.3.3.3/32

GE2/0/010:1:1::12/64

GE1/0/010:1:1::11/64

GE1/0/012.1.1.1/30

GE1/0/012.1.1.2/30

GE2/0/023.1.1.1/30

GE1/0/023.1.1.2/30

GE2/0/010:2:1::22/64GE1/0/010:2:1::21/64

The configuration in Figure 1-10 is as follows:l EBGP runs on the PEs and the CEs.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 PE2After the configuration is complete, PE1 can receive private network routes from CE1, but PE2and CE2 cannot do that.



26

Fault Analysis1. 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 peerrelationship is set up.

2. Run the display bgp vpnv6 all routing-table peer ipv4-address received-routescommand on PE2. The command output shows that PE2 has received the VPNv6 route sentfrom PE1.

3. Run the display bgp vpnv6 vpn6-instance vpn6-instance-name routing-table ipv6-address [ mask-length ] command on PE2 to view information about the tunnel to whichthe specified route is iterated.If the Relay token is 0x0, it indicates that the route to ip-address does not find the associatedtunnel. The cause is that the setup of LSP for the next hop of the route fails. display bgp vpnv6 vpn-instance vpna routing-table 66::66 128BGP 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 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). 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 notestablished successfully.

5. Check whether MPLS LDP is enabled on the interfaces between PE1 and P, and on theinterfaces 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.

ProcedureStep 1 Run the interface gigabitethernet 1/0/0 command on PE1 to enter the interface view.Step 2 Run the mpls ldp command in the interface view to enable LDP on the interface.

----End

SummaryTo transfer the traffic of private network across the public network, a public network tunnel isrequired.



27

If the setup of a public network tunnel fails, the possible reason is that MPLS LDP is not enabledon the interface, or an LDP session is not established. As a result, the PE does not choose theprivate network route sent from the peer PE as the optimal route.

1.2.9 CEs Cannot Ping Through Each OtherFault Symptom

BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 1-11. CE1 andCE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2.


PE1 PE2P1 P2

CE1 CE2


Fault AnalysisNOTE

Take the configuration of PE2 as an example. The configuration of PE1 is similar to that of PE2, and isnot mentioned here.

1. Run the display bgp vpnv6 all peer command on PE2 to check the IBGP peer relationshipbetween PE2 and PE1. You can find that the IBGP peer relationship is not set upsuccessfully.

2. Check the BGP configuration. You can find that the loopback interface is not specified asthe outbound interface of the local IBGP peer session by using the peer peer-ip-addressconnect-interface loopback interface-number command when the two PEs set up theIBGP connection.If the outbound interface is not specified for the local IBGP session, the outbound interfaceof the data stream is the outbound interface of the session by default.The IBGP peerrelationship between PEs is usually set up by using the loopback interface addresses witheach having a 32-bit mask, and the source interface through which BGP packets are sentis also set to the loopback interface.

ProcedureStep 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.



28

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.Step 6 Save the configuration.

On the local CE, ping the remote CE. If the ping succeeds, it indicates that the fault is rectified.----End

SummarySpecify the local loopback interface as the outbound interface of the local IBGP session whenconfiguring PE peers.

1.2.10 Failed to transmit Large Packets of the Private NetworkFault Symptom

When the Huawei device networks with devices from other vendors deploy Layer 3 MPLS IPv6VPN service by using the Ethernet interface, it is found that the packet larger than 1492 bytescannot be transmitted between private network users. Users cannot access certain websites ordownload files through FTP.Run the ping command, and find that the ping fails when the payload of the specified ICMP islarger than 1464 bytes.

Fault Analysis1. 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 theLayer 2 frame header. That is, a 4-byte label is added during the forwarding between thepenultimate hop and the tail-end hop; a 8-byte label is added in data forwarding betweenother P devices.

2. The link layer does not know the MPLS processing. By default, the link layer still receivesdata packets with the maximum size of 1500 bytes. Then, packets of 1492 to 1500 bytes istoo long after the MPLS packet header is added to the packets. Consequently, the link layercannot receive them, and data forwarding is adversely affected.

ProcedureStep 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

SummaryWhen large packets cannot be received, check whether the MTU of the inbound interface is toosmall.



29

1.2.11 PE Fails to Ping Through the Remote CE Network SegmentFault Symptom


Site3

vpn1

CE3

vpn1

Site2CE2

vpn1Site1

CE1

PE1P

Backbone

PE2

GE1/0/010::3:1:1/64

GE2/0/010::2:1:1/64

GE1/0/010::1:1:1/64

As shown in Figure 1-12, 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 theremote network segment where CE3 resides. Run the ping ipv6 vpn6-instance vpn110::3:1:1 command on PE1. PE1, however, cannot ping though the network segment whereCE3 resides.

Fault AnalysisMultiple private network interfaces on the ingress node (a PE) are bound to the same IPv6 VPNinstance. When the PE pings or traces the remote CE network segment, the source address ofthe ICMP packet is the lowest private network address that is Up on the local PE; if the remoteCE 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 vpn6-instance vpn6-instance-name dest-ipv6-address command, ensure that the remote CE has all the Up privatenetwork addresses of the local PE. If the source IP address is specified as a private networkaddress in the Up state on the local PE by using the ping command, and the private networkaddress is imported to the remote CE, the PE can ping through the remote CE network segment.

ProcedureStep 1 Ensure that the remote CE has all the private network addresses in the Up state that belong to

the local PE.



30

Step 2 Run the import-route direct command in BGP VPN instance view of the local PE. Ensure thatall private routes on the local PE can be advertised through MP-BGP. You can also replace theping ipv6 vpn6-instance vpn6-instance-name dest-ip-address command with the ping ipv6 -a source-ipv6-address vpn6-instance vpn6-instance-name dest-ipv6-address command.----End

SummaryWhen you ping the remote CE network segment from the local CE, it is recommended to specifythe source address of the ping packet; otherwise, the ping may fail.

1.2.12 CEs in the Inter-AS IPv6 V

Troubleshooting HUAWEI VPN

Documents

Transcript of Troubleshooting HUAWEI VPN