(RADIATOR) tigris and accounting

[Hugh Irvine]

Hello Magnus -

I think you should do several things:

1. check a debug on the Tigris to see whether or not the accounting 
packets are being sent

2. run a tcpdump/snoop/ethereal/whatever packet sniffer on the wire(s) 
to see whether the packets are there

3. check a trace 4 debug from Radiator to see whether Radiator is 
seeing the requests

It may be that the Tigris is not configured correctly, or it may be 
that there are packet filters stopping the requests in transit (or the 
accounting responses from getting back).

To say any more, I will need to see copy of your Radiator configuration 
file (no secrets) together with a trace 4 debug showing what is 
happening.

regards

Hugh


On Monday, October 14, 2002, at 07:45 PM, Magnus Drougge wrote:

>
> Hi!
>
> I have a non-fatal problem that I've been looking at for some time
> now. The situation is as follows (forgive me for not keeping this
> short):
>
> * 2 radius servers, primary and secondary (v 2.18.2) running on
>   2.4.x Linux (x86)
> * 7-slot tigris (v 11.5.x)
> * a number of DSL clients
> * a much larger number of dial-up clients.
>
> We allow anyone to phone in and get a dial-up connection (as we earn
> money on ticks, not subscription fees). Thus a very simple radius
> setup with an AuthByTest section is sufficient for our needs.
>
> We also have a limited number of DSL clients. Those clients are
> authenticated agains an MySQL database.
>
> All in all, about 10'000 authentications are made on a daily basis.
>
> The DSL clients is responsible for about 10% of the radiator's
> workload and there is absolutely no problem there.
>
> However, only about 0.2 percent of the authenticated dial-up 
> connections
> are properly accounted for. When looking at debug traces it seems that
> the accounting requests isn't even sent from the tigris!
>
> When we had a closer look at the tigris it turned out that it 
> repeatedly
> failed to send accounting requests to our radius, rendering the server
> 'down' for most of the time. Authentication still works as a charm...
>
> We thought that to be a bit odd as the secondary server is a mirror
> installation and tigris seemed to be much happier about that one.
>
> The next step was to reverse the order in tigris and letting the
> secondary server act as a proxy to the primary. The result is that we
> now have a 'hit-rate' of about 3-4 percent. Well, it's a great
> improvement but still outrageous...
>
> Finally.
>
> When looking at the statistics at the tigris there are some failed
> accounting requests but the result should not even come close to the
> figures we have. On the other hand, according to the tigris
> statistics, the number of accounting requests sent (including failed
> ones) compared to the number of authentication requests makes our
> figures more reasonable.
>
> Obviously the tigris refuses to send accounting requests for almost
> every successful authentication request.
>
> Is anyone recognizing the problem? Is there any more information I
> can provide in order to help producing a solution?
>
> Earlier I wrote that this is a non-fatal problem. Well, it is. Sort of.
>> From time to time we obviously need to know the owner of an ip-number
> at a given time. If the accounting works this is really easy but now
> we have to do some serious log crunching using output from a number of
> sources.
>
> Thanks for your time,
>
> Yours sincerely,
>
> /Drougge
> ______________________________________________________________________
> Magnus Drougge          Systemutveckling, Drift           ICQ #9058792
> Rix Telecom AB             www.rixtelecom.se          +46-31-780 00 00
> ----------------------------------------------------------------------
> ===
> 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.
>
>

NB: I am travelling this week, so there may be delays in our 
correspondence.

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