Re: Referential integrity across reboots

[Mark Ellison <ellison@ieee.org>]

Hi Randy,

I have also encountered the described issues with respect to VACM
configuration and ifIndex and entPhysicalIndex.  When multiple
administrations need access to thier rows in a shared table, then
instances must be part of the VACM configuration, and, index values
within applicable portions of the shared table must persist in order to
expereience VACM consistency.

The solution, as Andy described, is to persist index/instance values
across reboots.

For ifIndex, we've used an architectural range of values for physical
interfaces (which MAY change across reboot, or as a result of a
component hot-swap), and a range of values for virtual interfaces.  It
turned out these virtual interface instances contain the persistent
configuration data which was to be accessible to various
administrations, so index values for these instances MUST persist across
reboots if the VACM constraints are to work properly.

An interesting side effect of an agent persisting  index values is that
it simplifies management applications deriving performance and trending
information from agent data across reboots.

Regards,

Mark Ellison
Ellison Software Consulting, Inc.



Randy Presuhn wrote:

> Hi -
>
> A problem has popped up in a couple of working groups needing
> to handle persistant configuration data.
>
> An example of the basic problem is that VACM is based on the
> assumption that the name of an object instance to which access
> is to be controlled will remain the same across reboots.
> For objects whose names change, like table entries indexed
> with ifIndex, fine-grained access control becomes problematic.
>
> However, it's not just a problem with VACM.  It shows up
> anywhere where we can have things like row or instance pointers
> as configuration data that needs to survive a reboot, and
> those pointers can reference objects whose names might change.
> So, for example, the event mib, the alarm mib, the arc mib,
> the expression mib, the notification filtering in RFC 2573,
> rmon's thresholding, and nmpconf pm mib scripts are just a
> few examples of things that could run afoul of this.
>
> Thoughts?
>
>  ------------------------------------------------------
>  Randy Presuhn          BMC Software, Inc.  1-3141
>  randy_presuhn@bmc.com  2141 North First Street
>  Tel: +1 408 546-1006   San Jose, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------