Trouble: PADO frames with MAC-addresses 6x:xx:xx:xx:xx:xx on VPLS.

We faced some unusual behavior of CCR1036-8g-2s+EM (RouterOS 6.38.7).

After we switched PPPoE-clients, connected to that CCR, from local mikrotik PPPoE-server to remote NAS, connected to that CCR via VPLS tunnel (VPLS tunnel in its turn is bridged with client’s VLANs), part of our PPPoE-clients (clients MAC-addresses of which starts with 6 - 6x:xx:xx:xx:xx:xx) are not able to register on new PPPoE server anymore. We tried to terminate VPLS tunnel at the remote end on Cisco as well as on Huawei devices (those devices in their turn are connected to different interfaces of our central NAS)
But when PPPoE-server moved back to this CCR1036-8g-2s+EM these clients with MAC-addresses 6x:xx:xx:xx:xx:xx can register locally without any problems.

In «DEBUG pppoe-packets» on our central NAS we can see that:
1.PADI packets with source MAC-address 6x:xx:xx:xx:xx:xx passed through VPLS tunnel to PPPoE-server;
2.PADO packets with destination MAC-address 6x:xx:xx:xx:xx:xx are sent back from PPPoE-server.

In packet sniffer on VPLS tunnel interface of CCR:

  1. We can see that PADI packets with source MAC-addresses 6x:xx:xx:xx:xx:xx are sent from VPLS tunnel to PPPoE-server;
  2. We can’t see any PADO packets with destination MAC-addresses 6x:xx:xx:xx:xx:xx from our central NAS

At the same time – ICMP packets from NAS with destination MAC-addresses 6x:xx:xx:xx:xx:xx successfully pass via the same VPLS tunnel.

Can you explain, what happens to PADO frames with MAC-addresses 6x:xx:xx:xx:xx:xx as its destination on VPLS?

Problem is already fixed. Please upgrade to latest ROS version.

It was fixed in 6.39.3 (bugfix), or we need 6.40.4 (current) ?

v 6.40.4