James,
The business with the P or S was sorted out by Leslie. He explained what
they were both used for and I shall now start testing with the appropriate
values. The excellent part of your email explaining how to add new OIDs to
the system will obviously be of particular use to me.
I agree with anyone wanting to eradicate my misconceptions of how Tivoli
Netview should be setup to work correctly. The more I learn about the
product the more I realise I don't know. However, regarding the population
of the etc\hosts file to tell Netview how to relate a trap to a real
device, You are telling me that I have to do this and I accept that but I'm
still not sure I follow why I need to do this.
Basically, I get a trap from an outsourced router with IP address A.B.C.D
in it. This is usually one of the loopback addresses of the router and
would appear to always be from the address range of the provider (Ciscos
can only have one 'snmp-server trap-source' command active). Tivoli
Netview knows this device (if it has discovered it) as E.F.G.H. This is a
routable IP address from our address range. However, Netview cannot link
the two together.
There is absolutely no way I can know what A.B.C.D's go with which
E.F.G.H's. To discover this I have to somehow find the router E.F.G.H
which has an interface on it with the IP address A.B.C.D.
The only thing that really knows this information is Netview.
Consequently, what you are saying is that I have to ask Netview for the
information I need so I can tell Netview what to do. This sounds like
borrowing someones watch to tell them the time.
The problem that I wish to avoid if possible is having a huge etc\hosts
file with out of date information in it. Tivoli Netview will quite happily
update the interfaces on a particular router but he won't update the
etc\hosts file to follow. Seeing as these are managed outsourced routers I
have no control over them so they could change at any moment. Of course
they probably don't change that often but I would have to check them to be
sure every so often. Perhaps every time I got a cold start trap. This
does not sound like administrative heaven.
Now I come on to the part of 'why do I need to do this' and my thinking on
the subject. Please feel free to correct me if I have misunderstood
something. Most traps that I am interested in relate to interfaces going
up or down. These just refer to interface numbers so are not much use in
generating alerts. I need to run a script that takes this number and
relates it back to the router and interface having the problem. If this
script can query the database to find the box on which the trap IP address
is located, he can find the interface number and hence the IP address of
the interface that has caused the trap. Then he can send this information
to the TEC. Of course, I don't know whether this is possible (or even
desirable) and hence my original question asking it this searching of the
database was allowed.
The question is therefore can I get away without the etc\hosts file or am I
going to mess up a load of other things as well? Perhaps my script can
maintain the etc\hosts file itself if it has the information (:-).
Regards,
Alan.
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] Netview Polling
13/01/2005 19:41
Please respond to
nv-l@lists.us.ibm
.com
I cannot answer the business about whether the flag should be "S" or "P"
but Alan, you have a lot of other misconceptions about how NetView works
that need to be cleared up. My belief is that the comments at the top of
the oid_to_type file are correct, but I cannot say for certain as I don't
work on that code. But the other parts of this issue, I do know about.
First, in regard to the traps sent by your remote devices with the loopback
addresses in them. You have to provide the translation to the preferred
address in an /etc/hosts file precisely because NetView does not know where
they came from. All he is going to get is the address inside the trap and
that's why what you currently see is the loopback. That's what your remote
device sent. So if you cannot configure the device to send the address you
want, then you have to override it in /etc/hosts or in DNS. Got it? Name
resolution is the customer's responsibility. NetView only uses whatever
you have set up.
Second, with regard to the sysObjectId. The NetView for Windows product is
different from the NetView for UNIX one in that it maintains a BadOID
smartset. In there will be devices which responded with a OID that is not
defined in \usr\ov\conf\oid_to_type. The actual OID they responded with,
the one that is not defined, is not used when the object is added to the
database. Instead, a dummy OID of either 1.3.6.1.4.1.3.1.1.98 or
1.3.6.1.4.1.3.1.1.99 is used, so that this object can be added to the
BadOIDs smartset. That's why that entry in the oid_to_type file says "IBM
Unknown". It's just a placeholder. The Cisco 3700 has been given that OID
because whatever it responded with is not currently defined. If you want
to see what OID it did respond with then you need to set up the bad oid
logging as an option on the netmon daemon. The new log will show you what
OID that device responds with, the SNMP sysObjectId (like
1.3.6.1.4.1.9.1.185, etc), and the SNMP sysDescription. and that is what
you have to put in oid_to_type. From this you decide on the vendor and the
agent. Check to see if there is something appropriate in the fields
files.If not, add them manually.
For each type of device in there (each unique SNMP sysObjectID), you need
to manually update
-- the vendor list in \usr\ov\fields\C\ovw_fields,
-- the agent list in \usr\ov\fields\C\snmp_fields,
-- run 'ovw_fields' (to let Netview know about your changes),
-- then update the entries in the \usr\ov\conf\oid_to_type file.
When you edit the oid_to_type file, add one entry for each unique oid, no
wildcarding. Include the vendor and agent EXACTLY as written in the fields
files. For network devices, include the flag (G for router, H for hub or
switch, B for bridge). G causes devices to be drawn at the top level of the
map. H or B causes devices to be drawn at the Network level of the map
(with the Segment). No flag causes it to be drawn at the Segment level,
which is where they are now. You can 'promote' them to the higher level
with these flags.
Then...close and open the map to get all of this information incorporate.
Stop netmon. Delete the devices in that Smartset from ALL submaps. restart
netmon, and they will all be rediscovered with the new information, and
should NOT reappear in the Badoids Smartset, if you did it all correctly.
As Leslie says, "it is a badge of honor to have an empty Badoids Smartset!"
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
Inactive hide details for awatthey@mmm.comawatthey@mmm.com
awatthey@mmm.c
om [IMAGE]
Sent by: To
owner-nv-l@lis [IMAGE]
ts.us.ibm.com nv-l@lists.us.ibm.com
[IMAGE]
01/13/2005 cc
01:20 PM [IMAGE]
Please [IMAGE]
respond to Subject
nv-l [IMAGE]
Re: [nv-l] Netview Polling
[IMAGE]
[IMAGE]
Leslie,
Thanks for this information. However, am I doing the right thing here in
the right place?
You say add an S option but the Object ID of the router I've just located
is 1.3.6.1.4.1.9.1.340. According to the /usr/ov/conf/oid_to_type file,
that line has the options GS already.
Another router I've located has an Object ID of 1.3.6.1.4.1.3.1.1.98. The
oid_to_type file says this is 'IBM Unkown' yet the router is a Cisco 3700.
However, I would be able to add S to that line.
Also, the S character is not documented and the P character is documented
as causing the node to be polled using SNMP.
As far as populating the etc\hosts file. I can certainly do that but my
problem is going to be finding out what routable IP address goes with which
trap IP address. Is there no easy way of finding it in the database as it
must be there on an interface of something somewhere? If I can find which
box it is on easily then I may save myself the trouble of populating the
etc\hosts file with static information that could easily become out of
date.
Regards,
Alan.
Leslie Clark
<lclark@us.ibm.co
m> To
Sent by: nv-l@lists.us.ibm.com
owner-nv-l@lists. cc
us.ibm.com
Subject
Re: [nv-l] Netview Polling
13/01/2005 15:20
Please respond to
nv-l@lists.us.ibm
.com
You cannot stop netmon from discovering all addresses on a router, that's
its job. However, in the case where you don't have routing to those
addresses, you should just tell netmon to poll them via snmp. It will then
do an snmpget of the ifOperStatus of all of the interfaces, through the one
address you do have SNMP access to, and they will be nice and green. You
can do this either by putting one address for each one in the seedfile with
$ in front of it, or, in the /usr/OV/conf/oid_to_type file, you can put add
the S flag to the OID for those types of routers. Stop/start netmon, and
you are all set.
Regarding Francois' advice to add name resolution for the trap sources, I
would add that when you do this, you want to make sure that the forward
resolution resolves to the address you reach it by. If you were using just
the hosts file, it would be like this:
10.10.10.5 MyRouter1 # the address that I can talk to
10.10.10.1 My Router1 # The loopback address of the router, where traps
come from
So when Netview discovers it by 10.10.10.5, it will name it MyRouter1. When
a trap comes in from 10.10.10.1, it will look that address up and assign it
to MyRouter1 in the events display. When you use menu functions on Netview
against the node MyRouter1, it will lookup the address and use 10.10.10.5.
If the .5 address is already in your DNS, and you decide to add the .1
address to the etc\hosts file on the Windows box, you must also add the .5
address to the etc\hosts file because the hosts file will take
precidence.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager
awatthey@mmm.com
Sent by:
owner-nv-l@lists.us.ibm.co To
m nv-l@lists
.us.ibm.co
01/13/2005 04:35 AM m
cc
Please respond to
nv-l Subject
[nv-l]
Netview
Polling
Hi,
I'm on Windows 2000 with Netview 7.1.4 FP2.
I've been doing some traces of what Netview is doing and I've seen quite a
lot of activity. I was wondering how I could stop it. I have 'discover
all networks' with @limit_discovery in my netmon.seed along with a list of
the ranges it should work with.
Basically we have various parts of the network outsourced. I have
negotiated SNMP read access to all these routers. Netview discovers these
routers quite happily but also discovers that they have lots of other
interfaces with strange IP addresses. There is no routing in our network
to these addresses. Even though I have limited the range of IP addresses
that Netview should discover via the NETMON.SEED file, it still insists on
PINGing and doing NBNS name lookups on these addresses. Of course these
packets flow out of our default route and try to get to the Internet. This
not only wastes bandwidth but gets our IDS people after me as they think a
box has a virus trying to get to all sorts of strange addresses which have
nothing to do with our organisation.
Is there an automatic method (forget manually unmanaging things) of
stopping netview from refering to anything not specified in the seed file.
Regards,
Alan.
(Embedded image moved to file: pic19012.jpg)(Embedded image moved to file:
pic11443.jpg)(Embedded image moved to file: pic30195.jpg)
pic19012.jpg
Description: JPEG image
pic11443.jpg
Description: JPEG image
pic30195.jpg
Description: JPEG image
|
