Hi All, Currently we are using freeradiusd to proxy / load balance requests to our backend radius application. However as I'm sure many of you encounter there are times which require maintenance / upgrades of the backend servers, what is the "best practice" in regards to putting home_servers into maintenance so that freeradiusd doesn't attempt to send traffic to them? I'm not sure if there is a simple command we can run? Or is the only option to comment out the home_server from the home_server_pool and then kill -1 to the radiusd process? Brian Carpio
Brian Carpio <bcarpio@broadhop.com> wrote:
Currently we are using freeradiusd to proxy / load balance requests to our backend radius application. However as I'm sure many of you encounter there are times which require maintenance / upgrades of the backend servers, what is the "best practice" in regards to putting home_servers into maintenance so that freeradiusd doesn't attempt to send traffic to them?
I'm not sure if there is a simple command we can run? Or is the only option to comment out the home_server from the home_server_pool and then kill -1 to the radiusd process?
You might want to consider an alternative deployment, we use anycasting and found it very reliable and far easier to maintain: http://www.digriz.org.uk/ha-ospf-anycast Make sure there are at least two L3 hops between RADIUS servers. Cheers -- Alexander Clouter .sigmonster says: Do not believe in miracles -- rely on them.
Brian Carpio wrote:
Currently we are using freeradiusd to proxy / load balance requests to our backend radius application. However as I’m sure many of you encounter there are times which require maintenance / upgrades of the backend servers, what is the “best practice” in regards to putting home_servers into maintenance so that freeradiusd doesn’t attempt to send traffic to them?
Use "radmin" radmin> set home server state IP PORT dead
I’m not sure if there is a simple command we can run? Or is the only option to comment out the home_server from the home_server_pool and then kill -1 to the radiusd process?
Nope. Mark it dead. When it comes back up, the server will figure that out (if Status-Server is enabled) Alan DeKok.
Part of the problem is that during an upgrade our radius application still listens on port 1813 and 1812 and replies to the keepalves (working with development to resolve that since I think that is a problem) so in the mean time I'd like to be able to mark and upgrading server dead then decide when it should be marked alive. Thanks for the quick reply! Brian -----Original Message----- From: freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org [mailto:freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, February 04, 2011 11:45 AM To: FreeRadius users mailing list Subject: Re: Proxy Maintenance Process Brian Carpio wrote:
Currently we are using freeradiusd to proxy / load balance requests to our backend radius application. However as I’m sure many of you encounter there are times which require maintenance / upgrades of the backend servers, what is the “best practice” in regards to putting home_servers into maintenance so that freeradiusd doesn’t attempt to send traffic to them?
Use "radmin" radmin> set home server state IP PORT dead
I’m not sure if there is a simple command we can run? Or is the only option to comment out the home_server from the home_server_pool and then kill -1 to the radiusd process?
Nope. Mark it dead. When it comes back up, the server will figure that out (if Status-Server is enabled) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
So are there any other options then restarting radiusd? I have tried to comment out a home_server and even send a hup: radmin -e "hup" But that doesn't see to make freeradius reread the proxy.conf file... I don't see in the radmin command how I can disable a server (except mark it dead but since my backend server still replies to heartbeat messages its marked alive immediately). -----Original Message----- From: freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org [mailto:freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org] On Behalf Of Brian Carpio Sent: Friday, February 04, 2011 11:47 AM To: FreeRadius users mailing list Subject: RE: Proxy Maintenance Process Part of the problem is that during an upgrade our radius application still listens on port 1813 and 1812 and replies to the keepalves (working with development to resolve that since I think that is a problem) so in the mean time I'd like to be able to mark and upgrading server dead then decide when it should be marked alive. Thanks for the quick reply! Brian -----Original Message----- From: freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org [mailto:freeradius-users-bounces+bcarpio=broadhop.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, February 04, 2011 11:45 AM To: FreeRadius users mailing list Subject: Re: Proxy Maintenance Process Brian Carpio wrote:
Currently we are using freeradiusd to proxy / load balance requests to our backend radius application. However as I’m sure many of you encounter there are times which require maintenance / upgrades of the backend servers, what is the “best practice” in regards to putting home_servers into maintenance so that freeradiusd doesn’t attempt to send traffic to them?
Use "radmin" radmin> set home server state IP PORT dead
I’m not sure if there is a simple command we can run? Or is the only option to comment out the home_server from the home_server_pool and then kill -1 to the radiusd process?
Nope. Mark it dead. When it comes back up, the server will figure that out (if Status-Server is enabled) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Brian Carpio wrote:
So are there any other options then restarting radiusd?
I have tried to comment out a home_server and even send a hup:
radmin -e "hup"
But that doesn't see to make freeradius reread the proxy.conf file...
That won't work. Home servers aren't reloaded on HUP.
I don't see in the radmin command how I can disable a server (except mark it dead but since my backend server still replies to heartbeat messages its marked alive immediately).
Hmm... no, you can't disable a home server. The simplest thing would be to turn off the home server if it's not responsive. Alan DeKok.
Perhaps some sort of access list or host (/32) null route to make the NAS think the home server is dead? -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Monday, February 07, 2011 5:27 PM To: FreeRadius users mailing list Subject: Re: Proxy Maintenance Process Brian Carpio wrote:
So are there any other options then restarting radiusd?
I have tried to comment out a home_server and even send a hup:
radmin -e "hup"
But that doesn't see to make freeradius reread the proxy.conf file...
That won't work. Home servers aren't reloaded on HUP.
I don't see in the radmin command how I can disable a server (except mark it dead but since my backend server still replies to heartbeat messages its marked alive immediately).
Hmm... no, you can't disable a home server. The simplest thing would be to turn off the home server if it's not responsive. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
On Fri, Feb 04, 2011 at 07:44:41PM +0100, Alan DeKok wrote:
what is the “best practice” in regards to putting home_servers into maintenance so that freeradiusd doesn’t attempt to send traffic to them?
Use "radmin"
radmin> set home server state IP PORT dead
"WARNING This tool is experimental and should not be used in production environments." (Just quoting the manpage... maybe it's more paranoid than necessary)
On Sat, Feb 05, 2011 at 07:18:52AM +0100, Alan DeKok wrote:
Brian Candler wrote:
"WARNING
This tool is experimental and should not be used in production environments."
(Just quoting the manpage... maybe it's more paranoid than necessary)
From an old version of the server. It no longer says that.
I took that from http://freeradius.org/radiusd/man/radmin.html I see this was removed from git in July 2010. B.
participants (5)
-
Alan DeKok -
Alexander Clouter -
Brian Candler -
Brian Carpio -
Gary Gatten