Hello,
we are a Small WISP in Germany Have following Problem.
a ESXI Server in Cloud with paar Public IP Address installed on it a Router OS mikrotik as PPPoE Server to our Client.
in our Office have a internet connection of 150 Mbits down 15 up.
there is a L2tp Tunnel from Esxi Mikrotik to Cloud MIkrotik CCR in Office and from office go all of the traffic to customers over wirelless.
MTU for L2TP is 1500 here we got in office max 40 Mbits were we can transfer to Customers.
if we set the MTU to 1420 or 1450 of the L2TP, we got the full Speed of 150 Mbits in Office that we can give out to customers.
but with this MTU Value some Customers cant open some website or apps on Smart Phone like google play Store and i say here only few not all what is confuse me (they can ping the sites they cant open , or open after long time )..
the MTU Value of the L2tp 1500 is stable and all can open any site or app but it give a 40 Mbits speed over Tunnel ..
any help will be thankfull.
If you control the customers routers you can lower the mtu or change tcpmss on the firewall so the customer outputs a lower mtu size.
Hi ,
Can you please give a simple explain about what is tcpmss and how affect mtu and how can i do. it in Firewall ?
Well customers have mikrotik or avm fritzbox routers ,
I can Not lower mtu in fritzbox .
By the way connected pppoe showing in Server Show mtu size from 1480 Not 1492 as default should be.
Put this on your MikroTik router:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes
protocol=tcp tcp-flags=syn
hi well the regel you gaved me it is already in the mangel Firewall as dynamic installed..
the TCP MSS is 1421 - 65535 new TCP MSS 1420 on the out INterface all PPP
the TCP MSS is 1361 - 65535 new TCP MSS 1360 on the in INterface all PPP
These are dynamic regel when L2TP MTU and MRU is 1500 .
thank you
Dear all,
I have a PPPoE over L2TP in LNS mode, LAC is CIsco Router and my LNS is CCR1072 but I have one problem when all ppp disconnected, so the ppp not turn UP if on Cisco Router do not disable an enable the primary L2TP tunnel. After all the ppp session have disconnected, on the log I not see request of connection, If our carrier throw primary L2TP tunnel down so I receive request.
I use this guide for configure my LNS: https://blog.vayu.it/wp/index.php/2015/11/06/pppoe-over-l2tp-in-lns-mode-powered-by-mikrotik/
Thank you and best regards,
Hi Furuzi,
I see you old post about tunnel disconnection and I encounter the same. I tried many versions of routerOS, many CISCO parameters and I still got a tunnel disconnection on all my Mikrotik LNS… except one 
.
I’ve sorted the Cisco logs and it seems that after a period of time, Mikrotik does not send ICRP or ZLB anymore to maintain the tunnel. I also tried without L2TP tunnel authentication and it’s the same behavior. in green the normal operation for many days, IRCQ and ZLB ack, in orange Cisco does not receive ICRP, in red, timeout, start of disconnecting PPP in tunnel, and then tunnel reset:
2021-08-25 10:52:20.655 172.31.131.2 L2TP tnl 2167B4:0000D22B: FSM-CC ev Session-Conn
2021-08-25 10:52:20.655 172.31.131.2 L2TP tnl 2167B4:0000D22B: Search for cc: found existing cc
2021-08-25 10:52:20.655 172.31.131.2 L2TP tnl 2167B4:0000D22B: Session count now 345
2021-08-25 10:52:25.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:52:25.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:52:26.040 172.31.131.2 L2TP tnl 2167B4:0000D22B: Rx Hello, flg TLS, ver 2, len 20
2021-08-25 10:52:26.040 172.31.131.2 L2TP tnl 2167B4:0000D22B:
2021-08-25 10:52:26.040 172.31.131.2 L2TP tnl 2167B4:0000D22B:
2021-08-25 10:52:26.040 172.31.131.2 L2TP tnl 2167B4:0000D22B: Tx ZLB ACK to ZH_PPPoE_Core tnl 120
2021-08-25 10:52:26.040 172.31.131.2 L2TP tnl 2167B4:0000D22B:
2021-08-25 10:52:33.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:52:33.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICRQ, flg TLS, ver 2, len 92
2021-08-25 10:52:33.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:52:41.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:52:41.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICRQ, flg TLS, ver 2, len 92
2021-08-25 10:52:41.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:52:49.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Retransmit timer temporarily adjusted from 8000 ms to 1000 ms
2021-08-25 10:52:50.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:52:50.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:52:50.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICRQ, flg TLS, ver 2, len 92
2021-08-25 10:52:58.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: Retransmit timer temporarily adjusted from 8000 ms to 1000 ms
2021-08-25 10:52:59.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:52:59.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICRQ, flg TLS, ver 2, len 92
2021-08-25 10:52:59.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:53:07.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend CDN, flg TLS, ver 2, len 55
2021-08-25 10:53:07.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICCN, flg TLS, ver 2, len 177
2021-08-25 10:53:07.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: O Resend ICRQ, flg TLS, ver 2, len 92
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: General error - refer to error code
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Vendor specific
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Error Code
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Optional Message
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: FSM-CC established->Wt-STOPACK
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Shutting down tunnel
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Vendor Error
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: FSM-CC do Tx-StopCCN
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: FSM-CC ev Shut
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Tunnel shut
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: “Too many retransmits to 172.31.150.211”
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B:
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: Result Code
2021-08-25 10:53:15.649 172.31.131.2 L2TP tnl 2167B4:0000D22B: With 345 sessions
2021-08-25 10:53:15.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: FSM-CC in Wt-STOPACK
2021-08-25 10:53:15.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: VPDN Session count now 344
2021-08-25 10:53:15.650 172.31.131.2 L2TP tnl 2167B4:0000D22B: Session count now 343
I also tried with physical router instead of CHR, changing path, splitting tunnels to limit PPP. Nothing correct this tunnel lost.
Does anyone have stable L2TP LNS tunnels ?
Best Regards
Hi abyss
We have the same situation with an cisco asr1002 as LAC and a mikrotik router as LNS but we noticed after a packet loss or some kind of interruption, the l2tp tunnel go down and users on the LAC go to “dead” state.
We have to reset the tunnel after each interruption.
As i was going through the logs on my cisco router, it looks like the LAC is sending ICRQ(Incoming-Call-Request) but the LNS is not sending or the LAC not receiving an ICRP(Incoming-Call-Reply).
Did you or anyone figure out how to resolve this problem?
Thanks
Amir