Great email, excellent information.
Jason Allison
Principal Engineer
ARINC Incorporated
Office: (410) 266-2006
FAX: (410) 573-3026
-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Friday, May 17, 2002 4:49 PM
To: nv-l@lists.tivoli.com
Subject: [nv-l] Overview: IY26119 , IY26404, and the event "SNMP Address
Changed to <IP_ADDRESS>"
Ok, everyone, I bugged some people and got some great information.
Then I tried to express it clearly, for those of us outside of the ivory
tower.
If this confuses you, read it again. If you still think you are having
problems
with those new events, then call Support.
Normally, in the course of a demandpoll, netmon will use the information
you see in 'xnmsnmpconf -resolve <Selection Name>' to contact a node
via snmp. That includes an ip address associated with the node, as well
as the community string to be used. This is set at discovery, and is
stored
in the topology database. You can also see it in
ovtopodump -l <SelectionName> | grep "SNMP ADDRESS".
(The community string associated with it may be updated based on what
is in the alternates file, /usr/OV/conf/communityNames.conf).
If that interface is not up, netmon has always tried other interfaces on
the
node until it gets a response to a demandpoll. If it finds another
interface up and can get the information it requests, it will change the
snmp address to the first working one. (Presumably it does not change
it if it finds none that respond).
There are also situations when netmon sends the request to one
address and the SNMP agent on the node responds from another address.
It does not fail on the request to the first address, it just comes back
from a
different source. In that case, netmon will assume that this response
address
is the proper one to use, so it updates the node's snmp address.
Prior to V7, these changes went on quietly. Starting in V7, a trap is
issued
to tell you that the change has been made.
There are two cases in which the address change causes problems, and they
have been addressed by the fixes to two different APARs.
Case 1: IY26119 Unwanted address changes
In some environments it is undesirable for the snmp address to be changed.
For instance, only one interface of a router is allowed to accept snmp
requests, but
the response will come back to Netview via the nearest interface. You have
discovered the nodes by the interfaces that allow snmp and do not want
netmon
to change them.
Solution: The environment variable "NV_NETMON_IGNORE_RESP_SNMPADDR"
was added to allow user to have netmon ignore the different address in the
response
from the SNMP agent. The environment variable should be set in netnmrc.pre,
then
start netview from /etc/netnmrc. You can check if the environment variable
is properly
set by dumping the information: netmon -a 160
Case 2: IY26404 - Unnecessary address change traps
Netmon does an HSRP poll every 5 minutes to see if an HSRP interface has
moved from one node to another. It does this by doing an snmpget of sysName
via the address it knows is an HSRP interface, and checks to see if it is
talking to a
different node this time than it was last time.
Normally netmon will use a non-HSRP interface for regular snmp requests
(Daily config,
demand poll, snmp status poll,..), but use the HSRP interface for HSRP
poll. This resulted in
the snmp_addr for the router switching back and forth between the non-HSRP
address and
the HSRP address frequently. We did not see this in V6 because there was no
event to call
our attention to it. In V7.1 the trap made it evident. The fix to this APAR
prevents the
unnecessary traps from being sent, because it stops netmon from updating
the snmp_addr
in the database when the address is changed from a HSRP address to
non-HSRP address
(or reverse). We know the snmp_addr being changed to HSRP address is for
temporary usage
for the HSRP poll, and that it is not the regular interface netmon needs to
use for other
purposes, so the database is not updated, so no trap is sent.
Both of these fixes are in V7.1.1.
That leaves the normal cases. If there is really a change needed for
snmp_addr,
the trap will still be sent in V7.x (but not in V6.x). That is, if the
interface with the current
SNMP address goes down, netmon will find the next available up interface
and set
it as the SNMP address, and you will see the trap for that. Further, it is
likely that there
will be one 'normal' address change trap if you discover a node by
loopback and
then hear from it via the serial interface. This should not happen more
than once
at discovery or at the first configuration poll, but they would also be
considered normal,
unless you have set the "NV_NETMON_IGNORE_RESP_SNMPADDR" variable to
prevent this.
Leslie Clark
---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com
*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|