[OpenAFS] NAT issues.
Wed, 26 Apr 2006 17:45:31 -0400
--On Wednesday, April 26, 2006 2:30 PM -0400 Jim Rees <firstname.lastname@example.org>
> Sigh. Groan. Didn't we just discuss this last week for the hundredth
Can't say, I may have missed something, sorry if I did.
I am aware that the issue comes up pretty regularly, but then NATs are
pretty much a fact of life.
I think last week tho was John's issue with failed callbacks bringing our
server to it knees, and for that one there were no NATs involved, just an
old bad client with a possible local firewall issue (thanks to everyone btw
for the help with resolving that issue--we really appreciate how helpful
folks are in the afs community).
> The consensus was that it's a bad idea to allow ordinary users to pound on
> the servers that way. I did put code in cvs head that will check up and
> down servers every 30 seconds, but right now there is no convenient way to
> turn it on.
That kind of begs my question about whether a contact interval as an option
with a variable to be set is possible as seems to be the case in the
windows 1.5.1 client. I have absolutely no idea whether that would be
possible or not, or easy or hard--I freely admit absolute ignorance in that
arena, so please accept my apologies in advance if it's a stupid question.
It sounds like the latest server will help a good deal with NAT related
issues. In our particular cell, I'm guessing that it would only be a dozen
or so machines we'd want to tweak this way, and I'm very happy that the
1.5.1 windows client offers an option to tweak this setting. Assuming that
tweak works with windows clients (and I will ask some of our folks to test
it), it would be nice if the unix based clients offered a similar tweak.
> Doing this with ttl=1 is an intriguing idea, but I think it belongs in an
> external application, like natkeep, not in OpenAFS. And it would be hard
> to implement, requiring systype dependent code.
I agree that trying to implement something like natcheck from within
openafs is probably not a good approach (Todd Lewis brought that up on the
list a few years ago, and I chatted with him about the problems he ran into
looking at it this afternoon).
So long story short, if it's not desirable to get something controlling the
contact interval on the unix openafs client, I'll poke a bit at the natkeep
app and see how that looks....
> And the ultimate fix is
> tcp but that's a big job and a long way off.