Rob,
mib2trap only provides you with a starting point for defining a trap. It
uses that simple default format, but you can always improve on that by
using information from the original MIB.
Go to the cisco-ns-mib or whatever MIB contains the TRAP-TYPE (SNMPv1) or
NOTIFICATION-TYPE (SNMPv2) statement for this fcNameServerNotifications
trap, and find that statement.. The very next line will say VARIABLES
(SNMPv1) or OBJECTS (SNMPv2) and it will list in order what each of the MIB
variables or objects are that will be sent with this trap. You can
then use that name and change the format of the trap yourself to be more
meaningful. If that's not enough, you can also search the MIB for that
name and find where that object is defined, and there will probably be a
description clause with it which will explain just what that name object
represents.
Another alternative in current code if you have loaded all those MIBs with
the web console MIB loader is to select the ones which have trap
definitions in them and run the Java loader's --mib2Trap option on them.
It produces a different default format which identifies the trap varbinds
by name rather than by OID. If you like that better, then you should use
it. Remember that you can replace a trap definition with the addtrap
command as often as you like. If there is already a definition for the
trap defined in the addtrap command, it will be replaced.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Brinkworth, Rob"
<rob.brinkworth@l
andg.com> To
Sent by: "'nv-l@lists.us.ibm.com'"
owner-nv-l@lists. <nv-l@lists.us.ibm.com>
us.ibm.com cc
"Shirley, Tony"
<tony.shirley@landg.com>, "Skates,
12/28/2005 05:35 Andy" <andy.skates@landg.com>
AM Subject
[nv-l] Cisco MDS 9000 traps
Please respond to
nv-l
Hi All,
I'm trying to get NetView (7.1.4 FP3 on AIX 5.2) to manage Cisco MDS SAN
switches, in this example a Cisco 9216. I've loaded nearly 100 SAN-related
Cisco SNMPv2 MIB files with the Web Console MIB Loader and mib2trap. Here's
an edited highlight from our trapd.log file showing an example of an
incoming trap:
A fcNameServerNotifications 6 3 3 args: [1]
cisco.ciscoMgmt.293.1.1.4.1.2.143.43.9.0 (OctetString):.....
A [2] cisco.CiscoMgmt.293.1.1.4.1.8.143.43.9.0 (Integer): 2
A [3] snmpV2.snmpModules.18.1.3.0 (IpAddress): ......
In one way this all seems correct. The main trap is correctly getting
resolved to "fcNameServerNotifications" by virtue of the notification
definitions in cisco-ns-mib. However, there are no notification definitions
in cisco-ns-mib to allow the resolution of "..293.1.1.4.1..". There are
relevant OBJECT-TYPE entries in the MIB file, but that's no help as they
don't make it to the addtrap commands generated by mib2trap.
My problem is that the information is useless as it stands. If a SAN
specialist was called out-of-hours and passed the information above, it
would be of no help. No other Cisco MIBs appear to mention ciscoMgmt.293.
It
seems as if the MIB file has major shortcomings in being of little or no
use
in allowing the handling of traps by NMSs, but this seems a bit surprising
for a major player. It strikes me as much more likely that I'm missing a
fundamental point here!
I tried running the SNMPv1 version of the MIB file (cisco-ns-mib-v1smi)
through mib2trap but it doesn't appear to be any better.
Am I missing some crucial piece of the jigsaw here? Any advice gratefully
received.
Regards,
Rob Brinkworth,
Systems Management Integration Architect.
Legal & General.
This e-mail (and any attachments) may contain privileged and/or
confidential information. If you are not the intended recipient please do
not disclose, copy, distribute, disseminate or take any action in reliance
on it. If you have received this message in error please reply and tell us
and then delete it. Should you wish to communicate with us by e-mail we
cannot guarantee the security of any data outside our own computer systems.
For the protection of Legal & General's systems and staff, incoming emails
will be automatically scanned.
Any information contained in this message may be subject to applicable
terms and conditions and must not be construed as giving investment advice
within or outside the United Kingdom.
The following companies are subsidiary companies of the Legal & General
Group Plc which are authorised and regulated by the Financial Services
Authority for advising and arranging the products shown: Legal & General
Partnership Services Limited (insurance and mortgages), Legal & General
Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust
Managers Limited and Legal & General Portfolio Management Services Limited
(investments).
They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London
EC4N 4TP.
Legal & General Partnership Services Limited: 5045000 Legal & General
Assurance Society Limited: 166055 Legal & General (Unit Trust Managers)
Limited: 1009418 Legal & General (Portfolio Management Services) Limited:
2457525 Legal & General Insurance Limited: 423930
They are registered with the Financial Services Authority under numbers
shown. You can check this at www.fsa.gov.uk/register
Legal & General Partnership Services Limited: 300792 Legal & General
Assurance Society Limited: 117659 Legal & General (Unit Trust Managers)
Limited: 119273 Legal & General (Portfolio Management Services) Limited:
146786 Legal & General Insurance Limited: 202050
|