login connection

[Mel Barranco]

We have a HP9000/K380 OS 10.20 running Informix-SE 7.20. The remote bldg connection is thru "T1" using Sonicwall router to the main building. Infrequently, login connection is a problem from the remote bldg but not in the main building during the time 7-8AM. However, using another way to connect to the server from the Internet allows a connection to the main server (using the PC from the remote location). The syslog.log does not record the login connection made to the server using the SMART TERM emulator program.

As this happens infrequently, I wonder where the problem is coming from. Is there a log file other than syslog.log to look at for tracing connection log? What would cause this "erratic" connection problem from the remote bldg? Two days of the last four working days we observed this problem happening.

TIA
Mel Barranco

[Mike McKinlay]

Infrequently, as in, sometimes you timeout trying to get to the host? Does it happen more often than not? Closer to 7 or 8 am?

The timeframe sounds like a clue to me. You're connecting over a T1 line ... is it a frame relay connection or dedicated T1? If frame relay, what's the CIR? If only 256-384K, I'd wonder whether your connection is saturated ... maybe some kind of mongo data transfer takes place during that timeframe. Or maybe this is when lots of people come into the office and start signing on to everything?

[Pal Szabo_1]

Perhaps a script or data
processing occurs in this
timeframe.

Please check:
1. /var/adm nettl logs.
netfmt -f ./nettl.log00 or
similar

2. Turn on sar
3. Check the network traffic
during this period.
The easiest wy to write a script that process netstat -s output and counts packet traffic

[Berlene Herren]

Also, turn on logging with inetd -l and perhaps more will log to syslog.log. How are the users connecting? If using ptys, mayhap you need to increase nptys.

Berlene

I have picked up your call, BTW :)

[Mel Barranco]

Thank you Mike for the reply. We have a dedicated T1. Will try to find the scripts that runs that period of time (7-8 am).

Pal, thanks for the reply. Network traffic is at minimal during that time. nettl.LOG00 revealed old data from 9/2000 so it's not it. Your suggestion to check scripts is the next logical thing to do.

Berlene, nice talking to you, :), and thanks for the reply. As discussed, will try finding the scripts running during that time.

Mel

[Craig Gilmore]

If I read correctly, it appears that you have already identified the problem area. The problem happens to remote users getting to the main building across the T1 line. The users in the main building do not experience the problem.

I'm presuming that the servers being attached to are in the main building. Additionally, if remote users get to the main building NOT using the T1 line, but another path, they do not have the connection problem.

These items seem to point to either the T1 line or the connection equipment as the problem area. The T1 line and the connection equipment must be present in the link for the problem to manifest itself. The server and what is running on it appears to be the same if you use the T1 connection or the Internet connection back to the main building.

Remember, at the time the problem happens the T1 line shows the problem but not the Internet connection.