todo/serverside-ip-pools

   1 From: miquels@cistron-office.nl (Miquel van Smoorenburg)
   2 Subject: Serverside IP pools design [was: Re: Questions on IP address allocation]
   3 Date: Tue, 13 Nov 2001 13:29:24 +0000 (UTC)
   4 Message-ID: <9sr77k$ofn$1@ncc1701.cistron.net>
   5 To: freeradius-devel@lists.cistron.nl,freeradius-users@lists.cistron.nl
   6
   7 In article <DE6495F924D2304DA0FAD60FC1C00601150E3B@AVIANSERVER.aviancommunications.com>,
   8 John Padula <john_padula@aviancommunications.com> wrote:
   9 >I'm still looking into IP address allocation via the "+" option.
  10 >I wanted to check if there's any sense of a lease or expiration on the
  11 >IP address
  12 >given out.
  13
  14 No, and that's not really neccesary either, since other than with
  15 DHCP you have strictly defined session start- and stop points.
  16
  17 >I've checked the RFC and didn't see any mention of this, but
  18 >wanted to
  19 >make sure.
  20
  21 Because IP address allocation is completely outside the scope
  22 of the Radius RFC / protocol.
  23
  24 >Coming from the DHCP world, where there's a large blob of
  25 >processing
  26 >devoted to lease negotiation, it seems strange that (a) we just give out
  27 >an IP 'forever'
  28
  29 Not forever - until the end of the session.
  30
  31 >and (b) we just keep incrementing based on nas-port-id.  There's no way
  32 >to define
  33 >a range of IPs.
  34
  35 That's because it really is an ugly hack.
  36
  37 >Is there any way to establish a hook (in the 'module' model) where
  38 >a user could call some external function that would return an IP and
  39 >possibly manage that IP?
  40
  41 It's hard but not impossible. You would have to write a routine/module
  42 that knows about several pools (probably defined in radius.conf)
  43 and keeps an on-disk database that accounts for the IP addresses
  44 given out. It should look at all accounting-stop messages and mark
  45 the IP as free at the end of a session.
  46
  47 There is also the problem of 'lost packets'. If an accounting-stop
  48 packet gets lost, or if authentication fails on the NAS after you've
  49 send an authentication ack so that start and stop packets might
  50 not be sent at all, the IP address you allocated will not
  51 be freed - ever. So when the pool reaches a high watermark (>90%)
  52 then you will need to scan all sessions in the pool to see if
  53 they are still active, using "checkrad", until you're under the
  54 low watermark (<80%) again. High and low watermarks would presumably
  55 be defined as part of the pool definition in radius.conf
  56
  57 Other ways to keep the pool clean is to also check all authentication
  58 and accounting start packets for NAS/portno combination and if
  59 that matches with a presumably still active pool allocation,
  60 kill the allocation, since the original user is gone anyway.
  61 And perhaps a time-limit - use a minimum "Session-Timeout = 86400"
  62 for all sessions with addresses from the pool and periodically
  63 clean up all session that are older than (86400 * 1.2) or so.
  64 That should also be made part of the pool definition in radius.conf
  65
  66 ip-pool pool1 {
  67         range-start     = 192.168.10.10
  68         range-end       = 192.168.10.19
  69         cleanup-start   = 90%
  70         cleanup-end     = 80%
  71         session-timeout = 86400
  72         session-stale   = 90000
  73         session-db      = /var/log/radius/pool1.db
  74 }
  75
  76 .. or something. You get the idea.
  77
  78 The above is a description of how you could make serverside
  79 IP pools possible. Now someone needs to write the code.
  80
  81 Mike.
  82 --
  83 "Only two things are infinite, the universe and human stupidity,
  84  and I'm not sure about the former" -- Albert Einstein.