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?
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 )
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:
I've managed to workaroun with those rules:
Code: Select all
/ 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.If you have an wireless link to an AP with mode=station and no WDS it's almost imposible.
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...
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.
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.
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
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.
http://linux.about.com/library/cmd/blcm ... -relay.htm
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
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 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.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?
EoIP will give you grief.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 )
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.
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
EoIP Tunnels sux !!! can't reach more than 10mbit/s thrue and cpu resource is at max all the time
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.
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.
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?
Why does MT insist on avoiding the correct way of doing something because a hack-job exists that poorly accomplishes the end result?
That was what I was referring to way-back-when.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 what others seem to want though.
Excellent! (the PPPoE <-> L2TP thing, that is.)Iv2.10 will have support for PPPoE L2TP relaying some day, but not for simple
ethernet relaying, that could be accomplished with simple bridging.
--Eric
Re:
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?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:Code: Select all/ 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
Malcolm
Re:
I see this topic and ones like it all the time, I also would really really like the feature.Excellent! (the PPPoE <-> L2TP thing, that is.)
--Eric
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
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.
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
I have added LAC functionality on to the v4 feature requests, please vote on it http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests
Re:
EoIP - it's a trick, it's not a solution.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 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:
Wow... Yes. Quite a lot has changed since 2004EoIP - it's a trick, it's not a solution.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 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