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.
>
> _________________________________________________________________________
|