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>> </PRE> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <!--X-Follow-Ups-End--> <!--X-References--> <HR> <STRONG>References</STRONG>: <UL> <LI><STRONG><A HREF="msg11434.html">Re: (ASCEND) Re: SNMP Interface representation</A></STRONG></LI> <UL> <LI><EM>From</EM>: Andre Beck <beck@ibh-dd.de></LI> </UL> </UL> <!--X-References-End--> <!--X-BotPNI--> <HR> <UL> <LI>Prev by Date: <STRONG><A HREF="msg11486.html">(ASCEND) does anyone have problems with 5 app 36?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg11479.html">Re: (ASCEND) how to busy out channels</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg11434.html">Re: (ASCEND) Re: SNMP Interface representation</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg11493.html">Re: (ASCEND) Re: SNMP Interface representation</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="maillist.html#11480"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd255.html#11480"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>