FTP - pulling from unix to windows 2000 server

[Dwyane Everts_1]

All,

I have an FTP issue (according to my windows admin). We have a process that runs each night (off peak processing time) that ftp's a couple of files from a unix server (RP8400) to a windows 2000 server. The files are pulled by the W2K server from the unix server. The transfer some days only takes a few minutes, other days takes hours.

I have reviewed the syslogs on the unix side, I have reviewed all the switch logs between the windows server and the unix server...the logs are clean of issues. NNM 7.01 and OVOW 7.21 are also not reflecting any server/network issues. What other tools can I use to t-shoot this issue? Are there any known issues that are unknown to me? :) Is this usually a buffering issue?

Any ideas on a directions at this point would be greatly appreciated!

Dwyane

[John Poff]

Hi,

One thing you could try is to setup another system to automatically pull the same files via ftp at around the same time. If the second system pulls the files with no problems and W2K box is still slow, it might eliminate some variables.

Do you have access to the W2K box? If so, are there any clues about jobs (backups, other processing, etc.) running during the ftp?

You could also configure 'nettl' on the rp8400 to do some network tracing of the packets from the W2K server during the ftp sessions. It might shed some light on things also.

JP

[Scott Palmer_1]

Dwayne,

I would check to see if you have anything between & including the RP8400 & the w2k server set to auto negotiate. I have had instances in the past when transfering files, the something in the pipe was set to auto negotiate and switches to half duplex. ( which then makes your transfers take twice as long i there is something hard coded to full duplex). It is my opinion that if the hardware can handle it you should hardcode the NIC's to 100 or 1GB full duplex.

Sincerely

Scott Palmer

[Steven E. Protter]

You could run tcpdump (unix) or ethereal (either platform) and analzye network traffic at the time of the failure.

You might want to ask the Windows admin to show you the event log entries that led him/her to his/her conclusion.

SEP

[Dwyane Everts_1]

Gents...

Great suggestions! To answer some questions...

Access to the W2K Server: Negative.
Monitor the situation using nettl when it occurs: it is intermittent
tcpdump: same as nettl
Auto-negotiate: I'll check this out.

Thanks for the help...
Dwyane

[Steven E. Protter]

Have cron run a tcpdump to a file for a few hours a night, overwriting the previous files. Then when you have a problem you'll be ready to analyze.

lanadmin -x 0

show stats on lan0

adjust based on the actual lan.

lanadmin -X to change settings on the fly.

/etc/rc.config.d/hpbtlanconf to hard code lan settings. Attaching an example to show syntax.

SEP

[Dwyane Everts_1]

Found it!!!

The windows-based, "home" file server is in the process of "kicking the bucket." It had absolutely nothing to do with the unix server or network, or even the ftp server. Since each windows server is mapped to the file server, when it starting having issues...so did every server that was mapped to it.

Thanks for all the help....
Dwyane