Bryan, the following note from James Shanks may be pertinent:
Here's an item of interest that was passed to me from the Level 2 team in
Support:
James Shanks
Tivoli (NetView for UNIX) L3 Support
The following AIX PTFs have been PE'd:
AIX 4.2.1 PTF: bos.net.tcp.client 4.2.1.22 (IX84982)
AIX 4.3.2 PTF: bos.net.tcp.client 4.3.2.4 (IX85539)
If you get a customer on AIX 4.2.1 or 4.3 with strange socket issues,
e.g. netstat -an shows massive queue backups without an obvious reason,
check the lslpp -ha for one of these filesets. The AIX 4.2.1 PTF has been
replaced by bos.net.tcp.client 4.2.1.23. Rejecting the fileset is
currently the only 4.3 solution. This bug (IX87310) hoses the socket when
large data transfers occur over large MTU interfaces, i.e. loopback.
Problems reported, so far, include nvcorrd(1666)->nvserverd(1665) socket
problems, often masquerading as ruleset problems.
Blaine Owens
Eastman Chemical Company
Email - bowens@eastman.com
Phone - (423)229-3579
Fax - (423)229-1188
> -----Original Message-----
> From: Brook, Bryan S [SMTP:bryan.s.brook@lmco.com]
> Sent: Monday, May 10, 1999 1:33 PM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: events showing up late in control desk (nvcorrd, nvserverd)
>
> someone PLEASE throw me a bone...
>
> Our customer is reporting large delays (up to 4 hours) of events arriving
> in
> their control desks. I can force a trap to be sent from a network device
> and it hits /usr/OV/log/trapd.log with low delay (<1 sec). The event
> shows
> up delayed (10 sec< delay <4 hours) in the control desk. The only rule
> they
> have implemented is forwardall.rls. There are approx 4 ovws running each
> w/
> multiple dynamic workspaces.
>
> netstat -a |grep nvcorrd shows the following:
>
> Proto Recv-Q Send-Q Local Address Foreign Address (state)
> tcp 0 0 loopback.nvcorrd loopback.1339
> tcp 156 0 loopback.1339 loopback.nvcorrd
> ..
> ..
> ..
> ..
>
> There are several of these socket pairs each with a receive queue listed
> for
> the numbered socket. lsof shows these socket numbers are nvserverd
> processes. These bytes in queue are VERY slow to clear out. Bursts of
> traps cause large numbers (~31k) and queuing delays.
>
> Has anyone seen this behavior? What could be wrong. Any hints, ideas,
> suggestions would be greatly appreciated.
>
> --Bryan Brook
|