From: Ramon Castillo (
Date: Thu Sep 04 1997 - 18:44:11 CDT

Many Thanks to:

Alejandro Lopez-Valencia <>
James Kwong <>
Francis Liu <>
Leif Hedstrom <>

Original Post:

We have an Ultra Enterprise 3000 which is running
SUNWipop (Pop-3), xtacacs, DNS services, and of course is a mail server.

We made the tuning to the system as Sun's recommendations state,
The problem appears to be related to pop-3, as detailed in the next lines.

>From a mail client (pc, sun, whatever) running eudora, pine, netscape
mail, users try to read their mail but at the time they transfer their
passwords the server takes a very long time to let them log-in and
retrieve their mail.

We've been monitoring the processes in the server with top,
ps, vmstat, netstat, iostat, snoop and everything seems to be OK.
One curious thing is the fact that when users wait for the server response
top reports the process (pop3d) as sleeping whose owner is the user
who waits.

This is an extreamely urgent situation and it will be desirable
to have a response as soon as posible.


        Alejandro Lopez-Valencia suggest to use Qualcomm popper 2.4b2
which is based in inet.d (
or cucipop (
this last one os the only popper that can read and write over NFS without
any problems. SUNMWipop can harm inboxes if used over NFS.

        Francis Liu suggested to change to NIS+ or NIS as the main name
service to improve looking up users in the passwd file.

What we did:

        When I posted the message the problem pointed to be related to
POP service. Users were accessing our LAN through access lists and then
authenticating through tacacs to access their mail, so, to avoid tacacs,
we started to acces the POP server without tacacs authentication. POP server
worked OK.

        The E3000 is the gateway to a switch, the access lists server, the
router and then to Internet. As part of the tests we isolated the machine to
only been accessed by our LAN clients, this is, we disconnected the E3000 from
the switch, access list server and router. All clients accessed the server
through a HUB. The machine worked just fine, no delay on multiple access from
LAN clients.

        What we observed monitoring packets through the net is that packets loose their way out (or in) to where they came from. The problem is
definitively not related to Sun's Hardware or software. The E3000 is
just OK.

        Now we are checking our Cisco components configuration to find out
what's going on.

Thanks to everybody on the list.

Ramón Castillo, QED Communication Staff.
Col. Del Valle Mail: ramon@qed.Com.MX
Benito Juárez Tel: (525) 524 0772
03100 (525) 524 0803
México City Fax: (525) 524 7293

Aqui estan expresadas mis opiniones. De ninguna
manera estan relacionadas con las opiniones de
la empresa para la que trabajo, Sistemas QED.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:02 CDT