pppoe-relay

[Beccara]

Eoip has everything to do with this topic, without PPPoE-Relay you need EOIP tunnels to connect everything together

[normis]

By PPPoE-relay you probably meant PPPoE to L2TP relay like this:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2b1f.html
http://www.rfc-archive.org/getrfc.php?rfc=3817

Not simple ethernet to ethernet relaying like this:
http://linux.about.com/library/cmd/blcmdl8_pppoe-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.

[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?

[eflanery]

@normis

By PPPoE-relay you probably meant PPPoE to L2TP relay like this:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2b1f.html
http://www.rfc-archive.org/getrfc.php?rfc=3817

That was what I was referring to way-back-when.

Not what others seem to want though.

@normis

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]

@[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

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

[Equis]

@eflanery

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]

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.

[nz_monkey]

I have added LAC functionality on to the v4 feature requests, please vote on it http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/v4/Feature_Requests

[FFAMax]

@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

[savage]

@FFAMax

@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