[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf General Functional Questions
Jon Saperia wrote:
> on 07/06/2000 3:47 PM, Joel M. Halpern at firstname.lastname@example.org wrote:
> > I had overlooked that (background change detection) proposal. That would
> > indeed produce the results you propose. And was not what I was
> > expecting. I had assumed that one would indeed modify some internal
> > mechanisms so that if a change was being made to a variable which had been
> > modified by policy, that the "don't touch" flag would get set.
> Yes. The modification of the internal mechanisms to which you refer, does
> not imply that one would need to modify the low level instrumentation as
> Steve suggests.
It requires a change to the snmp protocol engine and to the CLI command
processor and any other engine that processes management commands. Such
a requirement is pretty unprecedented in MIB development.
Some other issues:
Before any varbinds are modified, the system must check to see if it is
under policy control (and thus would need to set the modified bit).
How does this engine know that a variable is under policy control?
This is difficult because it is hard to look at a policyAction script
and figure out which variables it is controlling because there are
conditionals (if A then set B else set C) and because some or all of
the script is opaque depending on how much work you want to do
Seems there are 2 strategies:
A. When a policyAction executes, save a list of OIDs it modified in a
master list of policy-controlled OIDs. Then we can check this list
before modifying any variable.
- Lots of memory used storing long list of OIDs.
- When a policy becomes inactive, hard to tell which OIDs to take
out of list (can't simply re-execute policyAction because
conditionals might have changed).
B. When you want to know if a variable has been modified, inspect
policyAction to see which variables are controlled.
- Requires execution of script to evaluate conditionals
- Interpreting script in bowels of snmp protocol engine is not a
good architectural decision.
When a policy goes away on an element and then comes back, should the
modified bit get cleared?
This doesn't work when the policy agent is a mid-level manager
(i.e.: where the agent that implements the Policy MIB enforces policy
in a subdomain through SNMP requests).
I think the modified bit proposal requires us to abandon that part of
So far I've talked about the requirement for the operator to think
twice before overriding a policy. The same is true when the tables
are turned: When an operator overrides a policy to firefight a
problem, the architect should think twice before returning it to
policy control. The problem is that without an explicit forceOff
state, the architect has no evidence that a modification to policy
was done deliberately.
I am opposed to the modified bit because it doesn't offer the right
services to network architects and operators alike and secondarily
because of the modeling and implementation problems it presents.
The current solution (the forceOff bit), allows operators to override
any policy that is causing operational difficulties (subject to
access control, of course). Meanwhile, the network architect can be
assured that policy overrides are applied only when necessary.