IMPORTANT - Re: (RADIATOR) AddressAllocator

[Hugh Irvine]

Hello Leon -

On Sat, 9 Feb 2002 09:53, Leon Oosterwijk wrote:
> All,
>
> I have a question about the AddressAllocator feature in Radiator. I'm
> thinking about implementing this for our dialup network. We currently have
> a fair number of IP Pools that are maintained on the NAS units themselves.
> This is turning into an unmanageable situation. I researched how easy it
> would be to implement the Radiator ip-pool management with AddressAllocator
> and <AuthBy DYNADDRESS>. Which researching I ran into a couple of issues
> I'd like some clarification on before I proceed with the implementation.
>

OK.

> 1: We have people sign up with up to four bonded (isdn) channels. How will
> these three login requests that follow the first one be handles. In other
> words, will radiator hand out an ip for each of the fourse requests?

You will need to check a trace 4 debug from Radiator and compare the 
Access-Requests in each case to see whether there is some way to identify the 
requests for additional channels. As long as there is a reliable way to 
identify such requests, it is fairly simple to construct Handlers to allocate 
an IP address only on the first request. Note that it will also be necessary 
to recognise the corresponding Accounting-Stop records, so as to de-allocate 
the IP address correctly (you could possibly use the Class attribute for 
this).

> 2: we have some users that dial in with the same username in different
> places and into different (or the same) NAS units. Obviously username is
> not enough of a unique identifier to delete pool information for. (if an
> needs to be reclaimed and radiator issues a sql statement to reclaim the ip
> for 'username' another user dialed in under the same username would also
> lose his/her ip assignment and the ip is liable to be handed out twice) 

The username is not used by the default DeallocateQuery - the IP address 
itself is used. Again, see the caveat above.

> 3:
> We currently have about 50% of the people dial in with a static ip and the
> other 50% will be dynamic. How will the ippool engine know which users to
> hand a dynamic ip and which ones not to. ? (currently this works by sending
> both a pool statement and a Framed-IP-Address attribute. The Framed ip
> address will take prededence if the ip information is not
> 255.255.255.254)

If a user definition contains a Framed-IP-Address reply attribute that is 
added to the Access-Accept *before* the call to the AuthBy DYNADDRESS clause, 
the address allocator will not allocate an additional address. Ie - the reply 
is checked to see whether there is already a Framed-IP-Address present, and 
if so no action is taken.

> 4: Is is possible to have the IPPOOL database definition in the
> AddressAllocator point to a second (backup) database that will hold ip
> information as well, incase the first one goes down.
>

This is possible, but you cannot have the same address pool definitions in 
the two databases, as there is no way to synchronise them. This is similar to 
the restrictions with DHCP.

If you have any other questions, please ask.

regards

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
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.