Folks, I'm working on getting AFS working on cluster nodes hiding behind a Redhat 7.2 based system doing IP Masquerading. Intermittently, servers are marked down on the nodes. This appears to be because the UDP timeout is too short. It also seems that the UDP timeout is hardwired into the 2.4 kernel. Iptables/netfilter doesn't allow one to change the UDP timeout. Ipchains theoretically does, but any attempt to change it logs something like the following:
kernel: Sorry: masquerading timeouts set 5DAYS/2MINS/60SECS The latter being UDP. It seems the documentation hasn't caught up with the kernel. I found two references in the archives from February 5th. One from Derek Atkins: > No. You can already have multiple AFS clients behind a NAT -- you > just need to set the NAT UDP timeouts to be fairly large. The second from Brandon S. Allbery: > Interesting. We've done it successfully with Linux NAT, both by upping > timeouts and with use of a hacked kernel that [only] bumped timeouts for > UDP 7000-7004. I have several questions: What is a fairly large timeout in seconds? Is there some known internal limit in AFS that determines this, or is it just an empirical finding that timeouts of some particular size just work? What is the exact kernel hack? I found some promising definitions in the 2.4 kernel source in net/ipv4/netfilter/ip_conntrack_proto_udp.c, but I'm not certain this is the right thing to change. Also, I don't see how to fix only ports 7000-7004 in this file. If someone has already done this on the 2.4 kernel, I think it might be of general interest to the AFS community. Does this lead to problems on the masquerading server? I can imagine that holding a large number of connections open per client could swamp the masq server. Does this ever happen? Thanks much. I hope this doesn't cover old ground, but I couldn't find the answers searching the web. Thanks again, -Barry. -- Ralph B. Robinson (Barry) Programmer Analyst, Senior Cornell Center for Materials Research [EMAIL PROTECTED] (607) 255-6065 _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
