Community discussions

MikroTik App
 
Reefbum
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Sun Apr 23, 2006 12:00 am

Radius Timeout

Wed Nov 29, 2006 4:39 pm

We have been using MT-2.9.32 on a hotspot setup using satellite connections.
Our radius servers are located here in our data center, due to the latency of the VSATs we have MT radius timeout set at 10000ms.

We upgraded to MT-2.9.38 last night and since then we have seen errors and timeouts in our logs. When going in to check the MT boxes we found that the radius time out setting will no longer allow us to use 10000ms for the time out and now it gives us a popup saying the range can only be 10~3000ms

Is there a reason this was done? We need our time outs higher than the 3000ms the new release allows.
Our networks are based in several countries and all the radius and web servers are located here in the US in our data center. Add this to the fact that our sites use VSATs and the latency is to high for the new release limits.

For now we have had to down grade all the boxes back to 2.9.32 so they will operate correctly.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

Wed Nov 29, 2006 5:23 pm

In the next releases of RouterOS the timeout setting max value will be 3s.
 
Reefbum
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Sun Apr 23, 2006 12:00 am

Wed Nov 29, 2006 6:27 pm

Is there a reason for this, or is this just something else MT thinks we all need? I don't see why there needs to be a limit on this or at least put a limit that can be used over Satellite links.

As it is now we will be stuck using the 2.9.32 ver as a 3s timeout just will not work for us. Our 10s timeout has been working well for us but set at 3s and we see many resends and timeouts in the logs.

We also did not see a reference to this change in the change log, at what version was this limit introduced?
 
User avatar
nickb
Member
Member
Posts: 406
Joined: Thu Jan 26, 2006 6:24 pm
Location: Southeast Kansas
Contact:

Wed Nov 29, 2006 8:03 pm

Things like this should be in the change log!
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

Thu Nov 30, 2006 11:39 am

what value do you see for this field "last-request-rtt" when you monitor the radius client?
This is done because, for example, for pppoe this timeout is to long - everything will be already timeouted.
 
Reefbum
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 64
Joined: Sun Apr 23, 2006 12:00 am

Fri Dec 01, 2006 8:01 pm

The average rtt we see is 3500ms ~ 4500ms

VSAT Latency to servers is about 1s
Radius is set to a 1s delay to help slow down any dos attacks
sql sometimes takes 1s to do the query (very large data bases)
VSAT Latency back to MT box is about 1s

This is of course perfect weather conditions, at our locations and perfect weather at the NOC location, if there are bad weather conditions the rtt time can reach 8-10s

I understand the issues of pppoe but I still don't understand why we as the users can't set our own radius timeouts in the newer versions like we can in the version we have had to roll back to.
Last edited by Reefbum on Sat Dec 02, 2006 3:59 am, edited 1 time in total.
 
spire2z
Long time Member
Long time Member
Posts: 516
Joined: Mon Feb 14, 2005 2:48 am

Sat Dec 02, 2006 2:46 am

Thats seems weird! Normally MT allows the user complete control and if there is a problem it's yours for configuring it wrong. Thats one thing I like about it! This seems to be a bit low and I have used satellite links too and 3s would be too little to guarantee a reply in all circumstances.
 
User avatar
awacenter
Member Candidate
Member Candidate
Posts: 201
Joined: Thu Dec 09, 2004 12:58 pm
Location: Castellón
Contact:

Mon Dec 04, 2006 10:31 am

I test lot of cases about a slow conexion (because of weather conditions, latency, ...), but I remark if you use a DB attached to radius server, this DB can be very slow, too. It happens because the DB has a hight load or a lack of memory of the machine.

Obviously, the unique solucion to mt is to wait, so the /radius timeoute has to be hight. Above all, this high timeout is usefull for roaming services because radius server do proxy radius and some AAA servar are too far or too slow to answer. My normal time in these cases are 8 secs.

Santiago
 
uldis
MikroTik Support
MikroTik Support
Posts: 3446
Joined: Mon May 31, 2004 2:55 pm

Mon Dec 04, 2006 5:13 pm

the clients will not waill so long if you have such high timeout, for example, if you have more that 10 clients connecting at the same time.
 
cmit
Forum Guru
Forum Guru
Posts: 1547
Joined: Fri May 28, 2004 12:49 pm
Location: Germany

Tue Dec 05, 2006 9:07 am

If the high latency is inherent to the network in question, you can just tell your clients that it WILL take that long - and they WILL wait, if that's the only way to get internet...

Of course USUALLY so high timeouts will be too long and won't be necessary. But there are those situations (like the described satellite links) where you NEED to set the so high just to make things work.

RouterOS always prouds itself (and that's a big part of why I like it so much) of being super-flexible - this is clearly a step in the wrong direction here (although not affecting most users).

And - hey: What's the problem in just letting people configure the timeout they like? It's not that this should be something RouterOS is limiting by itself!

Best regards,
Christian Meis
 
freebird
Frequent Visitor
Frequent Visitor
Posts: 98
Joined: Sun Feb 20, 2005 1:16 pm

Tue Dec 05, 2006 10:27 am

We too having some experiences with RADIUS authentification and
have to agree that 3000ms is too short. We usually set it to 10000ms (10s).

If you have a well stuffed DSL line because of many surfing customers,
the RADIUS connection can take some time. Especially if you are doing
roaming with other providers like "awacenter" already noticed.

We have far more INTERIM updates than START or STOP messages. And
the customer doesn't notice if this INTERIM update takes 1 or 7s.
But it should not run in a timeout ...

Please keep it flexible ... this fact is an argument for us not to update
at the moment.

seandsl
--

Who is online

Users browsing this forum: CJWW, Google [Bot], GoogleOther [Bot], keithy and 80 guests