This is one of my "soapbox" subjects....
I struggle a little with organisations who invest in NetView but do not invest
in
a reliable DNS infrastructure. I have had very good success with Ray's comments
below re routers and DNS. I put the SINGLE NAME of the router in the forward
lookup tables resolving to the SINGLE loopback address. In the reverse tables,
you resolve the loopback address back to the router name - remember the reverse
tables are more important than the forward name-lookup to NetView as he always
starts with addresses. My own policy from there, would be to put subsequent
adresses of the router in the reverse tables ONLY, resolving back to the SINGLE
name. I would not use separate names for different interfaces - if you want to
ping an interface specifically from NetView, simply drill down into the node
level
and select the interface to ping. You then put your loopback address in your
seedfile.
Soapbox off........
I think this solves most of the points raised by Leslie provided your DNS is
then
used consistently by everyone, but I would welcome further discussions...
If the problem with implementing DNS is a political rather then technical one
(often the case with clients I work with - different groups with overlapping /
underlapping responsibilities), then an aid I would setup in NetView is a
SmartSet
that captures nodes found by NetView, NOT in the DNS - it's a nice exercise in
the
NetView course and simply gathers hostnames that are, in fact IP addresses -
here's the expression you build:
~ ^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*$
That at least gives you a list of systems to pass to your DNS administrators
that
are not yet in the DNS tables....
Regards,
Jane
Ray Schafer wrote:
> Great suggestions Leslie, I wish I had more time to spend on it.
Hear, hear!
> 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
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
--
Tivoli Certified Enterprise Consultant & Instructor
Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
Tel: +44 (0)1628 782565
Copyright (c) 2000 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
|