--- /dev/null
+From: miquels@cistron-office.nl (Miquel van Smoorenburg)
+Subject: Serverside IP pools design [was: Re: Questions on IP address allocation]
+Date: Tue, 13 Nov 2001 13:29:24 +0000 (UTC)
+Message-ID: <9sr77k$ofn$1@ncc1701.cistron.net>
+To: freeradius-devel@lists.cistron.nl,freeradius-users@lists.cistron.nl
+
+In article <DE6495F924D2304DA0FAD60FC1C00601150E3B@AVIANSERVER.aviancommunications.com>,
+John Padula <john_padula@aviancommunications.com> wrote:
+>I'm still looking into IP address allocation via the "+" option.
+>I wanted to check if there's any sense of a lease or expiration on the
+>IP address
+>given out.
+
+No, and that's not really neccesary either, since other than with
+DHCP you have strictly defined session start- and stop points.
+
+>I've checked the RFC and didn't see any mention of this, but
+>wanted to
+>make sure.
+
+Because IP address allocation is completely outside the scope
+of the Radius RFC / protocol.
+
+>Coming from the DHCP world, where there's a large blob of
+>processing
+>devoted to lease negotiation, it seems strange that (a) we just give out
+>an IP 'forever'
+
+Not forever - until the end of the session.
+
+>and (b) we just keep incrementing based on nas-port-id. There's no way
+>to define
+>a range of IPs.
+
+That's because it really is an ugly hack.
+
+>Is there any way to establish a hook (in the 'module' model) where
+>a user could call some external function that would return an IP and
+>possibly manage that IP?
+
+It's hard but not impossible. You would have to write a routine/module
+that knows about several pools (probably defined in radius.conf)
+and keeps an on-disk database that accounts for the IP addresses
+given out. It should look at all accounting-stop messages and mark
+the IP as free at the end of a session.
+
+There is also the problem of 'lost packets'. If an accounting-stop
+packet gets lost, or if authentication fails on the NAS after you've
+send an authentication ack so that start and stop packets might
+not be sent at all, the IP address you allocated will not
+be freed - ever. So when the pool reaches a high watermark (>90%)
+then you will need to scan all sessions in the pool to see if
+they are still active, using "checkrad", until you're under the
+low watermark (<80%) again. High and low watermarks would presumably
+be defined as part of the pool definition in radius.conf
+
+Other ways to keep the pool clean is to also check all authentication
+and accounting start packets for NAS/portno combination and if
+that matches with a presumably still active pool allocation,
+kill the allocation, since the original user is gone anyway.
+And perhaps a time-limit - use a minimum "Session-Timeout = 86400"
+for all sessions with addresses from the pool and periodically
+clean up all session that are older than (86400 * 1.2) or so.
+That should also be made part of the pool definition in radius.conf
+
+ip-pool pool1 {
+ range-start = 192.168.10.10
+ range-end = 192.168.10.19
+ cleanup-start = 90%
+ cleanup-end = 80%
+ session-timeout = 86400
+ session-stale = 90000
+ session-db = /var/log/radius/pool1.db
+}
+
+.. or something. You get the idea.
+
+The above is a description of how you could make serverside
+IP pools possible. Now someone needs to write the code.
+
+Mike.
+--
+"Only two things are infinite, the universe and human stupidity,
+ and I'm not sure about the former" -- Albert Einstein.
projects / freeradius.git / blobdiff