[mrtg] Re: ADTRAN Atlas 800 plus
Greg.Volk at edwardjones.com
Greg.Volk at edwardjones.com
Wed Jul 31 20:02:25 MEST 2002
> Anyone here use mrtg to monitor an Antran Atlas 800 Plus?
> Having issues getting mrtg to graph the traffic.
> 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
>>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
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
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.
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
FAQ http://faq.mrtg.org Homepage http://www.mrtg.org
More information about the mrtg