From 0c4235879b6069de44bc156e0cce1c4cee88da66 Mon Sep 17 00:00:00 2001 From: miquels Date: Fri, 18 Jan 2002 12:39:16 +0000 Subject: [PATCH] * todo/serverside-ip-pools: new file describing how to implemented server-side IP pools * todo/radius.conf.sample2: removed, we have a radius.conf don't we --- todo/radius.conf.sample2 | 45 -------------------------- todo/serverside-ip-pools | 84 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 84 insertions(+), 45 deletions(-) delete mode 100644 todo/radius.conf.sample2 create mode 100644 todo/serverside-ip-pools diff --git a/todo/radius.conf.sample2 b/todo/radius.conf.sample2 deleted file mode 100644 index b25469a..0000000 --- a/todo/radius.conf.sample2 +++ /dev/null @@ -1,45 +0,0 @@ - -confdir: /etc/raddb -authlog: /var/log/radius.log -acctlog: /var/log/radacct/%s/detail -radwtmp: /var/log/radwtmp -radutmp: /var/log/radutmp -pidfile: /var/run/radiusd.pid -checkrad: /usr/local/sbin/checkrad - -avgroup common { - auth-recv-allow: Framed-MTU - auth-recv-allow: Idle-Timeout - auth-recv-allow: Reply-Message - auth-recv-allow: Filter-Id - auth-recv-allow: Port-Limit - auth-recv-allow: Session-Timeout - auth-recv-allow: Idle-Timeout - auth-recv-allow: Framed-Protocol - auth-recv-allow: Framed-Compression - auth-recv-allow: Service-Type = Login-User - auth-recv-allow: Login-Service - auth-recv-allow: Login-IP-Host -} - -proxy domain.com { - authproxy: pr1.domain.com:1645 - acctproxy: pr1.domain.com:1646 - auth-send-allow: A/V pairs - auth-send-deny: ALL - auth-recv-allow: Framed-Address = 192.168.1.2/26 - auth-recv-allow: Framed-Netmask = 255.255.255.255/26 - auth-recv-allow: common - auth-recv-deny: ALL - acct-send-deny: Caller-ID - acct-send-allow: ALL - authlog: /var/log/radius.pr1.log - acctlog: /var/log/radacct/pr1/detail -} - -nas 192.168.1.1 { - shortname: cs-1.alp - type: livingston -} - - diff --git a/todo/serverside-ip-pools b/todo/serverside-ip-pools new file mode 100644 index 0000000..087c605 --- /dev/null +++ b/todo/serverside-ip-pools @@ -0,0 +1,84 @@ +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 , +John Padula 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. -- 2.1.4