To: | nv-l@lists.us.ibm.com |
---|---|
Subject: | Re: [nv-l] Netview Polling - oid 'unknown IBM' |
From: | Leslie Clark <lclark@us.ibm.com> |
Date: | Fri, 14 Jan 2005 10:13:04 -0500 |
Delivery-date: | Fri, 14 Jan 2005 15:13:41 +0000 |
Envelope-to: | nv-l-archive@lists.skills-1st.co.uk |
In-reply-to: | <OFAAB30C4D.408CF86F-ON85256F88.0069DC07-85256F88.006A974E@us.ibm.com> |
Reply-to: | nv-l@lists.us.ibm.com |
Sender: | owner-nv-l@lists.us.ibm.com |
Regarding that mysterious OID 1.3.6.1.4.1.3.1.1.98, that is a special feature of Netview on the Windows platform. When it does not recognize the OID because it is not in the oid_to_type file, it sets it to that as a kind of marker, and makes a Smartset called Bad_OIDS or something like that, with that oid being the criteria for membership. For things with that oid you are supposed to inform Netview about what it is. This takes a couple of steps. The entry in the oid_to_type file is pretty clear. The Vendor and Agent parts of that entry must match exactly entries in the vendor list in \usr\ov\fields\c\ovw_fields, and the agent list in \usr\ov\fields\c\snmp_fields. After updating those files, you must run the command 'ovw_fields'. Then update the oid_to_type file. Give it the appropriate flag, G for routers and layer3 switches, B for bridges, H for hubs or layer2 switches, blank for servers. Those flags control the level of the map the devices are drawn at (G at the top level, B & H in the network submap level, blanks inside the segment submaps). You can also add entries to \usr\ov\conf\c\oid_to_sym if you want to use a certain symbol for that oid. Stop/start the daemons. Then delete and rediscover the object. After that, devices of that type will have their proper oid and symbol. Cordially, Leslie A. Clark IBM Global Services - Systems Mgmt & Networking (248) 552-4968 Voicemail, Fax, Pager
Sorry, I meant add the P flag. S is for secondary. P is for poll via snmp. As for the addresses, I'm not sure what you are asking. For the 'routers' on your map, try : rnetstat -Ix MyRouter1 You should get results like Index Interface IP address Network Mask Network Address Link Address 3 FastEthernet0/0 10.91.132.1 255.255.254.0 10.91.132.0 0x0006D728A1C1 5 BRI1/0 10.205.138.7 255.255.254.0 10.205.138.0 <none> 19 Serial0/0.1 10.210.65.210 255.255.255.248 10.210.65.208 <none> 18 Loopback0 10.211.65.210 255.255.255.255 10.211.65.210 <none> If the device has a Loopback configured, and you know that their standard is to configure the loopback as the trap source, then you have your answer and you can update your name resolution. If the not, then as the traps come in you will have to determine which router they go with. Eventually you will have them all configured. You can use the Find function to determine where that address is in your map, as well. The rnetstat command comes with Netview and should be in \usr\OV\bin. Cordially, Leslie A. Clark IBM Global Services - Systems Mgmt & Networking (248) 552-4968 Voicemail, Fax, Pager
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. |
<Prev in Thread] | Current Thread | [Next in Thread> |
---|---|---|
|
Previous by Date: | RE: [nv-l] NV tuning for Data collection, Liu, David |
---|---|
Next by Date: | Re: [nv-l] Netview Polling, awatthey |
Previous by Thread: | Re: [nv-l] Netview Polling, Leslie Clark |
Next by Thread: | Re: [nv-l] Netview Polling - oid 'unknown IBM', awatthey |
Indexes: | [Date] [Thread] [Top] [All Lists] |
Archive operated by Skills 1st Ltd
See also: The NetView Web