SOS!!! Mikrotik's PPP LCP Echo Request does not work well

RouterOS General
1

Hello everyone!
I use Mikrotik to work as a BRAS in my network diagram, 2 vlans created at eth0, then two pppoe-server interfaces created at the two vlan interfaces respectively, with the same pppoe profile, and at each pppoe-server interface, the keepalive Timeout was 10s.

Mikrotik was connected with another device, the device worked as pppoe-client, which supported vlan too (several pppoe-clients created different vlans).

The problem is:
(1)If the divice started more than one pppoe clients(start these clients synchronously, or at first only one client, after some time, started another client), these pppoe cleints will be dropped(pppoe session was terminated)
(2)If the divice only started one pppoe client, it will not be dropped.
Mikrotik version is V2.9.2

I am puzzled by this problem for a long time, any suggestion was welcome

I put a hub between Mikrotik and this device, from the captured packets, I found that Mikrotik’s LCP Echo Request has some problem, because I set “Keepalive Timeout” to be 10s, so Mikrotik should send out LCP echo request every 10s, but in fact, Mikrotik will send several LCP echo request packets with the peroid 1! After these LCP request packets(without LCP reply), Mikrotik sent out PADT to terminate the pppoe session.

I do not know how to attach a pic here, otherwize it will be more clear, I export the content of packets to txt format, 7 packets captured, the first 5 packets, Mikrotik sent out LCP echo request with peroid 1s, very quickly, the 6th packet, Mikrotik sent out PADT to pppoe client to terminate the pppoe session, the 7th packet, pppoe client agreed to terminate this session.
(Pay attention to timestamp in red lines)

No. Time Source Destination Protocol Info
53 61.184327 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPP LCP Echo Request
Frame 53 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x05
Length: 8
Magic number: 0x5ff4ad1b

No. Time Source Destination Protocol Info
54 62.194520 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPP LCP Echo Request
Frame 54 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x06
Length: 8
Magic number: 0x5ff4ad1b

No. Time Source Destination Protocol Info
55 63.204840 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPP LCP Echo Request
Frame 55 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x07
Length: 8
Magic number: 0x5ff4ad1b

No. Time Source Destination Protocol Info
56 64.214907 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPP LCP Echo Request
Frame 56 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x08
Length: 8
Magic number: 0x5ff4ad1b

No. Time Source Destination Protocol Info
57 65.225234 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPP LCP Echo Request
Frame 57 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x09
Length: 8
Magic number: 0x5ff4ad1b

No. Time Source Destination Protocol Info
58 66.235685 HewlettP_04:c8:0d 00:00:00_00:0b:02 PPPoED Active Discovery Terminate (PADT)

Frame 58 (56 bytes on wire, 56 bytes captured)
Ethernet II, Src: HewlettP_04:c8:0d (00:11:85:04:c8:0d), Dst: 00:00:00_00:0b:02 (00:00:00:00:0b:02)
PPP-over-Ethernet Discovery

No. Time Source Destination Protocol Info
59 66.256247 00:00:00_00:0b:02 HewlettP_04:c8:0d PPPoED Active Discovery Terminate (PADT)
Frame 59 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:00:00_00:0b:02 (00:00:00:00:0b:02), Dst: HewlettP_04:c8:0d (00:11:85:04:c8:0d)
PPP-over-Ethernet Discovery
PPPoE Tags

2

routeros ppp lcp echo is using tags as per later PPP specifications.
the non routeros ppp implementation does not use tags as per earliest ppp specification. A fix would be for routeros to accept non tagged behaviour but afaik mikrotik said no. (please correct me if im wrong)

3

Are you serious your still on 2.9.2 ? Many PPP fixes since then.

4

I did such a test, only one pppoe client, I observerd about 20 minutes, captured all the traffic at Mikrotik’s pppoe-server interface, and studied carefully, I found the periods of LCP echo requests are all 15s, But why the period is 15s, I set Keepalive Timeout to be 10s in pppoe server interface.
Then I did another test, at first only one pppoe client, after 20s, another pppoe client joined the test, the whole test lasted about 20 minutes, then I studied the ppp LCP echo request packets which Mikrotik sent to the two pppoe clients, I found that the period was not fixed, sometimes 10s, sometimes 15s, sometimes 1s.

The version was 2.9.27.

How to explain such phenomenon?

Best Regards!

5

That ppp’s keepalive’s timer gets interrupted by an unexpected signal and is unaware that it got interrupted by an unexpected signal?