Community discussions

MikroTik App
 
rastod
Member Candidate
Member Candidate
Topic Author
Posts: 122
Joined: Sat Jun 04, 2005 11:35 pm
Location: Slovakia

pppoe-relay

Wed Feb 01, 2006 11:43 pm

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?
 
Art
Member Candidate
Member Candidate
Posts: 123
Joined: Thu Jan 27, 2005 10:14 pm

Thu Feb 02, 2006 12:24 am

that will be good thing :)
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24708
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Thu Feb 02, 2006 9:34 am

why can't you use bridge with bridge filters?
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Thu Feb 02, 2006 4:03 pm

bridge, eoip, lots of things comes to mind...
Regards,
Chris
 
rastod
Member Candidate
Member Candidate
Topic Author
Posts: 122
Joined: Sat Jun 04, 2005 11:35 pm
Location: Slovakia

Thu Feb 02, 2006 10:00 pm

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 )
 
User avatar
[ASM]
Member Candidate
Member Candidate
Posts: 285
Joined: Sun Jun 06, 2004 12:59 am
Location: Sofia, Bulgaria
Contact:

Sat Feb 04, 2006 2:21 pm

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 
The light is faster than sound. People always looks smart before they start talking.
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Sat Feb 04, 2006 2:36 pm

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...
Regards,
Chris
 
User avatar
[ASM]
Member Candidate
Member Candidate
Posts: 285
Joined: Sun Jun 06, 2004 12:59 am
Location: Sofia, Bulgaria
Contact:

Sat Feb 04, 2006 6:29 pm

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 ;)
The light is faster than sound. People always looks smart before they start talking.
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Sat Feb 04, 2006 6:33 pm

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.
Regards,
Chris
 
User avatar
[ASM]
Member Candidate
Member Candidate
Posts: 285
Joined: Sun Jun 06, 2004 12:59 am
Location: Sofia, Bulgaria
Contact:

Sat Feb 04, 2006 6:57 pm

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 :)
The light is faster than sound. People always looks smart before they start talking.
 
rastod
Member Candidate
Member Candidate
Topic Author
Posts: 122
Joined: Sat Jun 04, 2005 11:35 pm
Location: Slovakia

Sat Feb 04, 2006 7:01 pm

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.
 
npero
Member
Member
Posts: 317
Joined: Tue Mar 01, 2005 1:59 pm
Location: Serbia

Sun Feb 05, 2006 4:03 pm

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.
 
eflanery
Member
Member
Posts: 382
Joined: Fri May 28, 2004 10:11 pm
Location: Moscow, ID
Contact:

Tue Feb 07, 2006 1:30 am

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
 
rastod
Member Candidate
Member Candidate
Topic Author
Posts: 122
Joined: Sat Jun 04, 2005 11:35 pm
Location: Slovakia

Thu Feb 09, 2006 4:58 pm

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
 
canram
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Tue Mar 15, 2005 11:46 pm
Location: Germany

Tue Mar 14, 2006 8:52 am

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 ?"
 
sten
Forum Veteran
Forum Veteran
Posts: 922
Joined: Tue Jun 01, 2004 12:10 pm

Tue Mar 14, 2006 6:27 pm

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.
Move along. Nothing to see here.
 
canram
Frequent Visitor
Frequent Visitor
Posts: 84
Joined: Tue Mar 15, 2005 11:46 pm
Location: Germany

Mon Mar 20, 2006 12:44 pm

Perhaps, we´ll see pppoe-relay in RouterOS 2.9.10. I hope so !
 
User avatar
mag
Member
Member
Posts: 378
Joined: Thu Jul 01, 2004 12:32 pm
Location: Cologne, NRW, Germany
Contact:

Mon Mar 20, 2006 2:47 pm

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.
 
motaba
just joined
Posts: 4
Joined: Thu Apr 27, 2006 9:01 pm

EoIP Tunnels sux

Thu Apr 27, 2006 9:12 pm

EoIP Tunnels sux !!! can't reach more than 10mbit/s thrue and cpu resource is at max all the time
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24708
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Fri Apr 28, 2006 8:54 am

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
 
Beccara
Long time Member
Long time Member
Posts: 606
Joined: Fri Apr 08, 2005 3:13 am

Fri Apr 28, 2006 9:01 am

Eoip has everything to do with this topic, without PPPoE-Relay you need EOIP tunnels to connect everything together
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24708
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Fri Apr 28, 2006 9:42 am

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.
 
User avatar
Hammy
Forum Veteran
Forum Veteran
Posts: 759
Joined: Fri May 28, 2004 5:53 pm
Location: DeKalb, IL
Contact:

Fri Apr 28, 2006 6:25 pm

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?
 
eflanery
Member
Member
Posts: 382
Joined: Fri May 28, 2004 10:11 pm
Location: Moscow, ID
Contact:

Fri Apr 28, 2006 8:26 pm

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
 
mstead
Member Candidate
Member Candidate
Posts: 113
Joined: Sat Mar 04, 2006 2:41 am

Re:

Sat May 02, 2009 6:15 am

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
 
User avatar
Equis
Forum Veteran
Forum Veteran
Posts: 888
Joined: Mon Jun 06, 2005 6:48 am

Re:

Tue May 05, 2009 3:46 am

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

:-)
 
slebrun
just joined
Posts: 12
Joined: Fri Jul 13, 2007 6:19 pm

Re: pppoe-relay

Wed May 13, 2009 4:46 pm

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.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1885
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

Re: pppoe-relay

Wed May 20, 2009 12:09 am

I have added LAC functionality on to the v4 feature requests, please vote on it http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet NSE7 | Extreme Networks ENA
 
User avatar
FFAMax
newbie
Posts: 28
Joined: Sat Oct 01, 2016 12:50 am

Re:

Mon Nov 13, 2017 1:28 am

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
 
savage
Forum Guru
Forum Guru
Posts: 1220
Joined: Mon Oct 18, 2004 12:07 am
Location: Cape Town, South Africa
Contact:

Re: Re:

Mon Nov 13, 2017 6:40 pm

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 :)
Regards,
Chris

Who is online

Users browsing this forum: Baidu [Spider], Bing [Bot], emdi, Kickoleg, magistryoda, sindy and 57 guests