As far as the design of the ascend mibs- there's some real clever things in there- like the eventgroup is a ring buffer-- a really efficient way of storing this data in a fixed amount of space, which is probably just a ton of arrays "under the hood". What I don't like is the modem mib- the information I want just isn't there- like a realtime query-able receive-level, and support for user's downstream speeds (it's been so long since 5.0Ai13... maybe in 6.0 it'll be there. though I was hoping we'd at least get 5.1 before next year.) -Will -----Original Message----- From: Andre Beck <beck@ibh-dd.de> To: Ascend Users <ascend-users@bungi.com> Date: Monday, December 08, 1997 6:47 AM Subject: Re: (ASCEND) Re: SNMP Interface representation On Fri, Dec 05, 1997 at 06:38:38PM -0500, Phillip Vandry wrote: > > > >Then if I want to monitor my dedicated customers, they probably fit in the > > > >static mappings, so I can assign them an ifIndex and use that ifIndex to > > > >monitor them whereas I will not assign a mapping to Joe 28.8 User. > > > > > > > >- -Phil > > > > > > I totally agree with this methodology. I don't care about the switched > > > connections. I care about the nailed ones. > > > > A good solution however should care about all of them. I may as well be > > interested in graphing certain dial-on-demand customer links. > > So if you have 50,000 dial up users, do you want each and every one of > your Maxes to reserve an interface slot for each user, in case that user > connects to that Max so you can monitor the user without having to first > look up the interface number? No, that's exactly what I dont want. This is what the interface-based approach would require - one "logical" interface per potential connection, and exactly this is what makes it a bad idea. Maybe nice with a Cisco1005 or similar two-fixed-interfaces-router, but fails badly with a NAS. What I want (and what seems to be there in 6.0) is one ifEntry per quasi-physical interface and a mapping from logical to physical interface that is easy to use and requires minimal SNMP traffic. > Remember that you can still find every session under this scheme. You > just have to do a table lookup to find the dynamically assigned > interface number for the less often used ones. Exactly what I want. And as stated - maybe Ascend makes access to nailed interfaces a bit more static, but IMHO it is more useful to supply a complete solution with minimal overhead for all interfaces but not only for nailed ones. Of course it is easier to query a fixed ifIndex and it was sufficient for a long enough time to become a quasi standard in the NMS world, but it never was thought this way _only_ and logic has to be added on the NMS side and not necessarily on the NAS. > > 2) Starting with 5.0A it is possible to automate the above. I've posted > > an example here on the list that marriages Ascend leased lines with > > MRTG. I will adapt this to the WAN MIB ASAP (6.0b site is already > > It is quite heavy to do this, though. It involves an snmpwalk. Yes, and that's what I would like to get fixed. 5.0A already made it easier due to a working sessionActiveTable (IIRC) but still required a full walk of the callStatusTable. With a working callActiveTable it would reduce again, but is still suboptimal. I'm under the impression that the WAN MIB in 6.0 will give a short way into the ifTable and eventually supply a nice set of shortcuts. It is a good question of how to supply a one-hop access for a ProfileName-->ifIndex mapping, but creating internal hash values from profile names by a known algorithm (i.e. known to the NMS) could do this if the table is then indexed by these hash values. In an optimal world this could allow to find such mapping in one GET or (if hash values collide) with a small set of GETNEXTs - certainly faster than with a full walk. Our infrastructure can stand a full walk every 5 minutes, but thats because it is rather small ;-> Andre. -- Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4 +-o-+--------------------------------------------------------+-o-+ | o | \\\- Brain Inside -/// | o | | o | ^^^^^^^^^^^^^^ | o | | o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o | +-o-+--------------------------------------------------------+-o-+ ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> ++ Ascend Users Mailing List ++ To unsubscribe: send unsubscribe to ascend-users-request@bungi.com To get FAQ'd: <<A HREF="http://www.nealis.net/ascend/faq">http://www.nealis.net/ascend/faq</A>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg11494.html">(ASCEND) Pipe75 won't drop one bonded line</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg11491.html">(ASCEND) Neat, huh?</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg11480.html">Re: (ASCEND) Re: SNMP Interface representation</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg11086.html">(ASCEND) Max 5.0Ap36</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#11493"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd255.html#11493"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>