Radius Timeout
RouterOS general discussion

11 posts   •   Page 1 of 1
User avatar
Reefbum
Frequent Visitor
Frequent Visitor
 
Posts: 62
Joined: Sun Apr 23, 2006 12:00 am

Radius Timeout

by Reefbum » Wed Nov 29, 2006 5: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: 2771
Joined: Mon May 31, 2004 2:55 pm

by uldis » Wed Nov 29, 2006 6:23 pm

In the next releases of RouterOS the timeout setting max value will be 3s.

User avatar
Reefbum
Frequent Visitor
Frequent Visitor
 
Posts: 62
Joined: Sun Apr 23, 2006 12:00 am

by Reefbum » Wed Nov 29, 2006 7: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: 398
Joined: Thu Jan 26, 2006 7:24 pm
Location: Southeast Kansas

by nickb » Wed Nov 29, 2006 9:03 pm

Things like this should be in the change log!

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

by uldis » Thu Nov 30, 2006 12:39 pm

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.

User avatar
Reefbum
Frequent Visitor
Frequent Visitor
 
Posts: 62
Joined: Sun Apr 23, 2006 12:00 am

by Reefbum » Fri Dec 01, 2006 9: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 4:59 am, edited 1 time in total.

spire2z
Long time Member
Long time Member
 
Posts: 517
Joined: Mon Feb 14, 2005 3:48 am

by spire2z » Sat Dec 02, 2006 3: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: 159
Joined: Thu Dec 09, 2004 1:58 pm
Location: Castellón

by awacenter » Mon Dec 04, 2006 11: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: 2771
Joined: Mon May 31, 2004 2:55 pm

by uldis » Mon Dec 04, 2006 6: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.

User avatar
cmit
Forum Guru
Forum Guru
 
Posts: 1551
Joined: Fri May 28, 2004 12:49 pm
Location: Germany

by cmit » Tue Dec 05, 2006 10: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 2:16 pm

by freebird » Tue Dec 05, 2006 11: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
--

11 posts   •   Page 1 of 1

Who is online

Users browsing this forum: 43north, Bing [Bot], Google [Bot] and 33 guests

It is currently Sat Nov 22, 2014 11:25 am