Timeouts

Wer (W)LAN-HotSpots auf Mikrotik-Basis einsetzt, wir mit mindestens 3 Timeouts konfrontiert:

• Idle-Timeout
  Maximal period of inactivity for authorized HotSpot clients. Timer is counting, when there is no traffic coming from that client and going through the router, for example computer is switched off. User is logged out, dropped of the host list, the address used by the user is freed, when timeout is reached.
• Session-Timeout
  Allowed session time for client. After this time, the user is logged out unconditionally.
• Keep-Alive-Timeout
  Keepalive timeout for authorized HotSpot clients. Used to detect, that the computer of the client is alive and reachable. User is logged out, when timeout value is reached. [Anm.: Wird technisch als ARP-Request umgesetzt, der nach 50% des Timeouts vom Router an den Host gesendet wird.]

Je nach dem welcher Timeout konfiguriert ist und welcher zuerst abläuft, wird der Benutzer früher oder später ausgeloggt.

 

Sonderfall

Ein Sonderfall tritt ein, wenn Benutzer sich außerhalb des Netzbereiches aufhalten und bei Rückkehr sich nicht neu anmelden sollten müssen. Dazu sollten die Timeouts natürlich entsprechend lange definiert werden.

Ein praktischer Anwendungsfall trat bei einem Corona-Testzentrum auf, bei welchem sich die ehrenamtlichen Mitarbeiter im Rhythmus alle paar Tage abwechseln. Die notwendigen Endgeräte kommen auch nur zu den jeweiligen Einsatzzeiten der Mitarbeiter in den Netzbereich. Die Geräte sollten immer eingeloggt bleiben, entsprechend lange Timouts wurden gewählt. Allerdings traten trotz dieser sehr langen Timeouts ungewollte „Logouts“ auf:

 

 

Als Grund wurde vom RADIUS immer ein „Lost-Service“ geloggt. Damit ist – unter anderem – der Ablauf der DHCP-Lease gemeint. Ist diese zu kurz eingestellt, wird der Benutzer bei Ablauf der Lease ebenfalls automatisch ausgeloggt!

 

DHCP-Lease

Die DHCP-Lease sollte demnach immer entsprechend lange eingestellt sein.
Die folgende Faustformel hat sich bewährt:

DHCP-Lease [t] = längster Timeout [t] ÷ T1

Beispiel:

Längster Timeout = 7 Tage
T1 = 0,5 der DHCP-Lease (RFC2131)
7 ÷ 0,5 = 14

Die DHCP-Lease sollte in diesem Beispiel mindestens 14 Tage betragen, um auch im denkbar schlechtesten Falle nicht vor einem Timeout abzulaufen.

 

Schlussgedanken

Da sich je nach Dauer der DHCP-Lease und der potenziellen Nutzer ein hoher Verbrauch an IPs ergeben kann, sollte der entsprechende Pool großzügig dimensioniert sein.

Leider ist es bei Mikrotik nicht möglich (Stand Juni 2021), den Verbrauch eines IP-Pools per SNMP auszulesen. Ein entsprechendes Monitoring wird dadurch erschwert. Jedoch können DHCP-Leases ausgelesen werden, was aber zu einer (geringen) Unterschätzung des IP-Adressverbrauchs führen kann (nicht jede verbrauchte IP wird durch den DHCP-Dienst aggregiert!). Dies sollte bei einem Monitoring berücksichtigt werden.