Subject: Re: (radius) Class

From: "Russell J. LeBar" <[email-masked]>
Date: Thu, 14 Jan 1999 10:49:09 -0600

But you should always have a primary and a secondary RADIUS server to
provide redundancy. Which means there is always a chance that the auth* is
done by one server but the accounting goes to another. Do you assume that
this rarely happens and thus the problems it creates are trivial?

-----Original Message-----
From: Dave Mitton <[email-masked]>

>At 12:02 PM 1/14/99 +0500, Nayani Srikanth wrote:
>>Sir/Madam,
>>        I have extensions to my previous qualms.
>>
>>  1) Is it essential for the accounting request to go to the same
>>     radius server which has given a access-accept ?
>
> Not by the protocol/RFC, But it may be an essential operational
>requirement because of the benefits that you may derive from from that.
> Several RADIUS servers use the combination of authentication information
>and accounting messages to attempt to track the real time status of the
>NASes, and do resource managmement.
>For example our BaySecure Access Control (BSAC) server (Funk SBR) has this
>requirement.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Fri, 15 Jan 1999 11:43:47 +0200 (MET-DST)

We have a proxy implementation on a cluster platform of typically two machines.
If authentication and accounting of a particular session are received on the
same machine, there is no problem. If they are received on different machines,
they exchange the relevant state information, and one will act as the MASTER
state holder.

This is just to illustrate that the way the servers keep state is independant
of the RADIUS protocol, and is strictly a server implementation issue.

What _is_ relevant to RADIUS is the means to link all requests of a particular
session. As explained in a previous mail, this can be done with Class or
Acct-Session-Id, but the RADIUS RFCs do not address this issue, hence the
recurring discussions and interop issues.

-