The answer to this question will vary, depending on the following two factors:
- Factor 1 - Version of Steel-Belted Radius:
Any version of Steel-Belted Radius, prior to 5.43 or any of the 6.0x versions, have a limit of 16K per object. SBR 5.43 and all versions of 6.1x have a limit of 32K per object. Any version of Steel-Belted RADIUS running on Solaris has a 32K limit per object.
- Factor 2 - Type of attribute and the size of its payload:
To calculate the maximum number of attributes, you will have to do some mathematical calculations. You must know the size of the attribute to be used, as well as its payload. Refer to the appropriate RFC or vendor documentation to find this information.
For example:
User-Name is a standard Radius attribute and It has a 3 byte header, before the payload. Then there is the payload length itself and finally 1 byte reserved for a Null character for string data. So, if you have a user name of 6 bytes, the total length of the user-name attribute and payload stored in the internal database would be 3 + 6 + 1 = 10 bytes.
To allow for internal database storage, you should add an additional 10 bytes per record. So, for this example, 20 bytes of space is required; which is 32,768 / 20 = 1638 entries.
In the older database version, the issue is when an attribute that exceeds the 16K limit is added, the GUI would suddenly clear the display of
all entries for that object; which makes it appear as if they have been deleted. The original set of attributes is still stored; but the GUI is not able to add or display them properly. Authentication was typically unaffected; but the configuration was unstable and eventually it started to fail.
