Mark, this exact question has come up before. And I know I have
struggled with this situation at every site where I have implemented
Netview. The product is not capable of what you are asking.
I would suggest that this user community talk it over and come up
with a suggested design change to make this possible.
The problem goes further than the eventual movement of interfaces.
There is the case where the interface it is discovered by has a
different name than the one on loopback, or has no name at all. Many
of the functions in Netview do not work if there is not a complete
match between the interface it was discovered by and the
names of the other interfaces. Some functions operate off the
Selection Name, and some off the IP Hostname (not always the
same) and some off the address of a particular interface, and
some off the address that it was first discovered by (I think that
is the one you get if you do xnmsnmpconf -resolve <nodename>).
You all should talk amongst yourselves and come up with a
requirement. Ideally, it should not matter which address a node
was discovered by. But it will take some real-world input to
get it right. If you can come up with something workable, I will
make sure it gets submitted into the system for consideration.
Some thinking points:
1)The Selection Name often gets those extra digits stuck to it,
so that is not a good choice for any function that is going to do
name resolution. The functions under Monitor seem to use this.
Maybe these functions should be using the IP Hostname field.
2) When a node is discovered (by some address), we already
pull the interface table and check interface types. What ifTypes
are used for loopback? 24 seems to be a standard. Those
Bay Circuitless IPs are a different problem, since they are not
even in the interface table. (They probably look like HSRP to
Netview now.) But just talking about regular loopbacks, it seems
like we ought to be able to check if there is one, and use the
address of that instead of the one we heard from. Use it for what?
as the one we resolve to fill in IP Hostname, for starters. If
loopback doesn't resolve, use the one we heard from as we do now.
3)What about events? For Netview events, it appears that we
know the name of the node we are dealing with. But unsolicited
traps are a problem. Just resolving the address we heard from
makes it really hard to jump from the event to the map (Options
Highlight node on map) or from the map to events (Monitor..Events..
Current Events), or to make rulesets based on node attributes. We
need a way for the 'Origin' field to map back to the node that contains
that address. I suspect that presently there is no pointer back that way.
So these functions only work if all of your interfaces resolve to the
same name, and we 'accidentally' end up knowing the node name.
Ideas? All the ones I can think of would entail a full database scan for
every event. Not good, given the resources already used for events.
4) The xnmsnmpconf database has a similar problem. Communities
set for one address or name are not necessarily known for the other
addresses that turn up on that node. Some work done in V6 in this are
shows promise, with the alternate communities file. It results in the
generation of records in this database. Could this be the
place to store the relationship between primary addresses and other
addresses? Like 'For any of these addresses, use the name resolution
and community string associated with this primary address' - and
that primary address should be the one found on the type 24 interface, if
there is one.
This forum is a good place to exchange ideas for improvement, so
put on your thinking caps.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
---------------------- Forwarded by Leslie Clark/Southfield/IBM on
06/07/2000 09:52 PM ---------------------------
"Lemire, Mark" <mlemire@jhancock.com>@tkg.com on 06/07/2000 03:58:11 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "IBM Netview Discussion (E-mail)" <nv-l@tkg.com>
cc:
Subject: [NV-L] forcing autodiscovery to use loopback address
I'm trying to find a way to force Netview (v. 5.1.1) to autodiscover
devices
through their loopback address wherever one is defined. The loopback we
are
interested in is not the 127.0.0.1 address, but the configurable loopback
interface on (Cisco) routers.
The way we have Netview configured, it will autodiscover an object -- say a
router -- through some arbitrary IP interface. If that interface is later
moved to another device, the next time Netview demand polls the router
object using this interface, it is really polling a different router and
this leads to problems. The only stable interface we can use is the
loopback address.
In situations where a known router needs to be discovered, we can place the
loopback address in the seedfile. However, we don't always get notified
when a new router is about to be added, and therefore need a way to drive
the autodiscovery process so it effectively does the same thing.
The use of circuitless IP and loopback addresses is widespread, so we're
hoping someone else has found a way to do this. The alternative is to
manually go in and delete newly discovered routers when they are not
discovered correctly, add the loopback to the seedfile, and rediscover.
(PS
Is there any way out there to automate the deletion of objects without
having to go through the GUI?)
Thanks!!
Mark Lemire
John Hancock
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|