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

Re: snmpconf a new issue: off-the-box operations




Wayne,

The best way of showing this is to describe it locally and then
extrapolate in a couple of steps to non-local.

The way the model works is I tell the PM agent that I'm interested in
running policy on certain element types and I also install the
policies that should run.

Let's say an element type is frame circuit and there are 3 circuits on
the system { port 2 DLCI 67}, { port 7 DLCI 134 } and
{ port 7 DLCI 135 }. We discover the following elements:

internal element database
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135

The system will iterate all circuit policies on each of these
elements.

If I want my filter or action to access the committed burst rate on
"this element", I simply write:
   getvar("frCircuitCommittedBurst.$0.$1")

The instance information is not required. We like to say that this
provides instance-independence.

Another example:
   // The following will shut off any unprovisioned access port for
   // security policy.
   Filter: !roleMatch("gold") && !roleMatch("bronze")
           && !roleMatch("trunk")
   Action: setvar("ifAdminStatus.$0", 2, Integer)

How about the following per-circuit filter that selects all circuits
who's committedBurst is greater than their port speed:
   getvar("frCircuitCommittedBurst.$0.$1") > getvar("ifSpeed.$0")

Notice how no instance information is needed even when we're accessing
a different but related element (the parent port).

If we added the element type rptrPortEntry, now we'd be executing
policy on repeater ports, for example:
   if (getvar("rptrPortAutoPartitionState.$0.$1") == 2) //partitioned
     ...

RFC1516 requires multiple repeaters to be placed in different
contexts. No problem. This multi-context agent will add the following
information to the internal element database:

internal element database
     element                    context
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135
4    rptrPortGroupIndex.1.1     "repeater1"
5    rptrPortGroupIndex.1.1     "repeater2"
6    rptrPortGroupIndex.1.2     "repeater1"
7    rptrPortGroupIndex.1.2     "repeater2"

The same policyScript code can now be executed and run correctly
without any knowledge that sometimes it is running in a different
context. Whenever "this element" is on repeater2, the agent
automatically directs the getvar() to inspect repeater2.

What we called instance-independence above now starts to look like
complete address-independence. (I think the guys who coined the term
instance-independence would claim they had this in mind all the
time).

Taking it further, if I wanted to do a proxy-agent implementation to
policy-manage some closed systems that don't implement the PM MIB, the
proxy-agent extends it's discovery to discover off-box elements (a
simple table walk can accomplish this). Now I extend the internal
element database a bit more:

internal element database
     element                    context         address     auth
1    frCircuitIfIndex.2.67
2    frCircuitIfIndex.7.134
3    frCircuitIfIndex.7.135
4    frCircuitIfIndex.1.67      ""              a.b.c.d     ***
5    frCircuitIfIndex.1.69      ""              a.b.c.d     ***
6    rptrPortGroupIndex.1.1     "repeater1"
7    rptrPortGroupIndex.1.1     "repeater2"
8    rptrPortGroupIndex.1.2     "repeater1"
9    rptrPortGroupIndex.1.2     "repeater2"


and now whenever "this element" is entry #4 or #5 above, getvar()
builds an actual SNMP PDU and sends it to a.b.c.d instead of doing a
local get. The script doesn't need to have any knowledge of the
location of the element it is acting on.
    
It seems to me we're onto something big here. We're writing policies
and the code is much simpler than we're used to because all
instance/addressing has been abstracted out. It's simplified to the
point where we don't know or care what element we are operating on or
where it is.  And the policies that we write can run on local agents
or proxy agents without re-write (if we add a proxy-agent later, just
install our existing policy database on it).

There *are* some things we need to do to some of the support tables in
the PM MIB to facilitate this and I'll outline them in another note.


Steve


"Wayne F. Tackabury" wrote:
> 
> At 02:42 PM 4/4/2001 -0400, Pablo Halpern wrote:
> Do you mean that you're not sure it is worth it to support off-the-box
> operations or that it is not worth it to do the work to detail it?
> 
> Personally, I've been somewhat mystified on the application of this ever
> since I noted it in the somewhat incomplete mention in the PM draft.
> 
> Maybe "mystified" is too strong a word.  Can Steve tell me what he was
> thinking about here in terms of application and how objects might get
> exposed as to their local agents?  I've been considering the notion of a
> "PolicyScript proxy" for some time now, but that would be a private matter
> of local proxy configuration, not exposed through the PM MIB.
> 
> Don't misread me--there might be and likely is some essential application
> I'm missing here, I just want to understand what it is and how it would
> play out administratively.
> 
> Thanks!
> 
> Wayne