I'm a bit curious here....
Lisa Napier wrote:
>
> From the documentation:
>
> The connection timewait option is necessary for end host applications whose
> default TCP terminating sequence is simultaneous close instead of the
> normal shutdown sequence (see RFC 793). In simultaneous close, four TCP
> segments are exchanges in the shutdown instead of the normal three.
Errr.. Exqueeze me? "Normal three"? Doesn't graceful TCP close always do
A ----- FIN -----> B
A <--- FIN+ACK --- B
A <---- FIN ------ B
A ---- FIN+ACK --> B
?
> The default behavior of the PIX Firewall is to track the normal three
> shutdown sequence and release the connection after the third segment. This
> quick release heuristic enables the PIX Firewall to sustain a high
> connection rate.
Does it do immediate close after the FIN from B to A?
or directly after the FIN+ACK from A to B?
Either way, this sounds like you're begging for drop entries, since there is a
very high possibility that this last segment will get lost in transit and
get retransmitted.
IMHO, a 70 second linger after the final packet is a good way to catch
FIN / FIN+ACK retransmits.
Connections like these are splendid candidates for connection replacement
if your connection pool grows full, so overload won't be a real concern
I think. Of course, if they are replaced, you'll inevitably see drops.
Regards,
/Mike
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK
Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50
Mobile: +46 (0)70 248 00 33
WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
