[mrtg] Re: ADTRAN Atlas 800 plus

[Greg.Volk at edwardjones.com]

> 
> 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.


--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
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