[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf out-of-policy indications



Hi,
comments inline

Steve Waldbusser wrote:
> 
> All I want is for the field engineer to have to do something special
> to override a policy. Shouldn't he at least know that he has done
> something significant? Wouldn't it be good if he was thus encouraged
> to think twice? 

I am wondering about a feedback loop that would make it apparent to the
field engineer that a proposed change might have wide-ranging
implications to policy. 

A management application could analyze all the conditions that might be
affected by modifying a particular managed object, but this seems a
heavyweight solution, and it could be difficult to synchronize between
the application evaluation of the conditions, and the local evaluation
of the conditions, i.e. it may be much more difficult for the
application to determine affected instances.

Any suggestions on how to provide feedback - upon request - to the field
engineer about how many policies would be affected by changing a given
managed object, so he could determine the scale of the potential impact
on policy?

> Wouldn't it be good if he was encouraged to mention it
> to the network architect? ("hey, I needed to disable the blah policy
> on trunk 7 last night because it was interacting poorly with the
> backup circuit").
> 

Should we provide some mechanism for standardizing notifications
advising of changes to objects that have been moved "out of policy"?
There are two purposes - to remind the field engineer that he made a
temporary change that should be reset, and to notify the architect that
somebody changed a value that is subsequently affecting policy. 

One approach could be to define a general policy-system-wide
notification control for periodically sending notifications as long as
each element is out of policy (notification per element or role). The
other is to provide an object associated with the "disable-this-policy"
object that controls the notification frequency related to reporting
this particular out-of-policy state. This would allow notifications to
be sent more frequently for important policies, and less frequently or
not at all for less important policy changes (although the field
engineer could prevent the architect from being notified). The third is
to depend on an application run by the architect to poll for all
out-of-policy indicators. This may be less reliable as a reminder
mechanism for the field engineer, since he'll need to remember to run
the report.

Is the third mechanism adequate? It certainly seems the simplest and
most backwards compatible.
If an engineer doesn't set the flag, and changes an object, he can
affect policy until the next re-evaluation. Assuming policy would reset
it before the architect checked it, the architect may never know that
the engineer made such a change, and that could have security and
reliability implications.
A notification sent to the architect could ensure that the architect
knows about the temporary policy change. Reliance on subsequent polling
would not.

> My proposal is that he issue 2 commands rather than one. The first
> disables the policy on the interface and the second is a normal
> SNMP set that makes the change.
> 

I concur that two commands may be better than automatic flag-setting,
since this would indicate intent to knowingly override. 

Another related comment follows this quote:
> "Joel M. Halpern" wrote:

> > Also, to respond to the note expressing concern about the interaction
> > between the Network Architect and the Field Engineer, if the systems folks
> > have decided that the field engineer should not be able to change certain
> > things, don't given that engineer permission to change them.  In my
> > discussions with ISPs they have confirmed that it is normal and desirable
> > for field engineers to change things, and that preventing them from doing
> > so would be a bad thing.
> >

Yes, configuring access control to prevent the field engineer from
changing things he shouldn't change is the first step. But even field
engineers can sabotage or abuse networks. I seems that it would be a
good thing to provide a standard mechanism for the architect to detect
what changes had transpired that forced policy-controlled elements to an
out-of-policy state.

I think there may be a need for an out-of-policy-state notification
(which the architect may choose to disable or filter via snmpv3) for
security/auditing purposes.

dbh
-- 
---
David Harrington            Network Management Architect Engineer
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA