OK, I give up.
According to the manual for v3.0 L2TP-server has a keepalive-timeout setting, but in V3.30 I can’t find it.
PPTP server set-up has a windows to set Keepalive, but L2TP doesn’t. You can set idle-timeout in ppp profile, but not keepalive.
Can anyone give me a clue as to the obscure and convoluted means MT in its wisdom has decided to deal with this?
Where did you see l2tp keepalive in manual?
Here I can’t find any:
http://wiki.mikrotik.com/wiki/Manual:Interface/L2TP
Here, in black and white:
Link I provided earlier is the latest manual for v3,v4 and v5. Do not look at old manuals.
delete that document. where did you find it? you can see it’s at least 3 years old (see footer)
I check the documentation for new protocols or ones that are still developing. L2TP is a lot older than 3 years and well established, and frankly I can’t imagine why you should suddenly decide to drop keep-alive timeouts from L2TP but keep them for PPTP and PPPoE.
So why have you unilaterally decided L2TP no longer needs keep-alive timeouts?
And how do I close down tunnels where the client was powered off without a controlled shutdown?
Maybe it was not dropped, but initially L2TP documentation had mistakes from Copy/Paste of other documents … Protocols are not the only ones that are constantly being developed. So is documentation!
If it was never there the Documentation I was using was unreliable even when it was brand-new.
However, that’s beside the point. If Mikrotik’s implementation of L2TP server has no keep-alive function what’s to stop dead tunnels cluttering up the server’s interface list for ever?
idle timeout or session timeout in ppp profile
Sorry, but neither of these meet the case. Subscriber sessions are not time limited so adding a session timeout could kill the tunnel while it’s being legitimately used. And if I put in an idle time-out what happens if the session idles out overnight and the subscriber wants to check his emails in the morning without having rebooted his Mikrotik?
Idle timeout drops the session between the server and client. If client can reach the server it will establish new session right away. So I don’t see any problems.
The problem would be that for those of my subscribers who leave their CPE on 24/7, and most of the rest who leave it powered up between checking their emails first thing in the morning and shutting off the power to everything when they go to bed, idle-timeout will be dropping and restarting sessions every few minutes for maybe 20-hours a day - each one adding yet another session record to a User-Manager database which already groans at the seams with unnecessary session records. I once had over 200,000 sessions and a full hdd I had to manually clear!
If a keep-alive timeout is good enough for P2P and PPPoE, why isn’t is good enough for L2TP?
Where all communications are initiated by the client, then this may well work. However in the real world (and particularly for the purposes L2TP is put to), communications are often initiated from the server end. What you suggest is certainly not a fix in this case.
Having hit this problem ourselves, the only way around it I found was to use netwatch to ping the L2TP server on a regular basis.
It would be very useful to have the keep-alive functionality within the L2TP client itself.
i am using 40-50 l2tp tunnels in my network. never have i had a tunnel disconnect unless there is packet loss. are you saying it’s idle timeout is actually set to something and you can’t change it? Ive got tunnels that have been up for months with barely any traffic traversing them.
hello
we are missing the keepalive feature too, right now our setup:
CPE (dsl) → LAC (wholesale partner) → LAC (our cisco) → LNS (mikrotik)
the problem is, if for some reason the cpe goes down (loses sync or such) then the tunnel between CPE and first LAC is being dropped properly,
but mikrotik still belives it is up, keeps the tunnel between MT and our LAC running and dosnt allow the client to reconnect - manual disconnect ist required,
we cannot put CPE into netwatch as different modems/routers are used, most of them with icmp blocked.
any chance to get keepalive working or other idea how to fix that?
regards
Hi,
sry to pick up this old thread again, but i’ve the same problem. Any solution yet?
I don’t understand why it’s so hard to implement this feature. The effort would be so low 
Greetz
Frankly, I don’t have that problem.
I also tried the LAC (Cisco) → LNS (Mikrotik) variant of tunneling dsl connections,
and if I pull the dsl cable from the modem, it only takes about 30 seconds for the l2tp server interface to disappear.
So, I guess there’s a 30 second hard-coded keepalive (at least in 5.17, which is what I used).
Yeah but if sync breakes and comes up again under 30seconds. The l2tp tunnel is created dynamic, this is what i prefer to avoid.
No.
The problem is NAT traversal and connection timeouts. Sometimes traffic has to flow just to keep the NAT state tables up to date!
What’s new in 5.22 (2012-Nov-23 09:28):
*) l2tp server - added keepalive-timeout setting;
Thanks!