No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


NE5000E export load sharing are problem

Publication Date:  2015-01-23 Views:  180 Downloads:  0
Issue Description

Version: NE5000E V200R003C02B609

Topology: The network topology as shown , BR1 and BR2 are NE5000Es, AR1 and AR2 are NE40E or NE80E. AR as PE equipment access VPN service, BR as P nodes.

Problem phenomenon:

The link between BR1 and city 2AR1, and the link between BR2 and city 2AR2 is trunk which is composed by two 155M POS link. Two link load imbalance after the trunk is released.The p6/0/5 traffic is heavy, and p7/0/2 only has a few traffic.

Handling Process

1) city 2 solution:

In the BR1 using the command to cancel the second- level load sharing.

Undo load-balance avoid-degradation mpls all

2) city 3 solution, you need to implement the following two measures:

A: On the SGS add an IP address

In city 3 as an example, most of the message mapping to SGSN ip address is add another IP address, such as,,,,,

B:The  flow between SGSN and RNC  can carry the original SGSN IP address and new IP address evenly.

After city3 expansion board, the city 1 SGSN need to add IP addresses to  meet the requirements. But the traffic carrying as source IP is smaller than thetraffic carry as the source IP from SGSN to the RNC , which lead to load imbalance when the traffic arrive NE5000E.

Therefore, you need to adjust the SGSN related configuration, make the traffic can evenly carry and as source IP, which can reach evenly load - sharing effect.



Root Cause

1, city 2 problem analysis & positioning process:

1)  capture packet  in p6/0/5 export interface on NE5000E  BR1 of the live network , message contents as follows:

[ N5KE - B1 -hidecmd ] displaype - probe60ephp - data

09f85000 80030705 e1d14024 c0030000

08380051 16fe1280 07ff4560 05d4368f  TTL of is 254, which means the packet enter BR1 is 255

00003e11 b5cb0af3 312d0af3 434c0868 SIP     DIP

2) After captured more messages, it is sure that  MPLSTTL are 255 when packets from city 1  AR1 enter BR1.If the  packets TTL is an odd number , NE5000E use level two load sharing hash algorithm for load - sharing calculation by default . Caught IP address as below, you can see IP address changes is very small. (these message are to city 2 AR1).

Sip                       DIP

3)Two port load sharing has improved greatly  after disable two load - sharing on simulation BR1 equipment   in a lab .Display information and used commands are as follows:

Undo load-balance avo id-degradation mpls all

[88.88 -hidecmd ] dis inter g3 / 1/8 | incrate

Last 10 seconds inputrate. 8360 bits / sec, 2packets / sec

Last 10 second sou TP utrate: 258081544 bits / sec, 310186 packets and sec

[ 88.88 -hidecmd ] disinter g9 /0/0 | incrate

Last 10 seconds input rate. 8472 bits / sec, 2packets / sec

Last 10 seconds output rate: 412907056 bits / sec, 496274 packets / sec

4) We can sure that   flow load imbalance in city 2 is caused by BR1 which enabled the secondary load - sharing.


Whether enable Secondary load - sharing scenario should considered with a live network .Need more audite when  in a changing network especially .

The live network enable secondary load sharing  by default,  packets entered BR1  TTL is 255, and IP packet source and destination IP change very small , so when equipment use the secondary load sharing of hash algorithm to handle packets load - sharing process, which lead to traffic are transmitted to one  interface.After use  command line to disable  secondary load sharing, load sharing has improved.  Captured packet city 3  and analysis to ensure thatmost traffic in  the city 3 AR1 is two stream. And live network use flow-by- flow load, thus lead to traffic went to one port. City 3 problem is due to insufficient of the traffic‘s variety and a few flow has too much traffic.