NetworkMgmt

HP OV NNM 9i Incident Configuration Action – Blat

7
August 11, 2011
by Michael McNamara in

I thought I would share command line (action I )came up with for having HP Open View NNM send email notifications based on the various SNMP traps received by the management station.

blat.exe -server smtp.acme.org -to Alert@acme.org -cc HelpDesk@acme.org -html -subject "HPOV: UPS on battery ($snn)" -body "<html><body><p style=font-family:Verdana;font-size:12px;font-style:normal;font-weight:normal;><b>HP Open View NNM Alarm Incident Report</b><br /><br />||<b>Date:</b> %date% %time% ($fot)<br />|<b>Alarm:</b> UPS on battery - power failure($name)<br />|<b>Node:</b> $snn($sln)<br />|<b>IP:</b> $mga ($oma)<br />|<b>Contact:</b> $sct<br />|<b>Location:</b> $slc<br /><br />|<b>Notes:</b> generated by HP Open View NNM 9i management server.<br /></p>|</body></html>"

The command line above will utilize blat to send an HTML formatted email message to alert@acme.org with a copy to helpdesk@acme.org with the body looking something similar to the figure to the figure to the right. I’ve sanitized the screenshot to protect the organization I’m currently employed with. The example above is for the SNMP trap ‘upsOnBattery’ while the image to the right is an example of the SNMP trap ‘powerRestored’. You’ll notice the | in the command line is interpreted as a CR/LF by NNM. Here are some of the parameters used in the above example;

  • $ssn – node name of the object sending the SNMP trap
  • $fot – first occurence time
  • $name – OID name of the trap received
  • $sln – DNS name of the node
  • $mga – management IP address
  • $oma – alternative management IP address
  • $sct – contact information for the object as stored in sysContact.0
  • $slc – location information for the object as stored in sysLocation.0

While it wasn’t too hard it did take some time to get all the formatting down and get it working reliably.

Cheers!

Remote Packet Capture with WireShark and WinPCAP

2
September 5, 2010
by Michael McNamara in

I’m just continually impressed with the quality of so many open source products available today. One such product that should be extremely high on any network engineer’s list is WireShark. WireShark has become the de-facto standard for packet capture software and is almost unrivaled in features and functionality.

Last week I had the task of diagnosing some very intermittent desktop/application performance issues at a remote site. I had installed WireShark locally on a few desktops but I wanted the ability to remotely monitor a few specific desktops without obstructing the users workflow to get a baseline for later comparison. I was excited to learn that WireShark and WinPCAP had (experimental) remote packet capture functionality built into each product. I followed the instructions on the WireShark website by installing WinPCAP v4.1.2 on the remote machine and then starting the “Remote Packet Capture Protocol v.0 (experimental)” service. With that done I then proceeded to launch WireShark on my local desktop and configure the remote packet capture settings. From within WireShark I chose Options -> Capture, changed the Interface from Local to Remote. Then enter the IP address of the remote machine along with the TCP port (the default TCP port is 2002). I initially tried to use “Null authentication” but was unsuccessful. I eventually ended up choosing “Password authentication” and used the local Administrator account and password of the remote desktop that had WinPCAP installed on it. If the remote desktop had multiple interfaces I could have selected which interface I wanted to perform the remote packet capture on. In this case the desktop in question only had an integrated Intel(R) 82567LM-3 network adapter. I clicked ‘Start’ and to my sheer amazement the packet trace was off and running collecting packets from the remote desktop. There will still be the occasional need to place the Dolch (portable sniffer) onsite when the situation demands it  but this is a great tool to have available.

Cheers!

Updated: Sunday September 5, 2010
The images appear to be missing above because the URL paths are wrong, not sure how WordPress messed up that. I don’t have time right now to fix it but I will fix it a little later.

Nortel ERS 8600 10GB and MRTG

0
July 16, 2008
by Michael McNamara in ,

MRTG logoI recently stumbled across a problem in MRTG when I was attempting to graph the utilization of a 10Gb interface on a 8683XLR card within a ERS 8600 switch. I noticed that the MaxBytes value that was listed in the MRTG configuration file was 176258176 (176.3 MBytes/s). While this was obviously incorrect I wondered how that value came to be.

I quickly fired up the trusty snmp-net toolset (snmpget) and confirmed from a CentOS Linux host that the ifSpeed OID was returning 1410065408, which is of course is not the correct value for a 10Gb interface. The problem here is that a 32 bit integer can only hold a maximum value of 2^32 – 1 (4,294,967,295). While I believe other manufacturers will just return the maximum value (4,294,967,295) the Nortel switch appears to return a very odd value. I’m not exactly sure why it’s returning that value, perhaps someone from Nortel can help answer that question.

How to fix it?

The Perl script that builds the configuration files for MRTG, cfgmaker, requires a little editing so that it knows how to react if it receives the odd value of 1410065408 when it polls the ifSpeed OID. Here’s the necessary edit;

223c223
<             if ( (not defined $value) || ($value == 2**32-1)) {
---
>             if ( (not defined $value) || ($value == 2**32-1)  || ($value = 1410065408)  ) {

This edit will cause the configuration script to ignore the ifSpeed value and use the ifHighSpeed value which should return a proper value for MaxBytes of 1250000000 (1250.0 MBytes/s).

A quick word of warning here, you MUST use SNMP v2 with MRTG in order to see the ifHighSpeed OID.

Here’s an example of the paramaters I use when calling the cfgmaker script;

/usr/local/mrtg/bin/cfgmaker --global "PathAdd: /usr/local/rrdtool/bin" --global "LibAdd: /usr/local/rrdtool/lib/perl" --global "WorkDir: /var/www/html/mrtg/mdc" --global "IconDir: /mrtg/" -global "WithPeak[_]: wmy" --global "LogFormat: rrdtool" --ifdesc=descr --no-down --zero-speed=100000000 --snmp-options=:::::2 snmpreadstring@sw-ers8600.dc.acme.org -output=sw-ers8600.dc.acme.org.cfg

The parameter “–snmp-options=:::::2″ above tells cfgmaker and MRTG to use SNMP v2 when polling the switch so it can retrieve the 64 bit counters such as ifHCInOctets and ifHCOutOctets as well as ifHighSpeed.

Cheers!

Update: Thursday July 17, 2008

I went back and decided to test the 10GB XFP ports on the Nortel Ethernet Routing Switch 5530. Interestingly enough that switch returns a value of 4294967295 when you query the ifSpeed OID. The output produced by cfgmaker correctly identifies that port as MaxBytes 1250000000 (1250.0 MBytes/s). I may need to call Nortel myself just to satisfy my curiousity on this one.

Cheers!

Update: Wednesday July 23, 2008

It seems that this problem was corrected in software v4.1.5.4 and later for the Ethernet Routing Switch 8600. I was able to confirm that an ERS 8600 switch running v4.1.5.4 does return 4294967295 as expected. Here’s the blurb from the release notes;

MIB value for ifSpeed is now displayed correctly for any 10 Gigabit interface.(Q01174158-01)

Cheers!

Go to Top