Ken, if I understand everything you said, you and I are on exactly the same
page. I use the loopback interface ONLY in DNS and use the trap source
statement in the routers and things work quite well - HOWEVER - I have a PMR
opened which I have mentioned briefly in other threads for failures that are
related to NetView sending SNMP queries to the wrong interface (not using
the loopback interface) AND I have a PMR where NetView sends out thew WRONG
SNMP community string and creates hordes of SNMP authentication failures.
Both of these PMRs are treated as Defects in v6.02 NETMON. So you are
exactly correct with the way you wish to proceed - use only the loopback
interface and only put that interface in DNS and things will be fine - as
soon as support provides eFixes for the two problems I just mentioned.
-----Original Message-----
From: Ken Viola [mailto:kviola@cpcug.org]
Sent: Thursday, September 13, 2001 6:37 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] DNS and Netview
Thank you Jane for your response. I am, however, met with extreme resistance
on the need
to provide reverse records for each interface when a loopback can be
utilized,
particularly when dealing with Cisco routers which can implement the
command,
"snmp-server trap-source Loopback0". The following are some of the
sentiments from our
telecom and DNS folks:
"...I do not even think Netview attempts a reverse lookup on every interface
upon
initialization. I believe that a reverse lookup is used only in resolving
traps. In that
case by using the router command "snmp-server trap-source Loopback0", all
traps are sent
from the router using the IP address of loopback interface not the interface
effected
(e.g. IFdown).
I do think it is worth finding the correct answer. It is not the initial
work that
concerns me but the continuing maintenance of DNS
every time an IP address is added or changed on a router. We have changed a
lot of IP
addresses on routers due to ... We
also add or remove circuits on a frequent basis. If we can just use forward
and reverse
lookup of loopback addresses on
DNS, the chore will be greatly simplified in the long run. Think of the
difference of
work over the next five years!
We pay Tivoli a lot of money. Can you find out from an "authoritative
source" to tell us
if trap resolution is the only time that
Netview needs reverse lookup?
Here is the data record from one trap on my Netview server. Note that it was
able to
resolve the node by using the reverse of the
loopback in the host file. The trap itself contained the port description
and not
another IP address to resolve.
Enterprise: 1.3.6.1.4.1.2.6.3
Generic: 6
Specific: 58916866
Node: KWV001gate155
Source: 63
Severity: Indeterminate
Category: 3
Time: 9/12/01 12:46 PM
Description: Interface Serial1.1 up."
Another user.... "we obtained the same results from our Netview server. Both
random and
"forced" traps were resolved for different interface events. Our Netview
server has
only Loopback addresses and SysNames in its' database for each of our
routers. Of
course we also used the "snmp-server trap-source Loopback0" command on all
our Cisco
routers. (The Cisco documentation states that this command forces ANY & ALL
router traps
to be transmitted with Loopback0 as the source address.)
We're satisfied since our management has stated they will not provide DNS
support for
all router interfaces unless Netview or Tivoli engineers provide written
documentation
establishing the need to do so. Our contracted engineers have agreed with
us
that router interface support via DNS is unnecessary ( if a router has both
a Loopback
address and the "trap-source" command while Netview uses the router
Loopback address in
its' database.). I'd appreciate hearing from anyone obtaining different
results from
their Netview server resolving router TRAPS. Thanks !"
"From Jane Curry's message, I understand that if we use an IP address in the
seedfile
instead of the router name a reverse lookup is
used to get the name. She seems to recommend the router name in the seedfile
rather than
the IP address so this lookup need not
be done.
We use Cisco routers which allow us to use the loopback address as the "trap
source" IP
address. Cisco documentation states
that this forces ANY & ALL router traps to be transmitted with Loopback0 as
the source
address. Our experience with Netview
shows that all traps sent to the Netview server from routers configured with
the trap
source command are resolved to the router
name using the reverse lookup of the loopback address.
Since we discover with the router name or loopback IP address and all traps
are sent to
the server with the IP address of the
loopback address is there any reason to engage in the very large maintenance
chore of
maintaining DNS with ALL interface
addresses pointing to the router name. It seems that given this scenario,
DNS of forward
and reverse lookup of loopback
addresses only, will function well with Netview."
Please provide as much clarity as possible so this issue can finally be put
to rest. I
have had several conflicting recommendations on this topic from all levels
of
Tivoli/Netview support personnel. I cannot offer a solution from any expert
at this time
unless it is backed by concreteevidence. Please continue to help bring this
issue to
closure.
Thanks,
Ken Viola
Jane Curry wrote:
> Ken,
> Please see inserted comments...
>
> Ken Viola wrote:
>
> > Hi All,
> >
> > Please help us with our DNS issue. We are implementing Netview on AIX
(as our
> > master Netview) with AMLM's running on NT distributed around the
country. The
> > AMLM's will offload polling from the AIX Netview and forward status
updates and
> > traps to the master Netview. The Netview is using /etc/hosts currently
as we are
> > in the process of updating DNS to reflect all of our network devices.
>
> I would very strongly recommend getting to an organisation wide DNS under
your
> NetView. /etc/hosts CANNOT resolve multiple IP addresses to 1 name (for
your
> routers) - only DNS (or NIS) can do that.
>
> > Netview
> > will only be used to manage network devices. It is intended that the
Netview
> > (AIX) server will act as a secondary caching nameserver only and will
not be
> > sourced by any other systems.
>
> NetView is a huge user of DNS so I would always put a DNS server on my
NetView
> system. It improves performance and reliability.
>
> > The issue is whether or not the DNS needs to be
> > updated with reverse records for each interface on all of our network
devices
> > for Netview to function optimally. If the device is able to handle a
loopback
> > address (ie Cisco routers), our thought is that only the loopback needs
to be
> > addressed for forward and reverse DNS records.
>
> I would strongly recommend having ALL interfaces in the reverse DNS
lookup. NetView
> finds addresses first, not names. The first thing he does having found an
IP
> address "clue" for his discovery algorithm, is to do a DNS reverse lookup
to try and
> find a name for it.
>
> Use loopbacks on your routers where possible. I would then put just the
loopback
> into your DNS forward lookup (so when you do "ping box1" or whatever, the
DNS always
> resolves to something that is contactable if the box is contactable at
all). I
> would also use the loopback name in the NetView netmon seedfile if you
want to
> ensure these devices are found quickly. You still need all the reverse
entries for
> your DNS.
>
> > If it is not capable, then one
> > interface will have a forward record with every other interface having a
reverse
> > record pointing to it. Is it necessary to provide reverse records for
each
> > interface if a loopback address can be assigned? We have around 10,000
devices
> > and it becomes very tedious and time consuming to require reverse
records for
> > each interface. What is the best practice to use for the sake of
Netview? Also,
> > if every interface needs to have a reverse record regardless of
loopback, are
> > there any Perl scripts available to automate the extraction of the
interface
> > information using snmpwalk with IP(as single parameter or via hosts
file) and
> > community strings in conjunction with h2n to generate the DNS files?
>
> > Thanks for any help you can provide.
> >
> > Ken Viola
> > kviola@cpcug.org
> >
> >
_________________________________________________________________________
> > NV-L List information and Archives: http://www.tkg.com/nv-l
>
> Cheers,
> Jane
> --
> Tivoli Certified Enterprise Consultant & Instructor
> Skills 1st Limited, 2 Cedar Chase, Taplow, Bucks, SL6 0EU, UK
> Tel: +44 (0)1628 782565
> Copyright (c) 2001 Jane Curry <jane.curry@skills-1st.co.uk>. All rights
reserved.
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
|