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 AT us.ibm DOT 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.
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> ---------------------- Forwarded by Leslie Clark/Southfield/IBM on
> 06/07/2000 09:52 PM ---------------------------
> "Lemire, Mark" <mlemire AT jhancock DOT com>@tkg.com on 06/07/2000 03:58:11 PM
> Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
> Sent by: owner-nv-l AT tkg DOT com
> To: "IBM Netview Discussion (E-mail)" <nv-l AT tkg DOT com>
> 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
> through their loopback address wherever one is defined. The loopback we
> 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.
> Is there any way out there to automate the deletion of objects without
> having to go through the GUI?)
> 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 AT tkg DOT com
The Kernel Group | Distributed Systems Management