Speaking of which, does anyone know how to force the authentication server to flip back to primary after it's failed over to secondary? If I remove the secondary, that brings the primary back, but I'm hoping for a switch. I'm currently set for fall-through, is that correct? Little luck on finding 4.2.x radius questions answered on 3KB... Thanks, Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Mon, 19 Jun 2000, Jeff Mcadams wrote:
Also sprach Scot Desort
Yes, I think that is the problem. Slightly ambiguous use of Primary first backup, and secondary terminology by 3COM. I am already using fall_through.
I'll give your commands a try and see if the acctg packets to the "first backup" stop.
As a little bit of clarification on the differences between authentication and accounting. There are differences in the needs of the two parts of the RADIUS protocol.
For authentication, you don't have a need for multiple RADIUS servers to get the request in normal operation. Yes, if you have a server go down, you need to fail over to the next. The question then becomes, when the first comes back up, do you switch back over to it, or just stay with the second one? Thus the authentication_algorithm settings to let you control that.
With accounting, however, its easily conceivable that you could want accounting messages to be sent multiple places in normal operation, and further, that each one of those potentially independant information might have a fail-over system available to it if it should fail. The possible permutations here get too much for a single controlling variable, so you have primary, secondary, tertiary, etc. servers that are for the individual locations, and that get a copy of all the accounting messages independantly. Then you have the first_backup, second_backup, etc. for each of those to handle the case where one of the servers fails that normally gets the accounting messages, and each one has its own backup servers.
Anyway...hopefully this clarifies things a bit more as to why authentication and accounting are handled differently, and how they are handled. Hopefully I haven't confused you further. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.