nv-l

Re: Status Color change

1999-11-04 12:23:30
Subject: Re: Status Color change
From: "Boyles, Gary P" <gary.p.boyles AT INTEL DOT COM>
To: nv-l AT lists.tivoli DOT com
Date: Thu, 4 Nov 1999 09:23:30 -0800
If this is NetView on NT... I'd suggest having your script use nvsniffer to
create/set the status on new "interface" icons.

Another way... that might work on either UNIX or NT... is to have your
application send Mid-Level Manager status-traps for interface-up/down...
basically fooling NetView into thinking that a mid-level manager has control
of the interface.

Regards,

Gary Boyles


-----Original Message-----
From: Ray Schafer [mailto:schafer AT TKG DOT COM]
Sent: Thursday, November 04, 1999 9:07 AM
To: NV-L AT UCSBVM.UCSB DOT EDU
Subject: Re: Status Color change


Deep,

I know exactly what you are trying to do, and have some suggestions:

Create a custom field "OnDialBackup".  This can be a string field so that
you
can update with either a C program or ruleset.   Make a collection that is
based on the value of this field set to "YES".

Unmanage the dial backup ISDN interface on the router.  (As you say, it is
misleading  Up is bad, down ois normal).  It dials in to some router or
routers  whose SNMP information is available to NetView, right?  There are
local router ISDN interfaces accepting the remote connection.  You can
configure the dial-in routers to send agent traps for link up.  The trap
will
have the interface index as well as the source. Create a ruleset that takes
an
action when a link up trap is recieved from any of the routers that are
dialed
into from the remote connection.  The action (not inline-action) can be
written
to do certain things.  It can query the MIB of the router being dialed into
for
the IP address of the router on the other side of the ISDN link.

If you are using OSPF the IP address of the router dialing in is available
parsing the output of this SNMP query:

snmpwalk <local router> .1.3.6.1.2.1.14.10.1.2 | grep -w "INTEGER: $INDEX" |
cut -d. -f5-8)

Where INDEX is the interface index of the interface comming up on the local
router.  (Probably $NVATTR_1 in the environment of the action script - but
check your agent traps - they may be different.)

BGP is different.  The addresses may be hard coded on the router interface
but
you can still get them with a few snmp queries (if you don't have to do the
queries, don't!).

snmpwalk <local router> .1.3.6.1.2.1.4.20.1.2 | grep -w "INTEGER: $INDEX" |
cut
-d: -f1 | cut -d. -f5-8 | sed
's/  *$//' # gives the IP address of the index which was activated.
Assign this to variable INDEXIPADDR

snmpwalk <local router> .1.3.6.1.2.1.15.3.1.5. | grep $INDEXIPADDR | cut -d:
-f1 | cut -d. -f5-8 | sed 's/  *$//'  # gives addresses of remote BGP
conection.
Assign this to REMOTE_BGP_IP

snmpget <locaql router> .1.3.6.1.2.1.15.3.1.2.$REMOTE_BGP_IP   # gives the
state of the BGP connection, if established someone dialed in.

"ovtopodump $REMOTE_BGP_IP" will tell you which node it belongs to.


When you identify the router on the other side of the connection, set the
OnDialBackup field of the remote router to be "YES".  You could do this by
generating a custom trap (which you could log as well) and have a ruleset
set
the database field for the remote object.  This will place the remote router
in
the DIalBackup Collection you created earlier.

The script can continue to monitor the router on dial backup, and send a
custom
trap when it is off which can be used to set the OnDialBackup database field
to
"NO", which causes it to leave the OnDialBackup collection.

It gets a little tricky to run these action scripts for a long time (more
than
10 minutes).  Actionsrv will time out after that time, and although the
script
runs, you get errors in the action server's log.  Also, if actionsrv dies
for
some reason, the port he needs to use is still open (the scripts inherited
the
open file descriptors) and he won't restart until all the actionsrv scripts
are
killed.  What I did was rexecute the script as a UNIX "at" job from within
the
script and exit.  That way, actionsrv is no longer it's parent.

All your operators then need to do is to monitor the collection of
OnDialBackup
routers with their Web browser.

Hope that helps!


pmenon wrote:

> Hi Netview experts,
>     How do I change the status color of any object to any other color from
a
> command line ?
>
> i.e is there a command or some utility which I can use outside the
framework
> to change the statys color of an object depending on its condition.
>
>     I have dial backup isdn's which most of the time is down so the color
> red, now if a router switches to a dialbackup this isdn interface will
turn
> green (normal) which offcourse is the normal operation.
>
> I want to make the color of this isdn interface different when it is down
so
> that my operators know what that specific color means and not red as they
> panic when they see a red color.
>
> Please remember I need this to be changed from command line, may from a
> script (automatically) and not from the framework.
>
> Any help on this matter will be greatly appreciated.
>
> Thanks
>
> Deep

--
Ray Schafer                   | schafer AT tkg DOT com
The Kernel Group              | Distributed Systems Management
http://www.tkg.com


<Prev in Thread] Current Thread [Next in Thread>