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