[OpenAFS] Windows client and firewall/antivirus/MTU conflict - possibility of file corruption

Richard Brittain Richard.Brittain@dartmouth.edu
Thu, 14 Jan 2010 12:15:42 -0500 (EST)


On Wed, 13 Jan 2010, Jeffrey Altman wrote:

> On 1/13/2010 3:20 PM, Buhrmaster, Gary wrote:
>>>
>>> For the time being at least, set the RxMaxMTU value back to 1260 octets.
>>>  This will result in a performance penalty but will avoid this data
>>> corruption.   Hopefully one night soon I will wake up in the middle of
>>> the night understanding where and how this data corruption is taking place.
>>
>> You mention SEP 11.0.4.  Does the problem still exist in release update 5?
>
> Richard said in his e-mail that the problem could not be recreated with
> 11.0.5.

To followup with respect to SEP 11.0.5, we have never seen file 
corruption, but we have seen temporary network lockup ( a known issue with 
older SEP versions too) and general performance degradation with some 
combinations of parameters.

Interface-MTU RxMaxMTU Client-threads  Network-bandwith-utilization

not set       0        4               25-45%, no lockups (default settings)
not set       0        4               30-50%, no lockup, exempt AFScache
                                                from SEP scanning
1300          0        4               0-50%, network lockups
1300          0        1               0-50%, network lockups
1300          1260     1               25-40%, no lockups

This is based on tests with just two machines, so should not be taken as 
definitive, but it seems that SEP 11.0.5 does not cause problems on a 
machine with the default MTU configuration.


>> I ask because of the following "interesting" fixes in RU5:
>>
>> http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007121216360648
>>
>>
>> With NICs that use a TCP offload engine, Symantec Endpoint Protection with Network Threat Protection enabled causes networking problems, such as connection failures and performance degradation
>> Fix ID: 1389258
>> Symptom: Teefer2 causes packet loss with TCP/UDP checksum offload by not preserving checksum data.
>> Solution: Teefer2 corrected to preserve checksum data.
>>
>>
>> DNS resolution fails while connected via Microsoft VPN
>> Fix ID: 1442277
>> Symptom: Teefer2 causes packet loss with TCP/UDP checksum offload by not preserving checksum data.
>> Solution: Teefer2 corrected to preserve checksum data.

-- 
Richard Brittain,  Research Computing Group,
                    Kiewit Computing Services, 6224 Baker/Berry Library
                    Dartmouth College, Hanover NH 03755
Richard.Brittain@dartmouth.edu 6-2085