Re: Proper way to write an original agent?

Robert Premuz (rpremuz@srce.hr)
Tue, 25 Jun 1996 18:36:00 +0200 (MET DST)

On Tue, 25 Jun 1996, Tatsuo Natsukawa wrote:
>
> Although the computation is easy, I have to look at 272 MIB variables
> to compute the number of open B channels and the number of modems in
> use. The following table is in Ascend MIB:
>
> callStatusTable----callStatusEntry----callStatusValidFlag
> -callStatusDataRate
> -...
>
> There are 136 rows in the table. I have to first check whether the entry
> in a particular row is valid, and if it's valid, I have to check the
> data rate to figure out whether it's a modem connection or not.
>
> I happen to have tkined and the Ascend on different LANs. What would
> people do to minimize the agent-to-manager traffic in general?

If I were you, I would write something like the following in your script:

$s walk varbinds {callStatusValidFlag callStatusDataRate} {

set nVarbinds [llength $varbinds]
for {set i 0; set j 1} {$j < $nVarbinds} {incr i 2; incr j 2} {
set callStatusValidFlag [linedex [lindex $varbinds $i] 2]
set callStatusDataRate [linedex [lindex $varbinds $j] 2]

# Here, check the value of callStatusValidFlag and compute what
# you need with callStatusDataRate.
}
}

I hope I haven't made some syntax errors (or, even worse, semantics
ones :)

So, the point is to use the walk command as it walks the given objects
by sending get-bulk requests if the session is an SNMPv2 session. And,
if the Ascent box answers the get-bulk requests properly, then you'll
get up to 16 variables (for scotty v.2.0.2) in each response while
walking the variables. This is the way to reduce the agent-to-manager
traffic.

But, if it's an SNMPv1 session, then you'll get only 2 variables per a
response as the get-next requests must be used in the walking.

v
-- rpr. : Robert B. Premuz * Email: rpremuz@public.srce.hr
http://public.srce.hr/~rpremuz/ * Voice at home: +385 (0)1 687564