(RADIATOR) Some users got connected without IP in NAS.

[Joe Hughes]

On 12/08/06, Martin Wallner <Martin.Wallner at eunet.co.at> wrote:
> Are you using dynamic IP pool? If yes, are you using the pool on the router
> or do you let RADIATOR do the dirty deed of giving out IP-Adresses?
>
> IMHO the best way is to let the router deal with the dynamic IP's....
>
> On a CISCO router it sometimes happens that the user don't get a dynamic
> IP-Address when the PPP Negotiation takes too long or the client demands an
> IP Address the router is not willing to give (we had some time ago a 64k
> dial in demanding our main DNS servers address... brrr :-), so client and
> router couldn't agree on an address, and the connection stays LCP
> up/negotiating for a bit.... in the 'show user' on a cisco it's shown as a
> virtual interface without an IP.....
>
> Another possibility is, that the router runs out of dynamic IP-Adresses...
> (all used), that is easyly checked by a 'sh ip local pool' ... if yes, just
> add some more addresses to the pool - you can do that on the fly...)
>
> If RADIATOR gives out the (dynamic) addresses, it can be that some addresses
> are not stored in the database, and RADIATOR dishes out the addresses
> twice... making a mess on the router... (that's why I don't like the Idea of
> Radiator giving out the Addresses, makes the router more vulnerable to such
> errors...)

I had the exact same decision to make and opted for RADIATOR handing
out the addresses, but using my own database procedures. I'm glad to
say its working very well to date and I have had no problems. Our PPP
kit is Cisco, although it isn't managed by us as it is under the
'management' (if you can call it that) of the telco.  My biggest
concern was a mismatch between the NAS and the Sessions table within
our database, and if either of them died causing a mismatch. It
becomes even more of a problem if you are enforcing concurrent login
checks because disconnected users can't login as your database
'thinks' they are still logged in.

I have also had issues where ADSL users connecting via PPP start a
session and don't get an IP address because of the NAS/Errors - I
adapted the procedures for START/STOP accounting mesages to handle
this.

Overall it's great - I have exact figures to hand on IP address usage
(handy for RIPE), I can easily allocate Static IP addresses to
customers and I have better control of the IP resource. That in mind,
I put a lot of work into additional functions to monitor the `health`
of the IP address pools and sessions table - if there is a mismatch
(active addresses vs active sessions) then it flags it up and notifies
me (to date, this hasn't happened).

There are downsides. If you don't have a reliable database system
(cluster/mirror) and it goes down, you're in big trouble. If you're
NAS randomly reboots and doesn't inform your database, you're in big
trouble.

Any reboot of the NAS requires some coordination with the
administrators. In my case, I disable authenticate attempts for a
given NAS, I then reboot the thing which clears down the sessions, I
then re-enable authentication and power back on the NAS.

--
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.