[OpenAFS] NAT issues.

[bil]

--On Wednesday, April 26, 2006 2:30 PM -0400 Jim Rees <rees@umich.edu> 
wrote:

> Sigh.  Groan.  Didn't we just discuss this last week for the hundredth
> time?

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.