|Subject:||Re: [nv-l] discovery and limiting discovery|
|From:||Leslie Clark <firstname.lastname@example.org>|
|Date:||Fri, 16 Jan 2004 09:31:17 -0500|
|Delivery-date:||Fri, 16 Jan 2004 14:46:32 +0000|
Well, in earlier releases I would have said to unmanage the networks that house the interfaces you don't care about. But in V7, probably to help with RFI, I think it is pickier about attaching things to unmanaged networks so I usually keep all networks managed and just unmanage the interfaces.
I recommend making an effort to deal with these always-red interfaces rather than ignoring them. If they are up but unpingable, switch that device to snmp status polling. If it is a routing problem, get it corrected. If it is an old, unused interface, get it deconfigured. That is part of the cleanup of the real network that all customers should do after discovery, and the information Netview provides in this area is the single biggest benefit of installing the product. When you are done, there will always be a few things that you cannot address, maybe because your company does not own the device. For that shorter (we hope) list of cases, then unmanage is the right thing to do. I then make a smartset of those interfaces so I easily re-unmanage them, since they will get managed from time to time as you are messing with the map.
An easy way to do this when they are all over the map:
Unmanage them manually
Locate ..objects by symbol status.. Unmanaged
View..Hightlights..Select Highlights (now all unmanaged stuff is selected)
Now make a smartset (UnmanageThese) of type Object List
Add from map
Remove anything from the list you did not want in there, and save it.
That smartset is for after discovery. If you have a more general rule as to what is to be unmanaged, you could make a dynamic smartset of interfaces with the addresses you need to unmanage. Make sure you include in the criteria some field that proves the thing is actually in the map, however. It is a bad idea to allow smartsets to give _expression_ to objects that are not otherwise in the map. It can lead to delete/rediscover problems.
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
I guess it depends on whether your switch has multiple IP-addressable
interfaces. Most switches tend to just have 1 IP address for management
info / loading. If this is the case, that's the only interface NetView
will show you - you need Switch Analyzer to manage down at the port
level. Therefore your question about unmanaging extra interfaces is
simple - there won't be any.
If you do have multiple interfaces on your box, by default they will all
be managed. However, you could use the nvmaputil utility to unmanage
particuler interfaces (look at the 7.1.4 docs or the Release notes for
7.1.3 for info on nvmaputil). The tricky bit here is how to specify the
interfaces you want unmanaged in an automatic way - I guess you would
need to craft some sort of lookup table for the relevant devices, with
primary address and interface(s)-to-unmanage information and then build
a script that runs nvmaputil to do the unmanaging.
Christopher J Petrina wrote:
> OK itneresting conundrum for everyone.
> What would it take and is it possible to do the following?
> I have a switch I wish to load from a seedfile into netview. This
> devices has multiple interfaces on it. I load the device using the
> uplink interface's IP address. Once it is loaded via that IP address
> it will be demand pulled to pull all other relevant information from
> the device. Such as other interfaces, sysname, etc.
> NOW -> I want the uplink to be managed but all other interfaces on the
> device I want to be unmanaged when it is discovered. Can this be done
> automatically? Or perhaps through a script written that will go in
> and unmaange the ports(interfaces) I do not care about on the device.
> Can you unmanage a range of ports given specific information from the
> Thanks for your brain work
> Chris Petrina
Tivoli Certified Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2004 Jane Curry <email@example.com>. All rights reserved.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [nv-l] discovery and limiting discovery, Jane Curry|
|Next by Date:||Re: [nv-l] 2 Separate Questions: servmon and Unmanage (the unmanage question), Leslie Clark|
|Previous by Thread:||Re: [nv-l] discovery and limiting discovery, Jane Curry|
|Next by Thread:||Re: [nv-l] discovery and limiting discovery, Christopher J Petrina|
|Indexes:||[Date] [Thread] [Top] [All Lists]|
Archive operated by Skills 1st Ltd
See also: The NetView Web