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.


Bandwidth Occupation Rate Reached 100% on the Egress Direction of an ETH-Trunk Port on an NE5000E During Peak Hours

Publication Date:  2013-10-08 Views:  93 Downloads:  0
Issue Description
The network topology was as follows: U-P-NE5000E-1 -> eth-trunk5 -> N-P-NE5000E-1. The live network equipment version was NE5000E V300R007C00SPC900. U-P-NE5000E-1 was not installed with a patch. The N-P-NE5000E-1 was installed with the V300R007C00SPC023 patch. Two backbone 5000E NEs were connected through Eth-trunk5, which contained five 10G ports. During peak hours, according to feedbacks from the customer, the bandwidth occupation rate on a member port G5/1/1 of the U-P-NE5000E-1 reached 100%. The load balancing over trunk interfaces was uneven. Services on the live network were MPLS services. The log was as follows:
<U-P-NE5000E-1>dis int b
Interface                   PHY   Protocol InUti OutUti   inErrors  outErrors
Eth-Trunk5                  up    up         34%    79%          0          0
  GigabitEthernet3/0/1(10G) up    up         31%    74%          0          0
  GigabitEthernet4/0/0(10G) up    up         31%    74%          0          0
  GigabitEthernet5/0/1(10G) up    up         31%    74%          0          0
  GigabitEthernet5/1/0(10G) up    up         42%    74%          0          0
  GigabitEthernet5/1/1(10G) up    up         31%    98%          0          0
<N-P-NE5000E-1>dis int b
Eth-Trunk5                  up    up         78%    33%          6          0
  GigabitEthernet1/1/0(10G) up    up         73%    31%          0          0
  GigabitEthernet3/0/0(10G) up    up         73%    31%          0          0
  GigabitEthernet4/0/0(10G) up    up         97%    31%          2          0
  GigabitEthernet4/1/0(10G) up    up         73%    31%          4          0
  GigabitEthernet5/0/0(10G) up    up         73%    41%          0          0
Handling Process
Possible causes of the issue are as follows:
1. New service flow was introduced to the live network, which led to uneven load balancing after calculation by the Hash algorithm.
2. Configurations on the live network of the customer were improper.
To address the issue, Huawei performed the following operations and observed the following information:
1. The customer confirmed that no new service flow was introduced lately.
2. Queried the ETH-Trunk port configurations and found that load-balancing was performed by packet.
<U-P-NE5000E-1>dis cu int Eth-Trunk  5
interface Eth-Trunk5
 mtu 4470
 ip address
 isis enable 1
 isis circuit-type p2p
 isis circuit-level level-2
 isis cost 190
 isis ldp-sync
 isis bfd enable
 traffic-policy Real-Time-Core outbound
 pim sm
 mpls te
 mpls te metric 2000
 mpls rsvp-te
 mpls ldp
 mode lacp-static
 load-balance packet-all
 trust upstream default

3. After analysis on the configurations, recommended the customer to run the following commands on the U-P-5000E-1 to rectify the uneven load balancing situation:
[U-P-NE5000E-1] load-balance mpls unequal-cost enable 
[U-P-NE5000E-1] load-balance mpls trunk-enhance enable

In should also be noted that after the command execution, a member port should be selected from eth-trunk5. Ran the shutdown / undo shutdown command on the port to make the commands valid. The issue was solved.
Root Cause
On ETH-Trunk ports of NE5000E, the principle of load balancing is as follows:
There are 16 table entries for the hash algorithm. In the environment of the customer, five ports were used. Therefore, according to the table, one port will have four quota and the other four ports have 3 quota. By default, the load balancing is unbalanced.
Run the following commands on equipment:
[U-P-NE5000E-1] load-balance mpls unequal-cost enable 
[U-P-NE5000E-1] load-balance mpls trunk-enhance enable

After the configuration, run the shutdown/undo shutdown command on any member port.
Avoid configuring odd number of egress trunk ports.