AW: (RADIATOR) Assign IP

[Martin Wallner]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060223/4f3407b8/attachment.html>