A5 Better SNMP IF-MIB Support?

[Dan6]

Currently, I only see one interface via SNMP, labeled “eth2”. This port does not appear to be carrying customer traffic, or at least that data is not being provided accurately via 1.3.6.1.2.1.2.2.1.10 and .16.

I would like to collect data on the ethernet port that carries traffic, whether this is via IF-MIB (preferred) or exposed in Mimosa’s MIB.

snmpwalk -v 2c -c public 10.1.16.9 1.3.6.1.2.1.2.2.1.2

IF-MIB::ifDescr.4 = STRING: eth2

[Chris]

Hi Dan,

Eth2 carries management traffic only, which is useful for determining device accessibility.

A5 and C5 byte counts are available if you’re looking to measure usage data over time.
http://ap.help.mimosa.co/snmp-oid-reference-a5

AP Byte Count
Rx .1.3.6.1.4.1.43356.2.1.2.9.4.1
Tx .1.3.6.1.4.1.43356.2.1.2.9.4.2

Client Byte Count
Rx .1.3.6.1.4.1.43356.2.1.2.9.6.1.1.4
Tx .1.3.6.1.4.1.43356.2.1.2.9.6.1.1.5

If you need aggregate Ethernet statistics exposed, we can submit a feature request for that.

[Dan6]

Thanks, Chris. I have relied on that reference so far and am tracking the wireless byte counters properly. I always like to track the ethernet side as sometimes the graphs disagree and it can make troubleshooting easier.

If we open a feature request, I have a few things I’d like to get installed into the Mimosa MIB(s). For instance, one specifically on the A5 is simply a count of associated radios. I can pull (some) stats on each radio, but there is no OID that just tells me how many radios are associated with an AP. I’d also like the AP to report the RSSI(s), SNR(s), and other performance metrics of both sides of the link, not just the receive /or/ transmit side on each.

Basically, I want the AP to be one place to poll for performance data, and I’d rather not be forced to poll client radios to gather that. I appreciate being able to poll client radios when needed, but it’s much easier to monitor only a handful of APs instead.

[Chris]

Hi Dan,

Understood. I’ll submit the request for these.

[Dan6]

While we’re on the subject, I’m getting a strange response to sysUptime:

`# snmpwalk -v 2c -c public 10.1.16.9 1.3.6.1.2.1.1.3.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (10294401) 1 day, 4:35:44.01`

Seems straight-forward, but the webui is showing me right at 16 days and I have client sessions > 7 days on this device, so I believe the webui. I can’t find a nice round factor for the returned timeticks and what I expect (#seconds * 100). I /should/ be getting a number about 138240000 instead but I’m getting 10294401. What scale is this being returned as? I think it should be scaled to #seconds * 100 per the MIB.

reference:
http://www.oid-info.com/get/1.3.6.1.2.1.1.3

[Chris]

Hi Dan,

The sysUptime OID refers to the SNMP daemon, and not the A5. Its time scale is hundredths of a second.

This is probably what you are looking for instead: mimosaLastRebootTime or .1.3.6.1.4.1.43356.2.1.2.1.5.0

[Chadwick]

Request for throughput OID for the wireless interface on the A5. The C5 has it (prior to 2.3.0 firmware) but A5 does not appear to. We like to track throughput in one sensor (in, out and total) for our APs and clients.

[Chris]

Hi Chadwick,

I’ll submit the request for the in/out throughput on the A5. Are you able to perform any numerical operations on values as part of your SNMP software? If so, it would offload the radio from having to perform extra logical operations. We’d like to reduce CPU load as much as possible to keep the C5 lean and fast.

The C5 still shows the Tx and Rx throughput, although the labels would lead one to believe they represent the PHY rate.
1.3.6.1.4.1.43356.2.1.2.7.1.0 (mimosaPhyTxRate.0)
1.3.6.1.4.1.43356.2.1.2.7.2.0 (mimosaPhyRxRate.0)

The actual PHY rate is available on the Chain level with mimosaTxPhy and mimosaRxPhy:
Tx chains 1 and 2
1.3.6.1.4.1.43356.2.1.2.6.2.1.2.1
1.3.6.1.4.1.43356.2.1.2.6.2.1.2.2

Rx chains 1 and 2
1.3.6.1.4.1.43356.2.1.2.6.2.1.5.1
1.3.6.1.4.1.43356.2.1.2.6.2.1.5.2

[Chadwick]

We are able to perform numerical calculations but there is a hard cost associated with that. To do it in our monitoring software (PRTG), that is 3 separate monitors (Tx, Rx and then combined throughput calculation). We pay for each monitor so it costs 3 times as much to do the computation. With 100’s of C5’s out there, that cost adds up very quickly and becomes prohibitive.

[Chris]

OK, understood. I’ll submit the request for the total as well.

[Dan6]

Can you explain the scale OID 1.3.6.1.4.1.43356.2.1.2.9.6.1.1.10 (mimosaPtmpClientTxAvgPer)?

iso.3.6.1.4.1.43356.2.1.2.9.6.1.1.10.1 = INTEGER: 0
iso.3.6.1.4.1.43356.2.1.2.9.6.1.1.10.2 = INTEGER: 3436
iso.3.6.1.4.1.43356.2.1.2.9.6.1.1.10.3 = INTEGER: 158
iso.3.6.1.4.1.43356.2.1.2.9.6.1.1.10.4 = INTEGER: 0
iso.3.6.1.4.1.43356.2.1.2.9.6.1.1.10.5 = INTEGER: 0

Is this percent error rate *100? That second client seems like it’s ~35% in the webui.

[Dan6]

Sorry, and can we confirm the scale of mimosaPtmpClientRxPkts and mimosaPtmpClientTxPkts? These say they’re just straight counter64’s, but I’m showing 20kbits/sec over 5 minute average with .3 (point three) pps according to this.

[Chris]

Hi Dan,

Yes, mimosaPtmpClientTxAvgPER represents the average PER, and you must divide by 100.
For example: 3436 / 100 = 34.36%, which is ~35% and varies over time.

The packet counters show number of packets sent to and received from a particular client, but this number does not speak to the packet size which can vary depending on the type of traffic. I will ask engineering if there is any scaling factor and get back to you, but our current documentation suggests that it is a pure counter.