Your problem has to do with the firewall and the "session timeout".
The keepalive setting is for the "connection timeout". The default for the
session timeout is usually 2 hours (aka 7200000 milliseconds). This is a
classic default for Check Point, etc.
But you cannot change the firewall settings (I reckon)
I know that the solaris tweak is to modify the parameter (at the OS level)
tcp_keepalive_time to something (obviously) greater than
the default 2h ( == 7200000 milliseconds )
You use ndd in solaris. I don't have a clue of the command in windows. I am
not a windows person.
hint: do a search in google with
+session +timeout +firewall +7200 +windows -linux
On Friday 03 June 2005 4:10, Stanley Horwitz wrote:
> We've run into an issue recovering alarge (around 27GB) MS SQL database
> across a firewall between a Windows 2003 box in production behind a
> Check-Point firewall and a Windows 2000 server that we use just for test
> purposes. Our Legato server is Power Edition on a Sun Solaris 9 box with
> a Sony PetaSite and S-AIT tape drives connected to our v480 server via
> fibre channel. All of our network equipment comes from Nortel.
>
> I have a call open with Legato on this issue. As far as I know, our
> network
> administrators have a call open with Nortel on this issue. So far,
> nothing more
> than head scratching has taken place since we first discovered this
> issue a
> few weeks ago.
>
> When a colleague of mine tries to do a test recover of a 27GB SQL DB
> across
> our firewall, the recover proceeds for a couple of hours. During this
> time, I believe
> the SQL module is building the tables and other infrastructure to
> house the
> recovered data on the target server. After that phase of the recover
> is done,
> it just dies with a connection error in the target client's daemon
> log and in the
> NetWorker server's daemon.log. We see no other errors.
>
> When the same equipment is used to recover a large set of non-SQL files
> across the same firewall, the recover succeeds. When my colleague
> attempts
> to recover small SQL databases in the same conditions, those recovers
> also
> succeed. The kicker is that when we can recover the same large SQL
> database
> if we do the recover to a target server that resides in the same
> subnet where our
> NetWorker sever resides.
>
> If anyone has any thoughts on where we should look to resolve this
> issue, or
> where our network administrators should look, I would be grateful to
> hear from
> you. Fortunately, we are doing this only for DR testing purposes, but
> we do need
> to get this to work in case a real DR takes place.
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listserv.temple DOT edu or visit the list's Web site at
> http://listserv.temple.edu/archives/networker.html where you can
> also view and post messages to the list. Questions regarding this list
> should be sent to stan AT temple DOT edu
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|