Troubleshooting HUAWEI VPN

HUAWEI NetEngine80E/40E Router V600R003C00

Troubleshooting - VPN Issue

02

Date

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 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 02 (2011-09-10)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

i

HUAWEI NetEngine80E/40E Router Troubleshooting - VPN

About This Document

About This Document Purpose NOTE

l This document takes interface numbers and link types of the NE40E-X8 as an example. In working situations, the actual interface numbers and link types may be different from those used in this document. l On NE80E/40E series excluding NE40E-X1 and NE40E-X2, line processing boards are called Line Processing Units (LPUs) and switching fabric boards are called Switching Fabric Units (SFUs). On the NE40E-X1 and NE40E-X2, there are no LPUs and SFUs, and NPUs implement the same functions of 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 HUAWEI NetEngine80E/40E.

Related Versions The following table lists the product versions related to this document. Product Name

Version

HUAWEI NetEngine80E/40E Router

V600R003C00

Intended Audience This document is intended for: l

System maintenance engineers

l

Commissioning engineers

l

Network monitoring engineers

Issue 02 (2011-09-10)


ii


About This Document

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

Description

DANGER

WARNING

CAUTION

Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results.

TIP

Indicates a tip that may help you solve a problem or save time.

NOTE

Provides additional information to emphasize or supplement important points of the main text.

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

Issue 02 (2011-09-10)

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.


iii


About This Document

Change History Changes between document issues are cumulative. The latest document issue contains all the changes 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.

Issue 02 (2011-09-10)


iv


Contents

Contents About This Document.....................................................................................................................ii 1 L3VPN Troubleshooting..............................................................................................................1 1.1 BGP Private Network Traffic Is Interrupted......................................................................................................2 1.1.1 Common Causes........................................................................................................................................2 1.1.2 Troubleshooting Flowchart........................................................................................................................2 1.1.3 Troubleshooting Procedure........................................................................................................................3 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......................................................9 1.2.2 Ping Between the PEs on a VPN Fails....................................................................................................11 1.2.3 Communications Between the VPN and the Public Network Fail on a Device......................................12 1.2.4 VPN Services Are Interrupted Because the Link Between an ABR and a BAS Fails in a Full-meshed NSSA................................................................................................................................................................18 1.2.5 A Routing Loop Occurs After a Sham Link Is Established Between PEs..............................................20 1.2.6 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..............................................................................23 1.2.7 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR..................24 1.2.8 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE............................26 1.2.9 CEs Cannot Ping Through Each Other....................................................................................................28 1.2.10 Failed to transmit Large Packets of the Private Network......................................................................29 1.2.11 PE Fails to Ping Through the Remote CE Network Segment...............................................................30 1.2.12 CEs in the Inter-AS IPv6 VPN Option C Fail to Communicate with Each Other................................31 1.2.13 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down ..........................................................................................................................................................................32 1.2.14 CE Cannot Access Some Web Servers Due to the MTU Configuration...............................................37 1.2.15 The RR Fails to Reflect VPN Routes....................................................................................................39 1.2.16 CE1 Cannot Register with CE2 Because the Maximum Number of Routes Exceed the Upper Threshold ..........................................................................................................................................................................41 1.2.17 Users Attached to a CE Cannot Access the Internet After BGP/MPLS IP VPN Services Are Deployed ..........................................................................................................................................................................43 1.2.18 VPNv4 Routes on a PE Cannot Take Effect.........................................................................................45 1.2.19 MPLS VPN Convergence Is Slow.........................................................................................................47 1.2.20 One-way Audio Occurs Between the CEs Because the vpn-target import-extcommunity Command Is Not Configured.............................................................................................................................................48 Issue 02 (2011-09-10)


v


Contents

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

2 VPLS Troubleshooting...............................................................................................................56 2.1 VSI of Martini VPLS Cannot Go Up...............................................................................................................57 2.1.1 Common Causes......................................................................................................................................57 2.1.2 Troubleshooting Flowchart......................................................................................................................57 2.1.3 Troubleshooting Procedure......................................................................................................................59 2.1.4 Relevant Alarms and Logs......................................................................................................................61 2.2 VSI of Kompella VPLS Cannot Go Up............................................................................................................62 2.2.1 Common Causes......................................................................................................................................62 2.2.2 Troubleshooting Flowchart......................................................................................................................62 2.2.3 Troubleshooting Procedure......................................................................................................................64 2.2.4 Relevant Alarms and Logs......................................................................................................................66 2.3 VSI Goes Up Only on One End........................................................................................................................66 2.3.1 Common Causes......................................................................................................................................66 2.3.2 Troubleshooting Flowchart......................................................................................................................66 2.3.3 Troubleshooting Procedure......................................................................................................................67 2.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.4.1 Common Causes......................................................................................................................................69 2.4.2 Troubleshooting Flowchart......................................................................................................................69 2.4.3 Troubleshooting Procedure......................................................................................................................70 2.4.4 Relevant Alarms and Logs......................................................................................................................71 2.5 Related Troubleshooting Cases........................................................................................................................72 2.5.1 VPLS Services Fail..................................................................................................................................72 2.5.2 VSIs Cannot Be Up in LDP Signaling Mode..........................................................................................74 2.5.3 Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are Up..........................76 2.5.4 VSIs Cannot Be Up in BGP Signaling Mode..........................................................................................77 2.5.5 PEs Cannot Interwork Though VSIs Are Up..........................................................................................79

3 VLL Troubleshooting.................................................................................................................81 3.1 The VC of Martini VLL Cannot Be Up...........................................................................................................82 3.1.1 Common Causes......................................................................................................................................82 3.1.2 Troubleshooting Flowchart......................................................................................................................82 3.1.3 Troubleshooting Procedure......................................................................................................................84 3.1.4 Relevant Alarms and Logs......................................................................................................................87 3.2 The VC of Kompella VLL Cannot Be Up........................................................................................................87 3.2.1 Common Causes......................................................................................................................................87 3.2.2 Troubleshooting Flowchart......................................................................................................................87 3.2.3 Troubleshooting Procedure......................................................................................................................89 3.2.4 Relevant Alarms and Logs......................................................................................................................92 Issue 02 (2011-09-10)


vi


Contents

3.3 A PW of Kompella VLL Cannot Be Up When the AC Interfaces at Both Ends of the PW Are Ethernet SubInterfaces and Adopt the tagged Encapsulation Type............................................................................................92 3.3.1 Common Causes......................................................................................................................................92 3.3.2 Troubleshooting Procedure......................................................................................................................92 3.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 Kompella VLL........................................................................................................................................................................93 3.4.1 Common Causes......................................................................................................................................93 3.4.2 Troubleshooting Procedure......................................................................................................................94 3.4.3 Relevant Alarms and Logs......................................................................................................................94 3.5 Related Troubleshooting Cases........................................................................................................................94 3.5.1 VC Under the Interface Is Missing After the Link Layer Protocol Changes..........................................95 3.5.2 Both the Session and the AC Are Up, But the VC Cannot Be Up..........................................................97 3.5.3 Ethernet and ATM are interconnected and the VC Is Up, But the Ping Between CEs Fails................101 3.5.4 CEs Cannot Communicate by Using the Accessing Mode of VLAN...................................................103 3.5.5 CEs Cannot Access Each Other Though the Static VC Is Up...............................................................103 3.5.6 Large Packets Are Lost in the Transmission Between CEs at Both Ends of L2VPN...........................105 3.5.7 Failed to Establish the MPLS LDP Session Between PEs When Using RIP-1 in the L2VPN Backbone Network..........................................................................................................................................................105

4 PWE3 Troubleshooting.............................................................................................................108 4.1 The PW Cannot Be Up...................................................................................................................................109 4.1.1 Common Causes....................................................................................................................................109 4.1.2 Troubleshooting Flowchart....................................................................................................................109 4.1.3 Troubleshooting Procedure....................................................................................................................111 4.1.4 Relevant Alarms and Logs....................................................................................................................114 4.2 Related Troubleshooting Cases......................................................................................................................114 4.2.1 PW Attributes Cannot Be Changed by Using the reset pw Command.................................................114 4.2.2 VPN Services Between Two PEs Are Unavailable...............................................................................117 4.2.3 Failed to Establish OSPF Neighborhood Between CEs........................................................................119

5 L2VPN IP RAN Troubleshooting...........................................................................................121 5.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS + L3VPN/IP..........................................................................................................................................................122 5.1.1 Common Causes....................................................................................................................................122 5.1.2 Troubleshooting Flowchart....................................................................................................................122 5.1.3 Troubleshooting Procedure....................................................................................................................123 5.1.4 Relevant Alarms and Logs....................................................................................................................124 5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/Secondary PW Switchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN)..............................................125 5.2.1 Common Causes....................................................................................................................................125 5.2.2 Troubleshooting Flowchart....................................................................................................................125 5.2.3 Troubleshooting Procedure....................................................................................................................126 5.2.4 Relevant Alarms and Logs....................................................................................................................128

Issue 02 (2011-09-10)


vii


Contents

5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS + L3VPN ..............................................................................................................................................................................129 5.3.1 Common Causes....................................................................................................................................129 5.3.2 Troubleshooting Flowchart....................................................................................................................129 5.3.3 Troubleshooting Procedure....................................................................................................................130 5.3.4 Relevant Alarms and Logs....................................................................................................................132 5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy + APS 1:1 Mode with TDM/ATM Base Stations.....................................................................................................................................132 5.4.1 Common Causes....................................................................................................................................132 5.4.2 Troubleshooting Flowchart....................................................................................................................132 5.4.3 Troubleshooting Procedure....................................................................................................................133 5.4.4 Relevant Alarms and Logs....................................................................................................................134 5.5 Trouble Cases.................................................................................................................................................134 5.5.1 Too Many Packets Are Lost Because ignore-standby-state Is Not Configured in the peer Command ........................................................................................................................................................................134 5.5.2 Traffic Is Interrupted After Primary/Secondary PW Switchover on a BTB IP RAN - PWE3 + (VSI + IP) ........................................................................................................................................................................135

Issue 02 (2011-09-10)


viii


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 BGP Private Network Traffic Is Interrupted 1.2 Related Troubleshooting Cases

Issue 02 (2011-09-10)


1



1.1 BGP Private Network Traffic Is Interrupted 1.1.1 Common Causes This troubleshooting case describes how to clear the fault that BGP private network routes is interrupted 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 Flowchart BGP private network traffic is interrupted after the BGP protocol is configured. Figure 1-1 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


2



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

Yes Is fault rectified? 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

Yes Is fault rectified? 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 Is fault rectified?

No

No Seek technical support

End

1.1.3 Troubleshooting Procedure NOTE

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 02 (2011-09-10)


3



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 active and selected. The original next hop and iterated next hop of this route are 3.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 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 active but not selected, check whether there is a route with a higher protocol preference in the IP routing table. If there is a route with a higher protocol preference, 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 support personnel. NOTE

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

l

If the target route is active and selected 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.

Run the display bgp vpnv4 all routing-table network { mask | mask-length } command on the remote 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.

Issue 02 (2011-09-10)


4



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. 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 # 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 NetEngine80E/40E 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 Out-Interface field and Relay token field in the command output are not empty, it indicates that this route can be iterated to a tunnel. dis bgp vpnv4 all routing-table 50.1.1.2 BGP local router ID : 2.2.2.2 Local AS number : 100 Total routes of Route Distinguisher(1:2): 1 BGP routing table entry information of 50.1.1.2/32: Label information (Received/Applied): 13316/NULL From: 1.1.1.1 (1.1.1.1)

Issue 02 (2011-09-10)


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 <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 Out-Interface: Pos1/0/0 Relay token: 0x1002 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, run the display ip vpn-instance verbose [ vpn-instance-name ] command to check the Tunnel Policy field. If this field is not displayed, it indicates that the VPN instance selects an LDP LSP or no tunnel policy is configured for the VPN instance. If the VPN instance selects an MPLS-TE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel policy of the VPN instance. You can view details of the tunnel policy by running the display this 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 # NOTE

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

If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or TE 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 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. 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

Issue 02 (2011-09-10)


6



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. 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. 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. If the peer is added to the peer group, run the display current-configuration configuration bgp | include peer destination-address command or the display current-configuration configuration bgp | include peer group-name command on the remote PE to check whether the upper limit on the number of routes to be received is configured on the remote PE. Issue 02 (2011-09-10)


7



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. 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. 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 | include peer 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 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 BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed

Relevant Logs BGP/3/ROUTPRIX_EXCEED

1.2 Related Troubleshooting Cases

Issue 02 (2011-09-10)


8



1.2.1 VPNs Configured with the Same VPN Target Cannot Communicate 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

POS1/0/0 PE1 172.1.1.2/24

Loopback1 1.1.1.9/32 GE2/0/0

CE3

GE1/0/0

POS2/0/0 PE2 172.2.1.1/24 POS3/0/0 172.2.1.2/24

POS3/0/0 172.1.1.1/24

Loopback1 3.3.3.9/32

P MPLSbackbone AS: 100

GE1/0/0 CE2 VPN-B AS: 65420

Fault Analysis 1.

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

Issue 02 (2011-09-10)


9



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 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. Issue 02 (2011-09-10)


10



1.2.2 Ping Between the PEs on a VPN Fails 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 sessions, 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 PE1 or PE2 to check BGP peer relationships. You can find that PE1 or PE2 establishes IBGP peer relationships with 1.1.1.2 or 1.1.1.1, as indicated by Established in the command output.

4.

Run the display bgp vpnv4 all peer command on PE1 or PE2 to check VPNv4 peer relationships. You can find that PE1 or PE2 establishes VPNv4 peer relationships with 1.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 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.

Issue 02 (2011-09-10)


11



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 Communications Between the VPN and the Public Network Fail on a Device Fault Symptom As shown in Figure 1-4, the network is divided into two areas, Area-A and Area-B. Each area has 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 enabled on PEs in each area, you can find that the communications fail in Area-B but succeed in AreaA. Service models of the two areas are the same; the only difference is that two switches are placed 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 the other the backup. The backup interface is in the inactive state and does not respond to any protocol packet.

Issue 02 (2011-09-10)


12



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

Server 10.1.1.1/27 VLAN10

VLAN10 Trunk VRRP for server

I n te rn e t

10.1.3.1/27 GE1/0/1 10.1.2.1/27 VLAN20 GE /2 0 1 0 V / 1 IF 2 LA /0 /2 E NI G AN F2 VL 0 VRRP for Internet

GE1/0/1 VLANIF10 A-PE1

Trunk

Trunk Trunk(slot 2)

GE1/0/1 VLANIF11

GE1/0/1 VLANIF10 A-PE2

Trunk(slot 2)

B-PE1

Area-A

WAN B-PE2

VRRP for server

GE1/0/1 GE VRRP for Internet VLANIF11 1 2 VL /0 / /0 / F 21 AN 2 1 I IF 2 GE AN 1 VL VLAN21 GE1/0/1 10.1.5.1/27

10.1.6.1/27

Area-B

I n te rn e t

Server 10.1.4.1/27

Issue 02 (2011-09-10)


13



NOTE

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

Fault Analysis Communications between the VPN and the public network can be easily implemented. You can analyze 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 PEs

Issue 02 (2011-09-10)

A-PE1

A-PE2

B-PE1

B-PE2

Route config uration

#

#

#

#

ip routestatic 10.1.1.0 255.255.255.224 Vlanif10 10.1.1.10 ip routestatic vpninstance Media 10.1.3.0 255.255.255.224 10.1.2.1 public #

ip routestatic 10.1.1.0 255.255.255.224 Vlanif10 10.1.1.1 ip routestatic vpninstance Media 10.1.3.0 255.255.255.224 10.1.2.1 public #

ip routestatic 10.1.4.0 255.255.255.2 24 vpninstance Media 10.11.4.10 ip routestatic vpninstance Media 10.1.6.0 255.255.255.2 24 10.1.5.1 public #

ip routestatic 10.1.4.0 255.255.255.224 vpn-instance Media 10.11.4.10 ip routestatic vpninstance Media 10.1.6.0 255.255.255.224 10.1.5.1 public #

VLAN IF10

# interface Vlanif10 ip binding vpninstance 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 #

-

-

VLAN IF20

# 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-PE2

VLAN IF11

-

-

# interface Vlanif11 ip binding vpn-instance Media ip address 10.1.4.2 255.255.255.2 24 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 #

VLAN IF21

-

-

# interface Vlanif21 ip address 10.1.5.2 255.255.255.2 24 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 in Area-A function normally, you can conclude that the configuration principle for Area-B is correct. 2.

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

3.

Run the display arp slot 1 command to check ARP entries of GE 1/0/1. You can find that there 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 (the Eth-Trunk connects B-PE1 and B-PE2 and transmits VRRP protocol packets). After the preceding steps, you can conclude that the missing of the ARP entry leads to the failure of the communications between the VPN and the public network (to be specific, from the public network to the VPN).

5.

The cause for the missing of the ARP entry on the interface board in slot 1 is shown as follows: (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 public network. (2) When a device in the public network needs to access 10.1.4.1, B-PE2 finds that the outgoing interface is VLANIF11. Because the static route (ip route-static 10.1.4.0 255.255.255.224 vpn-instance Media 10.1.4.10) is configured, B-PE2 randomly

Issue 02 (2011-09-10)


15



selects a member interface of VLANIF11 as the outgoing interface (in this troubleshooting case, the selected member interface is GE1/0/1), and sends ARP requests 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 is in the Active state and connects to B-PE1, and the backup interface is in the Inactive state and connects to B-PE2. The backup interface does not process any protocol packet. Therefore, after the server 10.1.4.1 receives an ARP request from B-PE2 through the backup interface, the application system does not response to this ARP request. In this case, although the interface of B-PE2, that is, GE 1/0/1, is directly connected to 10.1.4.1, it cannot receive the ARP response from 10.1.4.1, and consequently no corresponding ARP entry can be generated on GE 1/0/1. Since the ARP 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 through the master interface. The master interface is added to VLAN 11, and the Eth-Trunk of B-PE1 is also added to VLAN 11; therefore, the ARP response is sent to B-PE2 through the Eth-Trunk. As a result, when checking the ARP entries of the interface board in slot 2 on B-PE2, you can find that the outgoing interface of the ARP entry for 10.1.4.1 is the Eth-trunk, as shown in Figure 1-5.

Issue 02 (2011-09-10)


16



Figure 1-5 Networking diagram of ARP request and response

Server 10.1.1.1/27 VLAN10

Active

Inactive VLAN10 Trunk

I n t e rn e t

Area-A

10.1.3.1/27

GE1/0/1 VLANIF10

GE1/0/1 10.1.2.1/27 VLAN20 G /2 VL E1/ 1/0 F20 E AN 0/2 G A NI IF2 VL 0

A-PE1

A-PE2

Trunk(slot 2) Trunk

B-PE1

GE1/0/1 VLANIF10

WAN

Trunk Trunk(slot 2) VLAN 11

B-PE2

GE1/0/1 2 / 0 1/ 21 VLANIF11 E G NIF A VL

GE1/0/1 G VLANIF11 VL E1/0 AN /2 IF2 1 VLAN21 GE1/0/1 10.1.5.1/27

10.1.6.1/27

Area-B

I n t e rn e t

Inactive Server 10.1.4.1/27

Active

ARP request ARP reply

Issue 02 (2011-09-10)


17



The cause for the successful communications between the VPN and the public network in Area-A is that switches are placed in Area-A to transparently transmit Layer 2 services, as shown in Figure 1-5. Usually, after learning an ARP entry, a VLANIF interface generates a 32-bit host route for selecting the outgoing interface. If a PE is configured with a static route, the VLANIF interface has 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 on B-PE2, B-PE2 randomly selects a member interface of the outgoing interface (VLANIF11) to forward packets. If the member interface is incorrectly selected, the communications between the VPN and the public network fail. In the troubleshooting case, the ARP entry learning process is normal; therefore, the fault is caused by the configuration of the static network segment route.

Procedure Step 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 the public network. Step 3 Run the ip route-static 10.1.4.1 255.255.255.255 vpn-instance Media 10.1.4.1 command on B-PE2 to reconfigure the static route for communications between the VPN and the public network. After the preceding configuration, you can find that communications between the VPN and the public network are implemented. The fault is thus rectified. ----End

Summary When 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 outgoing interface, instead of a network segment route. Otherwise, a member interface of the VLANIF interface is randomly selected as the outgoing interface, and the preceding fault occurs.

1.2.4 VPN Services Are Interrupted Because the Link Between an ABR and a BAS Fails in a Full-meshed NSSA Fault Symptom As shown in Figure 1-6, ABR1, ABR2, BAS1, and BAS2 form a full-meshed network. All routers run OSPF, and the AS is divided into two areas, area 0 and area 1. Area 0 functions as the backbone area, consisting of ABR1 and ABR2. Area 1 is configured as an NSSA, consisting of two ABRs and two BASs. All links are configured with MPLS LDP to transmit MPLS L3VPN services. Considering the limited capability of the BASs, an upper limit on LSPs is set on the BASs and the BASs are configured not to function as transit nodes. When the link between ABR1 and BAS1 fails, VPN services between them are interrupted. Issue 02 (2011-09-10)


18



Figure 1-6 Networking diagram of the OSPF NSSA


Loopback0 2.2.2.2/32 Area0

ABR2

ABR1 Area1 NSSA

BAS1

BAS2



Fault Analysis 1.

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 routes defines that intra-area OSPF routes are preferentially selected. Therefore, the IGP path from ABR1 to BAS1 is ABR1 -> BAS2 -> ABR2 -> BAS1.

2.

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

Procedure Step 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 subinterfaces, and add the sub-interfaces to area 1 (an NSSA). Step 2 Run the interface interface-type interface-number.subinterface-number command to create a sub-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. Issue 02 (2011-09-10)


19



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

Summary Loopback interfaces should be added to the correct area.

1.2.5 A Routing Loop Occurs After a Sham Link Is Established Between PEs Fault Symptom As shown in Figure 1-7, OSPF runs on the network, and CE1 and CE2 respectively access PE1 and PE2. A sham link is established between PE3 and PE4 to transmit LSAs.PE1 and PE2 are not 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 set larger, ensuring that the traffic is preferentially transmitted through the link between CE1 and PE1. Other links adopt the default cost value. VRRP runs on GE2/0/0 of CE2, with CE1 as the VRRP gateway. In the preceding networking, it is found that devices on the network segment 10.1.1.0/24 can access PE3 and PE1, but cannot access PE4 and PE2, and devices on the office network can access PE4, PE2, PE3, and PE1. Figure 1-7 Networking diagram of the OSPF sham link

Cost 1 PE4

PE3 GE2/0/0 20.1.2.6/24 Cost 1

Exit Network Office

PE1

sham link GE1/0/0 20.1.2.5/30 Cost 10

GE1/0/0 20.1.2.9/30 Cost 1

GE2/0/0 20.1.2.1/30 Cost 1 PE2

Exit GE2/0/0 GE2/0/0 Network GE1/0/0 172.16.1.1/24 172.17.1.1/24 GE1/0/0 Office 20.1.2.13/30 10.1.2.17/30 Cost 10 Cost 20 CE1

CE2 GE2/0/0 10.1.1.1/24 Cost 10

Area1

GE2/0/0 10.1.1.2/24 Cost 20

Fault Analysis The possible causes are as follows: Issue 02 (2011-09-10)


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 can find that a loop is formed between PE2 and PE4. Theoretically, OSPF is a loop-free protocol. Why does the loop occur?

4.

Run the display ip routing-table command to view routing information about PE2. You can 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 CE2 is 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 between PE2 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 peer relationships in each OSPF area. You can find that all OSPF peer relationships (including the 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 find that the LSDB contains the LSAs that are advertised by CE1 and CE2 and destined for 10.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 reach 10.1.1.0/24. After being added with the cost value between CE2 and PE2, that is, 20, the cost 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, is smaller than the cost of the path PE4 -> PE2 -> CE2, that is 41. In this case, PE4 must select PE3, instead of CE2, as the next hop.

7.

Run the display ospf lsdb command to check the OSPF LSDB on PE4. You can find the LSA that is advertised by CE1 and destined for 10.1.1.0/24. Nevertheless, run the display ip routing-table 10.1.1.0 24 verbose command on PE4, and you can find two routes destined for 10.1.1.0/24. One is an OSPF route in the active state, with the next hop being PE2, 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 link is established between PE3 and PE4, and the route learnt from the sham link is considered as a BGP route. The preference of BGP routes is 255, whereas the preference of OSPF routes 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 from the sham link is BGP, leading to the routing loop between PE2 and PE4 on the network.

Procedure l

Solution 1: 1.

Issue 02 (2011-09-10)

Run the system-view command to enter the system view. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

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 select the 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 from preferentially 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 fundamentally prevents loops. NOTE

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

l

Solution 4: This solution is to optimize the existing OAM network. The specific measure is to set up a Layer 3 link between PE1 and PE2 and add this link to area 0. This solution can not only solve the current problem, but also prevent the traffic on the network (such as the traffic between CE1 and PE2) from being transmitted between the PEs. Details are as follows: 1.


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 the route destined for 10.1.1.0/24 to 10.1.2.17/30. After the preceding change, devices on the network segment 10.1.1.0/24 can access CE2, PE2, and PE4. Devices on other network segments can also access CE2, PE2, and PE4.

----End Issue 02 (2011-09-10)


22



Summary It 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 Option B Setup Because the Mask of the Loopback Address on an Intermediate Router Is Incorrect Fault Symptom As shown in Figure 1-8. 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-8 Networking diagram of inter-AS VPN Option B mode


AS 100


ASBR1


AS 200


ASBR2

PE2

PE1

CE1 Loopback0 2.2.2.5/32

AS 300

CE2

AS 300


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.

Issue 02 (2011-09-10)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

23


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.

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 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-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.7 PEs Cannot Learn Routes After the policy vpn-target Command Is Configured on an RR Fault Symptom As shown in Figure 1-9, 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 02 (2011-09-10)


24



Figure 1-9 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

1.


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

l

Issue 02 (2011-09-10)

Solution 2: Configure the VPN instance vpna on the RR. 1.


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.

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 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.8 VPN Routing Table on the PE Does Not Contain Any Route Sent from the Peer PE Fault Symptom Figure 1-10 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-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 PE2

After the configuration is complete, PE1 can receive private network routes from CE1, but PE2 and CE2 cannot do that. Issue 02 (2011-09-10)


26



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 vpn6-instance vpn6-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. 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). 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.

Procedure Step 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

Summary To transfer the traffic of private network across the public network, a public network tunnel is required. Issue 02 (2011-09-10)


27



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.9 CEs Cannot Ping Through Each Other Fault Symptom BGP/MPLS IPv6 VPN services are configured in the network shown in Figure 1-11. CE1 and CE2 belong to the same IPv6 VPN. After the configuration, CE1 cannot ping through CE2. Figure 1-11 Networking diagram of BGP/MPLS IPv6 VPN Loopback 1

Loopback 1

PE1

PE2 P1

P2

CE1

CE2

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. Issue 02 (2011-09-10)


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

Summary Specify the local loopback interface as the outbound interface of the local IBGP session when configuring PE peers.

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

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. Issue 02 (2011-09-10)


29



1.2.11 PE Fails to Ping Through the Remote CE Network Segment Fault Symptom Figure 1-12 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

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 the remote network segment where CE3 resides. Run the ping ipv6 vpn6-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 IPv6 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 vpn6-instance vpn6instance-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. Issue 02 (2011-09-10)


30



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

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.12 CEs in the Inter-AS IPv6 VPN Option C Fail to Communicate with Each Other Fault Symptom Figure 1-13 Networking diagram of inter-AS IPv6 VPN Option C

PE1

Backbone AS100

ASBR1

ASBR2

CE1

Backbone AS200

PE2

CE2

As shown in Figure 1-13, when the inter-AS VPN Option C is configured, the MP-EBGP peer relationship is established between PE1 and PE2, but CE1 and CE2 fail to communicate with each other. A check of the relevant routing table and forwarding table shows that there are two IGP routes between PE2 and ASBR2 for load balancing. An LDP LSP is established over one of the routes, Link_A; the other route, Link_B, has no LDP LSP established over it.

Fault Analysis If there are multiple equal-cost IGP routes to the loopback interface on a PE in the same AS as the ASBR, the ASBR imports any one of them into BGP as the route to the PE. If the selected route is not iterated to the corresponding LDP LSP, the ASBR discards the received data. As a result, the CEs fail to communicate with each other. Run the display bgp routing-table command on ASBR2 to view the BGP route to the loopback interface on PE2. The command output shows that the route, Link_B, is selected as the optimal route. The LDP LSP, however, is not set up over Link_B. As a result, the CEs fail to communicate with each other. display bgp routing-table 4.4.4.9

Issue 02 (2011-09-10)


31



BGP local router ID : 3.3.3.9 Local AS number : 200 Paths: 1 available, 1 best, 1 select BGP routing table entry information of 4.4.4.9/32: Network route. Label information (Received/Applied): NULL/13312 From: 0.0.0.0 (0.0.0.0) Route Duration: 03h58m55s Direct Out-interface: Pos3/0/0 Original nexthop: 162.1.1.2 Qos information : 0x0 AS-path Nil, origin igp, MED 2, pref-val 0, valid, local, best, select, pre 10 Advertised to such 1 peers: 192.1.1.1

Procedure l

Solution 1: Delete the links along which no LDP LSPs are set up so that only the routes associated with LDP LSPs can be imported into BGP.

l

Solution 2: Adjust the link costs based on the corresponding IGP to ensure that the costs of the IGP routes imported into IBGP are not equal. Then, the route associated with an LDP LSP can be selected as the optimal route. In the following example, OSPF is used as the IGP.

l

1.

Run the interface interface-type interface-number command to enter the view of the interface on which link costs need to be adjusted.

2.

Run the ospf cost cost command to adjust the link costs.

Solution 3: Enable MPLS and MPLS LDP on the devices along the link over which no LDP LSP is set up and on the link interfaces to set up an LDP LSP. 1.

Run the mpls command to enable MPLS on the local end and enter the MPLS view.

2.

Run the mpls ldp command to enable LDP globally and enter the MPLS LDP view.

3.

Run the quit command to return to the system view.

4.

Run the interface interface-type interface-number command to enter the interface view.

5.

Run the mpls command to enable MPLS on the interface.

6.

Run the mpls ldp command to enable LDP on the interface.

----End

Summary When importing routes to the loopback interface on the PE into BGP, ensure that the routes to be imported are associated with LDP LSPs.

1.2.13 Private Route Flapping Occurs Frequently When a Physical Interface Alternates Between Up and Down Fault Symptom On the network shown in Figure 1-14, 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. Issue 02 (2011-09-10)


32



Figure 1-14 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 and display fib 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 to fib -----------------------------------------------------------------------------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 Database information for ISIS(100) ---------------------------------Level-2 Link State Database LSPID Seq Num Checksum Holdtime Length ATT/P/ OL ------------------------------------------------------------------------------

Issue 02 (2011-09-10)


33



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 02 (2011-09-10)

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 IngressLsrID LocalLspID Tunnel-Interface Fec Nexthop In-Label Out-Label

: : : : : : : : :

3 12 1.1.1.2 32773 Tunnel1/0/2 1.1.1.1/32 1.1.2.2 NULL 65581


34



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 ...... -----------------------------------------------------------------------------TOTAL: 36 session(s) Found. LAM : Label Advertisement Mode SsnAge Unit : DDD:HH:MM

Issue 02 (2011-09-10)


35


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

Issue 02 (2011-09-10)


36



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, the fault is rectified. Then, check the link between Router A and Router B. ----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.

1.2.14 CE Cannot Access Some Web Servers Due to the MTU Configuration Fault Symptom On the network shown in Figure 1-15, 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. Issue 02 (2011-09-10)


37



Figure 1-15 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 interface 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 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. Issue 02 (2011-09-10)


38



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 restart command to restart the current interface. 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.

1.2.15 The RR Fails to Reflect VPN Routes Fault Symptom On the network shown in Figure 1-16, 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.

Issue 02 (2011-09-10)


39



Figure 1-16 Networking diagram of the RR failing to reflect VPN routes

Route Reflector

PE1 (Client1)

PE2 (Client2)

CE1

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

Issue 02 (2011-09-10)


40



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.16 CE1 Cannot Register with CE2 Because the Maximum Number of Routes Exceed the Upper Threshold Fault Symptom On the network shown in Figure 1-17, 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 02 (2011-09-10)


41



Figure 1-17 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 02 (2011-09-10)


42


5.


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 routing-table 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.17 Users Attached to a CE Cannot Access the Internet After BGP/ MPLS IP VPN Services Are Deployed Fault Symptom As shown in Figure 1-18, a PE is connected to an SPE and the SPE is connected to a UPE to form a layered network. Each PE is deployed with multiple VPN instances, each of which configured with multiple export RTs and import RTs. The PE is configured with logical interfaces, each of which is bound to a VPN instance and connected to the firewall. The SPE delivers default routes of each VPN instance to the UPE to guide the forwarding of traffic sent from the CE to the SPE. After the configurations, users attached to the CE cannot access the Internet. Issue 02 (2011-09-10)


43



Figure 1-18 Networking diagram of the case where users attached to a CE cannot access the Internet

PE

Firewall Internet

SPE

UPE

CE

Fault Analysis 1.

Run the display ip routing-table vpn-instance command on the UPE. Each VPN instance has learned two default routes.

2.

Run the display current-configuration configuration vpn-instance command on the UPE to view the configurations of VPN instances. Each VPN instance has been configured with multiple export RTs and import RTs.

3.

Run the display current-configuration configuration vpn-instance command on the SPE to view the configurations of VPN instances. RTs of two VPN instances are the same, and thus the default routes learned from two VPN instances are advertised to the UPE through the same export RT. In addition, the export RT matches multiple import RTs of one VPN instance on the UPE. As a result, the UPE learns multiple default routes from the same VPN instance. In this case, the traffic received by the SPE from the CE has multiple BGP next hops, and thus status entries cannot be created on the firewall. Consequently, users attached to the CE cannot access the Internet.

Procedure Step 1 Run the system-view command on the UPE to enter the system view. Step 2 Run the ip vpn-instance vpn-instance-name command on the UPE to enter the VPN instance view. Step 3 Run the vpn-target vpn-target &<1-8> import-extcommunity command on the UPE to configure VPN-target extended community attribute for the VPN instance.

Issue 02 (2011-09-10)


44



Ensure that each VPN instance on the UPE is configured with only one import RT so that only one default route can be learned. After the preceding operations, users attached to the CE can access the Internet. The fault is rectified. ----End

Summary Different from PEs or SPEs, a UPE on a layered network only use default routes to guide upstream traffic. Therefore, the UPE can be configured with multiple export RTs as required but should be configured with only one import RT. Otherwise, the fault occurs.

1.2.18 VPNv4 Routes on a PE Cannot Take Effect Fault Symptom On the network shown in Figure 1-19, 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. Figure 1-19 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

Issue 02 (2011-09-10)


45



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 Label: 0x0

BGP

Process ID:

255

Cost:

10.1.1.1

Interface:

0.0.0.0

Neighbour:

109568

Tunnel ID: 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. Issue 02 (2011-09-10)


46



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.

1.2.19 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-20 Typical Network Diagram for MPLS VPN

PE1

PE3

PE2

PE4 PE5

CE1

Issue 02 (2011-09-10)


PE6

CE2

47



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. 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.20 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-21, 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. Issue 02 (2011-09-10)


48



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-21 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 3

PE 4 Network

Phone1

Phone2

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. Issue 02 (2011-09-10)


49



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.21 PEs Fail to Exchange Private Network Routes Because the Mask Set for the Loopback Interface Is Not a 32-bit Mask Fault Symptom On the network shown in Figure 1-22, 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-22 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.

Issue 02 (2011-09-10)

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. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

50



2.

Run the display mpls ldp session command on the P. You can view that the LDP peer relationships between the P and PEs are 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. Destination/Mask 1.1.1.0/24

6.

Proto

Direct 0

0

Pre

Cost

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. 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 to enter the system view. Step 2 Run the interface loopback1 command to enter the view of Loopback1 bound to the VPN instance. Step 3 Run the ip address ip-address { mask | mask-length } command 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 02 (2011-09-10)


51



1.2.22 Some MPLS VPN Services on a Device Become Abnormal After the Service Cutover Fault Symptom On the carrier's MAN shown in Figure 1-23, all devices except Router A are non-Huawei devices. Router C and Router D (two non-Huawei devices) function as MAN's egress core routers at Site A and Site B respectively. The total outbound bandwidth of the egress device of the MAN is 3 x 2.5 GB. The bandwidth of the link from Router C at Site A to Router A on the backbone network is 1 x 2.5 GB, and the bandwidth of the link from Router D at Site B to Router B on the backbone network is 2 x 2.5 GB. Outbound bandwidths of Router E to Router A and Router G to Router B are both 2 x 10 GB. Figure 1-23 Networking of the MAN before service cutover

RouterE

RouterF

RouterG

RouterH

RouterB

RouterA Site A

Site B

Backbone network MAN

RouterD RouterC

10G 2.5G

The carrier optimizes the MAN and the backbone network to better facilitate the growing service requirements. As shown in Figure 1-24, backbone nodes Router A and Router B function as MAN's egress core routers and directly establish EBGP peer relationships with Router E and Router G on the backbone network respectively. Router C and Router D (previously core routers on the MAN) are removed from the networking for other purpose. The MAN continues Issue 02 (2011-09-10)


52



to use the private AS number. The IBGP peer relationship is established between Router A and Router B (two core routers on the MAN). The SR and the BRAS that are previously attached to Router C and Router D respectively are now attached to Router A and Router B respectively. Figure 1-24 Networking of the MAN after service cutover

RouterE

RouterF

RouterG

RouterH

Backbone network MAN RouterB

Site A

Site B

RouterA

10G 2.5G

As shown in Figure 1-25, after service cutover, service tests are performed on Router A. It is found that MPLS VPN services of some users in the same VPN instance work normally but some MPLS VPN services on the BRAS become abnormal.

Issue 02 (2011-09-10)


53



Figure 1-25 Networking of the MAN during service cutover

RouterE

RouterF

RouterG

RouterH

RouterB Site B

Backbone network MAN

RouterD

Site A RouterA

10G 2.5G

Fault Analysis 1.

Run the display current-configuration configuration command on Router A to check current configurations, and you can find that current configurations are correct.

2.

Check configurations about the interface MTU and the BRAS on Router A, and you can find that these configurations are correct.

3.

Run the ping lsp -a source-ip command (source-ip specifies the loopback interface address of Router A) on Router A to ping the loopback interface address of the BRAS. The ping succeeds, indicating that packet forwarding between Router A and the BRAS is normal.

4.

Run the ping lsp -a source-ip command (source-ip specifies the loopback interface address of the BRAS) on the BRAS to ping the loopback interface address of the inaccessible PE in the VPN. It is found that the ping fails.

5.

Run the display mpls ldp peer command on the BRAS to check information about LDP peers. You can find that the address used to establish the LDP peer relationship between Router D and the BRAS is the address of Loopback1 rather than Loopback0. Because customers have special requirements, the address of Loopback1 on Router C is set to the same as the address of Loopback1 on Router A.

Issue 02 (2011-09-10)


54



6.

Run the display mpls ldp peer command on Router A to check information about LDP peers. You can find that the address used to establish the LDP peer relationship between Router D and Router A is also the address of Loopback1 rather than Loopback0.

7.

Run the display current-configuration configuration command on Router D to check current configurations. You can find that the address of Loopback1 is mistakenly used to establish the LDP peer relationship on Router D. The fact is that the address of Loopback0 should be used to establish the LDP peer relationship on Router D. As a result, some MPLS VPN services forwarded by Router D cannot be accessed. Before service cutover is implemented on Router A, traffic is transmitted through previous core routers on the MAN. During service cutover, the traffic is switched to Router D. After service cutover, the traffic is not switched back to Router A, thus causing the fault.

Procedure Step 1 Set the address of Loopback0 as the address used to establish the LDP peer relationship on Router D. ----End

Summary The major cause of the fault is that MPLS LSP forwarding is abnormal. If the fault occurs, run the ping lsp commands with source addresses on the PEs to ping each other.

Issue 02 (2011-09-10)


55


2 VPLS Troubleshooting

2

VPLS Troubleshooting

About This Chapter This chapter describes common causes of VPLS faults and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs. 2.1 VSI of Martini VPLS Cannot Go Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI of Martini VPLS cannot go Up. 2.2 VSI of Kompella VPLS Cannot Go Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI of Kompella VPLS cannot go Up. 2.3 VSI Goes Up Only on One End This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI goes Up only on one end. 2.4 A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella VPLS Network This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that a Huawei device cannot establish a PW with another vendor's device on a Kompella VPLS network. 2.5 Related Troubleshooting Cases

Issue 02 (2011-09-10)


56



2.1 VSI of Martini VPLS Cannot Go Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI of Martini VPLS cannot go Up.

2.1.1 Common Causes This fault is commonly caused by one of the following: l

Encapsulation types of both ends are different.

l

MTUs of both ends are different.

l

VSI IDs of both ends are different.

l

LDP sessions are not in the Up state.

l

The tunnel policy for selecting a TE tunnel as the public network tunnel is incorrectly configured.

l

The local or remote end of the tunnel does not go Up.

l

The local or remote AC interface does not go Up.

2.1.2 Troubleshooting Flowchart After Martini VPLS is configured, the VSI cannot go Up. Figure 2-1 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


57



Figure 2-1 Troubleshooting flowchart for the fault that the VSI of Martini VPLS cannot go Up The Martini VSI is Down

Are encapsulation types of both ends the same?

No

Yes

Are MTUs of both ends the same?

No

No

No

Yes

Yes

Is fault rectified?

End

Yes

Is fault rectified?

End

No

No

Is fault rectified?

Yes

End

No

Yes

Are AC interfaces of both ends Up?

End

No

Yes

Tunnel is Selected?

Yes

Is fault rectified?

No

Yes

Is the LDP session Up?

End

No

Yes

Are the VSI IDs of both ends the same?

Yes

Is fault rectified?

No Is fault rectified?

Yes

End

No

Seek technical support

Issue 02 (2011-09-10)


58





Procedure Step 1 Check that the encapsulation types of both ends are the same. display vsi name tt Vsi Mem PW Mac Encap Mtu Vsi Name Disc Type Learn Type Value State -------------------------------------------------------------------------tt static ldp unqualify vlan 1500 up

l If the encapsulation types of both ends are different, run the encapsulation { ethernet | vlan } command in the VSI view to change the encapsulation type of either end, ensuring that the encapsulation types of both ends are the same. l If the encapsulation types of both ends are the same, go to Step 2. NOTE

The same encapsulation type on both ends is one of the prerequisites for the VSI to go Up.

Step 2 Check that MTUs of both ends are the same. display vsi name tt Vsi Mem PW Mac Encap Mtu Vsi Name Disc Type Learn Type Value State -------------------------------------------------------------------------tt static ldp unqualify vlan 1500 up

l If the MTUs of both ends are different, run the mtu mtu-value command in the VSI view to change the MTU of either end, ensuring that the MTUs of both ends are the same. l If the MTUs of both ends are the same, go to Step 3. NOTE

The same MTU on both ends is one of the prerequisites for the VSI to go Up.

Step 3 Check that the VSI IDs or negotiation-VC-IDs of both ends are the same. display vsi name tt verbose ***VSI Name Administrator VSI Isolate Spoken VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU Diffserv Mode Service Class Color DomainId Domain Name Tunnel Policy Name Ignore AcState Create Time VSI State VSI ID *Peer Router ID

Issue 02 (2011-09-10)

: : : : : : : : : : : : : : : : : :

tt no disable 3 ldp static unqualify vlan 1500 uniform --255 p1 disable 2 days, 2 hours, 47 minutes, 40 seconds up

: 101 : 2.2.2.2


59



VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex

: : : : : : : : :

187393 dynamic up 0xc0060401 0xc0060401 6 5 0 0

Interface Name State Last Up Time Total Up Time

: : : :

GigabitEthernet8/0/0.12 up 2010/02/05 06:36:57 2 days, 2 hours, 40 minutes, 19 seconds

l If the VSI IDs or negotiation-VC-IDs are different for both ends, run the pwsignal ldp command in the VSI-LDP view to modify the VSI ID of either end, or run the peer peeraddress negotiation-VC-ID vc-id command in the VSI-LDP view to modify the negotiationVC-ID of either end, ensuring that the VSI IDs or negotiation-VC-IDs of both ends are the same. l If the VSI IDs or negotiation-VC-IDs of both ends are the same, go to Step 4. NOTE

The same VSI ID or negotiation-VC-ID on both ends is one of the prerequisites for the VSI to go Up.

Step 4 Check that the LDP session between both ends is Up. Run the display vsi name vsi-name verbose command to check whether the Session field is displayed as Up. display vsi name tt verbose ***VSI Name Administrator VSI Isolate Spoken VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU Diffserv Mode Service Class Color DomainId Domain Name Tunnel Policy Name Ignore AcState Create Time VSI State VSI ID *Peer Router ID VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex Interface Name State Last Up Time Total Up Time

Issue 02 (2011-09-10)

: : : : : : : : : : : : : : : : : :

tt no disable 3 ldp static unqualify vlan 1500 uniform --255

: : : : : : : : : : :

101 2.2.2.2 187393 dynamic up 0xc0060401 0xc0060401 6 5 0 0

: : : :

GigabitEthernet8/0/0.12 up 2010/02/05 06:36:57 2 days, 2 hours, 40 minutes, 19 seconds

p1 disable 2 days, 2 hours, 47 minutes, 40 seconds up


60



l If the LDP session between both ends does not go Up, refer to the section "LDP Session Goes Down" to locate the fault and ensure that the LDP session goes Up. l If the LDP session between both ends is Up, go to Step 5. NOTE

The Up status of the LDP session is one of the prerequisites for both ends to perform the L2VPN negotiation.

Step 5 Check whether the VSI has selected a tunnel. Run the display vsi name vsi-name verbose command to check the following: l Check whether the Tunnel ID field is displayed as 0x0. If so, it indicates that the VSI does not select a tunnel. l Check the Tunnel Policy Name field. If this field is not displayed, it indicates that the VSI selects an LDP LSP or no tunnel policy is configured for the VSI. If the VSI selects an MPLSTE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel policy of the VSI. You can view details of the tunnel policy by running the display this 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 # NOTE


If the tunnel between both ends is not Up, refer to the session "LSP Goes Down" or "TE Tunnel Goes Down" to locate the fault and ensure that the tunnel goes Up. If the tunnel between both ends is Up and the TE interfaces are correctly configured, go to Step 6. NOTE

The Up status of the tunnel is one of the prerequisites for the VSI to go Up.

Step 6 Check that the AC interfaces of both ends are in the Up state. Run the display vsi name vsi-name verbose command on both ends to check whether the interfaces corresponding to the Interface Name field are in the Up state. l If not, refer to the section "Physical Interconnection & Interface Type" to locate the fault and ensure that the AC interfaces go Up. l If the AC interfaces on both ends are Up, go to Step 7. NOTE

The Up status of AC interfaces on both ends is one of the prerequisites for the VSI to go Up.


2.1.4 Relevant Alarms and Logs Issue 02 (2011-09-10)


61



Relevant Alarms None.

Relevant Logs None.

2.2 VSI of Kompella VPLS Cannot Go Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI of Kompella VPLS cannot go Up.


Encapsulation types of both ends are different.

l

MTUs of both ends are different.

l

BGP is not in the Established state.

l

The tunnel policy for selecting a TE tunnel as the public network tunnel is incorrectly configured.

l

The site-id of the local end is greater than the sum of the range and offset of the remote end.

l

The local or remote AC interface does not go Up.

2.2.2 Troubleshooting Flowchart After Kompella VPLS is configured, the VSI cannot go Up. Figure 2-2 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


62



Figure 2-2 Troubleshooting flowchart for the fault that the VSI of Kompella VPLS cannot go Up The Kompell VSI is Down

Are encapsulation types and MTUs of both ends the same?

No

Yes

Are site IDs of both ends the same?

No

End

No No

Is fault rectified?

Yes

End

No No

Yes Is the site-id of either end smaller than the sum of the range and offset of the other end?

End

Yes Is fault rectified?

Yes

Tunnel is Selected?

Yes

No

Yes

Is the BGP session Established?

Is fault rectified?

Is fault rectified?

Yes

End

No

No

Yes End

Is fault rectified? No

Yes

Are AC interfaces of both ends Up? Yes

No Is fault rectified?

Yes

End


Issue 02 (2011-09-10)


63





Procedure Step 1 Check that encapsulation types and MTUs of both ends are the same. display vsi name tt2 Vsi Mem PW Mac Encap Mtu Vsi Name Disc Type Learn Type Value State -------------------------------------------------------------------------tt2 auto bgp unqualify vlan 1500 up

l If the encapsulation types or MTUs of both ends are different, run the encapsulation { ethernet | vlan } command to change the encapsulation type of either end, or run the mtu mtu command to change the MTU of either end, ensuring that the encapsulation types or MTUs of both ends are the same. l If the encapsulation types and MTUs of both ends are the same, go to Step 2. NOTE

The same encapsulation type and MTU on both ends are two prerequisites for the VSI to go Up.

Step 2 Check that site IDs of both ends are different. [HUAWEI-vsi-tt2] display this # vsi tt2 auto pwsignal bgp route-distinguisher 200:1 vpn-target 201:1 import-extcommunity vpn-target 201:1 export-extcommunity site 1 range 10 default-offset 0 # return

l If the site IDs of both ends are the same, run the site site-id [ range site-range ] [ defaultoffset { 0 | 1 } ] command to change the site ID of either end, ensuring that the site IDs of both ends are different. l If the site IDs of both ends are different, go to Step 4. NOTE

Site IDs of the same VSI cannot be the same.

Step 3 Check that the BGP session between both ends is in the Established state. Run the display bgp vpls peer [ ipv4-address verbose | verbose ] [ | count ] [ | { begin | exclude | include } regular-expression ] command to check the BGP session between both ends. display bgp vpls peer BGP local router ID : 200.1.1.1 Local AS number : 100 Total number of peers : 1 Peer 1.1.1.1

V 4

AS 100

MsgRcvd 14

Peers in established state : 1 MsgSent 16

OutQ Up/Down 0 00:10:06

State PrefRcv Established 0

l If the BGP session is not in the Established state, refer to the section The BGP Peer Relationship Fails to Be Established to locate the fault and establish the BGP session. l If the BGP session between both ends is in the Established state, go to Step 4. Issue 02 (2011-09-10)


64



NOTE

The Established status of the BGP session is one of the prerequisites for both ends to perform the L2VPN negotiation.

Step 4 Check whether the VSI has selected a tunnel. Run the display vsi name vsi-name verbose command to check the following: l Check whether the Tunnel ID field is displayed as 0x0. If so, it indicates that the VSI does not select a tunnel. l Check the Tunnel Policy Name field. If this field is not displayed, it indicates that the VSI selects an LDP LSP or no tunnel policy is configured for the VSI. If the VSI selects an MPLSTE tunnel, a tunnel policy must be configured. The value of the Tunnel Policy Name field indicates the tunnel policy of the VSI. You can view details of the tunnel policy by running the display this 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 # NOTE


If the tunnel between both ends is not Up, refer to the session LDP LSP Goes Down or TE Tunnel Is Down to locate the fault and ensure that the tunnel goes Up. If the tunnel between both ends is Up and the TE interfaces are correctly configured, go to Step 6. NOTE

The Up status of the tunnel is one of the prerequisites for the VSI to go Up.

Step 5 Check that the site ID of either end is smaller than the sum of the range and default offset of the other end. [HUAWEI-vsi-tt2] display this # vsi tt2 auto pwsignal bgp route-distinguisher 168.1.1.1:1 vpn-target 100:1 import-extcommunity vpn-target 100:1 export-extcommunity site 1 range 5 default-offset 0 # returen

l If the site ID of either end is equal to or greater than the sum of the range and default offset of the other end, modify either the site ID of the local end or the range of the remote end. l If the site ID of either end is smaller than the sum of the range and default offset of the other end, go to Step 6. Step 6 Check that AC interfaces of both ends are Up. Run the display vsi name vsi-name verbose command on both ends to check whether the interfaces corresponding to the Interface Name field are in the Up state. l If not, refer to the section "Physical Interconnection & Interface Type" to locate the fault and ensure that the AC interfaces go Up. l If the AC interfaces on both ends are Up, go to Step 8. Issue 02 (2011-09-10)


65




2.2.4 Relevant Alarms and Logs Relevant Alarms None.

Relevant Logs None.

2.3 VSI Goes Up Only on One End This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VSI goes Up only on one end.

2.3.1 Common Causes This fault is commonly caused by the following: l

The local end is specified as a UPE by the remote end.

l

Multiple AC interfaces in the Up state are bound to the VSI on the local end but no tunnel is selected.

2.3.2 Troubleshooting Flowchart After VPLS is configured, the VSI goes Up only on one end. Figure 2-3 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


66



Figure 2-3 Troubleshooting flowchart for the fault that the VSI goes Up only on one end The VSI is Up only on the local end

Is the local end bound to two or more AC interfaces in the Up state?

Yes

End

No Does the remote end specify the local end as the UPE?

Yes End

No




Procedure Step 1 Check that multiple AC interfaces on the local end are bound to the VSI. display vsi name tt ***VSI Name : Administrator VSI : Isolate Spoken : VSI Index : PW Signaling : Member Discovery Style : PW MAC Learn Style : Encapsulation Type : MTU : Diffserv Mode : Service Class : Color : DomainId : Domain Name : Tunnel Policy Name : Ignore AcState : Create Time : VSI State : VSI ID *Peer Router ID

Issue 02 (2011-09-10)

verbose tt no disable 3 ldp static unqualify vlan 1500 uniform --255 p1 disable 2 days, 6 hours, 3 minutes, 55 seconds up

: 101 : 2.2.2.2


67



VC Label Peer Type Session Tunnel ID Broadcast Tunnel ID CKey NKey StpEnable PwIndex

: : : : : : : : :

187393 dynamic up 0xc0060401 0xc0060401 6 5 0 0

Interface Name State Last Up Time Total Up Time Interface Name State Last Up Time Total Up Time

: : : : : : : :

GigabitEthernet8/0/0.12 up 2010/02/05 06:36:57 2 days, 5 hours, 56 minutes, 34 seconds GigabitEthernet8/0/0.3 up 2010/02/07 12:33:13 0 days, 0 hours, 0 minutes, 18 seconds

If two or more AC interfaces are bound to the VSI, but the fault persists, go to Step 2. Step 2 Check that the remote end specifies the local end as the UPE. [HUAWEI-vsi-tt-ldp] display this # vsi-id 101 peer 1.1.1.1 upe #

l If the remote end specifies the local end as the UPE, it is normal to find that the VSI goes Up only on one end. l If the remote end does not specify the local end as the UPE, but the fault persists, go to Step 3. Step 3 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


Relevant Logs None.

2.4 A Huawei Device Cannot Establish a PW with Another Vendor's Device on a Kompella VPLS Network This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that a Huawei device cannot establish a PW with another vendor's device on a Kompella VPLS network.

Issue 02 (2011-09-10)


68




The vpls bgp encapsulation { ethernet | vlan } command is not configured in the system view.

l

The ignore-mtu-match command is not configured in the VSI view.

l

The default offset of another vendor's device is 1 and cannot be modified. When a Huawei device communicates with the device, the default offset of the Huawei device should be set to 1 and the site ID should not be set to 0.

2.4.2 Troubleshooting Flowchart After Kompella VPLS is configured, the Huawei device cannot establish a PW with another vendor's device. Figure 2-4 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


69



Figure 2-4 Troubleshooting flowchart for the fault that the Huawei device cannot establish a PW with another vendor's device A Huawei device cannot establish a PW with another vendor's device on a Kompella VPLS network

Is the vpls bgp encapsulation { ethernet | vlan } command configured in the system view?

No

Configure this command and check whether the fault is rectified

Yes

End

No

Yes

Is the ignore-mtu-match command configured in the VSI view?

No

Configure this command and check whether the fault is rectified

Yes

End

No Yes

Is the site ID of the Huawei device set to 0?

Yes

Set the site ID to 1

No Yes Is fault rectified?

End

No




Issue 02 (2011-09-10)


70



Procedure Step 1 Check that the vpls bgp encapsulation { ethernet | vlan } command is configured in the system view. l If the command is not configured in the system view, configure the command first. l If the command is configured in the system view, go to Step 2. NOTE

On the other vendor's device, the signaling command is configured by default in the BGP L2VPN address family view. In this case, the BGP Update packet sent by this device contains not only the VPLS address family (AFI=25, SAFI=65), but also a non-standard CSV field. Although this field is valid for Kompella VLL, it is not specified in RFC 4761 for VPLS. The Huawei device uses different address families for VPLS and Kompella VLL. After receiving a BGP Update packet from the other vendor's device, the Huawei device parses the packet. After identifying the VPLS address family, the Huawei device processes the packet as a VPLS packet. Then, the Huawei device identifies the non-standard CSV field, which should not have been in the VPLS packet. Therefore, the Huawei device considers that the length of the BGP Update packet is incorrect, and fails to establish the BGP peer relationship with the other vendor's device.

Step 2 Check that the ignore-mtu-match command is configured in the VSI view. l If the command is not configured in the VSI view, configure the command first. l If the command is configured in the VSI view, go to Step 3. NOTE

This command is used to ignore the MTU negotiation with another vendor's device.

Step 3 Check that default-offset of the Huawei device is set to 1. [HUAWEI-vsi-tt2] display this # vsi tt2 auto pwsignal bgp route-distinguisher 168.1.1.1:1 vpn-target 100:1 import-extcommunity vpn-target 100:1 export-extcommunity site 1 range 5 default-offset 0 # return

l If default-offset is not set to 1, set it to 1. l If default-offset is set to 1, go to Step 4. Step 4 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


Relevant Logs None. Issue 02 (2011-09-10)


71



2.5 Related Troubleshooting Cases 2.5.1 VPLS Services Fail Fault Symptom As shown in Figure 2-5, after a Huawei device replaces another vendor's device and functions as PE1, only VPLS services fail. Figure 2-5 Networking diagram of Martini VPLS Outbound

Inbound

MAN CE2 CE1

PE1 （Huawei device）

PE2 (Another vendor's device) Server

Martini VPLS

Fault Analysis NOTE

After a Huawei device replaces another vendor's device, only VPLS services fail. You can exclude the possibility of a link failure or the failure of another device.

1.

Run the display current-configuration command on PE1 to check whether the configurations are correct and consistent with those of PE2. You can find that configurations of PE1 are correct and consistent with those of PE2.

2.

Run the display vpls connection command on PE1 to check the VCState field. You can find that VCState is Up, indicating that a Layer 2 tunnel is established.

3.

When CE1 pings Server, run the display traffic-statistics vsi vsi-name [ peer peeraddress [ negotiation-vc-id vc-id ] ] command on PE1 to check whether the packet sending and receiving process is normal. You can find that packets can be correctly sent and received.

4.

When CE1 pings Server, you can capture VPLS packets in the inbound and outbound directions of PE1 on another device of the MAN. A captured VPLS packet in the inbound direction of PE1 is shown as follows: 0018 01FE 0001 0301

821D 0019 0800 0019

2010 E019 0604 E019

0014 0D9E 0002 0D9E

1CD2 0019 0019 0303

FC06 21D5 21D5 0302

8847 5FD6 5FD6 0000

22C0 0806 0303 0000

As indicated by the 0806 field, the captured VPLS packet sent from PE2 carries no VLAN tag and is just a common ARP packet. PE1 and PE2, however, are configured with the Issue 02 (2011-09-10)


72



encapsulation mode of VLAN, causing PE1 to add a VLAN tag to the VPLS packet. After adding a VLAN tag to the VPLS packet, PE1 forwards the packet in the outbound direction. A captured VPLS packet in the outbound direction of PE1 is shown as follows: 0019 E019 0D9E 0019 21D5 5FD6 8100 019b 0800 0604 0002 0019 21D5 5FD6 0303 0301 0019 E019 0D9E 0303 0302 0000 0000 0000

You can find that PE1 replaces the 0806 field (ARP packet identifier) with the 8100 field (VLAN packet identifier). As a result, VPLS services fail. If the VLAN encapsulation mode of PE2 (another vendor's device) is modified to send VLAN tags, or PE1 and PE2 are configured with the encapsulation mode of Ethernet, the fault can be rectified.

Procedure l

Solution 1: Modify the VLAN encapsulation mode of another vendor's device to send VLAN tags.

l

Solution 2: Change the encapsulation mode on PE1 and PE2 to Ethernet. The Huawei device (PE1) can be configured as follows: 1.


2.

Run the vsi vsi-name command to enter the VSI view.

3.

Run the encapsulation ethernet command to set the VSI encapsulation mode as Ethernet. After the preceding configurations, CEs can ping each other successfully, and VPLS services become normal.

----End

Summary Why can the Layer 2 tunnel be Up when PE1 has incorrectly parsed packets? To answer this question, check the configurations of PE2. You can find that the VPLS sending and receiving on PE2 is in the hybrid mode. That is, PE2 can process any types of packets; when receiving a VPLS packet carrying a VLAN tag, PE2 removes the VLAN tag and then forwards the VPLS packet. This is the cause for the problem. As defined by RFC 4448, if a packet transmitted on a PW is encapsulated to the tagged mode, the packet must carry a VLAN tag.

Issue 02 (2011-09-10)


73



2.5.2 VSIs Cannot Be Up in LDP Signaling Mode Fault Symptom Figure 2-6 Networking diagram of VPLS



PE1 Ethernet1/0/0

POS2/0/0 168.1.1.1/24 POS1/0/0 168.1.1.2/24


POS2/0/0 169.1.1.1/24 P

POS1/0/0 169.1.1.2/24

CE1

PE2 Ethernet2/0/0

CE2

VPLS in LDP signaling mode is configured on both PE1 and PE2. After the configuration, the VSI on both PEs cannot be Up. Then PE1 initiates CE-Ping to detect the IP address of CE2, but the detection fails. Locating the fault, you find that the VSI cannot go Up.

Fault Analysis 1.

Check the VSI status on PE1 and PE2. Run the display vsi verbose command. The display on PE1 is as follows. VSI Name : v1 VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU VSI State VSI ID *Peer Router ID VC Label Session Tunnel ID Interface Name State

: : : : : : : : : : : : : :

0 ldp static unqualify vlan 1500 down 1 3.3.3.9 17409 up 0x6002002, Ethernet1/0/0 up

The display on PE2 is as follows. VSI Name : VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU

Issue 02 (2011-09-10)

v1 : 0 : ldp : static : unqualify : vlan : 1500


74



VSI State VSI ID *peer Router ID VC Label Session Tunnel ID Interface Name State

: : : : : : : :

down 1 2.2.2.9 17408 up 0x6002001, Ethernet2/0/0 up

ACs on both ends are Up. The tunnel on both ends of a PW is in existence, and the tunnel ID is not 0x0. 2.

According to the displayed PW information, you can find that the designated remote LDP peer of the PE2 is not correct. It should be 1.1.1.9 rather than 2.2.2.9. Then modify the peer.

Procedure Step 1 Run the display vsi verbose command on PEs. Step 2 Check the status of VSI and AC. Find that the VSI is Down, but AC is Up. Step 3 Check the status of the PW. Find that the PW cannot be set up. Step 4 Check whether the tunnel is available. Find that the tunnel is ready. Step 5 Find that the designated remote LDP peer of the PE2 is not correct according to the displayed PW information. The incorrectness makes the PW establishment failed. It should be designated as 1.1.1.9 rather than 2.2.2.9. Modify the peer. Step 6 Reconfigure the remote LDP peer of the PE2, which means to designate it as 1.1.1.9. Then the PW is established successfully. ----End

Summary If the signaling protocol is LDP and the VSI cannot be Up, the errors related to the peer are as follows: l

The peer is specified incorrectly.

l

The address of the peer is not the peer LSR-ID. The LDP remote session then cannot be established.

l

The LSR-ID of the peer is re-defined. Then the LDP remote session cannot be set up.

If a VSI is Up, there must be at least two ACs are Up, or at least one AC is Up and one PW is Up. To locate the fault, you can check the status of the AC and PW first. l

It is simple to let an AC go Up. You must bind the AC with a physical interface, and the line protocol state of the interface must be Up.

l

There are many conditions for a PW to go Up, such as the correct configurations of MTU, encapsulation type, VSI ID, and remote peer. The key is that the local and the remote ends can receive labels from each other.

You can run the display vsi remote { ldp | bgp } command to find which device is faulty according to the label receiving. Issue 02 (2011-09-10)


75



2.5.3 Packets Cannot Be Forwarded Successfully Between Two PEs Though VSIs Are Up Fault Symptom After configuring VPLS, check the VSI status on PEs. You find that both VSIs are Up, but the packets cannot be forwarded successfully between two PEs.

Fault Analysis 1.

Check whether the PW is available. Run the display vsi verbose command to check whether the PW is available. If the PW is not available, check whether the delivering status of the PW is "up", as shown below: l If the status is not "up", it shows that the forwarding information is not delivered to the interface board, which leads to the failure of the forwarding. l If the status is "up" but the forwarding still fails, check the operating status of the interface board.

2.

Check the MAC limit. If the PW is available, but packets cannot be forwarded between PEs, run the display current-configuration | begin vsi vsi-name command to check the MAC limit. If the number of MAC address entries exceeds the MAC limit, re-configure the MAC limit.

3.

Check whether the BGP peer is reestablished. If the number of MAC address entries does not exceed the MAC limit, run the display bgp peer peer-address command to check whether the BGP peer is set up. When the BGP peer is being re-established, the VSI status remains Up in this short period.

4.

Check the encapsulation types of PEs on both ends. If the BGP peer is set up, run the display current-configuration | begin vsi vsi-name command to check the encapsulation types of PEs on both ends. If the types are different, re-configure them to be the same. If the fault persists, contact the Huawei technical personnel.

Procedure Step 1 Run the display vsi command to check whether the status of the PW is up. Step 2 Run the display vpls connection command to check whether the PW is available. Step 3 If the status is "up", check whether the operating status of the interface board is normal. ----End

Summary The fault occurs when one of the following conditions is met: l

The PW information is not delivered to the interface board.

l

The number of MAC address entries exceeds the MAC limit.

l

When the BGP peer is being re-established, the VSI state remains Up in this short period.

Issue 02 (2011-09-10)


76


l


The encapsulation types on PEs of both ends are different.

2.5.4 VSIs Cannot Be Up in BGP Signaling Mode Fault Symptom PE1 and PE2 establish IBGP, and are configured with VSIs respectively. After the configuration, you find that VSIs on both PEs cannot go Up. Figure 2-7 Networking diagram of VPLS



PE1 Ethernet1/0/0

POS2/0/0 168.1.1.1/24 POS1/0/0 168.1.1.2/24


POS2/0/0 169.1.1.1/24 P

POS1/0/0 169.1.1.2/24

CE1

PE2 Ethernet2/0/0

CE2

Fault Analysis 1.

Check the VSI status on PE1 and that on PE2. Run the display vsi verbose command. The display on PE1 is as follows. ***VSI Name VSI Index PW Signaling Member Discovery Style PW MAC Learn Style Encapsulation Type MTU VSI State BGP RD SiteID/Range/Offset Import vpn target Export vpn target Local Label Block Interface Name State

: : : : : : : : : : : : : : :

bgp1 0 bgp auto unqualify vlan 1500 down 1:1 1/10/0 2:2, 2:2, 19456/10/0, Ethernet1/0/0 up

The display on PE2 is as follows. ***VSI Name : bgp1 VSI Index : 0 PW Signaling : bgp Member Discovery Style : auto PW MAC Learn Style : unqualify Encapsulation Type : vlan MTU : 1500 VSI State : down

Issue 02 (2011-09-10)


77



BGP RD SiteID/Range/Offset Import vpn target Export vpn target Local Label Block Interface Name State

2.

: : : : : : :

1:2 2/10/0 2:2, 2:2, 19456/10/0, Ethernet2/0/0 up

Check whether PEs can receive the remote label. Run the display vsi remote bgp command on PE1 and PE2. No information is displayed, which indicates that PEs have not received the remote label. In this case, the BGP configuration may be faulty.

Procedure Step 1 Check the AC status on both PEs, finding that both ACs are Up. Step 2 Run the display vsi remote bgp command, and find no display. This indicates that the label is not received. Step 3 Check whether the VPN targets match. Step 4 If the VPN targets match, check whether a tunnel is available. Step 5 If the tunnel is available, run the display bgp peer command to check whether the BGP neighbor relationship is established. Step 6 If the BGP neighbor relationship is set up, run the display bgp vpls all command to check whether the remote label block is received. Step 7 If the remote label block is not received, check the BGP configuration. You can find that the VPLS address family is not configured. After configuring the VPLS address family, you can rectify the fault. ----End

Summary VPLS in BGP mode and VPLS in LDP mode are configured differently. The major difference is that VPLS address family need to be configured, and the peer in the address family need to be enabled in BGP mode. When using the BGP signaling, check whether the BGP VPLS peer is specified and the remote label block can be received. The VSI status is still determined by the status of the AC and PW. In addition, you need to pay attention to the setting of the encapsulation type and MTU.

Issue 02 (2011-09-10)


78



2.5.5 PEs Cannot Interwork Though VSIs Are Up Fault Symptom Figure 2-8 Networking diagram of VPLS



PE1 Ethernet1/0/0

POS2/0/0 168.1.1.1/24 POS1/0/0 168.1.1.2/24


POS2/0/0 169.1.1.1/24 P

POS1/0/0 169.1.1.2/24

CE1

PE2 Ethernet2/0/0

CE2

VPLS in BGP mode is configured on PE1 and PE2. Although VSIs go Up, PEs cannot interwork.

Fault Analysis 1.

Check the VSI status on PE1 and PE2. Run the display vsi verbose command. The display on PE1 is as follow: ***VSI Name : v1 VSI Index : 0 PW Signaling : bgp Member Discovery Style : auto PW MAC Learn Style : unqualify Encapsulation Type : vlan MTU : 1500 VSI State : up BGP RD : 168.1.1.1:1 SiteID/Range/Offset : 3/10000/0 Import vpn target : 100:1, Export vpn target : 100:1, Remote Label Block : 141293/10000/0, Local Label Block : 140288/10000/0, Interface Name : Vlan100 State : up *Peer Ip Address : 3.3.3.9 PW State : up Local VC Label : 140289 Remote VC Label : 141296 PW Type : label Tunnel ID : 0x1009, PW Type : label Tunnel ID : 0x1009,

The display on PE2 is as follows: ***VSI Name VSI Index PW Signaling

Issue 02 (2011-09-10)

: v1 : 0 : bgp


79



Member Discovery Style PW MAC Learn Style Encapsulation Type MTU VSI State BGP RD SiteID/Range/Offset Import vpn target Export vpn target Remote Label Block Local Label Block Interface Name State *Peer Ip Address PW State Local VC Label Remote VC Label PW Type Tunnel ID

: auto : unqualify : ethernet : 1500 : up : 169.1.1.2:1 : 3/10000/0 : 100:1, : 100:1, :, 140288/10000/0 : 141293/10000/0, : Vlan100 : up : 1.1.1.9 : up : 141296 : 140289 : label : 0x1009,

The status of ACs on both ends is Up. Check the PW information on PE and find the tunnel information exists. The tunnel ID is not 0x0. See the display of Tunnel ID as above. 2.

Run the display vsi remote bgp command on PE2. The display is as follows: Total Number : 1 **BGP RD NextHop EncapType MTU Export vpn target SiteID Remote Label Block

: : : : : : :

169.1.1.2:1 200.200.200.12 vlan 1500 100:1, 3 140288/10000/0,

Number

: 1

The preceding display shows that after receiving a VPLS packet, PE2 assumes that the encapsulation type of this packet is ethernet. However, according to Step 1, the encapsulation type of the VPLS packet sent by PE1 is vlan. PE1 and PE2 cannot agree on the encapsulation type of the VPLS packet. PEs, hence, cannot interwork.

Procedure Step 1 Run the display vsi verbose command on PEs. Step 2 Check VSI and AC, finding that both are in the Up state. Step 3 Check whether the tunnel is available, finding that the tunnel is ready. Step 4 Run the display vsi remote bgp command on one PE to check the encapsulation type of the VPLS packet to be received by the PE, finding that the encapsulation type is different from that sent by the peer PE. Step 5 Run the vpls bgp encapsulation command on the local PE to re-designate the encapsulation type. Ensure that both PEs agree on the encapsulation type of the VPLS packets. ----End

Summary The sender and the receiver should agree on the encapsulation type of the VPLS packet. Otherwise, interworking between PEs cannot be realized.

Issue 02 (2011-09-10)


80


3 VLL Troubleshooting

3

VLL Troubleshooting

About This Chapter 3.1 The VC of Martini VLL Cannot Be Up 3.2 The VC of Kompella VLL Cannot Be Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VC of Kompella VLL cannot be Up. 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 This section provides a step-by-step troubleshooting procedure for the fault that a PW of Kompella VLL cannot be Up when the AC interfaces at both ends of the PW are Ethernet subinterfaces and adopt the tagged encapsulation type. 3.4 The VC Cannot Be Up When a Huawei Device Communicates with a Non-Huawei Device Through Kompella VLL This section provides a step-by-step troubleshooting procedure for the fault that the VC cannot be Up when a Huawei device communicates with a non-Huawei device through Kompella VLL. 3.5 Related Troubleshooting Cases

Issue 02 (2011-09-10)


81



3.1 The VC of Martini VLL Cannot Be Up 3.1.1 Common Causes This fault is commonly caused by one of the following: l

The encapsulation types of both ends of the VC are different.

l

The MTUs of both ends of the VC are different.

l

The VC IDs of both ends of the VC are different.

l

The control word configuration of both ends of the VC are different.

l

The LDP session is not Up.

l

The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public network tunnel.

l

The tunnel on the local or remote end is not Up.

l

The AC interface on the local or remote end is not Up.

3.1.2 Troubleshooting Flowchart The VC cannot be Up after Martini VLL is configured. Figure 3-1 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


82



Figure 3-1 Troubleshooting flowchart for the VC of Martini VLL failing to be Up A VC of Martini VLL cannot be Up

Encapsulation types of both ends the same?

No

Fault rectified?

End

Yes

End

No

Yes MTUs of both ends the same?

No

Fault rectified? No

Yes

VC IDs of both ends the same

No

Fault rectified?

Yes

End

No

Yes Control words of both ends the same

No

Fault rectified?

Yes

End

No

Yes No LDP session is Up?

Fault rectified?

Yes

End

No

Yes

Tunnel is Up?

No

Fault rectified?

Yes

End

No

Yes

AC interfaces are Up? Yes

Yes

No Fault rectified?

Yes

End


Issue 02 (2011-09-10)


83





Procedure Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU. Run the display mpls l2vc vc-id command to check VC information. display mpls l2vc 102 total LDP VC : 1 1 up *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

0 down

GigabitEthernet8/0/0.5 up up up 102 VLAN 2.2.2.2 146433 remote VC label : 146432 disable exist 0 not set active up 1500 remote VC MTU : 1500 ---primary 1 days, 1 hours, 14 minutes, 17 seconds 0 days, 0 hours, 3 minutes, 16 seconds 0 days, 0 hours, 3 minutes, 16 seconds 2010/02/17 08:23:07 0 days, 21 hours, 43 minutes, 43 seconds

If the two ends are configured with different encapsulation types or MTUs, change the encapsulation type or MTU of one end to be the same as that of the other end. If the two ends are configured with the same encapsulation type and MTU but the fault persists, go to Step 2. NOTE

A VC can be Up only when the two ends of the VC are configured with the same encapsulation type and MTU.

Step 2 Check that the VC IDs of both ends of the VC are the same. display mpls l2vc 102 total LDP VC : 1 1 up *client interface session state AC status VC state VC ID VC type destination local VC label control word

Issue 02 (2011-09-10)

: : : : : : : : :

0 down

GigabitEthernet8/0/0.5 up up up 102 VLAN 2.2.2.2 146433 remote VC label disable


: 146432

84



forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

exist 0 not set active up 1500 remote VC MTU : 1500 ---primary 1 days, 1 hours, 14 minutes, 17 seconds 0 days, 0 hours, 3 minutes, 16 seconds 0 days, 0 hours, 3 minutes, 16 seconds 2010/02/17 08:23:07 0 days, 21 hours, 43 minutes, 43 seconds

If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same as that of the other end. If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3. NOTE

A VC can be Up only when the VC IDs of both ends of the VC are the same.

Step 3 Check that the CWs configuration of both ends of the VC are the same. display mpls l2vc 102 total LDP VC : 1 1 up *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

0 down


If the CWs configuration of both ends of the VC are different, change the VC ID of one end to be the same as that of the other end. If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step 4. NOTE

A VC can be Up only when the CWs of both ends of the VC are the same.

Step 4 Check that the LDP session between the two ends is Up. display mpls l2vc 102 total LDP VC : 1 1 up

Issue 02 (2011-09-10)

0 down


85



*client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :


If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the LDP session Up. If the LDP session is Up but the fault persists, go to Step 5. NOTE

A VC can be set up only when the LDP session is Up.

Step 5 Check whether the PW has selected a tunnel. Run the display mpls l2vc vc-id command. l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW. l Check the tunnel policy name field in the command output. – If tunnel policy name is displayed as "-", it indicates that an LDP LSP is used as the tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for a PW only after a tunnel policy is configured. – If tunnel policy name is not displayed as "-", it indicates that a tunnel policy is adopted. In this case, you can run the display this command in the tunnel policy view to view the tunnel policy configuration. [HUAWEI-tunnel-policy-p1] display this # tunnel-policy p1 tunnel select-seq cr-lsp load-balance-number 1 #

If the tunnel is Down, see "An LSP Is Down" or "A TE Tunnel Is Down" to locate the fault and then turn the tunnel Up. If the tunnel is Up and the TE interfaces are correctly configured, go to Step 6. NOTE

A VC can be Up only when the tunnel that bears the VC is Up.

Step 6 Check that the AC interfaces on the two ends are Up. Issue 02 (2011-09-10)


86



Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC status field is displayed as Up. l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to locate the fault and turn the AC interfaces Up. l If the AC interfaces on the two ends are Up, go to Step 7. NOTE

A VC can be Up only when the AC interfaces on both ends of the VC are Up.



Relevant Logs None.

3.2 The VC of Kompella VLL Cannot Be Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the VC of Kompella VLL cannot be Up.



l


l

The CE-IDs of both ends are the same.

l

ce-offset of the local end is different from ce-id of the remote end.

l

The BGP session is not in the Established state.

l

The tunnel policy is incorrectly configured so that the TE tunnel cannot be adopted as the public network tunnel.

l

ce-id of the local end is greater than the sum of site-range and default-offset set on the remote end.

l


3.2.2 Troubleshooting Flowchart Issue 02 (2011-09-10)


87



The VC cannot be Up after Kompella VLL is configured. Figure 3-2 shows the troubleshooting flowchart. Figure 3-2 Troubleshooting flowchart for the VC of Kompella VLL failing to be Up A VC of KompellaVLL cannot be Up


No

Fault rectified?

Yes

No


No

Fault rectified?

Yes

No

Yes CE IDs of both ends the same?

No

Fault rectified?

Yes

No Yes Local CE offset the same as remote CE ID?

No

Fault rectified? No

Yes BGP session established？

No

Fault rectified?

Yes

No

Yes No Tunnel is Up?

Fault rectified?

Yes

No

Yes


Yes

No Fault rectified?

Yes


Issue 02 (2011-09-10)


End

88





Procedure Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU. display mpls l2vpn vpn1 VPN name: vpn1, encap type: ethernet, local ce number(s): 1, remote ce number(s): 1 route distinguisher: 100:1, MTU: 1500 import vpn target: 100:1, export vpn target: 100:1, remote vpn site(s) : no. remote-pe-id route-distinguisher 1 1.1.1.1 100:1

If the two ends are configured with different encapsulation types or MTUs, run the mpls l2vpn l2vpn-name encapsulation vc-type command in the system view to change the encapsulation type of one end to be the same as that of the other end, or run the mtu mtuvalue command in the MPLS-L2VPN instance view to change the MTU of one end to be the same as that of the other end. If the two ends are configured with the same encapsulation type and MTU but the fault persists, go to Step 2. NOTE


Step 2 Check whether ce-ids of both ends of the VC are the same. display mpls l2vpn connection interface GigabitEthernet 2/0/2.10 conn-type: remote local vc state: up remote vc state: up local ce-id: 2 local ce name: ce2 remote ce-id: 1 intf(state,encap): GigabitEthernet2/0/2.10(up,ethernet) peer id: 1.1.1.1 route-distinguisher: 100:1 local vc label: 179221 remote vc label: 179222 tunnel policy: default primary or secondary: primary forward entry exist or not: true forward entry active or not:true manual fault set or not: not set AC OAM state: up BFD for PW session index: -BFD for PW state: invalid BFD for LSP state: true Local C bit is not set Remote C bit is not set tunnel type: lsp tunnel id: 0x2008004

Issue 02 (2011-09-10)


89



If ce-ids of both ends are the same, run the ce ce-name id ce-id command to change ce-id of one end to be different from that of the other end. If ce-ids of both ends of the VC are different but the fault persists, go to Step 4. NOTE

ce-ids of the PW of Kompella VLL cannot be the same.

Step 3 Check whether ce-offset of the local end is the same as ce-id of the remote end. Check the configurations in the MPLS-L2VPN-CE view. [HUAWEI] mpls l2vpn vpn1 [HUAWEI-mpls-l2vpn-vpn1] display this # mpls l2vpn vpn1 encapsulation ppp route-distinguisher 100:1 vpn-target 100:1 import-extcommunity vpn-target 100:1 export-extcommunity ce ce1 id 2 range 10 default-offset 0 connection ce-offset 1 interface Pos1/0/0 # return

If ce-offset of the local end is different from ce-id of the remote end, run the undo connection ce-offset id command in the MPLS-L2VPN-CE view to delete the CE connection first, and then run the connection [ ce-offset id ] interface interface-type interface-number command in the MPLS-L2VPN-CE view to set ce-offset of the local end to be the same as ce-id of the remote end. If ce-offset of the local end is the same as ce-id of the remote end but the fault persists, go to Step 4. NOTE

A Kompella VLL can be set up only when ce-offset of the local end is the same as ce-id of the remote end.

Step 4 Check that the BGP session between the two ends is Established. Run the display bgp l2vpn peer [ ipv4-address verbose | verbose ] command to check the status of the BGP session. display bgp l2vpn peer BGP local router ID : 1.1.1.1 local AS number : 100 Total number of peers : 1 Peer PrefRcv

V

AS

1.25.1.3 Established

4

100

Peers in established state : 1 MsgRcvd

MsgSent

OutQ

Up/Down

13433

836

0

00:00:39

State

If the BGP session is not in the Established state, see "The BGP neighbor relationship cannot be established" to turn the BGP session to the Established state. If the BGP session is in the Established state but the fault persists, go to Step 4. NOTE

A Kompella VLL can be set up only when the BGP session is in the Established state.

Step 5 Check whether the VC has selected a tunnel. Run the display mpls l2vpn connection interface interface-type interface-number command. Issue 02 (2011-09-10)


90



l Check the tunnel id field in the command output. If tunnel id is displayed as 0x0, it indicates that no tunnel is adopted for the VC. l Check the tunnel policy field in the command output. If tunnel policy is displayed as default, it indicates that an LDP LSP is adopted as a VC or no tunnel policy is configured. An MPLS TE tunnel can be adopted as a PW only after a tunnel policy is configured. tunnel policy indicates the tunnel policy adopted by the VC. You can run the display this command in the tunnel policy view to view the tunnel policy configuration. [HUAWEI-tunnel-policy-p1] display this # tunnel-policy p1 tunnel select-seq cr-lsp load-balance-number 1 # NOTE

If the tunnel binding destination dest-ip-address te { tunnel interface-number } command is configured in the tunnel policy view, you also need to run the mpls te reserved-for-binding command on the tunnel interface.



Step 6 Check that ce-id of the local end is smaller than the sum of site-range and default-offset set on the remote end. Check the configurations in the MPLS-L2VPN-CE view. [HUAWEI] mpls l2vpn vpn1 [HUAWEI-mpls-l2vpn-vpn1] display this # mpls l2vpn vpn1 encapsulation ppp route-distinguisher 100:1 vpn-target 100:1 import-extcommunity vpn-target 100:1 export-extcommunity ce ce1 id 2 range 10 default-offset 0 connection ce-offset 1 interface Pos1/0/0 # return

If ce-id of the local end is not smaller than the sum of site-range and default-offset set on the remote end, run the ce ce-name [ id ce-id [ range ce-range ] [ default-offset ce-offset ] ] command to change ce-id of the local end or site-range of the remote end, ensuring that ce-id of the local end is smaller than the sum of site-range and default-offset set on the remote end. If ce-id of the local end is smaller than the sum of site-range and default-offset set on the remote end, and ce-id of the remote end is smaller than the sum of site-range and default-offset set on the local end, go to Step 7. Step 7 Check that the AC interfaces on the two ends are Up. Run the display mpls l2vpn connection interface interface-type interface-number command on the two ends to check whether the AC interfaces are Up. l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to locate the fault and turn the AC interfaces Up. l If the AC interfaces on the two ends are Up, go to Step 8. Issue 02 (2011-09-10)


91





Relevant Logs None.

3.3 A PW of Kompella VLL Cannot Be Up When the AC Interfaces at Both Ends of the PW Are Ethernet SubInterfaces and Adopt the tagged Encapsulation Type This section provides a step-by-step troubleshooting procedure for the fault that a PW of Kompella VLL cannot be Up when the AC interfaces at both ends of the PW are Ethernet subinterfaces and adopt the tagged encapsulation type.

3.3.1 Common Causes This fault is commonly caused by the following: l

The encapsulation type of the VPN instance is different from that of the PW.



Procedure Step 1 Check that the encapsulation type of the PW is the same as that of the VPN instance. Check the encapsulation type of the VPN instance. display mpls l2vpn vpn1 VPN name: vpn1, encap type: ethernet, local ce number(s): 1, remote ce number(s) : 1 route distinguisher: 100:1, MTU: 1500 import vpn target: 200:1, export vpn target: 200:1, remote vpn site(s) : no. remote-pe-id route-distinguisher 1 2.2.2.2 100:1

Issue 02 (2011-09-10)


92



Check the encapsulation type of the PW. display mpls l2vpn connection interface GigabitEthernet 8/0/0.13 conn-type: remote local vc state: up remote vc state: up local ce-id: 1 local ce name: ce1 remote ce-id: 2 intf(state,encap): GigabitEthernet8/0/0.13(up,ethernet) peer id: 2.2.2.2 route-distinguisher: 100:1 local vc label: 179222 remote vc label: 228373 tunnel policy: default primary or secondary: primary forward entry exist or not: true forward entry active or not:true manual fault set or not: not set AC OAM state: up BFD for PW session index: -BFD for PW state: invalid BFD for LSP state: true Local C bit is not set Remote C bit is not set tunnel type: lsp tunnel id: 0x4008018

The PW can be negotiated only when the encapsulation types of the PW and VPN instance are the same. If the encapsulation types of the PW and VPN instance are the same but the fault persists, contact Huawei technical support personnel. ----End


Relevant Logs None.

3.4 The VC Cannot Be Up When a Huawei Device Communicates with a Non-Huawei Device Through Kompella VLL This section provides a step-by-step troubleshooting procedure for the fault that the VC cannot be Up when a Huawei device communicates with a non-Huawei device through Kompella VLL.

3.4.1 Common Causes This fault is commonly caused by one of the following: Issue 02 (2011-09-10)


93



l

default-offset of a non-Huawei device is 1 and cannot be configured. When a Huawei device communicates with the non-Huawei device, default-offset of the Huawei device needs to be configured as 1 and the CE ID cannot be 0.

l

The ignore-mtu-match command is not configured in the MPLS-L2VPN instance view.



Procedure Step 1 Check that the ignore-mtu-match command is configured in the MPLS-L2VPN instance view. If the ignore-mtu-match command is not configured, configure this command. If the ignore-mtu-match command has already been configured, go to Step 2. NOTE

After using this command, when a Huawei device communicates with a non-Huawei device through Kompella VLL, they will not negotiate the MTUs.

Step 2 Check that default-offset of the Huawei device is 1. [HUAWEI] mpls l2vpn vpn1 [HUAWEI-mpls-l2vpn-vpn1] display this # mpls l2vpn vpn1 encapsulation ppp route-distinguisher 100:1 vpn-target 100:1 import-extcommunity vpn-target 100:1 export-extcommunity ce ce1 id 2 range 10 default-offset 1 connection ce-offset 1 interface Pos1/0/0 # return

If default-offset of the Huawei device is not 1, set it to 1. If default-offset of the Huawei device is 1 but the fault persists, contact Huawei technical personnel. ----End


Relevant Logs None.

3.5 Related Troubleshooting Cases Issue 02 (2011-09-10)


94



3.5.1 VC Under the Interface Is Missing After the Link Layer Protocol Changes Fault Symptom The configuration is as follows: # Configure MPLS L2VC on an interface on PE that connects the AC. The VC ID is 100. [PE-Pos4/0/0] mpls l2vc 1.1.1.8 100

# View the configuration of the interface. [PE-Pos4/0/0] display this # interface Pos4/0/0 link-protocol fr mpls l2vc 1.1.1.8 100 # return

# This interface has a VC. The VC ID is 100. [PE-Pos4/0/0] display mpls l2vc interface pos 4/0/0 *client interface : Pos4/0/0 is down session state : down AC state : down VC state : down VC ID : 100 VC type : fr destination : 1.1.1.8 local group ID : 0 remote group ID : 0 local VC label : 146433 remote VC label : 0 local AC OAM State : up local PSN State : up local forwarding state : not forwarding BFD for PW : unavailable manual fault : not set active state : active forwarding entry : not exist link state : down local VC MTU : 4470 remote VC MTU : 0 local VCCV : Disable remote VCCV : none local control word : disable remote control word : none tunnel policy name : -traffic behavior name : -PW template name : -primary or secondary : primary VC tunnel/token info : 0 tunnels/tokens create time : 0 days, 0 hours, 3 minutes, 24 seconds up time : 0 days, 0 hours, 0 minutes, 0 seconds last change time : 0 days, 0 hours, 3 minutes, 24 seconds VC last up time : 2009/04/07 16:19:26 VC total up time : 0 days, 0 hours, 12 minutes, 37 seconds

# Another interface on the PE also has a VC. The VC ID is also 100, whose link layer protocol is HDLC. [PE-Pos4/1/0] display mpls l2vc interface pos 4/1/0 *client interface : Pos4/1/0 is down session state : down AC state : down VC state : down VC ID : 100 VC type : hdlc

Issue 02 (2011-09-10)


95



destination local group ID local VC label local AC OAM State local PSN State local forwarding state BFD for PW manual fault active state forwarding entry link state local VC MTU local VCCV remote VCCV local control word tunnel policy name traffic behavior name PW template name primary or secondary VC tunnel/token info create time up time last change time VC last up time : VC total up time :

: 2.2.2.8 : 0 remote group ID : 0 : 146433 remote VC label : 0 : up : up : not forwarding : unavailable : not set : active : not exist : down : 4470 remote VC MTU : 0 : Disable : none : disable remote control word : none : -: -: -: primary : 0 tunnels/tokens : 0 days, 0 hours, 3 minutes, 24 seconds : 0 days, 0 hours, 0 minutes, 0 seconds : 0 days, 0 hours, 3 minutes, 24 seconds 2009/04/07 16:19:26 0 days, 0 hours, 12 minutes, 37 seconds

# Change the link layer protocol of POS 4/0/0 to HDLC. [PE-Pos4/0/0] link-protocol hdlc

# Re-check POS 4/0/0 and find that no VC exists. [PE-Pos4/0/0] display mpls l2vc interface pos 4/0/0

# Check all interfaces on PE and find that only one VC is left. This VC is on POS 4/1/0 whose link layer protocol is HDLC. [PE] display mpls l2vc Total ldp vc : 1 0 up

1 down

*client interface : Pos4/1/0 session state : down AC status : down VC state : down VC ID : 100 VC type : hdlc destination : 2.2.2.8 local VC label : 146433 remote VC label : 0 control word : disable forwarding entry : not exist local group ID : 0 manual fault : not set active state : active link state : down local VC MTU : 4470 remote VC MTU : 0 tunnel policy name : -traffic behavior name: -PW template name : -primary or secondary : primary create time : 0 days, 0 hours, 5 minutes, 45 seconds up time : 0 days, 0 hours, 0 minutes, 0 seconds last change time : 0 days, 0 hours, 5 minutes, 45 seconds VC last up time : 2009/04/07 16:19:26 VC total up time : 0 days, 0 hours, 12 minutes, 37 seconds

Fault Analysis An interface (POS 4/1/0 for example) on a PE has an HDLC-type PW with the PW ID as 100, and you change the link layer protocol of another interface (POS 4/0/0 for example) to HDLC. Issue 02 (2011-09-10)


96



Then the system will delete the PW under POS 4/0/0 automatically. The reason is that the two PWs have the same VC ID and the same VC type.

Procedure Step 1 If you need to change the link layer protocol of a VC, ensure that the changed PW ID and VC type are not the same as those of VCs on other interfaces of the same device. ----End

Summary The combination of VC ID and VC type must be unique on the same device. If a VC changes its link protocol type and this causes a conflict with other VCs, the VC will be automatically deleted.

3.5.2 Both the Session and the AC Are Up, But the VC Cannot Be Up Fault Symptom Figure 3-3 Networking diagram

PE1 GE1/0/0 10.1.1.2/24

PE2 GE2/0/0 100.1.1.2/24 GE2/0/0 100.1.1.1/24

GE1/0/0 10.1.1.1/24

GE1/0/0 10.1.1.1/24

GE1/0/0 10.1.1.2/24

CE1

CE2

As shown in Figure 3-3, the VC cannot go Up after Martini VLL is configured, and all parameters about the remote end are 0s, namely, invalid values. Check the session and the AC, and find both of them are Up.

Fault Analysis Use the display mpls l2vc vc-id command on the PE to check whether the MTU values at both ends are consistent. For example: # Check the MTU value of the GE interface on PE1. [PE1-GigabitEthernet1/0/0] display mpls l2vc 100 total LDP VC : 1 0 up 1 down *client interface session state

Issue 02 (2011-09-10)

: GigabitEthernet1/0/0 : up


97



AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

up down 100 ethernet 2.2.2.2 146433 remote VC label disable not exist 0 not set active down 80 remote VC MTU --pwt1 primary 0 days, 0 hours, 18 minutes, 0 days, 0 hours, 12 minutes, 0 days, 0 hours, 12 minutes, 2009/04/07 16:19:26 0 days, 0 hours, 12 minutes,

: 0

: 120

44 seconds 37 seconds 37 seconds 37 seconds

# View the MTU value of the GE interface on PE2. [PE2-GigabitEthernet1/0/0] display mpls l2vc 100 total LDP VC : 1 0 up 1 down *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

GigabitEthernet1/0/0 up up down 100 ethernet 1.1.1.1 146433 remote VC label disable not exist 0 not set active down 120 remote VC MTU --pwt1 primary 0 days, 0 hours, 18 minutes, 0 days, 0 hours, 12 minutes, 0 days, 0 hours, 12 minutes, 2009/04/07 16:19:26 0 days, 0 hours, 12 minutes,

: 0

: 80


The display shows that the MTU value of the local end is not consistent with that of the remote end, which leads to the parameter negotiation failure. Modify the MTU value on either PE to make the MTU values consistent at both ends. For example, change the MTU value of the interface on PE2 to make it consistent with that on PE1. [PE2-GigabitEthernet1/0/0] mtu 80 [PE2-GigabitEthernet1/0/0] shutdown [PE2-GigabitEthernet1/0/0] undo shutdown

After the modification, the VC goes Up. [PE2-GigabitEthernet1/0/0] display mpls l2vc 100 total LDP VC : 1 1 up 0 down

Issue 02 (2011-09-10)


98




GigabitEthernet1/0/0 up up up 100 ethernet 1.1.1.1 146433 remote VC label disable exist 0 not set active up 80 remote VC MTU ---primary 0 days, 0 hours, 43 minutes, 0 days, 0 hours, 37 minutes, 0 days, 0 hours, 37 minutes, 2009/04/07 16:19:26 0 days, 0 hours, 37 minutes,

: 146433

: 80


Procedure Step 1 Check whether the correct peer addresses are configured on PEs at both ends. Step 2 Check whether the VC IDs at both ends are the same. Step 3 Check whether the encapsulation types at both ends are the same. Step 4 Check whether the control word is enabled or disabled at both ends. Both ends must enable or disable the control word simultaneously. Step 5 Check whether the MTU values are consistent at both ends. Step 6 If inconsistency occurs, modify the MTU value on either end to ensure consistency. Step 7 Use the shutdown command and then the undo shutdown command on the modified interface. ----End

Summary PWE3 extends Martini interface parameters. Some of them must be supported, and others need not be supported. Some of them must be matched while others need not match during the negotiation. The following lists the Martini interface parameters.

Issue 02 (2011-09-10)

Code

Length

Description

0x01

4

Interface MTU in octets

0x02

4

Maximum Number of concatenated ATM cells

0x03

up to 82

Optional Interface Description string

0x04

4

CEM [8] Payload Bytes


99



Code

Length

Description

0x05

4

CEM options

The following shows the PWE3 interface parameters. Code

Length

Description

0x01

4

Interface MTU in octets

0x02

4

Maximum Number of concatenated ATM cells

0x03

Up to 82

Optional Interface Description string

0x04

4

CEP/TDM Payload Bytes

0x05

4

CEP options

0x06

4

Requested VLAN ID

0x07

6

CEP/TDM bit-rate

0x08

4

Frame-Relay DLCI Length

0x09

4

Fragmentation indicator

0x0A

4

FCS retention indicator

0x0B

4/8/12

TDM options

0x0C

4

VCCV parameter

Items from 0x06 to 0x0C are extended in PWE3. When configuring interface parameters, note the following: l

The same MTU must be specified for the Ethernet interface; otherwise, the PW cannot be Up.

l

In ATM cell (0x0003 ATM transparent cell transport, 0x0009 ATM n-to-one VCC cell transport and 0x000A ATM n-to-one VPC cell transport) mode, the maximum ATM cell number must be sent to the peer in order to inform the peer how many cells it can handle at a time. When the remote end encapsulates packets, this number should not be exceeded. Inconsistency of the cell number at both ends does not affect the status of a PW.

l

Fragmentation and ATM cell have the same handling mode. The configuration of fragmentation and ATM cell handling mode is optional and may not be consistent at both ends. The local end only informs the remote end whether it can perform reassembly. The remote end decides whether to fragment packets according to the packet size and its fragmentation capability. The fragmentation capability does not affect the status of a PW, and it is not necessary to be the same at both ends.

l

VCCV processing is similar to ATM cell and fragmentation capability. The VCCV configuration is optional. The local end uses VCCV to inform the remote end of its VCCV capability. When performing VCCV, the peer chooses a path (CC) and a method (CV)

Issue 02 (2011-09-10)


100



according to the configuration at both ends. VCCV does not affect the status of a PW, and is not required consistent at both ends. l

The Request VLAN ID is used to inform the peer of its capability. During the forwarding, the remote end is required to insert a VLAN ID on its Layer 2 frame header. Other means can also be used. This configuration is optional. If the Request VLAN ID is carried, the VLAN IDs can be different at both ends.

3.5.3 Ethernet and ATM are interconnected and the VC Is Up, But the Ping Between CEs Fails Fault Symptom Figure 3-4 Networking diagram of L2VPN in which Ethernet and ATM are connected

PE1

Backbone

GE1/0/0

GE1/0/0

PE2 ATM1/0/0

ATM1/0/0 CE2

CE1

As shown in Figure 3-4, Ethernet and ATM are interconnected. After L2VPN is configured to support heterogeneous transport, the VCs at both ends are Up, but the ping between CEs fails.

Fault Analysis Check and ensure that the IP address of the two CEs is on the same network segment. Use the display local-ce mac command on the PE, and use the display arp command on the CE to check whether the ARP entries of the Ethernet link are set up successfully. If ARP entries are not set up successfully, run the local-ce ip command, the local-ce mac command, or the local-ce mac broadcast command on the PE. In this manner, the IP address and the MAC address of the Ethernet interface on the CE can be configured on the PE, and MAC broadcasting function can be enabled. For detailed configuration, refer to heterogeneous transport in L2VPN described in the Chapter "MPLS L2VPN Configuration" in the HUAWEI NetEngine80E/40E Router Configuration Guide - VPN. For ARP entries of the ATM link, you can use one of the following methods: l

Use INARP to generate MAP dynamically. Figure 3-5 shows an example to configure IP addresses. The configuration is as follows. [PE2] interface atm1/0/0 [PE2-Atm1/0/0] pvc 100/200

Issue 02 (2011-09-10)


101



[PE2-atm-pvc-Atm1/0/0-100/200] [PE2-atm-pvc-Atm1/0/0-100/200] [CE2] interface atm1/0/0 [CE2-Atm1/0/0] pvc 100/200 [CE2-atm-pvc-Atm1/0/0-100/200] [CE2-atm-pvc-Atm1/0/0-100/200]

map ip inarp broadcast ip address 10.1.1.1 255.255.255.0 map ip inarp broadcast ip address 10.1.1.2 255.255.255.0

Figure 3-5 Networking diagram of IP addressing

PE1 GE1/0/0 10.1.1.2/24

PE2 Backbone

GE1/0/0 10.1.1.1/24

ATM1/0/0 10.1.1.1/24 ATM1/0/0 10.1.1.2/24

CE1

l

CE2

The static MAP is used. Configure the map ip peer-ce-address broadcast command or the map ip default broadcast command in the PVC view of the ATM interfaces at both ends of the AC. For example: [PE2] interface atm1/0/0 [PE2-Atm1/0/0] pvc 100/200 [PE2-atm-pvc-Atm1/0/0-100/200] [PE2-atm-pvc-Atm1/0/0-100/200] [CE2] interface atm1/0/0 [CE2-Atm1/0/0] pvc 100/200 [CE2-atm-pvc-Atm1/0/0-100/200] [CE2-atm-pvc-Atm1/0/0-100/200]

map ip 10.1.1.2 broadcast ip address 10.1.1.1 255.255.255.0 map ip 10.1.1.1 broadcast ip address 10.1.1.2 255.255.255.0

Procedure Step 1 Check whether the IP address of CE at both ends is on the same network segment. Step 2 Run the display local-ce mac command on the PE, and run the display arp command on the CE to check whether ARP entries of the Ethernet link are set up successfully. Step 3 If ARP entries are not set up successfully, configure an IP address and MAC address for the Ethernet interface at the AC side and enable MAC broadcasting on the PE. For the ATM link, use INARP to generate MAP dynamically or use the static MAP. ----End

Summary In the application of heterogeneous transport, if the VC is Up but the ping between CEs fails, the cause is often the configuration error. You should perform configuration according to the link type to ensure that ARP entries can be generated correctly. Issue 02 (2011-09-10)


102



3.5.4 CEs Cannot Communicate by Using the Accessing Mode of VLAN Fault Symptom CEs adopt the accessing mode of VLAN. After the VLAN ID is changed, CEs on two ends cannot communicate.

Fault Analysis To modify the VLAN ID, you need to modify VC IDs of the AC interfaces along the packetsending direction in turn. To validate the modification, run the shutdown command and then the undo shutdown command on each VLAN interface.

Procedure Step 1 Use the vlan-type dot1q command on the AC interfaces along CE-to-PE direction, and then PE-to-CE direction to modify the VLAN ID. Step 2 Use the shutdown command to disable the AC interfaces. Step 3 Use the undo shutdown command to enable the AC interfaces. ----End

Summary When the VLAN access is adopted between CE and PE, the minimum VLAN IDs of interfaces on both ends of the AC that the packet passes by must be the same. Otherwise, the packet cannot be forwarded normally. The minimum VLAN IDs of the CE interfaces on both ends of the tunnel can be different.

3.5.5 CEs Cannot Access Each Other Though the Static VC Is Up Fault Symptom After the static VC is configured, the static VC is Up. CEs, however, CEs cannot access each other. For example: [PE1] display mpls static-l2vc Total svc connections: 1, 1 up, 0 down *Client Interface : GigabitEthernet2/0/1 is up AC Status : up VC State : up VC ID : 0 VC Type : ethernet Destination : 2.2.2.2 Transmit VC Label : 200 Receive VC Label : 100 Control Word : Disable VCCV Capability : alert lsp-ping bfd Tunnel Policy Name : -Traffic Behavior : -PW Template Name : -Main or Secondary : Main

Issue 02 (2011-09-10)


103



Create time : 0 days, 0 hours, 0 minutes, 17 seconds UP time : 0 days, 0 hours, 0 minutes, 17 seconds Last change time : 0 days, 0 hours, 0 minutes, 17 seconds VC last up time : 2008/07/24 12:31:31 VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds CKey : 6 NKey : 3

Fault Analysis Check the label of the static VC on the remote PE: [PE2] display mpls static-l2vc Total svc connections: 1, 1 up, 0 down *Client Interface : GigabitEthernet1/0/1 is up AC Status : up VC State : up VC ID : 0 VC Type : ethernet Destination : 1.1.1.1 Transmit VC Label : 200 Receive VC Label : 100 Control Word : Disable VCCV Capability : alert lsp-ping bfd Tunnel Policy Name : -Traffic Behavior : -PW Template Name : -Main or Secondary : Main Create time : 0 days, 0 hours, 0 minutes, 17 seconds UP time : 0 days, 0 hours, 0 minutes, 17 seconds Last change time : 0 days, 0 hours, 0 minutes, 17 seconds VC last up time : 2008/07/24 12:31:31 VC total up time: 0 days, 2 hours, 12 minutes, 51 seconds

You can see that the label configuration on the local PE is different from that on the remote PE. CEs can communicate after the following configuration: [PE1-GigabitEthernet2/0/1] mpls static-l2vc destination 2.2.2.2 transmit-vpn-label 100 receive-vpn-label 200

Procedure Step 1 Delete the static VC on one end and reconfigure it. ----End

Summary When the label of the static VC is incorrect, the data cannot be forwarded normally even though the VC is Up. In this case, you should pay attention to the consistency of labels at both ends of a VC. When configuring the static VC, note the following: l

The local transmit-vpn-labe is the same as the remote receive-vpn-label.

l

The local receive-vpn-label is the same as the remote transmit-vpn-label.

Issue 02 (2011-09-10)


104



3.5.6 Large Packets Are Lost in the Transmission Between CEs at Both Ends of L2VPN Fault Symptom After an L2VPN is set up between CEs, some large packets are lost in the transmission.

Fault Analysis The packets can be transmitted between CEs, but some may be lost. The cause may be the fragmentation, which occurs when the MTUs of the outgoing interfaces that packets pass by are smaller than the MTU of the source interface.

Procedure Step 1 Use the display interface command on the source interface to check the MTU. Step 2 Use the display interface command on the PEs that packets pass by to check whether there are outgoing interfaces whose MTUs is smaller than the MTU of the source interface. Step 3 Use the mtu command in the AC interface view on CE or in the outgoing interface view on PE to increase the MTU value, and thus ensure the packet sent by CE is not fragmented. ----End

Summary When CEs are connected through the L2VPN, the sent packet passing through PEs cannot be fragmented. Otherwise, the packet cannot be received normally.

3.5.7 Failed to Establish the MPLS LDP Session Between PEs When Using RIP-1 in the L2VPN Backbone Network Fault Symptom Figure 3-6 Networking diagram of the L2VPN backbone adopting RIP as IGP



POS2/0/0 POS2/0/0 100.1.1.1/24 100.1.1.2/24 PE-A

POS1/0/0

POS1/0/0

POS1/0/0 10.1.1.1/24

POS1/0/0 10.1.1.2/24

CE-A

Issue 02 (2011-09-10)

POS3/0/0 1.1.2.3/16 PE-B

POS3/0/0 1.1.2.4/16

P

CE-B


105



NOTE

IGP is short for the Interior Gateway Protocol.

After the L2VPN backbone network running RIP-1 advertises the local loopback0 address and the interface IP address, the MPLS LDP session between PEs cannot be set up. The prompt on PE-A is as follows: Del Session : EncdecEncode ldp notify msg failure.

Check the MPLS LDP session on PE-A. The display is as follows: [PE-A] display mpls ldp session LDP Session(s) in Public Network Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM) A '*' before a session means the session is being deleted. -----------------------------------------------------------------------------PeerID Status LAM SsnRole SsnAge KASent/Rcv -----------------------------------------------------------------------------2.2.2.2:0 NonExistent Passive 0/0 -----------------------------------------------------------------------------TOTAL: 0 session(s) Found.

The prompt on PE-B is as follows: Del Session : Tcp connection down

Check the MPLS LDP session on PE-B. The display is as follows: [PE-A] display mpls ldp session LDP Session(s) in Public Network Codes: LAM(Label Advertisement Mode), SsnAge Unit(DDDD:HH:MM) A '*' before a session means the session is being deleted. -----------------------------------------------------------------------------PeerID Status LAM SsnRole SsnAge KASent/Rcv -----------------------------------------------------------------------------1.1.1.1:0 Initialized Active 0/0 -----------------------------------------------------------------------------TOTAL: 0 session(s) Found.

Fault Analysis Check the routing table on PE-B. The display is as follows: [PE-B] display ip routing-table Route Flags: R - relay, D - download to fib -----------------------------------------------------------------------------Routing Tables: Public Destinations : 10 Routes : 10 Destination/Mask Proto Pre Cost NextHop Interface 1.0.0.0/8 RIP 100 1 100.1.1.1 Pos2/0/0 1.1.0.0/16 Direct 0 0 1.1.2.3 Pos3/0/0 1.1.2.3/32 Direct 0 0 127.0.0.1 InLoopBack0 1.1.2.4/32 Direct 0 0 1.1.2.4 Pos3/0/0 2.2.2.2/32 Direct 0 0 127.0.0.1 InLoopBack0 100.1.1.0/24 Direct 0 0 100.1.1.2 Pos2/0/0 100.1.1.2/32 Direct 0 0 127.0.0.1 InLoopBack0 127.0.0.0/8 Direct 0 0 127.0.0.1 InLoopBack0 127.0.0.1/32 Direct 0 0 127.0.0.1 InLoopBack0

RIP-1 can identify only the route of the natural network segment such as class A, B, and C. In the routing table of PE-B, there are two routes to peer 1.1.1.1. l

The IP address 1.0.0.0/8 learned by RIP-1.

l

The IP address 1.1.0.0/16 directly connected with PE-B.

Issue 02 (2011-09-10)


106



According to the "longest match" rule, the packet is sent to POS 3/0/0 whose IP address is 1.1.0.0/16. In the network segment connected with POS 3/0/0, the loopback address 1.1.1.1/32 does not exist. Therefore, the MPLS LDP session cannot be set up.

Procedure Step 1 Replace RIP-1 with RIP-2 to advertise the 32-bit loopback address. This address serves as the MPLS LDP session address on the PE. ----End

Summary RIP-1 can only identify the route of the natural network segment such as class A, B, and C. Therefore, RIP-2 should be adopted to advertise the 32-bit loopback address of PE.

Issue 02 (2011-09-10)


107


4 PWE3 Troubleshooting

4

PWE3 Troubleshooting

About This Chapter This chapter describes common causes of PWE3 faults and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs. 4.1 The PW Cannot Be Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the PW of PWE3 cannot be Up. 4.2 Related Troubleshooting Cases

Issue 02 (2011-09-10)


108



4.1 The PW Cannot Be Up This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that the PW of PWE3 cannot be Up.



l


l

The VC IDs of both ends of the VC are different.

l

The control word configuration of both ends of the VC are different.

l

The LDP session is not Up.

l

The tunnel policy is incorrectly configured so that the TE tunnel is not adopted as the public network tunnel.

l

The tunnel on the local or remote end is not Up.

l


4.1.2 Troubleshooting Flowchart The VC cannot be Up after Martini VLL is configured. Figure 4-1 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


109



Figure 4-1 Troubleshooting flowchart for the VC of Martini VLL failing to be Up A VC of Martini VLL cannot be Up


No

Fault rectified?

End

Yes

End

No


No

Fault rectified? No

Yes

VC IDs of both ends the same

No

Fault rectified?

Yes

End

No

Yes Control words of both ends the same

No

Fault rectified?

Yes

End

No

Yes No LDP session is Up?

Fault rectified?

Yes

End

No

Yes

Tunnel is Up?

No

Fault rectified?

Yes

End

No

Yes


Yes

No Fault rectified?

Yes

End


Issue 02 (2011-09-10)


110





Procedure Step 1 Check that the two ends of the VC are configured with the same encapsulation type and MTU. Run the display mpls l2vc vc-id command to check VC information. display mpls l2vc 102 total LDP VC : 1 1 up *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

0 down


If the two ends are configured with different encapsulation types or MTUs, change the encapsulation type or MTU of one end to be the same as that of the other end. If the two ends are configured with the same encapsulation type and MTU but the fault persists, go to Step 2. NOTE


Step 2 Check that the VC IDs of both ends of the VC are the same. display mpls l2vc 102 total LDP VC : 1 1 up *client interface session state AC status VC state VC ID VC type destination local VC label control word

Issue 02 (2011-09-10)

: : : : : : : : :

0 down

GigabitEthernet8/0/0.5 up up up 102 VLAN 2.2.2.2 146433 remote VC label disable


: 146432

111



forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

exist 0 not set active up 1500 remote VC MTU : 1500 ---primary 1 days, 1 hours, 14 minutes, 17 seconds 0 days, 0 hours, 3 minutes, 16 seconds 0 days, 0 hours, 3 minutes, 16 seconds 2010/02/17 08:23:07 0 days, 21 hours, 43 minutes, 43 seconds

If the VC IDs of both ends of the VC are different, change the VC ID of one end to be the same as that of the other end. If the VC IDs of both ends of the VC are the same but the fault persists, go to Step 3. NOTE

A VC can be Up only when the VC IDs of both ends of the VC are the same.

Step 3 Check that the CWs configuration of both ends of the VC are the same. display mpls l2vc 102 total LDP VC : 1 1 up *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

0 down


If the CWs configuration of both ends of the VC are different, change the VC ID of one end to be the same as that of the other end. If the CWs configuration of both ends of the VC are the same but the fault persists, go to Step 4. NOTE

A VC can be Up only when the CWs of both ends of the VC are the same.

Step 4 Check that the LDP session between the two ends is Up. display mpls l2vc 102 total LDP VC : 1 1 up

Issue 02 (2011-09-10)

0 down


112





If the LDP session is Down, see "An LDP Session Is Down" to locate the fault and then turn the LDP session Up. If the LDP session is Up but the fault persists, go to Step 5. NOTE

A VC can be set up only when the LDP session is Up.

Step 5 Check whether the PW has selected a tunnel. Run the display mpls l2vc vc-id command. l Check the VC tunnel/token info field in the command output. If VC tunnel/token info is displayed as 0 tunnels/tokens, it indicates that no tunnel is selected by a PW. l Check the tunnel policy name field in the command output. – If tunnel policy name is displayed as "-", it indicates that an LDP LSP is used as the tunnel for a PW or no tunnel policy is configured. An MPLS TE tunnel can be used for a PW only after a tunnel policy is configured. – If tunnel policy name is not displayed as "-", it indicates that a tunnel policy is adopted. In this case, you can run the display this command in the tunnel policy view to view the tunnel policy configuration. [HUAWEI-tunnel-policy-p1] display this # tunnel-policy p1 tunnel select-seq cr-lsp load-balance-number 1 #



Step 6 Check that the AC interfaces on the two ends are Up. Issue 02 (2011-09-10)


113



Run the display mpls l2vc vc-id command on both ends of the VC to check whether the AC status field is displayed as Up. l If the AC interfaces on the two ends are Down, see "Physical Interface Interconnection" to locate the fault and turn the AC interfaces Up. l If the AC interfaces on the two ends are Up, go to Step 7. NOTE

A VC can be Up only when the AC interfaces on both ends of the VC are Up.



Relevant Logs None.

4.2 Related Troubleshooting Cases 4.2.1 PW Attributes Cannot Be Changed by Using the reset pw Command Fault Symptom After a PW is configured on a PE, change PW attributes. Use the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type command. You find that PW attributes are unchanged. # Check the configuration of the PW template on PE. [PE] display pw-template pwt1 PW Template Name : pwt1 PeerIP : 1.1.1.1 Tnl Policy Name : -CtrlWord : Disable MTU : 1500 Max Atm Cells : 28 ATM Pack Overtime: 1000 Seq-Number : Disable TDM Encapsulation Number: 32 Jitter-Buffer : 20 Idle-Code : ff Rtp-Header : Disable VCCV Capability : alert lsp-ping bfd

Issue 02 (2011-09-10)


114



Behavior Name Total PW

: -: 1, Static PW : 0, LDP PW : 1

# Configure a PW by applying the PW template. [PE-Atm2/1/0.100] mpls l2vc pw-t pwt1 2.2.2.2 100

# View the PW configuration. [PE-Atm2/1/0.100] display mpls l2vc 100 total LDP VC : 1 0 up 1 down *client interface : session state : AC status : VC state : VC ID : VC type : destination : local VC label : control word : forwarding entry : local group ID : manual fault : active state : link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

Atm2/1/0.100 down up down 100 atm aal5 sdu 2.2.2.2 146433 remote disable not exist 0 not set active down 1500 remote --pwt1 primary 0 days, 0 hours, 18 0 days, 0 hours, 12 0 days, 0 hours, 12 2009/04/07 16:19:26 0 days, 0 hours, 12

VC label

: 0

VC MTU

: 0

minutes, 44 seconds minutes, 37 seconds minutes, 37 seconds minutes, 37 seconds

# Specify a new peer address for the PW in the PW template. [PE] pw-template pwt1 [PE-pw-template-pwt1] peer-address 3.3.3.3 Info: The attribute of this PW template has been modified, please use PW restart command to update PW's attribute

According to the prompt, do as follows. [PE-pw-template-pwt1] return

# Reset the PW. reset pw 100 atm-aal5-sdu

# View the output, and find that the peer IP address of the PW is unchanged. display mpls l2vc 100 total LDP VC : 1 0 up *client interface session state AC status VC state VC ID VC type destination local VC label control word forwarding entry local group ID manual fault active state

Issue 02 (2011-09-10)

: : : : : : : : : : : : :

1 down

Atm2/1/0.100 down up down 100 atm aal5 sdu 2.2.2.2 146433 remote VC label disable not exist 0 not set active


: 0

115



link state : local VC MTU : tunnel policy name : traffic behavior name: PW template name : primary or secondary : create time : up time : last change time : VC last up time : VC total up time :

down 1500 remote --pwt1 primary 0 days, 0 hours, 18 0 days, 0 hours, 12 0 days, 0 hours, 12 2009/04/07 16:19:26 0 days, 0 hours, 12

VC MTU

: 0

minutes, 44 seconds minutes, 37 seconds minutes, 37 seconds minutes, 37 seconds

# Reset the PW template. reset pw pw-template pwt1

# View the output, and find that the peer IP address of the PW still does not change. display mpls l2vc 100 Total ldp vc : 1 0 up 1 down *Client Interface : Atm2/1/0.100 Session State : down AC Status : up VC State : down VC ID : 1 VC Type : atm aal5 sdu Destination : 2.2.2.2 Local VC Label : 119811 Remote VC Label : 0 Control Word : Disable Local VC MTU : 1500 Remote VC MTU : 0 Tunnel Policy Name : -Traffic Behavior Name: -PW Template Name : pwt1 Create time : 0 days, 0 hours, 1 minutes, 7 seconds UP time : 0 days, 0 hours, 0 minutes, 0 seconds Last change time : 0 days, 0 hours, 1 minutes, 7 seconds

Fault Analysis Some PW attributes can be configured by using the PW template or by using the CLI command. However, the latter method has the higher priority. If PW attributes are specified in the CLI, then those specified in the PW template are invalid. The PW attributes do not change if the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type commands are run. In this case, you can use the PW template to set PW attributes, rather than using the CLI command. Do as follows: # Specify the peer IP address in the PW template. [PE] pw-template pwt1 [PE-pw-template-pwt1] peer-address 3.3.3.3 [PE-pw-template-pwt1] quit

# Apply the template to the PW. [PE] interface atm 2/1/0.100 [PE-Atm2/1/0.100] mpls l2vc pw-t pwt1 100

# View the output, and find that the IP address of the PW peer is unchanged. [PE-Atm2/1/0.100] display mpls l2vc 100 Total ldp vc : 1 0 up 1 down *Client Interface : Atm2/1/0.100 Session State : down

Issue 02 (2011-09-10)


116



AC Status : up VC State : down VC ID : 1 VC Type : atm aal5 sdu Destination : 2.2.2.2 Local VC Label : 119811 Remote VC Label : 0 Control Word : Disable Local VC MTU : 1500 Remote VC MTU : 0 Tunnel Policy Name : -Traffic Behavior Name: -PW Template Name : pwt1 Create time : 0 days, 0 hours, 0 minutes, 4 seconds UP time : 0 days, 0 hours, 0 minutes, 0 seconds Last change time : 0 days, 0 hours, 0 minutes, 4 seconds [PE-Atm2/1/0.100] return reset pw 100 atm-aal5-sdu

# View the output, and find that the IP address of the PW peer changes. display mpls l2vc 100 Total ldp vc : 1 0 up 1 down *Client Interface : Atm2/1/0.100 Session State : down AC Status : up VC State : down VC ID : 100 VC Type : atm aal5 sdu Destination : 3.3.3.3 Local VC Label : 119811 Remote VC Label : 0 Control Word : Disable Local VC MTU : 1500 Remote VC MTU : 0 Tunnel Policy Name : -Traffic Behavior Name: -PW Template Name : pwt1 Create time : 0 days, 0 hours, 0 minutes, 53 seconds UP time : 0 days, 0 hours, 0 minutes, 0 seconds Last change time : 0 days, 0 hours, 0 minutes, 53 seconds

Procedure Step 1 Create a PW template, and set PW attributes (especially those needing changes) on it. Step 2 Apply the PW template to the PW. Step 3 Run the reset pw pw-template pw-template-name command or the reset pw pw-id pw-type command in the user view to modify PW attributes. ----End

Summary The reset pw pw-template pw-template-name command or the reset pw pw-id pw-type command can only change the attributes that are set by the PW template.

4.2.2 VPN Services Between Two PEs Are Unavailable Fault Symptom PWE3 internetworking is configured in a test, as shown in Figure 4-2. Issue 02 (2011-09-10)


117



Figure 4-2 PWE3 internetworking

MPLS Backbone Loopback0 1.1.1.9/32


POS2/0/0 100.1.1.1/24 POS1/0/0 100.1.1.2/24 PE1 GE1/0/0.1

P PW


POS2/0/0 100.2.1.2/24 POS2/0/0 100.2.1.1/24 POS1/0/0

GE1/0/0.1 10.1.1.1/24

PE2

POS1/0/0 10.1.1.2/24

CE2

CE1

After the configuration, CE2 can receive data from CE1, but CE1 cannot receive data from CE2.

Fault Analysis 1.

Run the ping vc command to check whether the VC between the two PEs can normally forward data. You can find that the VC between the two PEs can forward packets normally. ping vc ip-interworking 100 control-word remote 100 Reply: bytes=100 Sequence=1 time = 11 ms Reply: bytes=100 Sequence=2 time = 4 ms Reply: bytes=100 Sequence=3 time = 4 ms Reply: bytes=100 Sequence=4 time = 4 ms Reply: bytes=100 Sequence=5 time = 4 ms --- FEC: FEC 128 PSEUDOWIRE (NEW). Type = ethernet, ID = 100 ping statistics--5 packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 4/5/11 ms

2.

Run the tracert command. You can find that CE2 can normally receive packets from CE1 and all packets sent by CE1 can reach PE1. This indicates that the fault occurs on the link between PE1 and CE1.

3.

Run the display this command on GE 1/0/0.1 of PE1 to view the configuration of the AC interface. You can find that the local-ce ip and local-ce mac commands are not used.

Procedure Step 1 Run the system-view command to enter the system view. Step 2 Run the interface interface-type interface-number command to enter the AC interface view of PE1. Step 3 Run the local-ce ip ip-address command to configure the IP address of the local CE interface, or run the local-ce mac mac-address command to configure the MAC address of the local CE interface. Issue 02 (2011-09-10)


118



After the preceding configurations, the local CE can ping through the remote CE. The fault is thus rectified. ----End

Summary When configuring PWE3 internetworking, you need to run the local-ce ip command or the localce mac command to configure the MAC address or IP address for the CE interface if the AC interface of the related PE is an Ethernet interface. For PWE3 internetworking, a CE and a PE can directly negotiate with each other. When the AC interface is an Ethernet interface, the negotiation between the CE and the PE is the process of learning MAC addresses from each other. When PE1 sends packets to CE1, PE1 must know the MAC address of the CE1 interface. You can run the local-ce mac command to configure the address of the directly connected interface on PE1 as the MAC address of the CE1 interface. When sending a packet, PE1 encapsulates the MAC address in the packet. You can also run the local-ce ip command to configure the AC interface address of PE1 as the IP address of the CE1 interface. PE1 thus can learn the MAC address of the CE1 interface through the IP address.

4.2.3 Failed to Establish OSPF Neighborhood Between CEs Fault Symptom As shown in Figure 4-3, CE1 is dual-homed to PE1 and PE2; CE2 is dual-homed to PE3 and PE4. l

CE1 and CE2 are connected to PEs through Frame Relay (FR).

l

PWs are set up between PE1 and PE3, and between PE2 and PE4, using MPLS LSPs as the tunnel.

l

When the path CE2 - PE3 - P - PE1 - CE1 fails, L2VPN traffic can be fast switched to the backup path CE2 - PE4 - PE2 - CE1.

l

When the path CE2 - PE3 - P - PE1 - CE1 recovers, L2VPN traffic can be switched back to this path.

Virtual Leased Line Fast Reroute (VLL FRR) symmetric networking is deployed on PEs; 128 sub-interfaces with different IP addresses are created on CEs. Open Shortest Path First (OSPF) is run on CE1 and CE2 to advertise the IP addresses of the sub-interfaces to each other. The problem is that the status of most neighborhood cannot be Full on CEs and CEs cannot communicate. Figure 4-3 Symmetric VLL FRR networking

PE1

P1 GE2/0/0 GE1/0/0

POS1/0/0

PE3 GE2/0/0 GE2/0/0

POS1/0/0 POS1/0/0

POS1/0/0 CE1

CE2

POS1/0/1

PE2

POS1/0/0

Issue 02 (2011-09-10)

P2 GE2/0/0 GE1/0/0

PE4 GE2/0/0 GE2/0/0


POS1/0/1 POS1/0/0

119



Fault Analysis The MTU of Ethernet interfaces on CEs is set to 4470. The type of the links connecting PEs and Ps are Ethernet and hence the maximum MTU is 1500. Therefore, when a large number OSPF neighbors are configured on CEs, the size of an OSPF packet is larger than 1500. VLL does not support packet fragmentation. Therefore, the large packets from CEs are discarded when they are forwarded through the VLL between PEs and Ps. In this way, OSPF neighborhood cannot be set up between CEs.

Procedure Step 1 Run the system-view command to enter the system view. Step 2 Run the interface interface-type interface-number.subinterface-number command to enter the AC sub-interface view. Step 3 Run the mtu mtu command to configure the MTU of the sub-interface. Step 4 Run the shutdown command to close the current sub-interface. Step 5 Run the undo shutdown command to start the current sub-interface. After the preceding configurations, OSPF neighborhood can be established between CEs and the fault is rectified. ----End

Summary L2VPN does not support packet fragmentation. So, large packets sent from the CE to the PE cannot be forwarded to the PSN side. When configuring VLL, you are recommended to set the MTU value of the interface connecting the CE to the PE to 1500 by using the mtu command. As a result, larger packets sent by the CE to the PE are fragmented first. The fragmented packets can be correctly forwarded in the public network.

Issue 02 (2011-09-10)


120


5

5 L2VPN IP RAN Troubleshooting

L2VPN IP RAN Troubleshooting

About This Chapter This chapter describes common causes of L2VPN IP RAN faults and provides the corresponding troubleshooting flowcharts, troubleshooting procedures, alarms, and logs. 5.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS + L3VPN/IP This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost or duplicate packets are received on the CSG in an IP RAN with the networking of HVPLS + L3VPN/IP. 5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/ Secondary PW Switchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN) This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost, duplicate packets are received, or traffic is interrupted on the CSG after a primary/secondary PW switchover is performed on a back-to-back (BTB) IP RAN with the networking of PWE3 + (VSI + L3VPN). 5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS + L3VPN This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost or traffic is interrupted on the CSG after a primary/ secondary PW switchover or switchback is performed on a BTB IP RAN with the networking of HVPLS + L3VPN. 5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy + APS 1:1 Mode with TDM/ATM Base Stations This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that L2VPN traffic is interrupted after AC switchover on the IP RAN in PW redundancy + APS 1:1 mode with TDM/ATM base stations. 5.5 Trouble Cases

Issue 02 (2011-09-10)


121



5.1 Packets Are Lost or Duplicate Packets Are Received on an Integrated IP RAN with the Networking of HVPLS + L3VPN/IP This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost or duplicate packets are received on the CSG in an IP RAN with the networking of HVPLS + L3VPN/IP.


The parameter ignore-standby-state is not configured when the VPLS PW is configured on the SR or PE-AGG.

l

The primary and secondary PWs on the CSG are both enabled to receive packets.

5.1.2 Troubleshooting Flowchart After an IP RAN with the networking of HVPLS + L3VPN/IP is configured, packets are lost or duplicate packets are received on the IP RAN. Figure 5-1 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


122



Figure 5-1 Troubleshooting flowchart for the fault that packets are lost or duplicate packets are received on the IP RAN with the networking of HVPLS + L3VPN/IP Packet loss or duplicate packets found on the IP RAN (HVPLS)

Is the PW on the SR/PEAGG configured to ignore the secondary state?

No

Configure the PW on the SR/PE-AGG to ignore the secondary state sent from the peer

End

Disable this function on the CSG

End

Yes

Are primary and secondary PWs on the CSG both enabled to receive packets?

Yes

No




Procedure Step 1 Check fault symptoms. l If packets are lost, go to Step 2. l If duplicate packets are received, go to Step 3. Step 2 Check that the parameter ignore-standby-state is configured when the VPLS PW is configured on the SR or PE-AGG. Run the display this command in the VSI-LDP view to check whether the parameter ignorestandby-state has been configured for the PW. l If the parameter has not been configured, run the undo peer peer-address [ negotiation-vcid vc-id ] command in the VSI-LDP view to delete the PW. After that, run the peer peerIssue 02 (2011-09-10)


123



address [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignore-standby-state command to create a new VPLS PW and configure it to ignore the secondary state sent from the peer. NOTE

l After the old VPLS PW is deleted, services will be temporarily interrupted until a new VPLS PW is completely configured. l In the scenario where PW redundancy in master/slave mode is configured, traffic will be switched to the secondary PW if the primary PW becomes faulty. If the PW on the SR or PE-AGG is not configured to ignore the secondary state sent from the CSG peer, the PW on the local end (local PW for short) will not forward traffic. The local PW starts to forward traffic after the peer switches from the secondary state to the primary state and sends the new state to the local end. During this process, data packets are probably lost. To prevent this problem, configure ignore-standbystate when configuring a PW on the SR or PE-AGG. This enables the PW to ignore the secondary state sent from the peer and allows the PW to remain in the forwarding state in the primary/ secondary PW switchover.

l If the parameter ignore-standby-state has been configured for the PW, go to Step 2. Step 3 Check that the primary and secondary PWs on the CSG are not both enabled to receive packets. Run the display this command in the view of the AC interface on the CSG to check whether the mpls l2vpn stream-dual-receiving command has been run. l If the mpls l2vpn stream-dual-receiving command has been run, run the undo mpls l2vpn stream-dual-receiving command in the AC interface view to delete the configuration. NOTE

The mpls l2vpn stream-dual-receiving command can only be run in a PWE3 L2VPN to prevent packet loss during PW state synchronization. If an L2VPN uses H-VPLS, the mpls l2vpn stream-dualreceiving command cannot be run. This is because VPLS broadcast will cause a base station to receive double data packets.

l If the primary and secondary PWs on the CSG are not both enabled to receive packets, go to Step 3. Step 4 Collect the following information and contact Huawei technical support personnel. l Results of the preceding troubleshooting procedures l Configuration files, log files, and alarm files of the device ----End


Relevant Logs None.

Issue 02 (2011-09-10)


124



5.2 Packets Are Lost, Duplicate Packets Are Received, or Traffic Is Interrupted After a Primary/Secondary PW Switchover on a BTB IP RAN with the Networking of PWE3 + (VSI + L3VPN) This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost, duplicate packets are received, or traffic is interrupted on the CSG after a primary/secondary PW switchover is performed on a back-to-back (BTB) IP RAN with the networking of PWE3 + (VSI + L3VPN).

5.2.1 Common Causes This fault is commonly caused in one of the following situations: l

The PW on the PE-AGG is not configured to ignore the secondary state sent from the peer.

l

The primary and secondary PWs on the CSG are both enabled to receive packets.

l

No Spoke PW is configured between UPE1 and UPE2.

l

The downlink interface tracked by VRRP is not switched to a Layer 2 interface.

l

BFD used to monitor the primary and secondary PWs does not monitor the AC interface status.

5.2.2 Troubleshooting Flowchart On a BTB IP RAN, packets are lost, duplicate packets are received, or traffic is interrupted after primary/secondary PW switchover. Figure 5-2 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


125



Figure 5-2 Troubleshooting flowchart for the fault that packets are lost, duplicate packets are received, or traffic is interrupted after primary/secondary PW switchover on a BTB IP RAN Faults occur after primary/secondar y PW switchover on a BTB IP RAN

Is the PW on the PE-AGG configured to ignore the secondary state sent from the peer?

No

Configure the PW on the PE-AGG to ignore the secondary state sent from the peer

End

Disable this function on the CSG

End

Configure BFD used to check primary and secondary PWs to monitor the AC interface

End

Configure a Spoke PW

End

Yes Are primary and secondary PWs on the CSG both enabled to receive packets?

Yes

No

Does BFD used to check primary and secondary PWs monitor the AC interface?

No

Yes No Is a Spoke PW configured?

Yes Seek technical support



Procedure Step 1 Check fault symptoms. Issue 02 (2011-09-10)


126



l If packets are lost, go to Step 2. l If duplicate packets are received, go to Step 4. l If traffic is interrupted, go to Step 5. Step 2 Check that the parameter ignore-standby-state is configured when the VPLS PW is configured on the PE-AGG. Run the display this command in the VSI-LDP view to check whether the parameter ignorestandby-state has been configured for the PW. l If the parameter has not been configured, run the undo peer peer-address [ negotiation-vcid vc-id ] command in the VSI-LDP view to delete the PW. After that, run the peer peeraddress [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignore-standby-state command to create a new VPLS PW and configure it to ignore the secondary state sent from the peer. NOTE

l After the old VPLS PW is deleted, services will be temporarily interrupted until a new VPLS PW is completely configured. l In the scenario where PW redundancy in master/slave mode is configured, traffic will be switched to the secondary PW if the primary PW becomes faulty. If the PW on the PE-AGG is not configured to ignore the secondary state sent from the peer, the PW on the local end (local PW for short) will not forward traffic. The local PW starts to forward traffic after the peer switches from the secondary state to the primary state and sends the new state to the local end. During this process, data packets are probably lost. To prevent this problem, configure ignore-standby-state when setting a PW on the PE-AGG. This enables the PW to ignore the secondary state sent from the peer and allows the PW to remain in the forwarding state in primary/secondary PW switchover.

l If the parameter ignore-standby-state has been configured for the PW, go to Step 3. Step 3 Check that BFD used to monitor the primary and secondary PWs is configured to monitor the AC interface status. Run the display bfd configurationpwinterfaceinterface-typeinterface-numberverbose command on PE-AGG1 and PE-AGG2 to check whether the Bind Interface is an AC interface. The parameter interface interface-type interface-number specifies an AC interface that is bound to the PW. display bfd configuration pw interface gigabitethernet 1/0/2.1 verbose -------------------------------------------------------------------------------BFD Session Configuration Name : test -------------------------------------------------------------------------------Local Discriminator : 1 Remote Discriminator : 1 BFD Bind Type : PW(Master) Bind Session Type : Static Bind Interface : GigabitEthernet1/0/2.1 PW TTL Mode : Auto PW TTL : Node : UPE Remote Peer : 8.8.8.8 Encapsulation Type : Vc Id : Select Board : Track Interface : GigabitEthernet1/0/2.1 TOS-EXP : 7 Local Detect Multi : 3 Min Tx Interval (ms) : 10 Min Rx Interval (ms) : 10 WTR Interval (ms) : Process PST : Enable Proc Interface Status : Disable Bind Application : L2VPN | OAM_MANAGER | MPLSFW Session Description : --------------------------------------------------------------------------------

l If it is not an AC interface, run the bfd cfg-name bind pw interface interface-type interfacenumber [ remote-peer remote-peer-address pw-ttl { auto-calculate | ttl-number } ] trackIssue 02 (2011-09-10)


127



interface command in the system view to configure the BFD session to monitor the primary and secondary PWs and the AC interface status. NOTE

BFD is required to monitor the AC interface status when it is checking PWs to ensure quick PW switchover in the case of link failure between the PE-AGG and UPE; otherwise, packets will be lost during primary/ secondary PW switchover.

l If it is an AC interface, go to Step 6. Step 4 Check that the primary and secondary PWs on the CSG are not both enabled to receive packets. Run the display this command in the view of the AC interface on the CSG to check whether the mpls l2vpn stream-dual-receiving command has been run. l If the mpls l2vpn stream-dual-receiving command has been run, run the undo mpls l2vpn stream-dual-receiving command in the AC interface view to delete the configuration. NOTE

The mpls l2vpn stream-dual-receiving command can only be run in a PWE3 L2VPN to prevent packet loss during PW state synchronization. If an L2VPN uses HVPLS, the mpls l2vpn stream-dualreceiving command cannot be run. This is because VPLS broadcast will cause a base station to receive double data packets.

l If the primary and secondary PWs on the CSG are not both enabled to receive packets, go to Step 6. Step 5 Check that a Spoke PW is configured between UPEs or between PE-AGGs. The following uses the Spoke PW between UPE1 and UPE2 as an example. Run the display vsi [ name vsi-name ] [ verbose ] command on UPE1 and UPE2 to check if there is a PW whose PW Type information is displayed as MEHVPLS. l If such a PW is not found, run the peer peer-address [ negotiation-vc-id vc-id ] [ tnlpolicy policy-name ] upe ignore-standby-state command in the VSI-LDP view to configure a Spoke PW. The command needs to be run on both UPE1 and UPE2 with the same parameters being specified or configured. NOTE

If no Spoke PW is configured, traffic will be interrupted because traffic uses the Spoke PW as a bypass after primary/secondary PW switchover is performed.

l If a Spoke PW is configured, go to Step 6. Step 6 Collect the following information and contact Huawei technical support personnel. l Results of the preceding troubleshooting procedures l Configuration files, log files, and alarm files of the device ----End

5.2.4 Relevant Alarms and Logs Relevant Alarms None. Issue 02 (2011-09-10)


128



Relevant Logs None.

5.3 Packets Are Lost or Traffic Is Interrupted on a BTB IP RAN with the Networking of HVPLS + L3VPN This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that packets are lost or traffic is interrupted on the CSG after a primary/ secondary PW switchover or switchback is performed on a BTB IP RAN with the networking of HVPLS + L3VPN.


The downlink interface tracked by VRRP is not switched to a Layer 2 interface.

l

No preemption delay is set for routers in the mVRRP backup group on the NPE or the preemption delay is set too short.

l

On the NPE, the VRRP-capable interface is not associated with the service VRRP backup group configured on it.

5.3.2 Troubleshooting Flowchart On a BTB IP RAN with the networking of HVPLS + L3VPN, packets are lost or traffic is interrupted after a primary/secondary PW switchover or switchback. Figure 5-3 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


129



Figure 5-3 Troubleshooting flowchart for the fault that packets are lost or traffic is interrupted after a primary/secondary PW switchover or switchback on a BTB IP RAN with the networking of HVPLS and L3VPN A fault occurs after a PW switchover in a BTB IP RAN

Is the AC interface on the downlink tracked by VRRP a Layer 2 interface?

No

Switch the physical interface tracked by VRRP to a Layer 2 interface

End

Yes

Is a preemption delay configured for the VRRP backup group on NPE1?

No

Set the allowed longest preemption delay for the VRRP backup group

End

Associate the interface with the VRRP backup group

End

Yes

Is the interface associated with the service VRRP backup group on NPE1

No

Yes




Procedure Step 1 Check fault symptoms. l If traffic is interrupted, go to Step 2. l If packets are lost, go to Step 3. Step 2 Check that the downlink AC interface tracked by VRRP is a Layer 2 interface. Issue 02 (2011-09-10)


130



Run the display this command on the AC interface on UPE1 and UPE2 to check whether the portswitch command has been run on this interface. l If the portswitch command has not been run, run the portswitch command in the AC interface view to switch the interface to a Layer 2 interface. NOTE

After VRRP is configured to track the interface status, master/backup switchover can be performed in the VRRP backup group along with the primary/secondary PW switchover immediately after the link between the PE-AGG and the UPE becomes faulty. VRRP monitors the protocol status on an interface. If the interface is a Layer 3 interface, the protocol status remains Down because L2VPN is configured on the interface, and the VRRP backup group status cannot be successfully negotiated. To address this problem, you need to switch the physical interface tracked by VRRP to a Layer 2 interface. After that, the protocol status on the interface changes to Up, and the VRRP backup group status can be successfully negotiated.

l If the downlink AC interface tracked by VRRP is a Layer 2 interface, go to Step 5. Step 3 Check that a preemption delay is set for routers in the mVRRP backup group on NPE1. On NPE1, run the display this command on the interface where the mVRRP backup group is configured. The command output will show whether a preemption delay has been set with the vrrp vrid preempt-mode timer delay command for routers in the mVRRP backup group. l If no preemption delay is set or the set preemption delay is too short, run the vrrp vridvirtualrouter-idpreempt-modetimerdelay delay-value command on the same interface to set the allowed longest delay for routers in the mVRRP backup group. NOTE

After PE-AGG1 recovers from a fault, if VRRP switchback in the mVRRP backup group is faster than the CSG's reselection of the primary PW or the spoke PW to reach PE-AGG1, traffic from the RNC to the NodeB is forwarded to NPE1 and then to PE-AGG1 and after that no PW is available for it. To prevent this problem, a VRRP switchback delay needs to be configured on NPE1 to allow a VRRP switchback only after a corresponding PW is established and the PW switchback is performed.

l If the allowed longest preemption delay is configured for routers in the mVRRP backup group, go to Step 4. Step 4 On NPE1, check that the VRRP-capable interface is associated with the service VRRP backup group configured on it. On NPE1, run the display this command on the interface where a service VRRP backup group is configured. The command output will show whether the direct-route track vrrp command has been run to associate the interface with the group. If they are associated, the link cost of the interface will change based on the VRRP status. l If they are not associated, run the direct-route track vrrp vrid virtual-router-id degradecost cost command to associate the interface with the service VRRP backup group. NOTE

In a VRRP backup group, IP addresses of the VRRP-capable interfaces on devices in the Master or Backup state will be advertised to L3VPN. Configuring a preemption delay cannot ensure that VPN FRR switchback on RSG1 is performed after VRRP switchback. After the direct-route track vrrp command is run to associate an interface with a VRRP backup group, the interface adjusts the cost of the direct route in the network segment to which the interface belongs based on the VRRP status, allowing a successful traffic switchback after fault rectification.

l If they are associated, go to Step 5. Step 5 Collect the following information and contact Huawei technical support personnel. l Results of the preceding operation procedure Issue 02 (2011-09-10)


131



l Configuration files, log files, and alarm files of the devices ----End


Relevant Logs None.

5.4 L2VPN Traffic Is Interrupted After AC Switchover on the IP RAN in PW Redundancy + APS 1:1 Mode with TDM/ ATM Base Stations This section describes the troubleshooting flowchart and provides a step-by-step troubleshooting procedure for the fault that L2VPN traffic is interrupted after AC switchover on the IP RAN in PW redundancy + APS 1:1 mode with TDM/ATM base stations.


No bypass PW is configured.

5.4.2 Troubleshooting Flowchart L2VPN traffic is interrupted after AC switchover on the IP RAN in PW redundancy + APS 1:1 mode with TDM/ATM base stations. Figure 5-4 shows the troubleshooting flowchart.

Issue 02 (2011-09-10)


132



Figure 5-4 Troubleshooting flowchart for the fault that L2VPN traffic is interrupted after AC switchover on the IP RAN in PW redundancy + APS 1:1 mode with TDM/ATM base stations Packet loss or duplicate packets found on an IP RAN in PW redundancy+APS 1:1 mode with TDM/ATM BTSs

No Is a bypass PW configured?

Configure a bypass PW

End

Yes




Procedure Step 1 Check that a bypass PW is configured between RSG1 and RSG2. Run the display mpls l2vc interface interface-type interface-number command on the AC interface on RSG1 or RSG 2 to check whether there is a PW whose primary or secondary or bypass information is bypass. l If such a PW is not found, run the mpls l2vc { ip-address | pw-template pw-templatename } * vc-id [ group-id group-id | tunnel-policy policy-name | [ control-word | nocontrol-word ] | [ ip-interworking | ip-layer2 | raw | tagged ] ] * bypass command in the AC interface view to create a bypass PW. The command needs to be run on both RSG1 and RSG2 with the same parameters being specified or configured. NOTE

If no bypass PW is configured, traffic will be interrupted because traffic should be directed to the bypass PW after primary/secondary PW switchover is performed.

l If a bypass PW is configured, go to Step 2. Step 2 Collect the following information and contact Huawei technical support personnel. l Results of the preceding troubleshooting procedures Issue 02 (2011-09-10)


133



l Configuration files, log files, and alarm files of the device ----End


Relevant Logs None.

5.5 Trouble Cases 5.5.1 Too Many Packets Are Lost Because ignore-standby-state Is Not Configured in the peer Command In an IPRAN with the networking of HVPLS + L3VPN, the parameter ignore-standby-state is not configured in the peer command when a VPLS peer is configured. This will cause loss of a great number of packets during primary/secondary PW switchover.

Fault Symptom As shown in Figure 5-5, in the IPRAN with the networking of HVPLS + L3VPN/IP, the L2VPN uses HVPLS (PWE3 accessing VPLS), and a primary PW and a secondary PW are configured for PW redundancy in master/slave mode. During primary/secondary PW switchover, too many packets are lost. Figure 5-5 Networking diagram for the IPRAN (HVPLS + L3VPN)

H-VPLS(PWE3+VPLS) SR1

RSG1

CSG

RNC

NodeB

SR2 L2VPN

Issue 02 (2011-09-10)

RSG2 L3VPN


134



Fault Analysis 1.

Run the display mpls l2vc interface interface-type interface-number command on the CSG. In the command output, the value of PW redundancy mode is master. It indicates that the PW redundancy mode is master/slave, and the CSG will send messages to SR1 and SR2 to notify primary/secondary PW switchover.

2.

Run the display vpls connection command on SR1 and SR2 to check the value of VCState. In the command output, the value of VCState is Up, which indicates that the Layer 2 tunnel has been set up.

3.

Run the display this command in the VSI-LDP view on SR1 and SR2 to check whether the parameter ignore-standby-state has been configured for PWs. The command output shows that this parameter has not been configured. On the network where PW redundancy in M/S mode is configured, if the primary PW fails, traffic will be switched to the secondary PW. If the secondary PW is in Backup state, traffic cannot be forwarded, which results in packet loss. If the parameter ignore-standby-state is configured for the PW on the SR, the PW will ignore the secondary state sent from the peer and be always in the forwarding state. This configuration can prevent packet loss during primary/secondary PW switchover.

Procedure Step 1 Run the system-view command to enter the system view. Step 2 Run the vsi vsi-name command to enter the VSI view. Step 3 Run the undo peer peer-address [ negotiation-vc-id vc-id ] command to delete the existing PW. Step 4 Run the peer peer-address [ negotiation-vc-id vc-id ] [ tnl-policy policy-name ] ignorestandby-state command to create a new VPLS PW and configure it to ignore the secondary state sent from the peer. After the operations, the number of lost packets decreases dramatically. The fault is rectified. ----End

Summary On the IPRAN with the networking of HVPLS + L3VPN, the parameter ignore-standbystate needs to be configured in the peer command when a VPLS peer is configured. This parameter configures a PW to ignore the secondary state sent from the peer and be always in the forwarding state. This configuration can decrease the packets lost during PW state synchronization in the case of primary/secondary PW switchover.

5.5.2 Traffic Is Interrupted After Primary/Secondary PW Switchover on a BTB IP RAN - PWE3 + (VSI + IP) On a BTB IP RAN with the networking of PWE3+(VSI+IP), if the downlink AC interface tracked by VRRP is not switched to a Layer 2 interface, the attached VPLS services will be interrupted. Issue 02 (2011-09-10)


135



Fault Symptom As shown in Figure 5-6, the Layer 2 and Layer 3 networks are back-to-back. On the L2VPN, HVPLS is deployed, and a primary PW and a secondary PW are configured for PW redundancy in master/slave mode. A Spoke PW is configured between UPE1 and UPE2 to prevent the network on one side of the UPEs from being affected by faults on the other side. When primary/ secondary PW switchover occurs on the network, traffic is interrupted. Figure 5-6 Networking diagram for a BTB IP RAN - PWE3 + (VSI + IP) UPE1

PEAGG1 CSG

PW ary m i pr spoke PW

NodeB

sec ond ary

RNC

PW PEAGG2

HVPLS （PWE3 accessing VPLS）

UPE2 IP

Fault Analysis 1.

Run the display vsi [ name vsi-name ] [ verbose ] command on UPE1 and UPE2. The command output shows that there is a PW whose PW Type information is displayed as MEHVPLS. It indicates that a Spoke PW has been configured.

2.

Run the display this command on the AC interface on UPE1 and UPE2. The command output shows that the portswitch command has not been configured on the interface. VRRP tracks the protocol status on the interface. Because the interface is bound to a VSI, the protocol remains Down, and the VRRP backup group status on the interface cannot be successfully negotiated.

Procedure Step 1 Run the system-view command to enter the system view. Step 2 Run the interface interface-type interface-number command to enter the view of a specified interface on UPE1 or UPE2. Step 3 Run the portswitch command to switch the interface to a Layer 2 interface. Step 4 Run the quit command to return to the system view. After the operations, traffic forwarding recovers. The fault is rectified. ----End Issue 02 (2011-09-10)


136



Summary VRRP tracks the protocol status on an interface. To ensure that the protocol status on the interface without an IP address is Up, you need to run the portswitch command on the interface to switch it to a Layer 2 interface.

Issue 02 (2011-09-10)


137

Troubleshooting HUAWEI VPN

Recommend Documents