Ken,
Interesting input from Scott on only putting loopback interfaces in both
forward (with which I have no problem) and reverse DNS.
Let me state very clearly that I have NO Tivoli authority - I am simply
a gal who has used NetView for a very long time and to use Leslie's
delightful phrase, I've seen some "goofy" networks in my time. Me
personally, the goofiest networks have nearly always turned out to be
goofy name resolution.
I am quite sure that NetView uses name resolution for more than traps.
That said, it's an excellent idea to force your Ciscos to always send
traps from the loopback (you can't necessarily do this for ALL your
devices now and in the future, perhaps??)
Name resolution is used during discovery. Discovery uses SNMP to get
things like ARP cache tables, routing tables and CDP tables. These
"clues" are IP addresses, not names. And lets not forget, this stuff
will be gathered not only during discovery polls but also on
configuration polls when NetView polls to discover whether anything has
changed (something you seem to do a lot - so you need these config
polls).
I do not know the current algorithm for what happens when a poll finds a
"new" interface (but I would love to!!.......); I do know that it has
changed over the years to be much better at resolving name resolution
changes.
So what needs to happen if we find a new interface on a box? Does this
IP address exist elsewhere in the NetView database? If so, is this a
duplicate address or an address that has moved? How to tell if there is
no DNS? (assuming it isn't an HSRP). If it is viewed as a duplicate, I
bet there is a good chance that NetView will delete it again. This can
lead to goofy database inconsistencies.
If the new address doesn't already exist in the database, without DNS
you need to get an SNMP response from the box that actually owns this
address. Pro tem, you probably get a "rogue" device on your topology
(green box, no icon). Since this address almost certainly isn't in your
ovsnmp.conf file, when you demand poll the new interface it will
probably use your global default community name(s) or public (depending
on the exact version of your NetView). I guess this is where a lot of
Scott's problems are coming in. You are in a "chicken-and-egg" scenario
where you can't get SNMP from the new interface because you don't know
the community name (I assume you don't use global public), and you can't
find out which (probably existing) box the interface belongs to because
there are no SNMP responses (though there may well be some
authentication failure traps around).
Eventually, you will config poll the existing box who does now have the
new interface and hopefully your rogue box in your topo display (that
you can ping but not demand poll) gets married up with it's real owner.
Config polls default to 24 hours and reducing this poll period will
obviously increase network traffic fairly dramatically. Yes - you can
manually demand poll it, provided an operator knows to do so; and you
still have the community name problem....
For brand new routers, if you only put loopback interfaces in forward
and reverse DNS, you need to ensure that you manually update and
activate your netmon seedfile BEFORE the device gets discovered via arp
cache, routing table, cdp table methods. Otherwise it is
non-deterministic which interface of your new router gets found first
and you probably end up with routers that have an IP address as it's
label, rather than the name of the loopback address. You also have the
same problem with what to put into your ovsnmp.conf in order to get any
SNMP response from your new box.
Oh, and if you use CiscoWorks, the last time we worked with this, it
appeared that whenever a new interface was discovered (even on an
existing router), if that interface was NOT in your reverse DNS then the
label of the router would change to be the IP address of the new
interface so you can get lots of "box label flap" if you have a very
dynamic environment.
Let me reiterate. I do not have Tivoli authority on this one and I have
no detailed intimate knowledge of the netmon algorithm. But if I were
the developer, I can see that many things are dramtically easier to
resolve if there is a complete reverse DNS. Hence I personally would
ALWAYS ensure that a process is in place to build / maintain a full DNS
with a known owner. It ain't that difficult and it affects EVERYTHING
in your enterprise. How can you do integrated enterprise management if
you don't have a single answer to "what's this box called?"
End of soap box - someone else's turn.
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.
|