Packet loss in PPPoE in NE20E-S2F

Created: May 23, 2019 16:46:11Latest reply: Sep 13, 2019 18:15:14 361 10 0 0
  Rewarded Hi-coins: 1 (problem resolved)

Hello all,


We have a NE20E-S2F VRP (R) software, Version 8.180 (NE20E V800R010C10SPC500) with a weird behavior.

Some PPPoE users, not all users, not the same users, completely random, get heavy packet loss after some minutes connected.

The packet loss occur only in PPPoE tunnel, when the user ping to the router or through it (ie Internet).

The router itself (wan interface) don't show this packet loss.

If the user reconnect, the problem is temporary or completely solved (again, totally random).


<BRAS4-SOVR>dis access-user summary

  Normal users                       : 21272


<BRAS4-SOVR>dis health

----------------------------------------------------------------

Slot                       CPU Usage  Memory Usage(Used/Total)

----------------------------------------------------------------

3       IPU                    27%          32%   2505MB/7829MB

----------------------------------------------------------------




  • x
  • convention:

Featured Answers
chenhui
Admin Created May 25, 2019 02:39:15 Helpful(0) Helpful(0)

Posted by broonu at 2019-05-24 17:07Posted by chenhui at 2019-05-24 17:07@broonu hi, You said "The router itself (wan interface) don't sh ...
Hi!

I think the first thing is that we should find out where the packets are discarded.

You can configure the route-policy to match the ICMP packets sent by the users whose ping randomly times out, or you can capture the packets and then filter out the same part.
  • x
  • convention:

All Answers
chenhui
chenhui Admin Created May 24, 2019 01:37:12 Helpful(0) Helpful(0)

@broonu hi,
You said "The router itself (wan interface) don't show this packet loss." What does it mean?
did you mean the packets are sent out but without reply?
  • x
  • convention:

broonu
broonu Created May 24, 2019 17:07:51 Helpful(0) Helpful(0)

Posted by chenhui at 2019-05-24 01:37@broonu hi, You said "The router itself (wan interface) don't show this packet loss." What does it m ...

Hi @chenhui

Let me try to explain:

This router has a 6 port trunk with a Huawei Switch 6720 (3 switches in stack-mode), in lacp-static.
So I have eth-trunk1.4002, that is the WAN interface of this router, eth-trunk1.4001 that is a L3 interface (it has IP address), and have a bunch of eth-trunk1.X interfaces, that are used for PPPoE, ie:

interface Eth-Trunk1.13
description BRAS PPPOE V.13
ipv6 enable
ipv6 address auto link-local
user-vlan 13
pppoe-server bind Virtual-Template 1
ipv6 nd autoconfig other-flag
bas
#
access-type layer2-subscriber
default-domain authentication ppp-user MYDOMAIN
ssid Eth-Trunk1.13
user detect retransmit 3 interval 20
#
#

I dont have any packet loss in eth-trunk1.4001 and eth-trunk1.4002 interfaces, but in those eth-trunk1.X interfaces, I have random packet loss, just in the PPPoE clients (about 70% packet loss), but is completely random, a client in eth-trunk1.754 may have packet loss and another client in same vlan don't. If reconnect the user with problem, it is solved.
  • x
  • convention:

chenhui
chenhui Admin Created May 25, 2019 02:39:15 Helpful(0) Helpful(0)

Posted by broonu at 2019-05-24 17:07Posted by chenhui at 2019-05-24 17:07@broonu hi, You said "The router itself (wan interface) don't sh ...
Hi!

I think the first thing is that we should find out where the packets are discarded.

You can configure the route-policy to match the ICMP packets sent by the users whose ping randomly times out, or you can capture the packets and then filter out the same part.
  • x
  • convention:

uzzi
uzzi Created May 26, 2019 06:31:19 Helpful(0) Helpful(0)

Appreciate if we can have design of it, I have checked the problem(s) documentation over this VRP version but didn't find any bug. What is the MTU you configured at customer side ? Also can you please share the configuration of virtual-interface 1, as @chenhui mentioned above it would be great if you start capturing packet(s) of Ether-Trunk 1.4001 and 1.4002 to diagnose further.

Thank you.

Kindest regards,
Uzair
  • x
  • convention:

Kindest%20Regards%3Cbr%20%2F%3E%0AMuhammad%20Uzair%3Cbr%20%2F%3E%0AHCIE%20%236776
broonu
broonu Created May 27, 2019 13:34:56 Helpful(0) Helpful(0)

Posted by chenhui at 2019-05-25 02:39 hi,I think the first thing is that we should find out where the packets are discard, you can confi ...
OK, I'll try to configure this.
  • x
  • convention:

broonu
broonu Created May 27, 2019 13:40:59 Helpful(0) Helpful(0)

Posted by uzzi at 2019-05-26 06:31 Appreciate if we can have design of it, I have checked the problem(s) documentation over this VRP ve ...
Hi @uzzi , this is my virtual template configuration:

interface Virtual-Template1
mtu 1500
description Template BRAS PPPoE
ip address unnumbered interface LoopBack0
ppp authentication-mode chap
ppp keepalive interval 30 retransmit 3 datacheck
pppoe-server ac-name BRAS4
tcp adjust-mss 1452
#

With this configuration, some CPE negotiate 1480 MTU (ie. Windows machines) and some 1492 (ie. Huawei ONU).
I get users with windows 1480 MTU working while some don't working, I also have ONUs with 1492 MTU working and some don't working.
  • x
  • convention:

uzzi
uzzi Created May 29, 2019 05:44:18 Helpful(0) Helpful(0)

Okay dear what I suspect there might be 2 things as config you shared seems okay.

(1)  Do the PPPoE user(s) stay connected all the time or it is dial on demand and they all connect on same time in morning. Huawei devices are very sensitive with this kind of threshold and it can start some auto protection.

(2) There might be any policy which applies on threshold either for user connection(s) or bandwidth and then became normal after a while.

Please try to capture the packets during problem time as that would give us better picture what actually is going on in your network moreover do you have any NMS in your network which shows the logs for your NE20 and did you enable logging in NE20 ? What is your traffic threshold on uplink being ISP and what graph shows when this thing happens ? I suspect Bandwidth issue.


Thank you.

Kindest regards,
Uzair
  • x
  • convention:

Kindest%20Regards%3Cbr%20%2F%3E%0AMuhammad%20Uzair%3Cbr%20%2F%3E%0AHCIE%20%236776
broonu
broonu Created May 30, 2019 17:51:43 Helpful(0) Helpful(0)

@uzzi

(1) Do the PPPoE user(s) stay connected all the time or it is dial on demand and they all connect on same time in morning. Huawei devices are very sensitive with this kind of threshold and it can start some auto protection.

Users stay connected all the time, about 21k sessions in this router.

(2) There might be any policy which applies on threshold either for user connection(s) or bandwidth and then became normal after a while.

There is a policy to manipulate traffic to CDN, CGNAT and Internet.


We changed Virtual-Template from "tcp adjust-mss 1460" to "tcp adjust-mss 1452" and disable IPv6 at all in PPPoE.
After disable IPv6, packet loss is gone.
  • x
  • convention:

uzzi
uzzi Created Jun 9, 2019 05:45:38 Helpful(0) Helpful(0)

Great the issue have been solved, it seems your network not supporting IP packet with DF bit size more than 1452 and it could be one of the reason for packet loss, moreover IPv6 is also process intensive specially when this much bulk request comes together.

Thank you.

Kindest regards,
Uzair
  • x
  • convention:

Kindest%20Regards%3Cbr%20%2F%3E%0AMuhammad%20Uzair%3Cbr%20%2F%3E%0AHCIE%20%236776
12
Back to list

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login