Stephen,
There might actually be a solution for you, and it would basically be
supported (from a NetView point-of-view). In fact, I'm in the middle
of writing a poller myself that uses this "feature".
The key here... is to send back to your NetView system MLM status
traps. DO NOT try and mimic netmon traps to do the job.
There is an example-program with NetView V6 called iface_status.tcl.
You can call this script out-of-the-box if you wish to accomplish
the job (on a NetView system). On NT it is in the \usr\OV\tcl directory.
On UNIX I assume its in the same place (i.e. /usr/OV/tcl).
What it does is produce mid-level manager status traps for Interface Up/Down
for any given node/address. This allows you to offload polling (or at least
set the polling interval VERY long).
Currently, I user a perl incantation of this script (I don't know TCL) to
have
site NetView NT systems report to a central NetView NT system.
Play around with it. It works.
Of course... there is one small problem (which is also why I use perl)...
In order for you to use this... you have to have a "send_snmp_trap" utility.
NetView has one... which is what they use in iface_status.tcl. Perl
libraries
provide one (which is why I use perl).
You'll either have to use perl, CMU snmptrap utility, or something else (I
wouldn't
be surprised if Linux has one built-in).
Well, have fun.
Gary Boyles, Intel
-----Original Message-----
From: James_Shanks@TIVOLI.COM [mailto:James_Shanks@TIVOLI.COM]
Sent: Wednesday, February 28, 2001 9:44 AM
To: IBM NetView Discussion
Subject: RE: [NV-L] Override status
Stephen -
I am not certain how you got into this situation because there have never
been any announced plans to provide MLM on Linux. So that should have been
known up front when your company did its initial purchase. And whether
the powers that be in your company will allow another platform or not, your
scripts are still not a supported way to run the product. They aren't
going to alter the status of objects in the database, only change it on the
map, so you are going to have to prohibit netmon from updating these
devices himself. You are welcome to try what you like but you won't get
much help from support for your scripts.
And yes, discovery in MLM is still limited to the same subnet, though
monitoring can be expanded by adding devices to the smartset which
represents what the MLM monitors. Leslie has covered that in this forum
before.
Sorry to rain on your parade but I don't have any suggestions. At this
point I am not even sure I understand the problem. Why not try explaining
that in detail and see if anyone else has a suggestion how to improve
things that doesn't require you to try to circumvent netmon.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Stephen Elliott <selliott@epicrealm.com>@tkg.com on 02/28/2001 11:44:30 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Override status
Thanks for confirming the trap generation process.
As regards to other MLM options, I really don't have any. Our data centers
are 100% Linux and the powers that be will not allow NT, period. We don't
have enough older equipment Sun or other to cover all the data centers with
Unix and we can't buy hardware anyway, so my hands are pretty well tied.
The
poller script using fping is the low-cost winner in this situation. It
actually works out, tho. The local poller is for back-end servers only.
Front-end network devices will still be polled by NetView. The netmon queue
should be reduced by 75% and we'll have better coverage of servers as their
polling cycle now is 5 minutes.
If (and that's a big IF) I can wrangle two or three boxes (Intel or SPARC)
out of them, I can build MLM's and locate them in the same site as the
NetView server to accomplish the same goal. Or maybe I can. Are MLM's still
limited to same segment only addresses? If the they are, then I'm still
stuck with a script.
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
-----Original Message-----
From: James_Shanks@TIVOLI.COM [mailto:James_Shanks@TIVOLI.COM]
Sent: Wednesday, February 28, 2001 8:58 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] Override status
I am not sure what you are actually asking. Yes, it is netmon who
generates all those traps, Node Down, Node Marginal, Node Up, and so on.
And that is why you do not see them. If you ant to see those, then your
script will have to generate those as well.
>From the sound of things, these interfaces and the nodes they are attached
to are already on the map. How are you bypassing netmon from polling them?
Be aware that nothing you do with the 58916871 will affect what is in the
topology database, so if netmon is also monitoring those interfaces, he
will override your status when he sees the need. While I don't want t
stifle your innovation, you should be aware also that what you are doing --
writing your own script to bypass netmon -- is not really supported. The
purpose of the status trap was so that you could change the status of items
you put on the map which were not being monitored by netmon, such as
applications and other non-IP resources.
I'd like to see an MLM on Linux too, but I fail to see how that should
cause you to do this. There are plenty of other MLMs, AIX, Solaris,
Digital, HP, and NT, and they can run on the oldest, cheapest boxes you
can find. Any box you can run Linux on, you can run NT. I have seen an NT
MLM run on an old 486, 83 MHz box, which didn't have enough horsepower to
drive the full NetView for NT GUI. Once it was running, the display was
disconnected.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
Stephen Elliott <selliott@epicrealm.com>@tkg.com on 02/28/2001 09:34:04 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'nv-l@tkg.com'" <nv-l@tkg.com>
cc:
Subject: [NV-L] Override status
Hello, All.
NV 6.0.1 on Solaris 2.6.
A question for James Shanks or Leslie Clark.
I have a task to write a status polling script that is to run in each of
our
data centers, thus off-loading status polling from NetView for these
interfaces. Netmon's polling queue is at it's limits and we can't do MLM's
as IBM has not developed a Linux MLM yet.
Down/Up notifications for interface status will be sent by the sript to
NetView via the 58916871 trap. So far, this works fine and the status of
the
interfaces in question get changed properly (the
nvevents.overrideCompundStatus is set to True as per your Override Status
document). Status is propagated upward for the Node as well, reflecting
Marginal or Critical based upon the submap propagation rules. The only fly
in the ointment so far is that there are no Node Down events being
generated
and I'm assuming that this is because netmon typically generates these when
it detects that all interfaces in a given node are down. Since we're
effectively bypassing netmon for interface status on these devices, it
won't
know when to gen a trap. Can you validate this for me? I'm hoping I've
missed something simple, otherwise I've got more code to write.
Regards,
Steve Elliott
Sr. Network Mgmt. Engineer
epicRealm, Inc.
214-570-4560
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
|