On 8/14/2013 4:32 PM, Andrew Deason wrote: > On Wed, 14 Aug 2013 15:48:41 -0400 > Jeffrey Altman <[email protected]> wrote: > >> Clients that are behind a NAT with an old enough client are very sad >> because every time the port mapping drops they are assigned a new port >> number. The file server then attempts to contact them at the old port >> number and fails. In the meantime they experience a timeout. I >> certainly received plenty of complaints from work at home end users. > > It will be slow, but it shouldn't break. If it does break, that's a > fileserver bug, since changing addresses should not cause a failure to > access a file. If I got a complaint every time a user thought AFS was > slow...
The symptom is that clients see file servers toggle between up and down states. The client has an existing connection which is tied to a specific addr/port on the file server. The actual addr/port changes and so the file server treats the connection as if it is being spoofed and drops the packets on the floor. The client connection times out and the server is marked down until the next ping cycle. For replicated volumes, the client fails over to another file server. Or if the client is Windows, the client forces the creation of a new connection and retries which in turn forces a new TMAY query, etc. The downside of this is the additional traffic that file server is going to generate. The file server already has enough trouble keeping up with incoming packet processing and event management when using the OpenAFS RX stack. As I said previously, I would like to see some empirical evidence that this fixes the problem not just a belief that it should and will be safe.
smime.p7s
Description: S/MIME Cryptographic Signature
