Hi,
and thank you, Xu and John, for your hints.
Had tried them already, did so again, no success.
But as usual, the winner is "THE MAN" as I call him, forgive me, James ;-)
HE put me in the right direction...
The summary (so far):
65 zombies.
63 objects were NOT removed when they should have been.
2 objects were re-discovered immediately when netmon was running.
ALL objects were in the object database.
NONE of the objects was in topology.
The only place i could STARE/GLARE at them was in a collection.
NONE of these objects had fields other than "standard-NetView-fields".
Some of these object's addresses actually DO exist in my network.
2 objects/9 addresses actually belong to a Cabletron Smart-Switch-Router...
SSR 8000 - Cabletron Systems, Inc. Firmware Version: 2.2.0.0 PROM Version:
prom-1.1.0.3
system.sysObjectID.0 : OBJECT IDENTIFIER:
.iso.org.dod.internet.private.enterprises.52.3.9.20.1.3
snmpwalk on this machine gives tons of MIB-information,
but rnetstat -A on this guy gives...
ERROR getting table from 172.28.90.1: The variable does not exist or is read
only.
Which points somehow in the "trouble-with-reading-arp-cache-direction",
right?
And then, new idea:
My "NetView/AIX-mentor" from the early days in 1997 had left me with 7 tiny
C-programs.
Usage: del_field Field_Name
Usage: dsp_fieldtype Selection_Name Field_Name
Usage: get_field Selection_Name Field_Name Value
Usage: get_field2 Object_Id Field_Name
Usage: set_field Selection_Name Field_Name Value
Usage: set_field2 Object_Id Field_Name Value
Usage: unset_field Selection_Name Field_Name
get_field2 (plus shell-scripts) is doing ALL MY CORRELATION-STUFF since 2
years...
set_field and set_field2 i'm using all the time to update my databases REAL
PRONTO...
So it seemed worth a try to use unset_field on ALL MY ZOMBIES.
And after running unset_field ON ALL FIELDS OF ALL ZOMBIES
(of course some fields are un-unset_field-able),
i could delete them at last and now they are gone for good...
Which leaves me with a final question:
2 (Cabletron)-objects still making "trouble".
2 (Cabletron)-objects still re-discovered after delete-from-everywhere.
Any experiences/hints regarding Cabletron SSR 8000 or
similar "smart" boxes playing router but giving arp-cache-troubles?
Thanks for all your help and patience.
The flames are burning themselves out already.
Cordially, Ralph.
iT-AUSTRIA / OE2100 / TK
Tel (mobil) 0664 1908469
Tel (iT-A) 21717 58948
FAX (iT-A) 21717 58979
Mailto:Ralph.Schiffinger AT erstebank DOT at
> -----Ursprüngliche Nachricht-----
> Von: James Shanks [SMTP:James_Shanks AT TIVOLI DOT COM]
> Gesendet am: Donnerstag, 12. August 1999 14:41
> An: NV-L AT UCSBVM.ucsb DOT edu
> Betreff: Removing Objects from NetView Database
>
>
>
> I am sorry to hear that you are having so much trouble, but let's see if
> we
> cannot better determine where the problem lies.
> Is it that the objects are not being removed when they should be or that
> they
> are being immediately re-discovered? Why not perform an experiment to
> check?
> Make sure you stop netmon so that he does not re-discover anything when
> you are
> trying to delete it.
>
> Select one of you objects from the map and right-click it to bring up the
> context menu and then display what object it is.
> Jot that down for later. Take note of how many maps it is in too. Then
> delete it.
> Then use ovobjprint to see if it is still in the object database and
> ovtopodump
> to see if it is still in topology. Do the same thing after you run
> ovtopofix.
> An object which is not in topology cannot be put on the map by ipmap at
> synchronization time.
>
> So you should be able to tell before you restart the map, whether your
> objects
> have been deleted. Note that they will not be if they have fields in them
> that
> have been set by other applications, like Ciscoworks. But Support can
> help
> you get rid of those if that is the problem.
>
> If the objects are truly gone when everything is restarted, and they come
> back,
> then that usually means that (1) those addresses really do exist in your
> network, and the (2) the method you are using to exclude them from netmon
> discovery isn't working. It could also mean that some node or other is
> giving
> netmon some very bad SNMP responses, but these have to be looked at as
> individual cases.
>
> I don't want to offend anyone, but this isn't rocket science or voodoo.
> But it
> may take patience to solve.
> And Support can help, so give them a call. At the worst they ask you to
> send
> them your databases so they an determine what, if anything, is wrong, or
> if you
> need new maintenance on the utilities or netmon itself. There is no
> utility
> that is smart enough to figure out what is wrong with the configuration
> and fix
> it. That is why you need people to help.
>
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
>
>
>
> Schiffinger Ralph 2100 <Ralph.Schiffinger AT ERSTEBANK DOT AT> on 08/12/99
> 03:15:28 AM
>
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> NetView
> <NV-L AT UCSBVM.UCSB DOT EDU>
>
> To: NV-L AT UCSBVM.UCSB DOT EDU
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: AW: Removing Objects from NetView Database
>
>
>
>
> Hi Ian,
>
> currently I've got exactly 65 of these zombies (bluesies).
> Until now I've found absolutely NO WAY to get rid of them.
> And, believe me, I really tried everything documented.
> And, btw, ovtopofix -r (undocumented) did not help either.
> Running NetView 5.1.1 / Framework 3.6 / AIX 4.2.1.0.
>
> Any (new) hints welcome.
> Thanks in advance.
> Cordially, Ralph.
> iT-AUSTRIA / OE2100 / TK
> Tel (mobil) 0664 1908469
> Tel (iT-A) 21717 58948
> FAX (iT-A) 21717 58979
> Mailto:Ralph.Schiffinger AT erstebank DOT at
>
>
> > -----Urspr << Datei: ATT01395.txt >>
|
