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


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


Packet Loss of VPN Packets in NE20

Publication Date:  2013-06-22 Views:  142 Downloads:  1
Issue Description
The version of the NE20 is VRP5.30-23138009. For the networking topology, refer to the networking diagram. The networking topology is simple. Services are carried by the MPLS VPN. When the 2 Mbps HD conference is held by the HBLT company, the images and voice at the provincial level are normal, but severe mosaic occurs and voice comes on and off at the video conference in cities except one. The customer cannot hold the conference normally. 
Alarm Information
Handling Process
For the first reason, the customer is recommended to add a 155 Mbps link so that the bandwidth between the aggregation NE40 and the NE20 amounts to 465 Mbps, which provides enough bandwidth. But during the test, the conference still fails to run normally.
For the second reason, the customer is recommended to check the link quality with the specific tool. The result shows that the delays at most cities are within 1 ms, except that the delay at CZ is longer. When packets are pinged, huge packet loss does not occur. Therefore, the link is basically qualified and the fault is not caused by the second reason.
For the third reason, check the VPN private route of the video conference. At POS 1/0/0, the outgoing traffic is large and many packets are congested and discarded. At POS 1/0/1 and POS 1/0/2, the incoming traffic is large, the outgoing traffic is small, and many packets are congested and discarded. The private route is as follows:
<ChangTuJu_NE20>disp ip routing-table vpn-instance hyds_VPN            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0            BGP  255 0        Pos1/0/0 BGP 255 0 Pos1/0/0 BGP 255 0 Pos1/0/0 BGP 255 0 Pos1/0/0
The above information shows that the fault is caused by the packet forwarding on the private route. Because the NE20 fails to support the IP-TRUNK, other measures shall be taken to balance the load of the three links. Add the following configuration:
tunnel-policy hyds_VPN
tunnel select-seq lsp load-balance-number 3
Then configure under the hyds_VPN:
tnl-policy hyds_VPN
For example:
ip vpn-instance hyds_VPN
route-distinguisher 100:1
tnl-policy hyds_VPN
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
After the configuration is enabled, check the private route of the hyds_VPN. The private route has three egress interfaces. Perform the 2 Mbps video conference test in the entire province again, severe mosaic due to packet loss does not occur. 
Root Cause
1. The bandwidth is not large enough.
Because the aggregation NE40 and the NE20 where the video server are connected by two 155 Mbps transmission devices, if all the 180 nodes participating in the 2 Mbps conference, the total bandwidths exceed the bandwidths of the two transmission devices.
2. The link is unqualified.
Because the SJZ node is attached directly to the switch connecting the NE20, but not transmitted through the 155 Mbps transmission device, the video conference in SJZ runs normally. Other cities connect with the province company through transmission devices, and the links between cities and counties are converted to 2 Mbps through the protocol converter, in addition, the distance is long, and thus the transmission quality cannot be guaranteed.
3. The NE20 forwarding problem
Because the NE20 and the aggregation switch where the video server is attached are connected by the 1000 Mbps transmission device, when packets are forwarded from the 1000 Mbps interface to the 155 Mbps interface, some packets may be lost. 
Contact Huawei Enterprise Personel