(list cc:ed)
Thanks for the hint Timothy, I have actually tried this earlier, but since some things have changed since then, I gave it a new try. I tried it within the server machine (server & client), and with a remote client via WLAN. It doesn't seem to be the bottleneck. The change is relatively small, and I'm kind of glad because encryption is a must since this system is WAN based. LAN is only development phase luxory. br, jukka > Jukka, > > Have you tried turning off encryption? > > fs setcrypt off > > This rids a tremendous amoutn of overhead, and I simply do not use it in > my > facility since all of our AFS servers are in a secure network. > > Best, > > --Timothy > > > > On Wed, Apr 10, 2013 at 10:51 AM, Jukka Tuominen < > [email protected]> wrote: > >> >> >> > On Tue, 9 Apr 2013 23:36:15 +0300 (EEST) >> > "Jukka Tuominen" <[email protected]> wrote: >> > >> >> Does it sound resonable to prefer DNS names over external IP's, and >> >> external IP's over local IP's? The rationale there would be to prefer >> >> dynamic over static definitions, and IP's that the clients can see >> >> over local IP's that may not be accessible always? (external meaning >> >> WAN and internal LAN IP's). I've started with whatever worked, and >> >> later on moved towards what I just described. >> > >> > I'm not quite sure if you're asking what you as a person should do, or >> > if you're asking what the code does. >> > >> > If you mean what IPs you should be specifying in various places, you >> > should put in the 'public' IPs that are always reachable by everyone. >> > That means put that in CellServDB and probably the fileserver NetInfo. >> > If you put a 'private' IP in there, then clients accessing from >> > elsewhere may also see that IP, and obviously they won't be able to >> > connect. We don't really do "split-horizon"-style setups, since >> everyone >> > gets the same list of IPs for fileservers. >> >> This answered my question. These are my initial findings with Wireshark: >> >> When running wireshark on the idle server machine, there was no striking >> errors that I could spot while browsing through the output. I then >> grepped >> /etc/ for any private IP entries. Since the machine is on DMZ, it has a >> private address in /etc/network/interfaces. >> /etc/openafs/server/CellServDB >> and /etc/openafs/CellServDB were the only other ones. I changed the >> latter >> two to public ones, but wireshark started to print "unreachable ports". >> It >> seemed that /etc/openafs/server/CellServDB had to have the private IP in >> place in order not to raise errors. >> >> It also seems, that there is quite a frequent traffic between the >> private >> and the public IP. I believe the traffic goes to the NIC at least, but >> propably not further (hub, switch or firewall) but I can't say for sure. >> Wireshark pairs the private and public, and then public and private on >> single lines, so how is that interpreted? >> >> I'd like to get rid of that noise because it may be _the_ problem, or at >> least it won't speed up things for sure. I'm just not sure whether it is >> possible from DMZ. Does anybody else have afs server on DMZ, and still >> get >> the full speed. And if yes, then do you have a private or public IP >> assigned? >> >> Or maybe I have just routed the traffic otherwise backwards, somehow... >> >> >> br, jukka >> >> > >> >> If you just want to see where the traffic is >> >> > going, capture some net traffic. All AFS traffic for a client >> >> > interacting with a server should happen on ports 7000-7003 UDP. If >> >> > we're contacting an IP that is one of the local host's interfaces, >> >> > it's up to the underlying OS where the packets physically go. >> >> >> >> OK, I'll try to figure out how to do that. Wireshark is my guess to >> >> start with. >> > >> > Yes, tcpdump or wireshark are the usual tools. wireshark is/can be >> > graphical and probably more intuitive if you haven't used similar >> tools >> > before. >> > >> > -- >> > Andrew Deason >> > [email protected] >> > >> > _______________________________________________ >> > OpenAFS-info mailing list >> > [email protected] >> > https://lists.openafs.org/mailman/listinfo/openafs-info >> > >> >> >> _______________________________________________ >> OpenAFS-info mailing list >> [email protected] >> https://lists.openafs.org/mailman/listinfo/openafs-info >> > > > > -- > Timothy Balcer / IT Services > Telmate / San Francisco, CA > Direct / (415) 300-4313 > Customer Service / (800) 205-5510 > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
