I have experienced this problem on several Solaris nodes and the result
have been unpredictable. On some
nodes registration will take place after retries, on some nodes I have not
been able to establish a connection with sysinfod after this error had
occurred.
There are a couple of remedies, as proposed by SUN support:
0. Upgrade to the latest version of SEA (1.0.3) and add the most
recent patches:
Pathes 106787-04 and 106874-01
1. Add a port statement in /etc/snmp/conf/mibiisa.reg
agents =
{
{
name = "snmpd"
subtrees = { mib-2, sun }
timeout = 2000000
watch-dog-time = 86400
port = 40000
}
}
and of course check whether the chosen port really is free.The result
is, however, unpredictable. On some nodes configuring the fixed port
also fixed the problem, on others all MIB communication was lost and
I
had to undo this step.
2. Add a parameter in the startup script /etc/rc3.d/S76snmpdx: '-f 0',
i.e. start the master agent as follows:
/usr/lib/snmp/snmpdx -y -c /etc/snmp/conf -f 0
This will cause the master agent to not erase subagents after no
communication with the subagent was established for some time. This
has been a known bug in earlier SEA releases, since the master
agent
probed e.g. the MIB-2 subagent with the wrong community name for
response, which - according to RFC specs did of cource not answer
the
probe - and then got removed from the master agent's registration
tabel. Result: processes are present in the Unix table but no
response will
come on any MIB requests.
3. Comparabe to step 2: set the watch-dog-time parameter higher in
/etc/snmp/conf/mibiisa.reg:
watch-dog-time = 31536000
But I must admit: these steps do not guaranteed solve the problems
with SEA connectivity. I still have nodes with SEA trouble, even
after performing all these steps. So far I have not been able to
find any more patterns. One thing seems clear, though:
multi-homed-hosts (several interfaces) cause more SEA trouble than
nodes with a single interface. And I have - sometimes - noticed
interference between the availability of one sub-agent on the
functioning of the other.
Hope this helps a bit. Anybody else with experience / solutions for
SEA connectivity problems?
Greetings,
Bart Benus
"Giovannini, Tom" <tom.giovannini@EDS.COM> on 28.09.99 00:39:59
Bitte antworten an Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
An: NV-L@UCSBVM.UCSB.EDU
Kopie: (Blindkopie: Ceta BenusB/D/ExternalStaff/WLB)
Thema: mgragentd, mibiisa not registered with master agent
My environment:
OS: Solaris 2.6 + maint
Tivoli 3.6
NetView for UNIX 5.1.1
Potential problem:
1. The status of mgragentd process is OVs_NON_WELL_BEHAVED
2. A message in the /var/adm/messages file reads:
Sep 24 18:45:25 pecsun04 mibiisa: Can't bind server
socket for port # = 33090, try another port in /etc/snmp/conf/mibiisa.reg
3. The snmpwalk seems to indicate a problem. Both the mgragentd
subagent and the mibiisa subagent are not registered with the master agent.
Command and associated output included below:
# /usr/OV/security/cmds/snmpwalk_unsecure -c public
127.0.0.1 .1.3.6.1.4.1.42.2.15.8.1.10
no MIB objects contained under subtree.
The output I expected was:
42.2.15.8.1.10.3 : OCTET STRING- (ascii): snmpd
42.2.15.8.1.10.2 : OCTET STRING- (ascii): mgragentd
42.2.15.8.1.10.1 : OCTET STRING- (ascii): relay-agent
In the TME 10 NetView Installation and Configuration Guide page 7-2, it
states that the snmpdx daemon and the mibiisa daemon must be running for
the
TME10 NetView Server to work correctly. These daemons are part of the Sun
SEA technology. The NetView manuals indicate that this could be a problem.
See the "MLM User's Guide", pgs 5-8, 5-12; and the "NetView Installation
and
Configuration" manual, pgs 7-3,4 for more info.
Has anyone experienced a similar problem? Any ideas?
Regards,
Tom Giovannini
Internet: tom.giovannini@eds.com <mailto:tom.giovannini@eds.com>
|