On a less obvious but more serious side effect, I also worked at one
installation where they used !@1.3.6.1.4.1.311.* in their seed file. It
resulted in a quarter million hints plus the daily status polling of a
quarter million Microsoft work stations to see if the OIDs had changed.
They saturated a T1 link doing that polling.
Bill Evans
NetView support
US DOE
For the sake of history I can't pass this one up. While developing the
first NetView/6000 education module in 1994 we used to start discovery
with a minimal seed file on purpose. We had a small AIX box and we
would pick some point in the IBM network as a start, initiate discovery
and go home. The next day the system would have crashed -- the database
filled all available disk space -- and we would get marvelous "death
stars" and "fans" in the resulting maps. Those maps were later used as
illustrations in the "TME 10 NetView For UNIX for Implementer" class
materials on "Customizing the Map".
Yes, we TRIED to discover just the IBM Class A network and not the whole
world; and didn't have a big enough machine. We would have a better
chance with today's hard disks but there are a lot more machines out
there as well.
________________________________
From: nv-l-bounces@lists.ca.ibm.com
[mailto:nv-l-bounces@lists.ca.ibm.com] On Behalf Of Leslie Clark
Sent: Wednesday, June 11, 2008 12:41 PM
To: Tivoli NetView Discussions
Subject: Re: [NV-L] Objects defined in Database
In my experience, negative address ranges prevent the hints, while the
!@oid entries, or name wildcards enable them.
So you can use them, but limit the number of hints with as many negative
address ranges as you can conveniently administer.
This is especially true when you use !@oid 0 to exclude non-snmp things.
Only use that with very complete exclusion ranges.
The hints will usually appear to come and go every few hours.
It is also possible that some odd device is causing the repeated
delete/rediscover of wierd interface things.
I would do an ovobjprint > junk
and then look at what the objects are. Probably there are loads of
things with sequence numbers stuck to the ends of them.
You do get a discovery every time you restart netmon. And you also have
configuration polling, which could cause repeated adds of interfaces on
existing devices, if there is something wierd about the device. Looking
at the attributes of anything that looks like repeats could help
identify an odd device, if that's what it is.
Another thing that can happen is that the seedfile is missing or
corrupted, in which case netmon runs as if there were no seedfile, That
could cause wholesale discovery starting from the existing network. And
once, I know, someone started netmon from the commandline, with no
seedfile option, and ended up discovering the world.
Cordially,
Leslie A. Clark
IT Services Specialist, Network Mgmt
Information Technology Services Americas
IBM Global Services
(248) 552-4968 Voicemail, Fax, Pager
REAMD@nationwide.com
Sent by: nv-l-bounces@lists.ca.ibm.com
06/11/2008 11:39 AM
Please respond to
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
To
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
cc
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>,
nv-l-bounces@lists.ca.ibm.com
Subject
Re: [NV-L] Objects defined in Database
Thanks Jim,
You are correct, Im running 7.1.4 fixpack 5 not
7.1.5.. I run ovtopofix -A once a week. Auto-discovery is not
running, it gets a new seed file everyday for MACD's. This morning I
removed all !OID entries from the seedfile and just completed an
ovtopofix -A. I brought down the map and killed all deamons and ran
nvTurboDatabase speed. I then did netnmrc and it took ovtopmd 15
minutes to initialize and it took netmon at least that long to
initialize. I'm probably going to open a PMR... Pretty strange things
happening..
Thanks, Dave
James Shanks <jshanks@us.ibm.com>
Sent by: nv-l-bounces@lists.ca.ibm.com
06/11/2008 08:59 AM
Please respond to Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
From
James Shanks <jshanks@us.ibm.com>
To
Tivoli NetView Discussions <nv-l@lists.ca.ibm.com>
cc
Subject
Re: [NV-L] Objects defined in Database
FixPack 3 for 7.1.5 has not been shipped yet Dave, so that's not where
you
are. cat /usr/OV/service/version.
OK, so you are saying that your object count is growing by leaps and
bounds
yet nothing has changed in the network? No DNS or re-IP sorts of
activities going on?
What's in your events? Are you seeing many new nodes being added and
managed or what?
If not, then it sounds to me like your seed file and discovery options
need
attention. If you have negative ranges or !@oid entries for example,
then
netmon will have to create a hint for every other object it finds, just
so
that it can compare the IP addresses or OIDs. These stub objects are
called hints and you have to run ovtopofix periodically to keep pruning
them from the database. And if any of these objects is renamed or
re-IPed,
then netmon will create another hint for the new device, compounding the
issue.
How often do you do ovtopofix? That's probably what you should do now.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Network Availability Management
Network Management - Development
Tivoli Software, IBM Corp
REAMD@nationwide.
com
Sent by: To
nv-l-bounces@list Tivoli NetView Discussions
s.ca.ibm.com <nv-l@lists.ca.ibm.com>
cc
06/11/2008 08:10 Subject
AM [NV-L] Objects defined in Database
Please respond to
Tivoli NetView
Discussions
<nv-l@lists.ca.ib
m.com>
Hi All,
I have about 5400 nodes (routers, switches, AceModules, ect)
that
i am monitoring with Netview 7.1.5 Fixpack3 on AIX 5300-05. My problem
is
that the Number of objects defined in the database keeps growing and
growing. Right now its at 127711 and 20 minutes ago it was 127590. How
can
I found out whats going on?
Number of objects defined in the database: 127711
Total number of fields defined in the database is: 259.
Total number of field values in the database: 2198111
Number of Integer fields: 587160.
Number of Boolean fields: 1138857.
Number of String fields: 315704.
Number of Enum fields: 156390.
Respectfully, Dave_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
_______________________________________________
NV-L mailing list
NV-L@lists.ca.ibm.com
Unsubscribe:NV-L-leave@lists.ca.ibm.com
http://lists.ca.ibm.com/mailman/listinfo/nv-l (Browser access limited to
internal IBM'ers only)
|