Search

Aprisa Link Monitoring Part 2

Another Fan Failure

Last weekend was short lived.  The probes that I setup on the Dude to monitor the fan status worked all too well.  We got the first stiff winds with snow/ice mix over the weekend. One of the fans was going from good to bad over and over again.  I called Paul and Jeremy who told me that there must be something wrong with my alerts; they probably thought that it was a false alarm because I just set those alerts up last week.  After telling them that I setup the same alert on all the radios and only one of them is complaining, their tone changed.

Another Link Flapping

On November 17th, another one of the links started flapping.  This was causing the 2-way radio network to key-up because the voter was losing its tone from the remote end’s E&M module.  Paul came in and asked me if I was doing anything with the radio configs.

“Nope.  But I can see that the Aprisa is going up and down again.  It looks like there are errors on the line.”

“These are Ethernet radios.  The error on the near end is saying that there is an Ethernet problem.  Did you disconnect the Ethernet cable from the radio at the far end?”

“Well, yes.  About 4 weeks ago.  Do you really think that has anything to do with it?  ‘Ethernet’ could mean the RF link – which is what I believe we are having trouble with because we can’t ping the remote end.  The wireless link can be looked at simply an extension cable for an Ethernet cable that goes sixty miles.  The sideband E&M cards are just VoIP devices in the radio…”  Paul’s cell phone rang.

“Ok. I’ll be right there…” and hung up his phone. “That was Jeremy. He logged into the camera that’s on the tower.  There’s someone climbing it right now.  I’m going to check it out.”

Revisiting ‘New’ Problems

My first post on Aprisa link monitoring involved setting up simple probes for the fans and doing some rudimentary checking for temperature alarms.  Based on this last couple of new issues that we have experienced, I decided to revisit this one.  Aside from getting too many text messages and Paul not trusting the alerts, the fan alarms worked very well.  After talking to Paul and him thinking that I had caused a failure by pulling a Ethernet cable out of the far end radio thereby causing a radio link error, I have decided to revisit monitoring the RF Ethernet link.

On my first post, I mentioned that I needed to follow up with the manufacturer and verify that the OIDs that I picked actually were the right ones.  Well, I got the reply:

—–Original Message—–

From: Ian Fleming [mailto:here@there.org]

Sent: Thursday, 11 November 2010 3:40 a.m.

To: Support

Subject: RE: Support request

Leif,

Thanks for the MIB.  We are having some trouble with fans failing and would like to monitor them.  This helps. […]

Thanks,

-ian

Hi Ian

We have revised the fan used in the XE a few years ago, the new part number is KD1206PTB1 (2).GN.I55, SUNON DC12V 1.8W. The newer ball bearing fans have proven to be more reliable than the older style fans. Replacement fans can be purchased from 4RF directly.

[…]

Kind Regards

Leif

So, I got more information than I expected.  The OEM fans have been replaced with a new model.  Paul put the new fans on order.  After they are replaced, maybe my fan probes will never go into alarm again!  The more interesting item e-mailed was the MIB that came as an attachment.  I don’t know why they don’t post these on their website.  It’s too bad you have to e-mail support to get this information.  Hopefully this will help someone out there with an Aprisa XE.

The intent of this post is to address what actually happened with the link flapping on the 17th of November.  Paul and Jeremy confirmed that a tower climber was next to our dish with a hot feed line.  Essentially, he was spraying RF all over the place as he was climbing our tower.  This caused errors on the Ethernet RF link.  When the climber finally plugged the hot line into his antenna, the interference stopped.  I now want to graph RSSI and errors over the RF link.  This is how I did it with help from the MIB e-mailed to me from the engineer, Lief, at 4RF.

Graphing RSSI

Graphing and displaying RSSI is a little different than just reporting whether something is operational or not using a probe.  The probe only tests if a condition is true or not and takes action based on the condition.  To graph in the Dude required me to setup a function.  Then the function can then be setup as a probe.  When the function is setup as a probe, I was given more options than just to test for a simple condition.  I can display the information on the device and test for more than one condition.

Create the Function

The OIDs that I am interested in are:

  • aprisaXECorrectableErrorCount.0: 1.3.6.1.4.1.14817.7.3.1.2.6.1.0
  • aprisaXEUncorrectableErrorCount.0: 1.3.6.1.4.1.14817.7.3.1.2.6.2.0
  • aprisaXETerminalRSSI.0: 1.3.6.1.4.1.14817.7.3.1.2.1.5.0
Setting up the Function

Setting up the Function

The first one that I mapped to a function was the relative signal strength indicator (RSSI).  Because this OID will always return a negative integer, I decided to make it positive by multiplying it by -1.  This makes the chart “work”.  When I tried to graph it using negative values, the chart didn’t appear at all.  Unfortunately, the Dude does not have an absolute value function.  Being that RSSI will always be negative, multiplying by -1 should do fine all the time.

After creating the function, I had to test it.  I displayed this function on the device.  To do this, I right clicked on the device and selected the ‘Appearance’ option.  Under General tab, the Label field will display everything that shows up on the device.  Variables and functions are enclosed in square brackets.  I had to play around with this a little to get the RSSI to show up the way that I wanted it to be displayed.  This was only for displaying the real-time data for the OID function that I just setup.  Next I had to setup a probe to monitor which gave me a nice chart to view the history of RSSI on the Aprisa radio.

Also notice my error counters.  I made a function for the “link error” OID’s that I noted above as well; but this is an incremental counter.  To alert for the errors, I had to use the following function Aprisa_ErrorCount():

rate(oid("1.3.6.1.4.1.14817.7.3.1.2.6.1.0") + oid("1.3.6.1.4.1.14817.7.3.1.2.6.2.0"),10)

Because the OIDs counters are cumulative, the rate (10 seconds) is graphed.  The probe is setup to error if the function does not equal zero:

if(Aprisa_ErrorCount() = 0, "", concatenate("Warning: errors detected! Error rate is ", Aprisa_ErrorCount()))

Setup the Probes

This probe will be setup using the function you just created.  Add a new probe, and select function.  For the RSSI to be marked as available, the function has to result in a number greater than 1.  The error condition checks that if() statement to see if it is normal.  The first parameter of the statement must be true for it not to be in an error state.  Because I am using this probe only to graph RSSI, I set the normal condition to -10000 – an impossible value.  This probe should never go into an error if it is available.

The Value field is used for the chart. I put in my function so that it would graph it out.  Now, I have a nice little chart to look at:

Aprisa Terminal RSSI chart (values are negative)

Fans

You are probably wondering about the fans.  My last post I mapped the temp alarm OID.  Well, this is great; however, there will probably be some damaged equipment or a malfunctioning link if the temperature alarm is going off.  How about just monitoring the fans for alarm conditions?  That’s just what I did after getting the MIB from New Zealand and reading it.

I found the alarm OID.  I just mapped them to probes.  The normal condition is zero.  Anything else is bad.

aprisaXEFan1Status.0: 1.3.6.1.4.1.14817.7.3.1.2.21.1.0
aprisaXEFan2Status.0: 1.3.6.1.4.1.14817.7.3.1.2.21.2.0
Advertisements

6 Comments on “Aprisa Link Monitoring Part 2”

  1. John Versluys says:

    Is there some way I can get the Aprisa MIB from you. We are tring to use a network monitoring product call ManageEngine. I have received some MIB’s from 4RF but ManageEngine says there are formating and other errors in them and so can’t use them. Perhaps what you had would work better.

    Thanks

    • itcoop says:

      Here is the file that they sent me:
      http://sdrv.ms/OwF14Z
      Note that I really never use private.enterprise MIB files. I create custom probes of interesting counters by reading the MIB manually. It seems like compiling MIBs and dependency issues are a common issues. This is why I reference the absolute OIDs of the interesting counters/gauges as opposed to referring to the MIB. Is there something in particular you want to monitor? Hope this helps!

      • John Versluys says:

        Thanks very much for your help. We’re hoping to monitor most of the values from the Aprisa but need to have a MIB in our monitoring software. 4RF are having another look at it. We might have to resort to editing the MIB ourselves to remove code issues.

  2. Noel Torres says:

    HI! We recently acquired Tivoli Netcool as an NMS. We’ve compiled the Aprisa MIBs but there are traps being sent that we don’t understand. I tried accessing the link you’ve provided John but I can’t get through. Is there any other way I can get the Aprisa MIBs from you? Thank you very much.

  3. Faisal says:

    Hi,
    Please can you also send me the MIB file for Aprisa XE. Also advise do we need to upgrade Aprisa software to make it compatible with MIB files?
    It will be great help.

    Thanks!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s