Re: Referential integrity across reboots

[Andy Bierman <abierman@cisco.com>]

At 10:13 AM 7/25/2002, 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?

It's about time we tried to fix this problem.
It turns out that it was a mistake (in the IF-MIB,
Entity MIB, etc.) to allow the object index to change
after a reboot.  The arbitrary local integer isn't the
problem -- just the fact that it can change after a reboot.
We (cisco) had to add a feature to IOS to retain
ifIndex values across a reboot, because customers demanded it.

It turns out that ifAlias doesn't help at all, because the
OID name of the object is what must be persistent. Otherwise
all the OID pointers to that object instance break when the
box is rebooted.  It also turns out that if the agent can
remember these instance values across a reboot, that it's
easier to make sure that the same instance value gets used,
rather than trying to adjust all the OID pointers that might
be affected.  It's also not possible if the OID pointer
is in the NMS application instead of configured in the agent.

The solution is to simply mandate that instances preserved
across a reboot come back with the same values.  Currently,
it's a SHOULD, not a MUST.


> ------------------------------------------------------
> 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.
> ------------------------------------------------------

Andy