That is odd. I didnt mention it, but I also use load balancing, though with
a Linux Server doing the clustering
rather then a layer 2 switch. Same concept though, it intercepts the packets
destined for the radius server
ip address, and redirects them to the cluster nodes, who have the ips bound
as loopback addresses, so
that they will not respond to ARP broadcasts and interfere with the cluster
server doings its job.
Anyways, the BindAddress is working on my 3 Suns, Solaris 2.6 and 7.0, when
using the loopback, clustered
address. The only other time I had the problem like that, is when my NAS
servers were speaking to
the radius servers, by way of a different ip address then the replies were
coming back from, as you surmised.
However on every flavor of radius ive used, using a localaddress or
bindaddress to force the issue has solved it.
Heh sounds like a packet sniffer is the only way to go, as well as trace 4
logs on Radiator and any debug
logs your NASs can produce.
----- Original Message -----
From: "Chris" <[EMAIL PROTECTED]>
To: "Ron Hensley" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 16, 2000 5:21 PM
Subject: Re: (RADIATOR) Load Balancing Radiator
>
> I tried this, so also to listen only on that ip, however this also did not
> appear to work possibly because the ip is bound to the loopback (it has to
> be bound to the loopback because of the method of load balancing the
> Summit 7i is doing.
>
> So when I did this, radiator only responded to requests on 1.2.3.4 (which
> is configured on the loopback) but replied to those requests with the
> ethernet ip.
>
> I'm setting up a packet sniffer to confirm this wednesday AM so I don't
> have to rely on lucent debug.
>
> Chris
>
> > In the main global section
> >
> > BindAddress 10.0.0.1
> >
> > Thats the one for the normal auth/accounting information to listen and
> > respond with.
> > Make it whichever ip bound to the nic, you want it to use and reload.
> >
> > ----- Original Message -----
> > From: "Chris" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, October 16, 2000 1:18 PM
> > Subject: (RADIATOR) Load Balancing Radiator
> >
> >
> > >
> > > I'm trying to load balance radiator across three seperate servers
> > > with an Extreme Summit 7i switch. All servers respond correctly to
> > > requests out of the server farm. However when put in the server farm
they
> > > respond to the authentication request with the ethernet ip even though
the
> > > request was sent to an ip on the loopback. Because it is responding
with
> > > a different ip than what the request was sent to, my portmasters are
> > > ignoring the response. I noticed the 6.27.11 LocalAddress tag but
seems
> > > to only work with AuthBy Radius. Is there a way to have radiator
respond
> > > with the ip that the request was sent to with AuthBy Unix? The manual
> > > implies that this is default but it doesn't seem to be doing it.
(perhaps
> > > because the address is on the loopback?)
> > >
> > > Has anyone run into the same problem?
> > >
> > > Here is my config:
> > >
> > > Foreground
> > > LogStdout #THIS LINE IS FOR TESTING, OUTPUT GOES TO SCREEN
> > > LogDir /var/log/radiator
> > > DbDir /etc/raddb
> > > PidFile /var/run/radiusd.pid
> > > DictionaryFile /etc/raddb/dictionary.livingston
> > > AuthPort 1812
> > > AcctPort 1813
> > > SnmpgetProg /usr/local/bin/snmpget
> > > Trace 4
> > > SocketQueueLength 100000
> > >
> > > <Client 1.2.3.4>
> > > Secret xxxxx
> > > DefaultRealm xxx
> > > </Client>
> > > <Client 2.3.4.5>
> > > Secret xxxxx
> > > DefaultRealm xxx
> > > </Client>
> > > <Client 3.4.5.6>
> > > Secret xxxxx
> > > </Client>
> > > <Client 7.8.9.1>
> > > Secret xxxxxx
> > > </Client>
> > > <Client DEFAULT>
> > > Secret xxxxxx
> > > DupInterval 2
> > > NasType Livingston
> > > SNMPCommunity frii
> > > LivingstonOffs 22
> > > LivingstonHole 1
> > > </Client>
> > >
> > > <AuthBy GROUP>
> > > Identifier Frii
> > > AuthByPolicy ContinueWhileReject
> > > <AuthBy SQL>
> > > AuthSelect
> > > AccountingStopsOnly
> > > DBSource xxxxxxxxxxxxx
> > > DBUsername xxxxx
> > > DBAuth xxxxxx
> > > AcctSQLStatement insert into data values ('%n',%t,%{Acct....
> > > </AuthBy>
> > > <AuthBy GROUP>
> > > AuthByPolicy ContinueUntilReject
> > > <AuthBy FILE>
> > > Filename /etc/raddb/users-pop
> > > </AuthBy>
> > > <AuthBy FILE>
> > > Filename /etc/raddb/users
> > > </AuthBy>
> > > </AuthBy>
> > > </AuthBy>
> > >
> > > <AuthBy UNIX>
> > > Identifier FriiSystem
> > > Filename /etc/mypasswd
> > > </AuthBy>
> > >
> > > <SessionDatabase SQL>
> > > Identifier FriiSessions
> > > DBSource xxxxxxxx
> > > DBUsername xxxxx
> > > DBAuth xxxxxx
> > > AddQuery replace into Sessions values.........
> > > CountQuery select NASIDENTIFIER ........
> > > DeleteQuery delete from Sessions where .........
> > > </SessionDatabase>
> > >
> > > <Realm /realm1/i>
> > > RewriteUsername s/^([^@]+).*/$1/
> > > AuthBy Frii
> > > SessionDatabase FriiSessions
> > > </Realm>
> > > <Realm /realm2/i>
> > > RewriteUsername s/^([^@]+).*/$1/
> > > AuthBy Frii
> > > SessionDatabase FriiSessions
> > > </Realm>
> > > <Handler>
> > > AuthBy Frii
> > > SessionDatabase FriiSessions
> > > </Handler>
> > >
> > > Chris Bissell | Front Range Internet,
Inc.
> > > [EMAIL PROTECTED] | www.frii.com
[EMAIL PROTECTED]
> > > Technical Operations | 970-224-3668
800-935-6527
> > >
> > >
> > > ===
> > > Archive at http://www.starport.net/~radiator/
> > > Announcements on [EMAIL PROTECTED]
> > > To unsubscribe, email '[EMAIL PROTECTED]' with
> > > 'unsubscribe radiator' in the body of the message.
> > >
> >
>
> Chris Bissell | Front Range Internet, Inc.
> [EMAIL PROTECTED] | www.frii.com [EMAIL PROTECTED]
> Technical Operations | 970-224-3668 800-935-6527
>
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
