From: Phil Baldwin (baldwinp@EURODIS.com)
Date: Wed Oct 23 2002 - 02:33:47 EDT
Hi again,
I thought I'd summarise, although I'm not a lot clearer on the exact cause
of the problem.
It seems that the problem was caused by path mtu discovery (PMTUD) not
working correctly, which resulted in T64 servers trying to send only
unfragmented packets across our WAN (MTU negotiation had become broken) and
for some reason our Unix servers had stopped operating as expected. M$
servers were unaffected.
This was, in the end resolved (fingers crossed) by:
i) rebooting all our Tru64 servers.
ii) setting pmtu_enabled = 0 in the inet stanza of the sysconfigtab (this
can be changed without a reboot). This turns off Path MTU discovery.
This link to a cisco document may explain better:
<http://www.cisco.com/warp/public/105/38.shtml>
Thanks go to:
Phil Lawrence (HP / Compaq)
Des and Rob and all the others that helped at our WAN provider.
George Banane (Tru64 lister)
Chris Edwards (Tru64 lister)
Regards
Phil.
ORIGINAL QUESTION:
Hi there,
I know that this is somewhat O/T, but I also know there's a lot of
experienced people out there.
The problem is when our remote users (across a WAN) try and ftp / ODBC /
Net8 from our Unix Servers (GS320, GS140 and ES40) to Windows-based PCs and
servers (mainly Win2K I think), the Unix boxes seem to settle to use the
default TCP window size of the W2K boxes and try and send 3MB in one go
across our WAN, causing a few 'performance issues' (understatement).
We have Cisco routers and switches comprising our WAN, and have been assured
(by our WAN provider) the problem is not to do with MTUs or autonegotiation.
Has anybody out there had any similar experiences?
much appreciate any help..
I will summarise when I get to the bottom of it.
tia
Phil.
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:57 EDT