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>

Reminder

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

upgrade

Traffic Load Unbalancing Occurs on the Outbound Interface on an NE5000E.

Publication Date:  2013-01-07 Views:  46 Downloads:  0
Issue Description

Version: NE5000E V200R003C02B609

Topology: As shown in the following topology, BR1 and BR2 are NE5000Es. AR1 and AR2 are NE40Es or NE80Es. AR1 and AR2 function as the PEs to access the VPN services. BR1 and BR2 function as the Ps.

Problem description:

BR1 and AR1 in city 2 and BR2 and AR2 in city 2 are connected through a 155 Mbit/s POS link respectively. The two POS interfaces are bundled together to form a trunk interface. After the trunk interface is removed, traffic forwarding over the two POS links is unbalanced. The traffic on POS 6/0/5 is much greater than that on POS 7/0/2.

 

Handling Process

1.         To resolve the problem, use the following solution in city 2.

Run the undo load-balance avoid-degradation mpls all command on BR1 to disable two-level load balancing.

2.         To resolve the problem, take the following measures in city 3.

       Assign a new IP address to the SGSN.

Take city 3 for example. Most packets are destined for 10.243.49.33 of the SGSN. 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, and 10.243.49.38.

       Enable the packets transmitted from the RNC to the SGSN to evenly carry the original IP address of the SGSN and the newly assigned IP address to the SGSN.

After the capacity of the SGSN in city 1 is expanded, the newly assigned IP address meets the preceding requirement. However, the traffic from the RNC to the SGSN with 10.243.49.44 as the source IP address is less than that with 10.243.49.33 as the source IP address. As a result, the traffic cannot be load balanced after reaching the NE5000E.

Therefore, to load balance traffic on the NE5000E, modify the SGSN configurations to enable traffic to evenly carry 10.243.49.33 and 10.243.49.44.

Root Cause

1.         The problem identification in city 2 is as follows:

       The on-site Huawei technical support personnel capture packets on POS 6/0/5 on BR1 on the live network. The following command output displays information about a captured packet.

[N5KE-B1-hidecmd]display pe-probe 6 0 ephp-data

  09f85000  80030705  e1d14024  c0030000

  08380051  16fe1280  07ff4560  05d4368f  The TTL value is 254 when the packet is sent out, which indicates that the TTL value is 255 when the packet enters BR1.

  00003e11  b5cb0af3  312d0af3  434c0868  SIP 10.243.49.45   DIP 10.243.67.76

       Based on the analysis of multiple captured packets, the TTL values of the captured packets are all 255 when they are transmitted from AR1 in city 1 to BR1. By default, an NE5000E uses two-level hash to load balance packets with the TTL values odd. The IP addresses carried in the captured packets are as follows. They vary to a small extent. (All these packets are destined for AR1 in city 2.)

SIP            DIP

10.243.49.42    10.243.67.74           

10.243.49.45    10.243.67.71           

10.243.49.124   10.243.67.23           

10.243.49.45    10.243.67.76           

10.243.49.124   10.243.67.23           

10.243.49.42    10.243.67.72           

10.243.49.124   10.243.67.25           

10.243.49.42    10.243.67.71           

10.243.49.45    10.243.67.76           

10.243.49.42    10.243.67.78           

10.243.49.36    10.243.67.73            

       The Huawei R&D engineers replicate the configuration on the live network and disable two-level hash on BR1. They find that traffic load balancing on POS 6/0/5 and POS 7/0/2 is improved. The command output is shown as follows.

undo load-balance avoid-degradation mpls all

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

    Last 10 seconds input rate: 8360 bits/sec, 2 packets/sec             

    Last 10 seconds output rate: 258081544 bits/sec, 310186 packets/sec           

[88.88-hidecmd]dis inter g9/0/0 | inc rate                       

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

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

       Thus they confirm that the traffic imbalance occurs as a result that two-level hash is enabled on BR1.

Solution

when we modify the configuration on router we should considered the old config is usefull or not.

Suggestions
Two-level hash for load balancing is enabled on an NE5000E on a live network. The TTL value is 255 when a packet is sent to BR1, and the source and destination IP addresses in the packet do not vary largely. Therefore, when the NE5000E uses the hash algorithm for two-level load balancing, the traffic is forwarded through only one interface. After two-level load balancing is disabled, the traffic can be load balanced on two interfaces. Based on the analysis in city 3, most of the traffic to AR1 in city 3 includes two data flows. However, per-session load balancing is used on the live network, causing the traffic to be forwarded through only one interface. The problem in city 3 lies in that the traffic does not include diversified data flows and some traffic is larger than other traffic.

END