James,
I already have an application working that provides status of my nodes
various software applications, so it won't be that difficult for me to have
this app also status the interfaces that I was using netmon for.
If I could find a way for netmon to work in our network scheme, I would
still use it. Unfortunately, it doesn't seem to work the way I need it to.
If I could find a way to have Netview bind to a specific interface, I might
be able to still use it. I might possibly be able to set up xnmsnmpconf to
help me out, but I currently just have the default in it, so I am not sure
how to set it up to meet my needs (if even there is a way)
However, I am getting incorrect statuses when I have netmon running in
conjunction with my application. I can modify my app to do everything that
netmon provides, so if I have to get rid of one or the other, it has to be
netmon.
I have attempted to contact support, but after several days, they haven't
even returned my call (they only said that I was #44 on the queue, and it
would take some time for them to call back). Based on the feedback that I
have gotten from you and the rest of the list, I doubt they can help me
anyway. We make extensive use of the Netview programming API, and it looks
like very few others do, so it looks like I am on my own. If you have any
other suggestions (possible advice on using xnmpsnmpconf), please let me
know.
Thanks,
Jeff
James Shanks
<jshanks@us.ibm.c
om> To
nv-l@lists.us.ibm.com
Sent by: cc
owner-nv-l@lists.
us.ibm.com Subject
Re: [nv-l] Monitoring nodes running
ospf
04/01/2005 05:27
PM
Please respond to
nv-l@lists.us.ibm
.com
Jeff,
Get rid of netmon? Very ambitious, and not the sort of thing most people
try.
The ovsuf file in /usr/OV/conf will show you the dependencies. netmon has
plenty but no other daemons depend on him. So yes, you can shut him down.
If he stays registered, however, then whenever you start the GUI, the
netview start-up script will try to start him. So you'd probably have to
de-register him with "ovdelobj /usr/OV/lrf/netmon.lrf". Or you could
just have the script ovstop him after it starts ovw.
The issue is, who's going to provide status now? You'll have to update the
topology and object databases now yourself, and send appropriate traps
after doing so, so that ipmap will update the maps. A tall order, I think.
And not one that is well-documented.
At this point I'm going to decline to advise you. This is pretty far
afield from where I usually operate. I frankly think you should use
NetView in the standard fashion and just get your remote box to supply
status of its interfaces the way others do. The closer you stay to normal,
the easier it will be for you. And you will be able to get more help from
Support. Start running NetView without netmon but still trying to get
ipmap to update status for you is beyond what they could probably help you
with. In fact, I'm no longer certain that NetView provides the proper
platform for what you want to do, unless you want to try using xxmap and
the open topology facilities rather than netmon and ipmap.
The so-called open topology facilities are covered in the Programmer's
Guide and Programmer's Reference, but they are not for the faint of heart.
However, using them you can write an application to update the status of
your own objects on the map, which can represent anything at all. I once
saw an app to track the status of rental motorboats on a lake that they
used in a class on that stuff long ago -- but I haven't been involved with
it for years. So I'm not going to try to explain it, especially here.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jeff.ctr.vandenbu
ssche@faa.gov
Sent by: To
owner-nv-l@lists. nv-l@lists.us.ibm.com
us.ibm.com cc
Subject
04/01/2005 03:06 Re: [nv-l] Monitoring nodes running
PM ospf
Please respond to
nv-l
James,
Since netmon cannot discover/status the nodes the way I need it to, I am
going to try and not use netmon at all. Is there any problem with shutting
netmon down, and not having it ever running (do other daemons depend on
netmon, etc), or am I better of just excluding all my IPs in the seed file.
Thanks,
Jeff
James Shanks
<jshanks@us.ibm.c
om> To
Sent by: nv-l@lists.us.ibm.com
owner-nv-l@lists. cc
us.ibm.com
Subject
Re: [nv-l] Monitoring nodes running
04/01/2005 12:01 ospf
PM
Please respond to
nv-l@lists.us.ibm
.com
Jeff,
xnmsnmpconf lets you define an SNMP proxy. That would be the interface we
would use for SNMP if you have one defined, at least so far as I understand
it.
Your other issue is beyond me. I'm not the netmon guy. And so far as I
know, the only way to diagnose netmon problems is with the netmon trace.
I'm sorry that Support hasn't called you back, but realistically, they are
going to have a very hard time following all this. You've made so many
changes from normal here that I'm not certain anyone can help.
But netmon isn't capricious. It's doing pings and SNMP polling, based on
what's in it's databases and config files. So if it's not doing that
correctly, then the thing to do, in my mind, is to undo your changes
completely and start over. No dual definitions in the seed file, no
special entries in xnmsnmpconf. Just basic stuff. You may have to
delete these nodes from your databases and rediscover them, with just one
discovery entry in the seed file and one entry in xnmsnmpconf, nothing
special, to put things right. The thing to remember, I think, is that if
netmon is confused now, it's because, somehow, you confused him. So try to
"un-confuse" him and proceed more cautiously after that.
That's the only advice I can give you. I'm sorry if it's a bitter pill
and not more helpful.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jeff.ctr.vandenbu
ssche@faa.gov
Sent by: To
owner-nv-l@lists. nv-l@lists.us.ibm.com
us.ibm.com cc
Subject
04/01/2005 11:05 Re: [nv-l] Monitoring nodes running
AM ospf
Please respond to
nv-l
James,
How can I let xnmsnmpconf define a "preferred" interface? What would
happen if I define this interface as my "virtual" IP interface on the box?
That sounds like what I want, but I am not sure what the syntax of
xnmsnmpconf is to do this.
Also, another problem I am running into:
When I stop/start software on some boxes, the status of the active
interface changes. In other words, I stop my custom app on host1, netmon
changes the status of ethernet 0 (the active interface) on host1 from
normal to critical on the map. If I display object status from the menu,
the status is listed as normal (but still displayed as critical on the map.
These should have nothing to do with Netview (although they include SNMP
subagents)
I even tried to rebuild the topology without my custom topology. letting
netmon do the only discovery, and I got the same results. What gets worse
is that I shutdown a custom app on host3, and host1 and host2 E0 switch
from normal to marginal??????
Note that in my seed file I have both ICMP and SNMP defined as status
polling (can this be done?). This was the only way I could get netmon to
status everything correctly (except this problem). I tried using either
ICMP or SNMP and still got the same results.
I have left a message with support, but I am still waiting for them to call
me back.
James Shanks
<jshanks@us.ibm.c
om> To
Sent by: nv-l@lists.us.ibm.com
owner-nv-l@lists. cc
us.ibm.com
Subject
Re: [nv-l] Monitoring nodes running
04/01/2005 08:34 ospf
AM
Please respond to
nv-l@lists.us.ibm
.com
I'm not the expert with regard to using our APIs, but I don't see how you
can do what you want using our code, unless perhaps you can set up name
resolution so that each interface is regarded as a separate host. The way
you want to do things and the way NetView was designed to do them seem to
me to be two entirely different things. As others have already explained,
the NetView model is to let bind with whatever interface it is directed
to. We use whatever works. Once on the box, we let SNMP tell us what the
other interfaces are doing, rather than try to set up separate sessions
over them. xnmsnmpconf lets you set up a preferred interface, but it's
one per host, and if that one's down we'll try another. You really are on
your own here with this design you've cooked up, so far as I can see.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jeff.ctr.vandenbu
ssche@faa.gov
Sent by: To
owner-nv-l@lists. nv-l@lists.us.ibm.com
us.ibm.com cc
Subject
03/31/2005 04:18 Re: [nv-l] Monitoring nodes running
PM ospf
Please respond to
nv-l
James,
What I am mainly looking for is a way to bind Netview to do all it's
outgoing/incoming SNMP querys to a particular IP (interface ) on the
server. I have 3 IP's (interfaces) defined on the server:
server - this IP/interface uses ospf to select which interface to use
server-ethernet0
server-ethernet1
I want Netview to always use the IP associated with server, but Netview
seems to always use the active interface at the time. I know with net-snmp
you can set the address/port you want it to listen on. I actually tried
this, but then netmon failed, stating that SNMP wasn't bound to localhost.
I am having trouble when I fail the active interface, I lose all SNMP
status, instead of swapping to the other interface.
Note we have already had to modify ping, traceroute, etc to bind in this
way. Any way to do this in Netview. Any suggestions would be greatly
appreciated.
Thanks
James Shanks
<jshanks@us.ibm.c
om> To
Sent by: nv-l@lists.us.ibm.com
owner-nv-l@lists. cc
us.ibm.com
Subject
Re: [nv-l] Monitoring nodes running
03/30/2005 12:55 ospf
PM
Please respond to
nv-l@lists.us.ibm
.com
Custom daemons using the OVsnmp APIs? I presume that you've done a lot of
reading in the Programmer's Guide and especially the Programmer's Reference
about using these routines. I can't say I quite follow what you are trying
to do with them, however.
In any case, OVsnmpOpen uses the NetView SNMP database, the one you
maintain with xnmsnmpconf to obtain the peer address for the open. Before
opening the session it does an OVsnmpResolveConfEntry( ) to get the IP
Address or proxy address to use. That means that if there's already an
IP Address in the xnmsnmp cache, he'll use that one. If there isn't one,
he'll try gethostbyname to determine one, and take the first one he gets
back.
So, offhand, my advice would be to trying clearing the xnmsnmpconf cache
before you establish your session. That would force a re-evaluation. You
could even dump it and see what it contains. But if that doesn't do it,
then the issue has to be name resolution.
HTH
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
jeff.ctr.vandenbu
ssche@faa.gov
Sent by: To
owner-nv-l@lists. nv-l@lists.us.ibm.com
us.ibm.com cc
Subject
03/29/2005 04:07 [nv-l] Monitoring nodes running
PM ospf
Please respond to
nv-l
I have a small network with ~ 12 boxes. Each box consists on 2 Ethernet
ports, and then a 3rd "virtual" interface, with ospf running on each box.
My problem is with several custom polling daemons that status MIB variables
on these various nodes. I have each node defined in the host file on the
Netview box with the virtual IP. The polling daemons use Netview API calls
(OVsnmpOpen) to open an snmp session with each node using the virtual
IP/hostname. The problem occurs during failures. If I fail the active
interface on the remote box, the snmp polling responses timeout, and don't
switch over to the other route to the nodes It seems as if the snmp
session binds to the active interface, rather than the virtual IP that is
defined.
Also, if I shutdown the active interface on the Netview box, I lose all
statuses from all nodes. I am not sure if this is a Netview configuration,
a Netview API, or an snmp issue. Any suggestions??
Is there a way to setup Netview to status (via SNMP) multiple IP addresses
for the same node.
Can a daemon/lrf be set up to respawn? I could then have the session
timeout, then respawn.
Thanks,
Jeff VanDenbussche
JSA/ATO-E
HNL Support
(609) 485-4200
|