RE: [Emerald] Revelation

Brandon Bryant ( nailer@midlink.com )
Mon, 21 Dec 1998 14:02:00 -0500

Well, I just got off the phone with Ascend. There is apparently no way to
force the ascend to switch back. So restarting the service looks like as
good a solution as any.

-----Original Message-----
From: Dale E. Reed Jr. [SMTP:daler@iea-software.com]
Sent: Monday, December 21, 1998 1:01 PM
To: emerald@iea-software.com
Subject: Re: [Emerald] Revelation

Kurt Schafer wrote:
>
> Your MAX isn't broken. Every Radius server I've ever seen performs that
way.
> I would even go so far as to hazard a guess that the Radius spec outlines
it
> that way.

(BTW: The MAX isn't a RADIUS server, its a RADIUS client).

The RFC says:

The Access-Request is submitted to the RADIUS server via the network.
If no response is returned within a length of time, the request is
re-sent a number of times. The client can also forward requests to
an alternate server or servers in the event that the primary server
is down or unreachable. An alternate server can be used either after
a number of tries to the primary server fail, or in a round-robin
fashion. Retry and fallback algorithms are the topic of current
research and are not specified in detail in this document.

> Imagine if your 'primary' server was down. Each authentication/accounting
> request would have to 'double-dip' to get responded to in the event of a
> prolonged outage.

Yes and unless you are not monitoring your system, you should be able
to manually switch over to a backup fairly quickly.

--Dale E. Reed Jr.  (daler@iea-software.com)_________________________________________________________________       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |   http://www.iea-software.com

For more information about this list, including removal,please see http://www.iea-software.com/maillist.html



For more information about this list, including removal,please see http://www.iea-software.com/maillist.html