Years ago, I made a request for realm based (or domain based) authentication for PPPoE -> L2TP (LAC support).

It would be nice for mikrotik to be able to add this feature into ROS v4.

LAC functionality is relatively simple to implement. ROS v3 already supports PPPoe and L2TP, you just need to develop the striping of the Ethernet frames and direct them into the L2TP tunnel. Add the support for the domain and associate with the tunnel.

E.g.

User initiate a PPPoE session with username@domain.com

The ROS picks up the PPPoE, looks for the realm portion, strips the oE portion, sets up an L2TP tunnel to an LNS (based on the realm) and sends the PPP information over the L2TP tunnel.

I have no information except to add I would like this also.

Yes this would be a fantastic feature.

This would definitely be a useful feature, it would allow us to replace some cisco 1811s with mikrotik routers. We currently use the 1811s to terminate the PPPoE sessions via l2tp on a cisco 7200VXR in our core.

Any comment from the mikrotik team? This is a much-wanted feature!
-jonesy

yes, I still agree that I very much want it

I would like to see this as well.
LAC functionality is the main reason why I still need to deploy Cisco routers at remote PoPs.

Hi,

I've requested this too, quite a while ago and it would make my life a lot easier if it was there (even in v3).

/M

Have added to v4 feature requests, please vote on it http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Has this LAC/LNS functionality every been added to the mikrotik routers ? Looks like a few people would like it

Cheers

Anthony

LAC/LNS feature is not added to MikroTik RouterOS yet.

LAC/LNS feature is not added to MikroTik RouterOS yet.

Any plans to look into it?

I don't mean to hijack the thread, but how do you currently do this ?
Can you point me to another thread please ?

I'm in the process of setting up a Layer 2 DSL service and would love to terminate it on a Mikrotik, not a Cisco.
Is it possible ? Is there a workaround ?

Been waiting for this myself, been using a Cisco to do it.

Also while at it, lest not forget to implement PPPoE intermediate agents.

F.

Hi guys - I appreciate my question is not likely being posted in the best forum. I use Mikrotik everywhere possible, but LNS is still a problem. That being said, I need to find a solution to do LNS to do DSL termination. I have been using another product (ImgStr e am), but there are some limitations. I was thinking of a Cisco 2901, but I don't know what software options I need to support this. Anyone have a suggestion for a Cisco router that can pass at least 100mbps of LNS traffic? Looking for used/refurb preferably.... Be great if it was 1U, but not a solid requirement... I just don't dig the whole Cisco licensing thing (and the exceptionally high cost of the hardware) and I'm afraid if I buy something (used/refurb) the software image won't support LNS. Any info would be greatly appreciated.

Thank you and sorry for posting here, but seems others have some info on this topic....

I use Mikrotik everywhere possible, but LNS is still a problem.

Hi maxrate,

We terminate a few hundred ADSL users on an RB1000 (ROS 5.14) - what problems are you seeing ?

Regards,
Terry Froy
Spilsby Internet Solutions
http://www.spilsby.net/

+1 for LAC feature where today using a Cisco gear stays compulsory.

Already requested in 2007 : [Ticket#2007082266000461]

Terry: This is something I'm considering doing. Would you mind sharing your config?

Hi Terry - would love to do this on ROS - any chance you might share a sample config.

philb -have you managed to get it to work as yet?

Hi chaps,

Terminating ADSL in the UK is quite straightforward as you get the sessions via L2TP.

/ppp profile
set 0 change-tcp-mss=yes name=default only-one=default remote-ipv6-prefix-pool=\
none use-compression=default use-encryption=default use-ipv6=yes use-mpls=\
default use-vj-compression=default
add change-tcp-mss=yes dns-server=79.98.xx.1,79.98.xx.2 local-address=\
79.98.xx.xx name=default-l2tp only-one=default use-compression=no \
use-encryption=no use-ipv6=yes use-mpls=no use-vj-compression=no
add change-tcp-mss=yes local-address=79.98.xx.xx name=default-pptp only-one=\
default use-compression=default use-encryption=yes use-ipv6=yes use-mpls=\
default use-vj-compression=default
set 3 change-tcp-mss=yes name=default-encryption only-one=default \
remote-ipv6-prefix-pool=none use-compression=default use-encryption=yes \
use-ipv6=yes use-mpls=default use-vj-compression=default
/ppp aaa
set accounting=yes interim-update=1m use-radius=no
/ppp secret
add caller-id="" disabled=no limit-bytes-in=0 limit-bytes-out=0 name=\
testuser@spilsby password=changeme profile=\
default-l2tp remote-address=79.98.xx.1 routes="" service=l2tp

The only other thing is that you need to enable the L2TP server on RouterOS, set it to use the default-l2tp profile and then ensure that any RADIUS servers you are using sends the L2TP tunnel endpoint (IP address which RouterOS will accept connections on from the upstream LACs) - depending on whether your L2TP feed can cope with jumbo frames, you may have to force a lower MTU on your customers in the L2TP server (we defaulted to 1460 before we got a jumbo-capable feed).

I will point out that we are currently terminating our ADSL users back on FreeBSD's mpd5 due to significant shortcomings with RouterOS IPv6 support (DHCPv6 PD is broken as well as lack of PPP multilink on the server-side) but we do still have some users terminated on the MikroTik.

Happy to answer any other specific questions...

Regards,
Terry Froy
Spilsby Internet Solutions
http://www.spilsby.net/

Hi Terry - many thanks for your reply - for us it is a temporary measure and as such will only need to support IPv4
We currently have a Linux machine running l2tpns terminating the L2TP tunnel from the LAC and the inbound PPP connections.

Is there a way of setting the L2TP "secret" that is shared with the LAC - ROS just appears to have a username:password requirement for incomig L2TP?

Regards Murray Southwell
murray@staff.tasmanet.com.au

+1 for this feature, been a long time waiting

another +1 for this!!!!!!

Solved the problem running an instance of L2tpns on ubuntu

My face when I realise the people posting in this thread are all people I've talked to externally to the forums in the last few months =

Murray: When are you going to bundle it up into a RouterOS Metarouter image?

Murray: When are you going to bundle it up into a RouterOS Metarouter image?

I havn't had a great run with Metarouter - Stability for production environment just isn't there yet. Concept is great - Configuring is way easy - just can't stop them locking up every month or so

So in short - not yet

BUMP...

plz Mikrotik o mighty gods of routing..
don't forget this feature

bump

Bump

Bump

bump

BUMP!

+10

is there something new about this feature. I really want to use mikrotik as LNS server.

September 2008

+10


Years ago, I made a request for realm based (or domain based) authentication for PPPoE -> L2TP (LAC support).
It would be nice for mikrotik to be able to add this feature into ROS v4.

LAC functionality is relatively simple to implement. ROS v3 already supports PPPoe and L2TP, you just need to develop the striping of the Ethernet frames and direct them into the L2TP tunnel. Add the support for the domain and associate with the tunnel.

E.g. User initiate a PPPoE session with username@domain.com

The ROS picks up the PPPoE, looks for the realm portion, strips the oE portion, sets up an L2TP tunnel to an LNS (based on the realm) and sends the PPP information over the L2TP tunnel

We are migrating to Cisco

We are migrating to Cisco

good for you

but the writing is on the wall

http://www.businessinsider.com/cisco-ha ... ars-2013-8

We are migrating to Cisco

good for you

but the writing is on the wall

http://www.businessinsider.com/cisco-ha ... ars-2013-8

?

Cisco have had a good run for 30 years, the party is over for Cisco, the next 30 years are going to be incredibly tough for Cisco, they have 50% of their workforce in middle management roles, not clever for them to get into such a state IMHO, like I said "the writing is on the wall"

http://idioms.thefreedictionary.com/the ... n+the+wall

Ok but....i need lac and routeros not support this functionallity..

I still haven't got around to this, but it's on the cards again.

Before I resign myself to just using l2tpns on linux... Terry: Are you still using Mikrotik for this (have any of your bugs been squashed yet?) or have you moved elsewhere too? Are you doing any of this authenticated and accounted against a RADIUS server rather than using manual config on the mikrotik?

It's easily possible to use Mikrotik as an LNS (even in 5.26, as the L2TP Keepalive function is already available there), but in terms of LAC you're really out of luck. Still, i resort to using Cisco gear for most LAC/LNS duties.

Hi hedele,
Are you sure? Do you use Mikrotik as LNS in production? if yes, what is the max number of sessions that you could run?
Anybody else doing this?
We are interested only on the LNS side so it could be a good news for us.
Thanks

Hi ganewbie,

Yes LNS functionality works, with one caveat - L2TP tunnel authentication is not supported, so whoever is on the LAC side must NOT use a l2tp tunnel password or l2tp tunnel authentication.
On a Cisco LAC, you will need to put "no l2tp tunnel authentication" in the corresponding VPDN group or template. It's also possible to send an av-pair in the case of RADIUS-provisioned VPDN.
User sessions will show up as "normal" dynamic l2tp server bindings, just like if another Mikrotik Router connects using l2tp-client, so RADIUS authentication and all the other stuff works normally.

I use this in production in small scale, up to 5 users, as I only need this for a special service configuration, but didn't encounter anything troubling there.
Currently I am using this on 6.13 (x86) and 5.26 (RB1100AH). In regards of scaling - I guess this pretty much scales the same way as terminating PPPoE or Mikrotik L2TP clients, the number of L2TP server binding interfaces will get cumbersome in Winbox after a certain amount of sessions.

Hi hedele,
Thanks for the quick answer. In our case there is authentication but only password (no username).
Is is basically terminating PPPoE sessions for DSL clients on L2TP tunnels. It looks like this might not work then.
Thanks again,

Hi ganewbie,

I think you misunderstood - there is a difference between authenticating users, and authenticating the l2tp tunnel itself.
Authenticating users works fine, authenticating the l2tp control channel does not.
Cisco enforces L2TP control channel authentication by default, which needs to be disabled as I mentioned in my last post.
Most ISPs use L2TP control channel / tunnel authentication, so if you want to use Mikrotik as a LNS, you need to ask your wholesale provider to disable that.

You are probably not familiar with authenticating the L2TP control channel because it is not a supported feature on RouterOS.
It is kind of similar to using a md5 secret in OSPF or BGP. If your side does not support it, no adjacency will be created and the other side has to disable authentication.
What happens is that during the establishment of the first L2TP connection, the LAC and LNS want to authenticate each other by exchanging a password, and only if that is successful, the user session will be established.
RouterOS does not support that, so it needs to be disabled on the LAC.

Is there something new about this functionality (authenticating the l2tp) in new release?

Hello All,

We will keep bringing the subject up till it happens

At least give us a heads up for how much time is left for this dream to come true

Thanks
Your loyal consumer

http://www.mikrotikcanada.ca

Router#show run
Building configuration...

Current configuration : 3833 bytes
!
! Last configuration change at 20:31:58 EST Fri Dec 31 1999
!
upgrade fpd auto
version 15.0
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
logging snmp-authfail
no logging buffered
no logging console
enable secret 5 $1$123$456
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication ppp default group radius
aaa authentication ppp vpdn group radius
aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa authorization network vpdn group radius
aaa authorization auth-proxy default group radius
aaa accounting delay-start
aaa accounting update periodic 15
aaa accounting network default
action-type start-stop
group radius
!
!
!
!
!
!
aaa session-id common
!
!
!
clock timezone EST -5
ip source-route
no ip gratuitous-arps
ip icmp rate-limit unreachable 1000
ip cef
!
!
!
!
ip name-server 8.8.8.8
no ipv6 cef
!
multilink bundle-name authenticated
vpdn enable
vpdn multihop
!
vpdn-group agas-xxxx
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
local name xxxx-1
lcp renegotiation always
ip pmtu
ip mtu adjust
!
!
!
!
!
!
!
!
!
username xxxx-1 password 0 "PASSWORD"
username "username secret 5 $1$123$W02.B/456/
!
redundancy
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/1
description to CCR1036-12G-4S-SFP2-UPLINK_TO_COGENT
ip address x.x.x.x x.x.x.x
no ip redirects
no ip proxy-arp
duplex full
speed 1000
media-type sfp
no negotiation auto
no snmp trap link-status
no keepalive
!
!
interface FastEthernet0/2
no ip address
shutdown
duplex auto
speed auto
!
!
interface GigabitEthernet0/2
description Circuit# Bell Canada
mtu 9216
no ip address
no ip redirects
no ip proxy-arp
duplex full
speed 1000
media-type sfp
no negotiation auto
no cdp enable
!
!
interface GigabitEthernet0/2.xxxx
description VLAN to BELL AGAS service
encapsulation dot1Q 2003
ip address x.x.x.x x.x.x.x
no ip redirects
no ip proxy-arp
no cdp enable
!
interface GigabitEthernet0/3
description RADIUS
ip address x.x.x.x x.x.x.x
duplex auto
speed auto
media-type rj45
negotiation auto
!
!
interface Virtual-Template1
mtu 1492
ip unnumbered GigabitEthernet0/1
no ip redirects
no ip proxy-arp
no logging event link-status
peer default ip address pool Residential
keepalive 30
ppp mtu adaptive
ppp authentication pap callin vpdn
ppp authorization vpdn
ppp multilink
ppp timeout authentication 100
!
!
ip local pool Residential x.x.x.x x.x.x.x
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip route 0.0.0.0 0.0.0.0 x.x.x.x
ip route x.x.x.x x.x.x.x x.x.x.x
ip route x.x.x.x x.x.x.x x.x.x.x
!
ip radius source-interface Virtual-Template1
logging alarm informational
!
!
!
!
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 4 x.x.x.x
radius-server host x.x.x.x auth-port 1812 acct-port 1813 key 123456
radius-server directed-request restricted
radius-server vsa send accounting
radius-server vsa send authentication
!
control-plane
!
!
bridge 1 protocol ieee
!
!
!

!
line con 0
transport preferred none
stopbits 1
line aux 0
stopbits 1
line vty 0 4
access-class 4 in
exec-timeout 60 0
password xxxxxx
transport preferred telnet
transport input all
transport output telnet
!
end

http://www.mikrotikcanada.ca
http://www.cisco.com/c/en/us/td/docs/io ... d_book.pdf
http://www.mikrotikcanada.ca

what was that?..

That is the setup for Cisco 7200 for the LNS function.
Is that setup possible on Mikrotik today? just for the LNS function not LAC as LAC has been done by Telco.

LAC/LNS is currently unsupported.

Hi ganewbie,

Most ISPs use L2TP control channel / tunnel authentication, so if you want to use Mikrotik as a LNS, you need to ask your wholesale provider to disable that.

RouterOS does not support that, so it needs to be disabled on the LAC.

This is seriously unacceptable after so many years and so many users requesting this feature.

Firstly because "your wholesaler" will quite happily tell you "tell me when you want to put away your toys, stop PRETENDING that you are an ISP, and use _a_real_LNS_". (translation -> "Get Stuffed!")

It is a MAJOR piece of functionality which holds back Mikrotik/RouterOS being "taken seriously" in the ISP market.

And by "taken seriously" I mean many many many thousands of sales, and most especially in the CCR product line, if RouterOS fully implemented ALL the L2TP features.

A high-spec CCR fully supporting L2TP (multiple cores, etc) would kill a 10-20 thousand dollar Cisco router, people would be falling over themselves to buy them by the truckload.

+ tunnel authentication
+ tunnel switching of sessions based on realm

Get your act together, make it happen!

People will stop laughing at you, and you'll be raking in the megabux.

I agree, if Mikrotik improve this area they will be on to a sales winner.

Even in the times of 100+mbit Internet connections PPP is still the primary method of connection for consumer internet, and tunnelling of that is as relevant as it has ever been.

It's not just "Add LAC/LNS functionality" though. As much as I like RouterOS it is missing a bunch of stuff that is required to match the functionality you can get on Cisco/Juniper/AlcatelLucent kit when used in a LAC/LNS/BNG type role.

e.g. RADIUS VSA's to change behaviour on a per-session basis, something akin to Cisco's AVPAIR attribute. This was a smart move by Cisco. You only need a single attribute in the RADIUS dictionary, but can specify all matter of options that are specific to your equipment.

This can be used to set a session to a bridge, specify a VRF for the connection to be placed in, specify advanced traffic shaping attributes.

e.g.
Place a connection in to a particular VRF:
Mikrotik-AVset=ip:routing-mark=vrf-acmecorp-wan
Mikrotik-AVset=ip:pool=acmecorp-wan-4G

Initiate a LAC connection to a LNS with the IP 103.19.88.7 (tunnel the connection):
Mikrotik-AVset=tunnel:ipaddress=103.19.88.7
Mikrotik-AVset=tunnel:password=mtiktest
Mikrotik-AVset=tunnel:type=l2tp


Also if the session is part of a "profile" and an attribute is defined for a setting, it should be preferred over the setting in the profile (this is mostly already the case, but a bunch of stuff is only able to be set in the profile).

+100

LAC/LNS is currently unsupported.

This can be a game changer for most of us and put RouterOS on the high end leauge of the routers.
Please consider it seriously.

mrz wrote:LAC/LNS is currently unsupported.

Well, thanks for the update.
But do you have plans?

waiting for this still..

Still waiting for this, as well - but in the meantime making do with what we've got. I have 450+ DSL users spread across two x86 6.x routers happily - as long as Tunnel-Password is not set.

If I felt like it I would dive into RADIUS dictionary on Mikrotik to create custom attributes, but I don't think RouterOS is going to do anything with them - certainly anything I did would be "unsupported" by MT.

I could put in dozens of CCR1036's across multiple clients if we had a bit more functionality…one small guy in one small market.

Up for the Request!!

We are moving the whole network to a Mikrotik but we can't substitute the Cisco LNS/LAC... That's a mess...

Greetings!

You can now authenticate L2TP tunnels.

Tested working in 6.33rc25. No idea when it first appeared.

Hi timoid,
Could you please shed more light on the way to set it up?
Which telco you have tried it with?
Thanks,

Hi timoid,
Could you please shed more light on the way to set it up?
Which telco you have tried it with?
Thanks,

interested too..

Great news, it looks Mikrotik implemented LNS.

Changes since 6.33rc33:
*) l2tp: implemented PPPoE over L2TP in LNS mode, RFC3817;

The challenge now is testing.

We have tested this with Cisco IOS LAC and it works perfectly.

Bring on Mikrotik LAC

We have tested this with Cisco IOS LAC and it works perfectly.

Bring on Mikrotik LAC

We are scheduling test for the weekend, is it possible to share your settings?
How many PPPoE session did you see running on the L2TP?
Thanks,

I have also tested this and it is work and long awaited.

Steve

LNS added http://forum.mikrotik.com/viewtopic.php ... 74#p505174

LNS added http://forum.mikrotik.com/viewtopic.php ... 74#p505174

Normis,

An documentation on this anywhere?

Steve

it's actually pretty easy to set up.
In winbox, you now have a new tab in the PPP menu called "L2TP Secrets". In there, you create an entry for the LAC IP address and the L2TP tunnel authentication password. Incoming L2TP control connections from a LAC will now be authenticated properly Incoming PPP sessions from the LAC will show up as L2TP server bindings, just like any other incoming L2TP client connections.

As far as I see it, you can't use hostnames for L2TP secrets, so a "terminate-from hostname" Cisco equivalent is not provided, just "terminate-from ip".

hello,

I have been waiting for RFC 3817 support in RouterOS for a loooooooooooooooooooooong time.....I see that LAC functionality is not yet implemented tho? This is what I was really hoping for.

is there any chance this might make it to RouterOS someday

I want our Mikrotik line edge routers to connect customer PPPoE requests back to our primary Cisco LNS (which is a massive powerhouse of a router) for PPPoE termination, ie LAC mode. I'm going to give it a test next week, but in the meantime does anyone else have LAC connectivity outbound working?

You guys need to stop pretending.

This thread has been active for 7 years and STILL only half of a BNG solution exists.

As someone with a clue already posted, Mikrotik needs to wake up and smell the roses before anyone will actually take them seriously in the SP market.

Do yourselves a favor and use the vBNG features on the Cisco 1000V, sure you'll have to pay but you know it will work and will support any environment you put it in.

Mikrotik need to get a virtual x64, fast-path platform out pronto which supports both the LAC and LNS functionality.

Hello,

LNS protocol works on MikroTik RouterOS very stable faster and more reliable than Cisco Routers now!

The previous major issue within MikroTik RouterOS was for "AVP" authentication protocol which MikroTik doesn't supported and the broblem caused by that issue:
-There are two kind of LNC in BELL infrastructure " Alcatel router " and " Juniper router "
MikroTik RouterOS had no issue to accept L2TP requests from Alcatel LAC and users can authenticated without any issue but none of the requests from Juniper LAC doesn't seen by MikroTik Routes " LNS "
I have added the debug file from Juniper router when it try to authenticate and authorize MikroTik LNS requests:
---------------------------------------------

Effective administrative state is enabled
State is established
Failover resync is silent failover
Local tunnel id is 3830, peer tunnel id is 1887
Host profile is none
Tunnel is Up for: 0 days, 0 hours, 0 minutes, 16 seconds
Sub-interfaces total active failed
Sessions 235 1 209
Switched-sessions 0 0 0
Statistics packets octets discards errors
Control rx 78 73302 558 0
Control tx 881 137238 0 0
Data rx 22 1268 0 0
Data tx 223 6503 0 0
Control channel statistics
Receive window size = 64
Receive ZLB = 56
Receive out-of-sequence = 0
Receive out-of-window = 22
Transmit window size = 4
Transmit ZLB = 26
Transmit queue depth = 1
Retransmissions = 607
Tunnel operational configuration
Peer host name is 'MikroTik'
Peer vendor name is 'MikroTik'
Peer protocol version is 1.0
Peer firmware revision is 0x0001
Peer bearer capabilities are none
Peer framing capabilities are sync
————————————————————————————————————————
————————————————————————————————————————
bas1-burlington03:wholesale#sh log data severity 7 | include electromech-2
DEBUG 11/02/2015 19:11:48 l2tp: Authenticate configuration data: tag = 2, type
= 1, transport = ipUdp, routerId = Router 0x80000043, address = 67.69.118.59,
tName = electromech-2, tSecret = 3L3c7M3c, tLocalHostName = bas1-burlington03,
tRemoteHostName = , tLocalAddress = 67.69.201.193
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = dying, event = start, next state =
closeDown
DEBUG 11/02/2015 19:11:48 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Update IP transport config: local address = 67.69.201.193, remote address =
67.69.118.59
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = closeDown, event = open, next state
= openDown
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = openDown, event = upActive, next
state = txSccrq
NOTICE 11/02/2015 19:11:48 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Changing mibState from idle to connecting
NOTICE 11/02/2015 19:11:48 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing effective adminState from
disabled to enabled
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = closeDown,
event = open, next state = openDown
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = txSccrq, event = txComplete, next
state = waitCtlReply
INFO 11/02/2015 19:11:48 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Processing incoming in-sequence sccrp
DEBUG 11/02/2015 19:11:48 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = waitCtlReply, event = sccrp, next
state = txScccn
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2): tunnel: state = txScccn, event = txComplete, next
state = established
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Changing ifOperStatus from Down to Up
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing ifOperStatus from LowerLayerDown
to Down
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = openDown,
event = up, next state = txIcrq
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing mibState from idle to connecting
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = txIcrq, event
= txStarted, next state = waitReply
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Changing mibState from connecting to established
INFO 11/02/2015 19:11:49 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Processing incoming in-sequence icrp
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = waitReply,
event = icrp, next state = waitForwarding
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing ifOperStatus from Down to Up
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state =
waitForwarding, event = forwardingEnabled, next state = txIccn
DEBUG 11/02/2015 19:11:49 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = txIccn, event
= txStarted, next state = established
NOTICE 11/02/2015 19:11:49 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing mibState from connecting to
established
NOTICE 11/02/2015 19:11:50 l2tp (interface TUNNEL l2tp:121500/electromech-2):
Discarding incoming duplicate icrp
WARNING 11/02/2015 19:12:06 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Lac incoming open disabled - tunneled
interface down
DEBUG 11/02/2015 19:12:06 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = established,
event = close, next state = txCdnClose
NOTICE 11/02/2015 19:12:06 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing ifOperStatus from Up to Down
NOTICE 11/02/2015 19:12:06 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Changing mibState from established to
disconnecting
WARNING 11/02/2015 19:12:06 l2tp (interface TUNNEL
l2tp:121500/electromech-2/11480336): Lac incoming open disabled - access
interface down
DEBUG 11/02/2015 19:12:06 l2tpStateMachine (interface TUNNEL
l2tp:121500/electromech-2/11480336): lacIncomingSession: state = txCdnClose,
event = reset, next state = txCdnClose
———————————————————————————————————————

INFO 11/02/2015 19:43:05 aaaUserAccess: User: 3113@enginet.ca; id: GigabitEthernet 5/0/0.1380174:138-174; tunnel access granted
DEBUG 11/02/2015 19:43:05 l2tp: Authenticate configuration data: tag = 2, type = 1, transport = ipUdp, routerId = Router 0x80000043, address = 67.69.118.59, tName = electromech-2, tSecret = 3L3c7M3c,
tLocalHostName = bas1-burlington03, tRemoteHostName = , tLocalAddress = 67.69.201.193
DEBUG 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Update IP transport config: local address = 67.69.201.193, remote address = 67.69.118.59
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Changing effective adminState from disabled to enabled
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = closeDown, event = open, next state = openDown
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnelRecovery: state = closeDown, event = open, next state = openDown
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Changing ifOperStatus from LowerLayerDown to Down
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = openDown, event = upActive, next state = txSccrq
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Changing mibState from idle to connecting
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnelRecovery: state = openDown, event = up, next state = idle
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2/11480396): Changing effective adminState from disabled to enabled
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = closeDown, event = open, next state = openDown
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = txSccrq, event = txComplete, next state = waitCtlReply
INFO 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Processing incoming in-sequence sccrp
WARNING 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Remote error in incoming sccrp
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = waitCtlReply, event = badPacket, next state = txStopCcnDisconnecting
WARNING 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500): Changing destination lockout state from not locked to waiting for lockout timeout
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = openDown, event = silentTerminate, next state = resetOpenDown
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2/11480396): Changing mibState from idle to disconnecting
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = resetOpenDown, event = reset, next state = openDown
NOTICE 11/02/2015 19:43:05 l2tp: No more configuration records
INFO 11/02/2015 19:43:05 aaaUserAccess: User: 3113@enginet.ca; id: GigabitEthernet 5/0/0.1380174:138-174; type: 0; terminating: l2tp session call failed
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2/11480396): Changing mibState from disconnecting to idle
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = openDown, event = dying, next state = dying
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = dying, event = dead, next state = dead
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Changing mibState from connecting to disconnecting
INFO 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:109546/accelerated-3): Processing incoming in-sequence hello
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = txStopCcnDisconnecting, event = txComplete, next state = disconnecting
WARNING 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2/11480396): Lac incoming open disabled - tunneled interface down
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2/11480396): lacIncomingSession: state = dead, event = close, next state = dead
INFO 11/02/2015 19:43:05 l2tp: Downstream buffer sent on slot 5
INFO 11/02/2015 19:43:05 l2tp: Upstream buffer received on slot 5
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = disconnecting, event = controlChannelDrained, next state = idle
NOTICE 11/02/2015 19:43:05 l2tp (interface TUNNEL l2tp:121500/electromech-2): Changing mibState from disconnecting to idle
DEBUG 11/02/2015 19:43:05 l2tpStateMachine (interface TUNNEL l2tp:121500/electromech-2): tunnel: state = idle, event = dying, next state = dying
————————————————————————————————————————
But recently MikroTik fixed this issue and after 3 days test I have about 300 active session on my MikroTik RouterBOARD as LNS and my processor " cpu usage is only 1% and this is when my Cisco router with less users used 17% of CPU.

1: Upgrade your RouterOS to " 6.35rc11 (2016-Feb-17 09:09) "

*) l2tp - added support for max-sessions;
*) l2tp - added support for proxy authentication when receiving forwarded PPPoE sesssions;
*) l2tp - added support for Hidden AVP, it is needed for proxy authentication;

2: Enable L2TP Server and make sure using a correct MTU.

3: In L2TP-Secret setup the secret key

4: If you have Radius server " MikroTik Usermanager is the one I'm using " setup radius

You would be fine.

For any questions feel free to reach me on my cell @ (647)-204-0455.
I can help you to setup LNS configuration on your MikroTik Router free of charge.

Any sign of this feature???

I'm down to last two ciscos, I'd hate to have to start the count increasing again...

Any sign of this feature???

I'm down to last two ciscos, I'd hate to have to start the count increasing again...

It is working now! time to move from Cisco to MikroTik.

I can confirm, LNS functionality on Mikrotik attached to Bell Canada is now working correctly with the release candidate package!

Do You mean LAC functionality is working? ie I can authenticate as an L2TP client to a Cisco server (LNS)

What version is this working on?

Great news if it is working

Barry

Do You mean LAC functionality is working? ie I can authenticate as an L2TP client to a Cisco server (LNS)

What version is this working on?

Great news if it is working

Barry

Yes, it is working.
You could use " 6.35rc12 (Release candidate) " version of RouterOS. check the change-log.
I already have 450 active customer on my CCR1036 working very stable.

Please feel free to ask if you have any questions.

When both ends are mikrotik devices ,Is there any benefit to use LAC/LNS in replace of EOIP+Bridge ?

Yup, It works!

even works on 6.34.2 so I can stay off the bleeding edge...


Thanks,

Barry

Currently it is LNS only.

Hopefully LAC will be added soon.

As far as I can see LAC works to the extent that an L2TPtunnel can be established to a Cisco LNS. ( >6.33.4 )

Unfortunately I cannot pass PPPoE sessions over the L2TP to the cisco yet.

Will this happen? (When might this happen?)

I'm currently about to start configuring a Cisco to act as a Mikrotik EOIP concentrator to Cisco PPPoE server bridge ;-<

2U of rack space to replace ???? lines of code?


Barry

@macgaiver

Can you explain how to do proxy LCP from mikrotik? ie how to forward PPPoE session?

That is the component which appears tp be missing from LAC functionality.

If I drop PPPoE into bridge with L2TP client, then there is no PPPoE termianation, if I run a PPPoE server then I cannot authenticate client as I don't have secret for session.

Mikrotik RouterOS currently can not be a LAC.

Maybe one day. . .

Have anyone tried LNS in Fastpath mode? how much faster does it goes? I'm looking for last drop of evidence to give my bosses to get permission to replace some Ciscos

I have only given it brief testing as I lack the provisions to really get a CCR based system to break a sweat in terms of PPP, but judging from my experiences with plain Ethernet routing, Fastpath gives about a 2.5x speedup compared to non-fastpath. When replacing Cisco LNSes with Mikrotik, the devil is in the details (support for radius attribute-value pairs). If you are using any of the Cisco av-pairs in your Radius system, that alone will present quite a hurdle to overcome.

hedele, please provide us with more detailed description, what 'radius' attribute is missing. So we can look into it and find out what is wrong.

Hello sergejs

I am testing LNS from mikrotik, and on the other side (as LNA) there should be a cisco. Well I guess so.

The problem that I see is the following: it seems that the max rate is always configured at 10Mbit, whatever I try. In few words each entry from the PPPoE will have a max download speed of 10M

I tried to figure out what's wrong and I asked to the guys providiing me the LNA. The answer is that "you should use the right radius attributes on your side".

On my side, I do not see any "speed limit", i.e. the queues are there and everything looks great, from the PPPoE point of view.

So I suppose that the limit should be in the LNA<->LNS tunnel, i.e. the l2tp tunnel.

I think some L2TP parameters should be sent or setup somewhere on the mikrotik side. Personally I am not totally convinced that those parameters should be sent from the LNA to the LNS but I am checking with you (mikrotik) to know if there is a way to check the "parameters" of the L2TP tunnels on the mikrotik side. Probably a table in the PPP menu would be great, with the summary for each L2TP tunnel

Let me know if you would need the log file with l2tp debug trace.

P.S. I hope I am not the only one having such a issue!

Regards

So Bell Wholesale is recommending Cisco or Juniper for this. Reading thi thread I am confused if LNS and LAC is fully supported or not? If it's a maximum of 10mbps or doesn't support some geography then this is not service ready.

1- Can someone please weigh in as a whole and specifics of this so we can make a decision to go or not go (preferred) with expensive licensing from Cisco.

2- I understand Cisco and Juniper need licensing based on number of users. Does MikroTek need licensing too for this?

Thanks,

So finally is LAC/LNS supported or not?
If this is a 10mbsp limit or if supports some Cisco and not Juniper or some products and not others then it can't be reliable as a carrier grade product.

1- What is the licensing pricing for this?
2- Can someone sum up if this is really working for an ISP or just stick to old Cisco?

@Torontobb

A basic set of LNS features is supported. No extra licencing is required to use them and there are no bandwidth limits.

The missing features will likely be implemented in RouterOS v7

1- nz_monkey, can you please detail what you mean by basic? What is left to do?

2- what is the release timeline for v7?

1.
- RADIUS VSA's to terminate session in to a VRF
- Ability to run L2TP server in a VRF
- AAA switching. E.g. ability to push request to different AAA profiles based on realm/called station/peer address

2.
Your guess is as good as mine. I don't think even Mikrotik know when it will be released

Thanks nz_monkey. What you wrote under #1 is what is left to do?

See the post from "PDF" stating the 10mbit limit.

Thanks

Yes that is what is left to do. If you don't need those features than the current feature set should meets your needs.

As for a 10mbit limit, we have not seen this. We have LNS clients on 100mbit plans that can reach those speeds.

Hello all,

today we switched some SHDSL, WLL and Leasedlines (QSC AG Germany LACs) from our Cisco to Mikrotik CHR LNS.

The speed is excellent in comparison!

We also miss the possibility to terminate some accounts in a VRF. So the Ciscos unfortunately can not retire.
We also don't see the 10mbit Limit. We have Customers which can reach 100mbit/s without a Problem.

+1 for VRF and differend AAA-Profiles via RADIUS.

Best regards!
-Boris

I can confirm that MikroTik works with L2TP/LNS/LAC fully and as expected.

I do have an issue with not being able to browse all sites and my provider says it's an MTU of 1622 on the interface but is not sure about VLAN2020 and L2TP tunnel. I am assuming I am having an MTU issue so how can I go about proving this is the issue and setting the proper MTU?

They can't also tell me anything if they are using L2 MTU or not. This is Bell Canada by the way. Here is my settings:

https://snag.gy/n6umta.jpg

I do have an issue with not being able to browse all sites and my provider says it's an MTU of 1622 on the interface but is not sure about VLAN2020 and L2TP tunnel. I am assuming I am having an MTU issue so how can I go about proving this is the issue and setting the proper MTU?

Torontobob, MTU can be troubleshot with the ping command line utility. You set a size along with the DF bit set.
This will test for MTU 1500 to 8.8.8.8. It's 20 bytes for the IP header and 8 bytes for the ICMP header and 1472 bytes of good ole spam data.

You'll either get replies back that all is good like:
... or waa waa waa:
Alternatively, you might just get a failed messaged back.

You can use ping commands to test each hop and see what the MTU looks like along your path.

Regardless, MTU sizing shouldn't cause a negative experience unless it's less than 1280 in IPv6 and 576 in IPv4. Managing MTU related tasks like path MTU discovery is a key feature of ICMP. A major reason why certain messages shouldn't be blocked under any circumstance in both ICMP for IPv4 or IPv6. The subject of MTU management, remember where and who is responsible for fragmentaiton. In IPv4 the routers are and in IPv6 the hosts are. This can be seen in IPv6 pretty clearly by the "Packet Too Big" message.

Idlemind - I did exactly that on client end modem and found 1464 to be the largest MTU so with 28 added that is 1492.

I have set my fiber interface to 1492 and no luck. I can ping speed test.net but can't browse it.

To give some background this is two fiber coming into my CCR1036. One from DSL wholeseller which hands the DSL modem traffic to us using LNS/LAC/L2TP and another fiber for IP Transit.

Doing pptp into CCR1036 I can browse any site just fine. But using DSL modem connected I can't browse all site. I thought this might be MTU but I can't tell for sure.

DSL wholeseller is using Alcatel 7750 with MTU 9212 for layer two. For layer 3 I am told their end is a Juniper and they say MTU 6212 but I am not sure if this is on interface, L2TP tunnel, or vlan2020 which they give us.

Also, I don't know if they use L2 MTU or not. I guess that is the Alcatel?!

Bottom line is I can not browse to speedtest.net but I can cnn.com

Is this an MTU issue or something else?

Test MTU along each hop, if you can ping speedtest.net at the MTU size you've indicated then you should get there regardless (caveat - if the http version of the request actually goes to different servers than your icmp test the result could be different). Remember in IPv4 land each router is responsible for fragmentation. It is possible there is a router in the path that has an MTU size that's different and isn't handling fragmentation properly.

Some people see an improvement by using the clamp mss to path mtu feature in the firewall:
Personally, I avoid using this unless I have to, it only addresses TCP connections and it's use likely indicates ICMP or fragmentation is broken in the path. A good test would be to lower the MTU on your router and ensure that it is doing fragmentation and ICMP correctly. You can go down to 1280 if you are using IPv6 or 576 for IPv4 only. It won't be fast but it'll work. By lowering your MTU on your router it is more likely it will assume the fragmentation duties in IPv4 or send the necessary ICMPv6 message to the client to lower MTU before it hits an offending router. Additionally, it may alleviate issues being caused by a host that should be telling your machine to fragment packets or an IPv4 host setup to not fragment packets correctly.

Just to make sure are you rolling in an IPv4 only world or are you dual-stack with IPv6? Additionally I might need to see a diagram to see what you've got going on. It sounds like the problem is customers that are on a DSL modem that ends up getting transported by another provider into your network and handed-off for upstream connectivity. Correct? If that's the case you may need to try to adjust the MTU behind the DSL modem along with troubleshooting why packets aren't being fragmented correctly going into or out of the Alcatel. If the Alcatel's are typically bridged to the customer a really good first step would be to reduce MTU on the customer device. Here in the US that was a major annoyance for years, the DSL modems simply didn't play nice with the fragmentation process. Then, suddenly PPP went away and everyone got 1500 MTU Ethernet hand-offs and it hasn't been an issue but that's another topic for another time ...

By test along the way you mean do a tracert and then my ping test each of those hops?

Thanks,

Yes, that should help identify where your MTU is changing in the path and if you own the router in question you can fix it. If not then you'll have to complain to the ISP that owns the router

Can anyone post a working config for using a Mikrotik as an LAC to a Cisco LNS?

I realise this isn't currently feature ready.

Thanks

Can anyone post a working config for using a Mikrotik as an LAC to a Cisco LNS?

I realise this isn't currently feature ready.

Thanks

update: sorry, only Mikrotik as LNS

- configure you L2TP server
- configure a PPP profile for L2TP
- add l2tp-secret for remote LAC server IP xxx.xxx.xxx.xxx
- configure PPP secret via RADIUS or local

Like:

Can anyone post a working config for using a Mikrotik as an LAC to a Cisco LNS?

RouterOS cannot act as a LAC.
You can only use RouterOS as a LNS currently.

I can confirm that MikroTik works with L2TP/LNS/LAC fully and as expected.

I do have an issue with not being able to browse all sites and my provider says it's an MTU of 1622 on the interface but is not sure about VLAN2020 and L2TP tunnel. I am assuming I am having an MTU issue so how can I go about proving this is the issue and setting the proper MTU?

They can't also tell me anything if they are using L2 MTU or not. This is Bell Canada by the way. Here is my settings:

https://snag.gy/n6umta.jpg

Hi there,
Judging by your username, am I correct in assuming you're using Bell Canada AHSSPI to provide Wholesale DSL? If so, did you ever get this sorted out? I'm in the same boat as you right now -- I'm about to move from Cisco to Mikrotik for Bell LNS and just noticed the 1622 MTU mentioned in an old email from a Bell engineer, however looking at my Cisco config, I don't have any interfaces or templates set for MTU1622...

Yes, we got it done and working well. Quiet a bit of work though. However, I can confirm it works.

Yes, we got it done and working well. Quiet a bit of work though. However, I can confirm it works.

Torontobb, you mind sharing your email contact? I have a few questions, wondering if you'd be kind enough to help us out.
Edit: I've actually got most of the config completed and am fairly confident what we have is going to work. I'm moving from Cisco to Mikrotik and just want to compare a few items before our maintenance window later this week.

Hey sorry I was not watching this email.
I can post our configs here once you ask your specific questions.

How many users are going to support and what model of MT are you using?

Hey sorry I was not watching this email.
I can post our configs here once you ask your specific questions.

How many users are going to support and what model of MT are you using?

Hey there
I got it all working. Thanks anyways!

Dear Mikrotik,

we are still searching for a way to replace our Cisco Dial-In VRF setups.

It would be great if the following LAC feature could be implemented:

1. Create a new L2TP endpoint / LNS
2. Radius attribute to forward PPP sessions to this other endpoint.

Under mpd this is possible after my research:

create link template VRF01 l2tp
set l2tp peer 1.2.3.6
set l2tp peer 1.2.3.8 (redundant LNS)

Radius attribute:

mpd-action = "forward VRF01"

In this way, PPP sessions could be forwarded to private LNSs. So we can map them to VPNs without VRF implementation.
We only need additional CHR or hardware routers.

Thank you and best regards!
-Boris

Are there any improvements or info about lac support?

I would be very interested if LAC features were supported in RouterOS. A popular way to run PPPoE in a WISP network is by using VPLS, which is a very attractive option. However, If the tower site router could be used as a LAC, then the PPPoE session would be simply turned into an L2TP connection which can be nicely routed through an OSPF routed network, rather than extending a layer2 segment all the way through the network back to the edge / core with VPLS.

It has the benefit of having the PPPoE server be right at the tower, but without actually needing to manage the routing / firewall for the public IPs since they're handled at the core. It would also be more flexible in cases where we may not be able to run VPLS to all segments of a network. With IPSEC encryption thrown on top of the L2TP session, the pppoe sessions could potentially go over the public internet as a backup.

There is so much potential with LAC, I'd love to see it happen on Mikrotik!

Just as an update, I got the following response from Mikrotik support.

LAC feature is moved to RouterOS v7 as new Linux Kernel will make implementation much more easier, so currently LAC is not supported. Sorry.

Regards v7, yes, we are working on it, no dates atm.

Back to waiting for v7...

My use-case is to push dial-in connections from machines into meta-router instances. Without this, I cannot pass the PPP termination into the metarouter. With 6.41.x, due to problems with being unable associate dynamically generated tunnel interfaces (from multiple logins) - with a VRF domain, I cannot achieve exactly what I wanted.

Mikrotik support - hello... do you have any idea when v7 might begin to be trialled by beta customers?

We use a few Cisco 7206 routers as a LAC to allow third parties to have wholesale access to our network. I have heard this is fairly commonplace. If RouterOS could function as a LAC, we would replace those Ciscos very quickly. Additionally, I mentioned above that having a LAC at every site would make it very easy to deploy redundant PPPoE access for our customers.

Sorry to pitch in on a 10 (yes 10!) year old thread but can Mikrotik give us ANY indication of v7 or LAC function being implemented?
PLEASE

NTB

Sorry to pitch in on a 10 (yes 10!) year old thread but can Mikrotik give us ANY indication of v7 or LAC function being implemented?
PLEASE

NTB

Hi NTB.

Your best bet would be to email support@mikrotik.com - The forum is for User to User support, while the Mikrotik guys do post here, the official channel is via the support email.

Thanks for the reply. I'll send an email

Here's the reply I got from support:

On 11 June 2018 at 07:04, Emils Z. [MikroTik Support] <support@mikrotik.com>
wrote:

> Hello Norrie,
>
> Although LAC is currently not supported in RouterOS, it is possible to use
> RouterOS as LNS. LAC support may come in future, but there are no direct
> plans as of yet.
>

ATM I've been playing with a couple of virtual instances of bsdrp followng the example below and using a CHR instance to generate 50 pppoe client connections. Is anyone able to share a working Mikrotik LNS configuration please?

https://bsdrp.net/documentation/example ... ab?s[]=lns

There's not much to it.

Add the L2TP secret for the tunnel ranges, if your LAC requires it:
Enable L2TP server:

Now L2TP tunnels will be created from each user according to your PPPoE profile.

ATM I've been playing with a couple of virtual instances of bsdrp followng the example below and using a CHR instance to generate 50 pppoe client connections. Is anyone able to share a working Mikrotik LNS configuration please?

Are there any mainstream OSes like PFsense, VyOS or similar that support LAC? Until RouterOS supports it, as far as I can tell there's no compact and low-power routers that support that feature. I can't physically fit a Cisco 7206 into a small cabinet and run it off a couple small batteries like I can with a Mikrotik hEX or something. The best option at the moment seems to be a low-power ruggedized PC.

I got this up and running in eve-ng https://bsdrp.net/documentation/example ... d_l2tp_lab
I've just bought an APU2 https://www.pcengines.ch/apu2.htm and I've installed BSDRP but I've not had time to test it yet

NTB
8o)

I did a base FreeBSD install on an old PC with a few NICs and I followed this guide to get MPD5 installed. I only used the install instructions, since the configuration is for something differently. http://dnaeon.github.io/installing-and- ... n-freebsd/

Once installed, I copied the sample config (mpd.conf.sample) to mpd.conf, then changed the configuration to load the "simple_lac" config.
In the simple_lac configuration further down, I added an L2TP secret and changed the L2TP peer IP to my LNS Mikrotik router. On the LNS Mikrotik router, I added an L2TP secret with the IP of the FreeBSD box.
I plugged my laptop into the fxp0 NIC, established a PPPoE session using Windows 10 and everything worked. The FreeBSD box forwarded the session to the Mikrotik LNS as an L2TP tunnel and the LNS accepted it as normal. Unfortunately, there seems to be some limitations compared to using a Cisco 7206 or something similar. There doesn't appear to be a way to specify a PADO delay to handle load balancing / redundancy and I can't seem to figure out if there's a way to specify a secondary "backup" L2TP IP that it can round-robin or to use if case the first IP fails. This makes having redundancy a bit difficult unless the LNS's L2TP server IP is handled with VRRP or some other trick.

Another option is ProL2TP on Linux, though licensing is $1000+ per LAC depending on user count and some of the missing features I mentioned are coming but not yet implemented.

So, not great options so far... Come on Mikrotik! We'd love to see LAC built in natively so we're not strapping full PCs or ARM boards running BSD to a Mikrotik router