Here, in black and white:Where did you see l2tp keepalive in manual?
Here I can't find any:
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.delete that document. where did you find it? you can see it's at least 3 years old (see footer)
If it was never there the Documentation I was using was unreliable even when it was brand-new.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!
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 or session timeout in ppp profile
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!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.
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.If client can reach the server it will establish new session right away. So I don't see any problems.
No.are you saying it's idle timeout is actually set to something and you can't change it?
The problem is NAT traversal and connection timeouts. Sometimes traffic has to flow just to keep the NAT state tables up to date!Ive got tunnels that have been up for months with barely any traffic traversing them.
We are looking to use a Mikrotik as an LNS also from a Cisco LAC.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).