# emerge world, openafs client incredibly slow.

## Oo.et.oO

i emerged world recently and amongst the other typical rampant problems and annoyances, afs is now incredibly slow.  

i'm running 1.4.14 in kernel 2.6.37

i tried back-revving to 1.4.12 and 1.4.9 but neither will build on this machine/kernel (amd64).

so i re-emerged 1.4.14 and the kernel module and now afs won't authenticate at all:

```
Unable to authenticate to AFS because Authentication Server was unavailable.
```

but i know the server is up as others can auth.   also, this machine is super unresponsive whenever afs isn't working, which makes diagnosis very painful.  i'm not sure why this is, it's not like my $HOME is mounted on afs.  

i don't even know where to begin, and i've already compared my afs configuration to the one i had yesterday, they are the same.  

any ideas?

thanks

-eric

----------

## depontius

This sounds like something more fundamental in your network stack.  I'd skip AFS for the moment, and do some more traditional network diagnostics -you said "amongst the other typical rampant problems and annoyances."  I'd especially pay attention to traceroute to your afs servers, since both use UDP.  Are you running a firewall, and have you checked that it's doing what you think it is?  A misbehaving firewall can really foul things up in mysterious ways.

----------

## Oo.et.oO

thanks for the reply.  okay, they changed the name on our new afs home cell on us.  i guess they sent an email on it...

anyway, afs is back up and running but is still VERY slow.   

here is a traceroute to what i believe is my Cell host: names/IPs changed to protect the innocent:

```
REMOVED

```

edit: holy crap i'm a moron and i was using TCP traceroutes this whole time.  UDP traceroute is wicked slow...

it maxes out the 30 hop default before getting there and each one is VERY slow but it just gives me the * * * thing.

same with -U -m 60

oh, they ALSO changed vpn servers on us.  that must be it.  i can get good upd traceroutes to cnn.com so....

 :Evil or Very Mad: Last edited by Oo.et.oO on Mon Aug 15, 2011 6:54 pm; edited 1 time in total

----------

## depontius

I'd try traceroutes to a few other hosts, as well.  Why don't you post "netstat -Nr" while you're at it?

----------

## Oo.et.oO

i'm not sure how afs is working at all, i only get stars "* * *" for 120+ hops in a traceroute to my afs server and other servers inside the firewall (through the vpn).

is this a vpn server issue or something in the way i have openconnect setup?

i'm trying to figure out if my openconnect script (which is mostly from vpnc) is setting up a UDP or TCP tunnel.  but i don't even know if that matters for TCP vs UDP packets in the tunnel...?

----------

## depontius

I think you need to be a little more explicit about your setup.  I think this is the first I've seen that we're talking AFS through a VPN.  That makes things quite a bit different.

First, is your directly connected (not the VPN) network fully functional, with reasonable ping times, traceroutes, etc?  Next, how is your traceroute to the VPN host, even before you actually connect?  Try a traceroute to your "internal" DNS through the VPN, and see how that works.  Basically, skip AFS for the moment and see if you have first your network working properly, then verify that you have good networking through the VPN, (It sounds as if you don't, and that's the real problem here.) and after you're clean with those to, then you can think about AFS.  

AFS is too complex of a sunofagun, and can do too many ugly things to your system, to use as a network debug tool.

----------

## Oo.et.oO

the rest of my networking (TCP) seems to work fine both inside and outside the VPN.  some packet loss on the tun device, but tolerable amounts, nothing compared to UDP which is all packets lost.  can afs switch to tcp after losing all its packets?

when i updated gentoo the AT&T VPN client we were using just kinda stopped working.  rather than debug that closed source, no more support, POS i switched to openconnect which connects to a cisco front end somewhere on our network.  it's a test-bed, so at first i wasn't surprised that it was slow.  

i'm finally digging into it after a week of very slow afs performance, but totally normal vpn performance otherwise.

traceroute (tcp) to afs host:

```

traceroute to btv.myCell.com (10.61.34.106), 30 hops max, 60 byte packets

 1  yktv02-g06-s.myCell.com (10.2.249.130)  100.205 ms  100.289 ms  100.284 ms

 2  rcx-id-b-v548.myCell.com (10.2.248.132)  106.294 ms  107.183 ms  107.185 ms

 3  hny-sc-b-v279.myCell.com (10.2.248.14)  107.289 ms  107.294 ms  107.291 ms

 4  rcx-sc-a-v256.myCell.com (10.2.1.6)  107.520 ms  107.826 ms  109.102 ms

 5  rcx-p9-a.myCell.com (10.2.4.6)  107.135 ms  107.241 ms  107.237 ms

 6  * * *

 7  * * *

 8  btv-sc-a-v557.myCell.com (10.61.4.11)  119.226 ms  119.454 ms  119.365 ms

 9  btv-bd-b-ge0-1.myCell.com (10.61.1.4)  121.839 ms  121.822 ms  123.142 ms

10  btv-co-b-v803.myCell.com (10.61.2.13)  120.667 ms  121.571 ms  120.434 ms

11  btv-sd-3a-v814.myCell.com (10.61.2.58)  119.972 ms  118.595 ms  118.618 ms

12  pop-server1.myCell.com (10.61.34.106)  116.471 ms  115.359 ms  122.913 ms

```

----------

