I just found the following page on Adtran's web site that deals with the Atlas 550 MIBs...
http://www.adtran.com/adtranpx/Rooms/DisplayPages/LayoutInitial?Container=co m.webridge.entity.Entity[OID[D572AE186E5859428AB1DEC316902AC4]] Now I have a dumb question, what do I do with the MIB to use with MRTG. Thanks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 2:59 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [mrtg] Re: Adtran Atlas550 } }Is anyone currently monitoring stats on an Adtran Atlas550? I }have 2 550's, }both with a Quad-T1 and DualV.35 cards, I would like to }collect some stats }on PRI channel utilization as well as V.35 traffic. } If the snmp support in the 550 is anything like it was in the Atlas-890 then you're probably not going to get much. I even opened a ticket with Adtran about getting stats from the 890. For some reason, the MRTG list archive search results are pointing at a different, unrelated message than my original, so I have appending the message here... /****BEGIN ARCHIVE MESSAGE****/ Re: [mrtg] ADTRAN Atlas 800 plus ------------------------------------------------------------------------ -------- To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [mrtg] ADTRAN Atlas 800 plus From: [EMAIL PROTECTED] Date: Wed, 31 Jul 2002 13:02:25 -0500 Delivered-To: [EMAIL PROTECTED] In-reply-to: <[EMAIL PROTECTED]> > > Anyone here use mrtg to monitor an Antran Atlas 800 Plus? > Having issues getting mrtg to graph the traffic. > > Or > Does anyone have an example of the cfg file needed. > Cfgmaker is having a rough time. > > > Steven Nichols > Network and Systems Administrator > Internet and NOC Manager > I jumped through some serious hoops trying to do this. Eventually I gave up because my ATM switch shows a constant bit rate (these are on a CBR contract), and the the following is the relevant portion of my conversation with Adtran about polling the CSU... -------------------------------------------------------------- >> >>I can't poll the terminating equipment because all the ports >>that are connected to my 890's terminate, on both ends, to >>IBM 3745 FEPs which are definitely not snmp-manageable. >> >>Correct me if I'm wrong, but >>iso.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifInOctets >>and >>iso.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOutOctets >>are physical layer (1) counters right? They are protocol independant >>and mib-2 compliance dictates that these counters should display a >>one-to-one correlation with every In and Out byte on the interface. >>These Atlas 890's were purchased partly because they were advertised >>as mib-II compliant. MIB-II compliance means working SNMP counters. >>Working SNMP counters on the CSU are a requirement so that we can >>monitor the utilization of these critical mainframe circuits. >> >>Are there any plans to fix this glaring inadequacy in future >>firmware? > > Greg, These statistics are L2 counters. In your application, the ATLAS has no idea of the difference between idle code (7E or FF), the start and end of a frame (7E), or an abort (7F). In this setup, the ATLAS is only multiplexing a serial stream of 1s and 0s between the T1 and V.35 interfaces. To get really technical, the ifInOctets and ifOutOctets stats should be exactly equal to the assigned bandwidth for the interface. This is because the ATLAS knows no difference between IDLE code and actual data in this setup, therefore it is a fixed rate interface. If we were to change anything in code, it would be to return the fixed rate instead of a Null value. You will not get any useful utilization statistics from any CSU/DSU that is not L2 aware, ADTRAN or otherwise. The ATLAS does have a packet (HDLC) handler built in that is meant for encapsulation this type of traffic in Frame Relay. If you would like the ATLAS to become L2 aware and collect utilization statistics we can change your configurations to pass these links through the packet handler (in a private Frame Relay environment). However, this setup requires you to use ATLAS at both ends of the circuit. It is also much more CPU intensive than your current setup and will reduce the maximum number of links you can route through the box (from 30 T1s to about 8). In my opinion it is not worth going through this trouble to get these stats on IBM legacy protocol. The true value of the SNMP management is to alert you of T1 circuit outages and such. If you would like more information regarding the packet handler. Just let me know. ------------------------------------------------------------ So that's where I left the issue. The only thing I can really disagree with in the above response is the part of about 'this is not worth the trouble to get stats on an IBM legacy protocol.' These are _very_ important circuits to me, and I would really, really like to know what the utilization is on them independant of what the mainframe tells me. Nonetheless, this is where I left the issue. -- Attached file removed by Ecartis and put at URL below -- -- Type: application/ms-tnef -- Size: 2k (2410 bytes) -- URL : http://www.ee.ethz.ch/~slist/pantomime/49-WINMAIL.DAT -- Unsubscribe mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/mrtg FAQ http://faq.mrtg.org Homepage http://www.mrtg.org WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi -- Unsubscribe mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/mrtg FAQ http://faq.mrtg.org Homepage http://www.mrtg.org WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
