Page 1 of 1

pppoe-relay

Posted: Wed Feb 01, 2006 11:43 pm
by rastod
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?

Posted: Thu Feb 02, 2006 12:24 am
by Art
that will be good thing :)

Posted: Thu Feb 02, 2006 9:34 am
by normis
why can't you use bridge with bridge filters?

Posted: Thu Feb 02, 2006 4:03 pm
by savage
bridge, eoip, lots of things comes to mind...

Posted: Thu Feb 02, 2006 10:00 pm
by rastod
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 )

Posted: Sat Feb 04, 2006 2:21 pm
by [ASM]
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 

Posted: Sat Feb 04, 2006 2:36 pm
by savage
If you have an wireless link to an AP with mode=station and no WDS it's almost imposible.
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...

Posted: Sat Feb 04, 2006 6:29 pm
by [ASM]
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 ;)

Posted: Sat Feb 04, 2006 6:33 pm
by savage
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.

Posted: Sat Feb 04, 2006 6:57 pm
by [ASM]
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 :)

Posted: Sat Feb 04, 2006 7:01 pm
by rastod
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.

Posted: Sun Feb 05, 2006 4:03 pm
by npero
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.

Posted: Tue Feb 07, 2006 1:30 am
by eflanery
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

Posted: Thu Feb 09, 2006 4:58 pm
by rastod
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.

http://linux.about.com/library/cmd/blcm ... -relay.htm

Posted: Tue Mar 14, 2006 8:52 am
by canram
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 :D !!!!! As rastod already said: "why not integrate pppoe-relay ?"

Posted: Tue Mar 14, 2006 6:27 pm
by sten
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?
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.
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 )
EoIP will give you grief.

Posted: Mon Mar 20, 2006 12:44 pm
by canram
Perhaps, we´ll see pppoe-relay in RouterOS 2.9.10. I hope so !

Posted: Mon Mar 20, 2006 2:47 pm
by mag
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

Posted: Thu Apr 27, 2006 9:12 pm
by motaba
EoIP Tunnels sux !!! can't reach more than 10mbit/s thrue and cpu resource is at max all the time

Posted: Fri Apr 28, 2006 8:54 am
by normis
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

Posted: Fri Apr 28, 2006 9:01 am
by Beccara
Eoip has everything to do with this topic, without PPPoE-Relay you need EOIP tunnels to connect everything together

Posted: Fri Apr 28, 2006 9:42 am
by normis
By PPPoE-relay you probably meant PPPoE to L2TP relay like this:
http://www.cisco.com/en/US/products/sw/ ... d2b1f.html
http://www.rfc-archive.org/getrfc.php?rfc=3817

Not simple ethernet to ethernet relaying like this:
http://linux.about.com/library/cmd/blcm ... -relay.htm

Iv2.10 will have support for PPPoE L2TP relaying some day, but not for simple
ethernet relaying, that could be accomplished with simple bridging.

Posted: Fri Apr 28, 2006 6:25 pm
by Hammy
The problem with tunnels that terminate elsewhere is the reduction in reliability and redundancy. My network is designed to have every AP be a PPPoE server and have multiple router paths out. I won't have a bunch of T-1s in my NOC, but wireless backbone into tower A, DS3 into Tower B, wireless backbone into tower C, all completely different providers, all completely diverse, no central point. Tunneling to the NOC ruins that reliability and doubles the network traffic when all is working well.

Why does MT insist on avoiding the correct way of doing something because a hack-job exists that poorly accomplishes the end result?

Posted: Fri Apr 28, 2006 8:26 pm
by eflanery
That was what I was referring to way-back-when. :)

Not what others seem to want though. :(
Iv2.10 will have support for PPPoE L2TP relaying some day, but not for simple
ethernet relaying, that could be accomplished with simple bridging.
Excellent! (the PPPoE <-> L2TP thing, that is.)

--Eric

Re:

Posted: Sat May 02, 2009 6:15 am
by mstead
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 
I was looking at this and wondering if this guy was talking about a neat way to avoid using WDS. Anyone know if this is a way of relaying pppoe frames from a station mode wlan to an internal ethernet interface using the bridge NAT feature?

Malcolm

Re:

Posted: Tue May 05, 2009 3:46 am
by Equis
Excellent! (the PPPoE <-> L2TP thing, that is.)

--Eric
I see this topic and ones like it all the time, I also would really really like the feature.
It's been asked for years ago many time with still no luck, I have no idea why its not implemented yet, would a MT rep be able to comment on this?

Thanks

:-)

Re: pppoe-relay

Posted: Wed May 13, 2009 4:46 pm
by slebrun
PPPoE->L2TP relay to create a LAC/LNS structure would be awesome.

Client initates PPPoE session.

Mikrotik router checks the domain of the username request.

Mikrotik router tunnels to the appropriate server and relays.

Cisco calls this VPDN, as I recall.

Re: pppoe-relay

Posted: Wed May 20, 2009 12:09 am
by nz_monkey
I have added LAC functionality on to the v4 feature requests, please vote on it http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Re:

Posted: Mon Nov 13, 2017 1:28 am
by FFAMax
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.
EoIP - it's a trick, it's not a solution.

EoIP or any another new instance
1. decrease performance
2. adding possibility of faults or appearing new issues (bugs derivation)
3. complication of trivial things
4. makes diagnosis more difficult

Re: Re:

Posted: Mon Nov 13, 2017 6:40 pm
by savage
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.
EoIP - it's a trick, it's not a solution.

EoIP or any another new instance
1. decrease performance
2. adding possibility of faults or appearing new issues (bugs derivation)
3. complication of trivial things
4. makes diagnosis more difficult
Wow... Yes. Quite a lot has changed since 2004 :)