> is being used. I KNOW that we could potentially work around this by
> using the session id and port number or ip address and port number and
> changing our database design, but that is a kludge and completely
> patchwork solution. Is a fix for this in the works? Has anyone else
> found this to be a problem? Please let Lucent know too. Thanks!
Note that even if the PM4 were to use a unique number for each port in the
chassie that still would not completely remove the problem you are having.
It would only reduce the occurrences. RADIUS accounting is not time
senestive and you could easily receive a start record after the stop. The
only way to insure a unique key for a database is to use a combination of
the user-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, and if the
Session ID can not be assured to be unique (unable to roll over, be reset,
etc) you need to apply some other supplementary id by way of possibly the
Class attribute or some other way.
Also if you are using triggers and they do not factor in the delay time
you can also have a major number of problems.
Overall adding either an attribute for the blade number or making the
numbers unique across the chassie would be nice and reduce the problem but
it would not remove it.
----
Thomas C Kinnen - <tkinnen@livingston.com> <tkinnen@ra.lucent.com>
"All of the opinions stated above are my own and not my employer's,
unless they were given to me by my employer"
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>