To have a better experience, please upgrade your IE browser.upgrade
Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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.
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.
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 10.243.49.33.Can add another IP address, such as 10.243.49.28, 10.243.49.30, 10.243.49.32, 10.243.49.34, 10.243.49.36, 10.243.49.38.
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 10.243.49.44 as source IP is smaller than thetraffic carry 10.243.49.33 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 10.243.49.33 and 10.243.49.44 as source IP, which can reach evenly load - sharing effect.
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 10.243.49.45 DIP 10.243.67.76
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).
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 .