(RADIATOR) Hacking around an upstream issue.

[Martin Edge]

Kinda, it's a load issue.

The policy from our upstream RADIUS is to pound the primary until it fails,
and then failover.

They have no RR or Load Balance functionality. We get enough load on that
one server that you'd expect it to timeout occasionally..

I may just whack another proxy inbetween my supplier and myself and do RR or
LB there..



-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
Behalf Of Ingvar Berg (EAB)
Sent: Wednesday, September 04, 2002 10:09 PM
To: Radiator
Subject: RE: (RADIATOR) Hacking around an upstream issue.


Sounds like a broken NAS, sending alive packets for a terminated session...
/Ingvar

>
> The NAS's appear to be sending an Alive packet for a Session
> after we have
> received the Stop packet for the _same_ Session.
>
> This is due to the first attempt to send the Alive packet
> failing, the NAS
> waits 10 seconds for a retry. During this ten seconds, the
> user disconnects,
> the NAS sends a stop record.
>
> The NAS then sends off the second attempt for the Alive packet.
>
> Consequently, the session is 'reopened' in my SessionTable,
> as the Alive
> packet triggers a delete/insert .. for all intensive purposes
> I see a dead
> session, which was actually already closed off.
>
> Thanks
> Martin
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Wednesday, September 04, 2002 9:50 AM
> To: Martin Edge
> Cc: Radiator
> Subject: Re: (RADIATOR) Hacking around an upstream issue.
>
>
>
> Hello Martin -
>
> What exactly is the problem?
>
> If you just want special processing for Alives, do something
> like this:
>
> <Handler Acct-Status-Type = Alive>
> 	....
> </Handler>
>
> regards
>
> Hugh
>
>
> On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote:
>
> > Hey Guys,
> >
> > Want to see if anyone has any ideas of how I should deal with this
> > situation.
> >
> > We are currently getting the following for the 'occasional'
> user session
> > from our Upstream RADIUS..
> >
> > Order	Amount	Type
> > -------------------------------------------------
> > 1	1 		Start
> > 2	Many 		Alive's (every 15 min)
> > 3	1		Stop (0 sec, Acct-Delay-Time)
> > 4	1		Alive (9 seconds afterwards, Acct-Delay-Time=10)
> >
> > We are told that what is happening, is the first attempt is made to
> > send the
> > first Alive packet. By coincendence, the user disconnects
> between these
> > retries, and the Stop packet is fired off. The Retry Alive packet is
> > sent
> > after the Stop packet for that session has arrived.
> >
> > Until they can come up with a network-fix for the problem
> (to prevent
> > Additional Packets for the Same Session to be sent before completely
> > failing
> > the current packet (until $x times tried), I'm going to have to
> > develop a
> > hack around to work out on what basis to ignore these extra Alives.
> >
> > I was thinking I have two options
> >
> > 1:- Make Radiator see whether the SessionID is still active
> for an Alive
> > packet (could be costly on DB work each instance)
> > 2:- Make Radiator store recent sessionIDs it has closed off
> in a DB or
> > DBM
> > file, and check incoming Alive packet -isn't- in the
> recently expired
> > list.
> >
> > Which would be the best? Where should I start? :)
> >
> > Thanks,
> > Martin
> >
> > ===
> > 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.
> >
> >
>
> --
> 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.
>
===
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.

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