Hi all,
it would be very useful to add PPPoE-RELAY agent to mikrotik firmware. It is very small open source deamon. We are using it on a pocket installation of linux instead of mikrotik. If there would be PPPoE-RELAY support we would buy at least 50 license of mikrotik. What can we do to convince you to do it?
that will be good thing 
why can’t you use bridge with bridge filters?
bridge, eoip, lots of things comes to mind…
Of course, we tested filtered bridge and it works but it does not seem to be serious solution, especially if the defice is routing too. Is it correct to put two routed segments - their interfaces to bridge?
Also we tested EoIP but we found unknown problems with it. Users connected by PPPoE through longer EoIP tunnel have problems with packetlose and speed. ( Longer - I mean that it is going through more than 3 routers in network )
If you have an wireless link to an AP with mode=station and no WDS it’s almost imposible.
I’ve managed to workaroun with those rules:
/ interface bridge nat
add chain=dstnat in-interface=wireless-client mac-protocol=0x8863 action=dst-nat \
to-dst-mac-address=MAC-OF-REMOTE-PPPOE-SERVER comment="" disabled=no
add chain=dstnat in-interface=wireless-client mac-protocol=0x8864 action=dst-nat \
to-dst-mac-address=MAC-OF-REMOTE-PPPOE-SERVER comment="" disabled=no
Ok, given, I have not actually tested this, but theoretically, I see no reason for it not to work. If you actually used WDS, then I might understand it not working.
You have a AP without a IP (I hope), to terminate PPPoE On, let’s call it wlan1 You have a ‘backhaul’ connection, let’s presume also Wireless, connecting to your back-end network, let’s call it wlan2, IP 1.1.1.1
You have a dedicated access concentrator in a office, IP 2.2.2.2 For simplicity, we are presuming that the network is operational, fully routed, and working.
On the high site, a bridge is created between wlan1 and wlan2 - let’s call this bridge1. Now, PPPoE coming from the client connected to wlan1, will also be available on wlan2. wlan2 does have a IP address, 1.1.1.1
From 2.2.2.2, we create a EoIP tunnel to 1.1.1.1, because of the tunnel, PPPoE will also show up at 2.2.2.2. You install your PPPoE Server on 2.2.2.2, listen on the EoIP interface, and all your connections will terminate there.
Sure, this is highly over simplified, you need to have some really funky firewalls here - ideally you want to ensure that only PPPoE goes over the bridge, and the EoIP tunnel. But untill I try this myself, I see no reason for this not to work…
I’m talking about this:
Client ↔ AP ↔ MT box ↔ PPPoE server
The configuration is for MT box…
If MT Box is the pppoe server there is no such problem 
Indeed. And now read what I said, setup the bridges, setup the EoIP tunnel between the MT Box and the PPPoE Server, and it should work.
If you get the PPPoE Requests at the MT, there is no reason why you cannot tunnel it to kingdom come, if you so desire.
I’ve tried this first bu the problem is that “MT box” sends to AP with it’s own MAC (AP is not Mikrotik based). After 2 hours tring with EoIP, I’ve NAT’ed them in 5 mins
Hi All, I asked for PPPoE-relay as a general problem. If you have one PPPoE user behind a wireless client, it is no problem. But when there are more clients it is problem, because wireless bridge is bridging IP only, not MAC. WDS solve this. There is no problem. So why I asked for PPPoE-relay?
PPPoEuser <–>AP<–>…routerA…PPPoEserver
The problem is if I wan to keep routed network and I want to allow PPPoE but I do not want to use EoIP I need to configure bridge on routerA but it is not correct while it is router also. And why not to use EoIP? We have tested it, it decreases quality of user’s link. Moreover it is not so beautiful and flexible. And PPPoE-relay module is so small and easy open-source.
PPPoE-relay be nice option in configuration like this
pppoe server(ISP)–AP ISP–wireless----MT wireless client—network client all with diffrent PPPOE acounts.
For this I use cheap router LinkSys, Asus and similar with Linux and install pppoe-relay module is work very well.
Actually, the best way I can think of to do something like this, would be for MT to add support for the actual L2TP layer 2 functions. By spec, it should be possable to directly bridge Ethernet (and others, like PPP) directly to L2TP.
This way, you could encapsulate the PPPoE within an L2TP connection to a central server, which would terminate both the L2TP, and the PPPoE within it. Many other vendors do support doing this.
The current MT L2TP implementation does not allow that, and thus requires yet another layer of encapsulation (EoIP), which is non-dynamic (unlike PPPoE, L2TP, and PPTP). In fact, functionally, there is very little difference between L2TP and PPTP, under MikroTik.
–Eric
Hi all,
PPPoE-RELAY agent is very small, easy and fast application so WHY NOT TO ADD IT to Mikrotik. Installation takes minute on standard linux system.
I suppose everybody knows it’s functionality: it proxies PPPoE sessions updating MAC translation table between two interfaces - interface with pppoe users and interface where pppoe server relays.
I´m also using pppoe-relay on all my CPEs. It´s a very usefull tool and very easy to integrate.
I also would like to see this tool in future Router-OS Releases, because EoIP really decrease performance.
@Mikrotik: Please think about integrating pppoe-relay 
!!! As rastod already said: “why not integrate pppoe-relay ?”
I wouldn’t worry so much about it being correct. I would worry about it generating more icmp redirects than you can handle. Even if you firewall them, the mere generation of the packets would require quite a bit of processing power.
EoIP will give you grief.
Perhaps, we´ll see pppoe-relay in RouterOS 2.9.10. I hope so !
i am using often PPPoE to connect CPEs but had very few problems in using EoIP-tunnels over a routed (wireless) backbone or even through internet.
I think its a question of network-design too, personally i like the idea of encapsulating customer traffic into tunnels, instead of flooding them through a bridged network mess.
If it’s easy to implement, i’d like to see a PPPoE-relay too, as PPPoE has become quite important and i might be a useful addition. But i consider it more a nice-to-have than a must-have.
EoIP Tunnels sux !!! can’t reach more than 10mbit/s thrue and cpu resource is at max all the time
PPPoE relay relays PPPoE traffic from one etheret-like interface to another. Simple bridging. I think there is a terminology conflict here. EoIP has nothing to do with this topic