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

Packets Are Lost Between NE40Es

Publication Date:  2012-07-27 Views:  43 Downloads:  0
Issue Description
Two NE40Es are connected through the ATM interface. In between is a 155 M STM-1 link, which bears the Iub services between the RNC and the NodeB. It is found that packet loss occurs unexpectedly and sometimes is very serious. The version of the NE40E is V300R003C02B382. 
Alarm Information
Null
Handling Process
1. To facilitate fault identification, replicate the configuration of the two ATM interfaces to the ATM subinterface. Enable traffic statistics on the subinterface. Thus, the packets discarded can be recorded in the subinterface count. When the count of discarded packets on the subinterface is found increasing, collect and analyze the statistics. (For the services that can be configured on the ATM interface, all functions, except transparent transmission of ATM cells, can be configured on the corresponding subinterfaces. The functions configured on the subinterface are clearer in logic. In addition, the statistical function supported by subinterfaces is more powerful.)The following methods are available for enabling the statistical function on subinterfaces:
a. For all the subinterfaces on a router, run the subinterface traffic-statistics enable command in the system view.
b. For the specified subinterface on a router, run the statistic enable command in the specified subinterface view.
2. If it is not convenient to configure subinterfaces on the device, when the problem occurs, enter the two commands in the following example repeatedly in the views of these two ATM interfaces. Then send the command execution results to us for analysis. For example:
[211-Atm8/1/0]display atm sar phy-stat
[211-Atm8/1/0]display atm sar sys-stat
Run the preceding two commands for ten times on the two ATM interfaces respectively when lots of packets are found lost. Then collect the execution results for analysis.
3. Based on the logs, it is found that, when the problem occurred, the status of LDP sessions between one NE40E and the MSR22002 and between the other NE40E and the MSR22001 went Down and then Up from time to time. The networking shows that the ATM link acts as the public network tunnel between the MSR22002 and the MSR22001 to bear the VPLS services. Most service input interfaces are GE interfaces. In this case, if the traffic on GE interfaces is out of control, the public network tunnel tends to be congested. Therefore, a preliminary conclusion can be drawn that the traffic on the ATM interfaces exceeds the interface bandwidth, thus leading to the discarding of protocol packets between the MSR22002 and the MSR22001 and the continuous oscillations of the status of LDP sessions.4. The ATM QoS feature of V300R003 provides the scheduling function based on PVC queues. The priority of queues can be adjusted. If the ATM link is used to bear the L2VPN services, this function can be used to adjust the weight of PVC queues. In the scenario of this case, run the pvc-queue cs6 pq outbound command in the ATM PVC views of the NE40E-MSR22001 and the NE40E-MSR22002 so that protocol packets can preferentially pass ATM interfaces in the case of traffic congestion. Thus, the status of LDP sessions remains stable.5. After the ATM interfaces are configured with the scheduling function based on PVC queues, the problem does not recur. 
 
Root Cause
The service traffic on the link between ATM interfaces is too heavy, which leads to packet loss. 
Suggestions
For the L2VPN services over the ATM link, it is recommended that you enable the PVC queue-based scheduling function of the ATM QoS feature. 

END