This is not enough.
RADIUS - the protocol - cannot do it 100% reliably. Period.
RADIUS is setup to make sure data gets there - but not in any particular
order or over any period of time.
It is possible, and I have seen it, to get a Start for session 1, a
start for session 2, and THEN the stop for session 1 - when the
user logged out and logged back in. This is especially likely with ISDN.
A user can disconnect and reconnect within one second. Timeouts for one
try in RADIUS is 3 seconds. If the first STOP packet gets delayed at all,
you have a race condition.
RADIUS was *deliberately* designed this way, it was never meant to be
used as a resource allocation protocol.
This is why another protocol - like SNMP - is used. Let's use a simple
case where the limit is one login per user.
Request comes in - RADIUS checks database.
1 - user is not shown as logged in in database. ie, STOPs have been
received for all Starts. ACK
2 - user is shown as logged in in database on NAS X. Now you use SNMP to
query NAS X to be *sure* the user is still on.
a - SNMP reports user is not on. Close the open entry and flag it
as a special closure. ACK
b - SNMP reports user is on. Leave current entry alone. NAK
This is the simplest example.
-MZ
-- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message.