> Robert and Jan-Peter,
>
> Thank you for your advice, and I agree with you. Now I am studying
> the tkined source. I hope it'll start to make sense to me.
>
> Now this might not be a good topic for this mailing list, but since we
> already have a discussion going...
>
> My problem is that I need to walk through a big MIB-variable table to
> compute the two numbers (number of open B channels and the number of
> modems in use), and it takes quite a bit of time to walk through the
> table, unless tkined and the Ascend are on the same LAN.
>
> 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?
The best way to minimize traffic with SNMP is to do as few queries
as possible, and do them less often. An alternative, is to find another
MIB or MIB variable that gives you the answer you need, with fewer and/or
smaller SNMP exchanges. It helps (maybe not in this case) to combine
requests together in one packet. This reduces overhead (IP/UDP/SNMP
headers), however, you must be careful not to make a packet bigger than is
allowed (the RFC says something like 432 bytes, however, Cisco routers can
reply to packets much bigger). For your table of 136 rows, you shouldn't
have to worry too much... even if it's 100 bytes per packet: that's only
13.6 Kbytes per query, which would be fine once a minute over ethernet.
It probably take 30 seconds just to `walk' all the rows in the table!
That's one good thing about `walk', it gets one variable at a time (and
there is some inherent waiting involved). (`walk' is bad for the same
reason ;-) You have an advantage here... you only need to walk
callStatusValidFlag, then if it's valid, you can get callStatusDataRate,
etc. for that row. scotty was _made_ to do this sort of job.
By the way... how is your Ascend box working for you? We were
going to try to use Ascend and gave it up. We'd tried Shiva, and gave
that up too. We are now using Cisco 752's and they seem to really work.
Have fun!
Ed
> --------------------------------------------------------------------
> Tatsuo Natsukawa natsu@itjit.ad.jp http://www.itjitnet.or.jp/~natsu/
> finger natsu@natsu.itjit.ad.jp for my PGP public key
>
> From: Robert Premuz <rpremuz@srce.hr>
> Subject: Re: Proper way to write an original agent?
> Date: Mon, 24 Jun 1996 16:52:52 +0200 (MET DST)
>
> > On Mon, 24 Jun 1996, Jan-Peter Richter wrote:
>
> > : As far as I understand SNMP network management philosophy, calculation
> > : of derived measures should be done by the NM application, not the (or an
> > : additional) agent. So the "proper way" would be to not write an agent
> > : at all. (I may be wrong on this, and if I am, please correct me.)
> >
> > I agree with Jan-Peter. So, Tatsuo, simply, make tkined compute the
> > derived variables before drawing them and you won't need the agent at
> > all.
>
+-------------------------------------------------------------------------+
| Ed Phillips <flaregun@udel.edu> University of Delaware (302) 831-6082 |
| Associate Systems Programmer, Network and Systems Services |
| Public key footprint: 1C D4 AC C2 A3 D5 97 AA DB 3B D8 85 88 E7 40 B8 |
| finger -l flaregun@polycut.nss.udel.edu for PGP public key |
+-------------------------------------------------------------------------+