Most companies create a private MIB tree that looks like this: iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).... companyX(xxx). productA(aaa)... productB(bbb)... productC(ccc)... ...and within each product, one can have a complete set of mib files unique to that product (in some cases, one must be willing to do some editing and renaming of the mib files if the vendor does not publish a complete set for each product). Ascend has a single set of MIB files that are supposed to support all Ascend products (and Ascend does not have a "product" level within their tree). This appears to be a problem in cases like the following: 1) Given the set of MIBs published in September, take two Pipeline 130-FT1s. Configure them in an "identical" manner (except for the DCLIs and IP Addresses required to be unique for each Pipeline). Pay special attention to the Pipeline "20-700" SNMP trap settings, and make sure that both Pipelines "know" the same SNMP manager address. 2) Now upgrade one Pipeline to 5.1A, and leave the other Pipeline at 5.0Ap1. 3) Now use any SNMP software to simply try to pull up the interface table for each pipeline: 3a) The Pipeline at 5.1A gives us entries for: Console 1 BRI Slot 1 Line 1 Nailed T1 ie0 wan0 - wan10 wanidle0 tunnel0 mcast0 rj0 bh0 local lo0 3a) The Pipeline at 5.0Ap1 gives us entries for: Console 1 BRI Slot 1 Line 1 ...and nothing else. Not even an entry for the fractional T-1 Wan port. Not even an entry for the ethernet port. If one reads the mib file, one expects both devices to give similar information in this very basic table. If this is the situation with the ascend-supplied RFC mibs, and a simple revision difference, what happens when we have a mix of Ascend products AND an mix of revisions, all expecting us to have different mib revisions? What happens when we have two vendors, each who make use of a different "RFC mib" that they supply in subset form? It would appear that Ascend needs to add the following levels to their mib tree: ...ascend(529). product(1-x). revision_major_num(4 and up). revision_suffix(0-9???). HERE STARTS THE TABLES If this were done, one could manage a random group of different Ascend products at different revisions, and be able to work with older mibs that are appropriate for older versions. Where I come from, we call this "working", and we call the example above "broken". Comments? Surfing the electromagnetic spectrum, looking for that perfect Hertzian wave james fischer jfischer@supercollider.com ++ 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="msg09718.html">Re: (ASCEND) "System Password: " prompt?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg09692.html">(ASCEND) Users stay connected but cannot see any web sites</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg09784.html">Re: (ASCEND) Users stay connected but cannot see any web sites</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg09702.html">Re: (ASCEND) SNMP MIBs, Different Equipment, Different Revisions</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="mail13.html#09700"><STRONG>Main</STRONG></A></LI> <LI><A HREF="thrd204.html#09700"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> </BODY> </HTML>