nv-l
[Top] [All Lists]

RE: forcing autodiscovery to use loopback address

To: nv-l@lists.tivoli.com
Subject: RE: forcing autodiscovery to use loopback address
From: "Lemire, Mark" <mlemire@jhancock.com>
Date: Fri, 9 Jun 2000 09:04:26 -0400
Thanks both to you and Leslie for the excellent feedback.  We will consider
taking Leslie's offer to take a stab at putting together a straw solution to
this problem and submit it for review by this community.    

In reply to your suggestions:
1. We have a nightly discovery process that builds inventory records for
every interface on our network devices and have integrated that into the dns
definitions which are rebuilt daily.  We had been building DNS aliases for
many, if not all of the router interfaces to ensure that whichever one
Netview used resolved to the correct hostname.  However, this is problematic
for our operators when DNS resolves to an interface that happens to be down.
We have decided to *only* define the loopback address to DNS with
forward/reverse resolution as you suggest.

2. Your suggestion of adding all loopback addresses in the seedfile in
interesting.  Through our batch process, we can add all loopback addresses
for routers that are "staged" in the inventory; i.e. about to be added to
the network.  If a device comes online sometime after Netview startup, will
netmon always prioritize using a seedfile address to discover an object,over
and above its normal SNMP discovery process?  If so, that sounds like a
great interim solution until a better implementation can be built into
Netview.

3. We have been thinking about running nightly discrepancy reports to
identify selection names that don't match the DNS hostname -- sounds like a
great idea.

PS:  I know this has been asked before, but is there any scripted way to
safely *delete* an object from all related databases?  I know there exists
(or used to exist) several undocumented comands like ovwdbdmap -d and
ovtopofix -r, but I having once corrupted the database using these, I have
shied away from them.  The ability to delete objects is the one thorn in our
side that prevents from automating much of the map maintenance and we'd LOVE
to have a way to do this!! 

        -----Original Message-----
        From:   Ray Schafer [SMTP:schafer@tkg.com]
        Sent:   Thursday, June 08, 2000 7:49 PM
        To:     IBM NetView Discussion
        Subject:        Re: [NV-L] forcing autodiscovery to use loopback
address

        Great suggestions Leslie,  I wish I had more time to spend on it.  I
will
        reply in more depth later.  But I have had good success with Cisco
loopback
        interfaces if I follow these rules:

          1. Make sure that you can forward and reverse resolve the loopback
             interfaces on the Cisco Routers.  I would even strongly suggest
that you
             request name resolution for each router to be changed so that
the IP name
             for the router resolves to the loopback address of the Cisco
router, (and
             that the address resolves to the IP name!!).
          2. Create a seed file that contains all the loopback addresses.
          3. Find any router whose selection name is not the IP name for the
router -
             delete it from the map and re-read the seed file (netmon -y).

        Using the loopback is a great way to nearly always gaurantee that
netmon can
        perform the daily check for the router.


         lclark@us.ibm.com wrote:

        > 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
        >
        >
_________________________________________________________________________
        > NV-L List information and Archives: http://www.tkg.com/nv-l

        --
        Ray Schafer                   | schafer@tkg.com
        The Kernel Group              | Distributed Systems Management
        http://www.tkg.com


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web