Hello mates.
Is there any particular reason that PPPoE server does not work in this case?
Is it a bug, feature or any technical reason for this?
ARP protocol should handle IP to MAC translation and PPPoE works purely on MACs.
Isn't it?
---
Best regards,
RQ

PPPoE works directly over ethernet (MAC) so nothing that ARP can help you with. If you're using ARP reply-only as a sort of security measure, you'll have to reconsider your strategy.

Hi mkx,

I use DHCP Server with "Add ARP for leases", with add to IP list from radius and ARP Reply-Only for CGN IP Pool.
This should prevent subscribers from stealing Internet by manually setting IP addresses. Client Isolation is enabled on OLT, so they can't see each other MACs.
I would like to use PPPoE for White IPs on the same VLAN. This will save me 3 IP addresses as PPP uses /32 mask.
So why PPPoE Server does NOT work?

Have you narrowed the search down to the topic title, i.e. if you change arp to enabled for that /interface vlan, the PPPoE server starts working, or is it just the only unusual setting you have found and you only suspect it to be related?

There is no reason why arp=reply-only on an interface should prevent a PPPoE server on the same interface from working, so if it really does, it must be a bug and you have to open a support ticket via Mikrotik servicedesk.

Other than that, you can assign /32 public addresses to the customers and give them the private address of the Mikrotik interface as a gateway. The exact way of setting this up on the client side depends on the operating system of the client; at Mikrotik side, it is enough to add routes to those public addresses (or to the whole prefix) via that interface by setting the interface name as a gateway of those routes, and in your case, manually adding the corresponding ARP records to the ARP table. The advantage of not using PPPoE is that you don't reduce the MTU for those customers, but of course there is no authentication in this case.

Hi sindy,

Yes, arp=reply-only is the only parameter which breaks PPPoE.
I agree about other methods, but the topic is about why is it NOT working?
I did not try this for some time, maybe something changed, but I doubt.
Thank you for your reply.

Any other ideas?

As you say you are not interested in suggestions regarding other ways of connecting the public addresses but only in why it does not work this way, what "other ideas" do you have in mind? I've already written before that if setting arp to reply-only affects the pppoe server operation on an interface, it is a bug (or an undocumented intention at best), as PPPoE does not use ARP at all. So it can only be resolved if you raise a support ticket, because if the Mikrotik guys don't know about an issue, they cannot fix it.

Hi,

By "other ideas" I meant that maybe I can still missing something in settings why it does not work.
Also having a PPPoE server running in parallel with DHCP is useful for transition all subscribers from one to another and for engineers on client side when no mobile Internet is available to connect to billing system and register new subscriber or change subscribers MAC in case of dead router or so on...

Anyway thank you Sindy for your suggestion I will try to test this solution with my Billing System.

And the most important part of this post is that it really works. I tested it again and it works.
PPPoE server drops all active sessions just after I switch VLAN ARP to reply-only.
Clients began to reconnect very slowly one by one only in 1 minute or so. There were near 500 PPPoE sessions.
As this is production router I changed settings back immediately previously because of panic and rush, so I did not wait for it to start working again.
My bad, sorry and thank you.

PPPoE server drops all active sessions just after I switch VLAN ARP to reply-only.
Clients began to reconnect very slowly one by one only in 1 minute or so. ...
As this is production router I changed settings back immediately previously because of panic and rush, so I did not wait for it to start working again.

From what you just wrote I gather that the comeback of the clients is only slow if proxy arp is on and that if it is off, they come back faster? I can imagine any change of the interface configuration to cause a restart of the PPPoE connections (which is not nice but can be understood), but if the speed of reconnection depends on the proxy-arp setting, it's still something that should be fixed.

I'm not using proxy arp at all.
I suppose this is due to closure of all pppoe sessions without sending PoD and reconnect time depends on client connection timeout settings.
If I kill any pppoe session now (with arp reply-only) it reconnects almost immediately, as usually (with arp enabled). The delay is observed only during change the parameter.

Sorry, of course I had in mind reply-only when writing that.