I believe I have had the same problem and it was solved with IBM AIX
support help.
This is because of the feature "PATH MTU Discovery" that is enable by
default on AIX 4.3.3.
It allow the TCP stack to detect the optimal MTU size (=frame size) when
talking to others hosts. The drawback is that it create a "clone" route for
each of the hosts that the system try to communicate with.
This can a very big number on a Netview box.
The number of "clone" route is probably the reason of the segmentation
fault.
You can disable this feature by entering:
/usr/sbin/no -o tcp_pmtu_discover=0
/usr/sbin/no -o udp_pmtu_discover=0
You will need to add these line in your /etc/rc.net file.
You can also see the status of the variables with: /usr/bin/no -a
netstat -r should show that your default route Flags are now "UG" instead
of "UGc".
Regards,
Francois Le Hir
Network Projects & Consulting Services
IBM Global Services
Montreal Quebec
Phone: (514) 205 6695
---------------------------------------------------------------------------------------------------------------------
Date: Wed, 25 Apr 2001 09:22:34 -0400
From: "Leslie Clark" <lclark@us.ibm.com>
Subject: RE: Network problems preventing status polling and discovery??
Regarding your gateway: you appear to have lost your gateway configuration.
Go into
smitty tcpip
minimum
select your main adapter
Enter
This will re-establish your default gateway. It happens sometimes, I don't
know exactly under what circumstances. But I keep an eye out for it.
Regarding the netstat core: At current AIX levels, the netstat -r
frequently
fails like that, as does netstat -a. Something to do with the linked list
changing before
the command reading it finishes. You could try AIX support, but in all of
the pmrs I
have searched, no one seemed to think that was a problem.
Anybody else?
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Treptow, Craig" <Treptow.Craig@principal.com>@tkg.com on 04/24/2001
06:07:38 PM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc:
Subject: RE: [NV-L] Network problems preventing status polling and
discovery??
Thanks for the help. Since that tracing and then stop/start of netmon
hasn't caused netmon to do anything different that I've seen, I got to
looking in the netmon.trace file, and found this:
Tue Apr 24 16:59:47 CDT 2001
Note: default gateway not configured. You should ensure
that your network configuration does not require a default gateway.
**** Warnings from /usr/OV/bin/nmcheckconf configuration check script
This started showing up this past Saturday evening when I was attempting to
clear the database and start a rediscovery. Netview had some problems that
I worked with support on, but I did notice this until today. Anyway...
I do have a default gateway:
# netstat -rn
Routing tables
Destination Gateway Flags Refs Use If PMTU Exp
Groups
Route Tree for Protocol Family 2 (Internet):
default 162.131.204.10 UGc 0 0 en1 - -
127/8 127.0.0.1 U 16 939760 lo0 - -
Segmentation fault(coredump)
#
Of course the coredump, isn't a good thing. <SIGH>
Perhaps all of this is related??
> -----Original Message-----
> From: Leslie Clark [mailto:lclark@US.IBM.COM]
> Sent: Tuesday, April 24, 2001 4:41 PM
> To: IBM NetView Discussion
> Subject: Re: [NV-L] Network problems preventing status polling and
> discovery??
>
>
> I would guess that netmon was very busy and would turn on
> tracing to see
> what it is doing. That's usually what it means when the
> demandpoll dialog
> hangs there empty, in my experience. If it won't answer to a
> 'netmon -a 3'
> then it probably also won't answer to a 'netmon -M -1', so
> you would have
> to change it at the daemon startup (use smitty nv6000 or serversetup).
> Last time I did that for the problem you describe I found that it was
> working
> over the seedfile, which contained a few thousand devices. I
> cut that back
> to just the rules and netmon could get on with its work.
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> Detroit
>
> "Treptow, Craig" <Treptow.Craig@principal.com>@tkg.com on 04/24/2001
> 04:51:11 PM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> Sent by: owner-nv-l@tkg.com
>
>
> To: "NetView List (E-mail)" <nv-l@tkg.com>
> cc:
> Subject: [NV-L] Network problems preventing status polling
> and discovery??
>
>
>
> Hi. We are running Netview 6.0.2 on AIX. I am having trouble getting
> Netview to perform a discovery, or at least it is very
> inconsistent. For
> the last couple of days, we have been fighting other problems
> that have
> been making network response times very slow for applications. I'm
> theorizing that some of our network problems are causing
> Netview to timeout
> on SNMP polls, etc.
>
> Along with this, any demand poll I've tried, just sits there.
> I'm also
> theorizing that this might be related, and that it is simply
> retrying and
> timing out, but I'm not sure.
>
> I'm looking for ways to prove these theories. Does anybody
> have any ideas
> on how to do that? I've struggle to find the answers in the
> archives of
> this list so far.
>
> Thanks.
>
> Craig Treptow
> Principal Financial Group
> I/S Network Administration
> (515) 247-6207
>
> ______________________________________________________________
> ___________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
>
> ______________________________________________________________
> ___________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|