Berthold Cogel wrote:
Is NAT in play? Are callbacks being lost? The 1.2.13 server almost certainly has issues tracking the client port if NAT's in play. The empty modes are just what Linux shows you when there's no fetchstatus data to show.No NAT. Most of the internal network security related things are done with some dirty ACL magic by our network gurus. If the traffic hits some of their rules they're really fast when it comes to hit the bad guys. I've asked them, but there was nothing special in the monitoring data.
1.2.x is going to have problems with not only NATs but also with clients that change their IP addresses, IP addresses that are used by more thanone client, clients that support the TellMeAboutYourself RPC but do not generate a UUID, and many other scenarios.
Many VPNs use NAT techniques so if there is a VPN in play then you must think NAT.NATs have two characteristics that are bad for AFS. The first is the port mapping. This is a killer for 1.2.x file servers because those file servers assume that all clients are on port 7001 and cannot distinguish between two clients on the same IP address with different port numbers.
The second problem is the port mapping timeout. However, this is really not a NAT issue but a firewall rule issue. If your firewall opens the firewall for incoming responses based upon an outgoing UDP packet and only does so for 30 seconds or so, the AFS callbacks are not going to work. The firewall must leave the inbound port open for at least ten minutes.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
