AW: (RADIATOR) Assign IP

[Hugh Irvine]

Hello Martin -

Many thanks for your most thoughtful discussion.

I agree that multiple named pools on the NAS equipment is the  
preferred approach.

regards

Hugh


On 23 Feb 2006, at 10:20, Martin Wallner wrote:

> David,
>
> assigning dynamic IP through RADIUS is a tricky business... It  
> would be easier to give the users standard IP's via their login and  
> route them through the network or use local pools for usergroups on  
> the NAS. Believe me. There is a way around this MOST UGLY way to  
> deal out addresses, even if it don't look like it yet when you look  
> at your project...
>
> The thing with direct allocation from RADIUS is, that you are  
> getting too dependend on the functioning of the RADIUS server, it  
> also has to track and update the ip-allocation table and the  
> radonline table, to remove and reuse IP's. One single lost request  
> series can bring the database out of sync with the real situation,  
> and you can become 'stuck' dynamic IP-Adresses (a) on RADIUS side,  
> which would bring up the nice problem that it might be put out  
> twice, (b) on NAS side, where the IP is still in use, and the  
> RADIUS is happily giving it out to the next one... and you have (a)  
> Situation...You/RADIUS has to track the availiability of the NAS 
> (es) and deal with it accordingly.
>
> To clean up such stuck IP-Adresses you normally need to clean up  
> the database (which means that you open the database, look after  
> the IP, and have to look up all the NASes where it could be used  
> and clear the connection). After the 5th or 10th IP you are  
> checking so, you have to go up to top and do it again, because you  
> still don't know... so you normally end up with a complete reset of  
> the pool database and you just kick all users out from the NAS to  
> restart the IP allocation process...
>
> I inherited such a system (with steelbelted radius) when we took  
> over a company, and it was FASCINATING to see how the support and  
> cc-people hammered on the databases at least once a week, to clean  
> up stuck addresses, while trying to calm down customers, who could  
> connect, but couldn't do anything (because the NAS(es) did a 'load  
> balancing' between two different users... :-/)
>
> Even before I could finally implement something useful (RADIATOR)  
> on this POS, I removed the dammned Dynamic Allocation by Radius  
> from the old system and implemented local default pools directly on  
> the NAS.... MUCH better, I was the hero of support and cc (for a  
> day :-), and since then this works like a charm...
>
> 2 Possible workarounds (straight from my head and without knowing  
> your case) instead dynamic allocation per RADIUS:
> a) static IP's, given out for users who ARE moving from one NAS to  
> another (and let whatever IGProuting you are using in your  
> infrastructure do the rest), directly brought in in the user  
> database on a per user base ....
> b) local named pools on the NAS .. RADIATOR generates the av-pairs  
> necessery for the user who requests access, so that the NAS just  
> dynamically gives out of the pool he got instructed to by RADIUS  
> (that needs a unique pool of adresses on each router per group and  
> uses a bit more ip-adresses this way, but you can finetune it).  
> brought in into the user (group?) database... and you can avoid  
> dynamic routing with this, when it's not available on some/all NAS...
>
> Martin
>
>
>
> Von: owner-radiator at open.com.au im Auftrag von David Felipe Rios Rojas
> Gesendet: Mi 22.02.2006 21:31
> An: radiator at open.com.au
> Betreff: (RADIATOR) Assign IP
>
> Hello.
>
> Radiator has successful finished first test; it authenticates and
> replay connection attributes to RAS.
> Now I want to make it more complex: Several RAS must not assign
> dynamic IP, so Radiator should do it; I've read Reference Manual
> but I don't see information about this; how could I do it?
> This can not be a general feature because some RAS _must_ assign
> dynamic IP and Radiator should not; that's depending of RAS IP
> address.
>
> Regards,
>
> --
> David Rios R.
> Equipo Ingenieria de Desarrollo
> Unidad Gestión Tecnológica
> Empresas Publicas de Medellin
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.