[OpenAFS] Openafs vs Red Hat's Netkey

Mon, 9 Dec 2013 12:12:26 -0500

--089e011603c6a46c8304ed1d1959
Content-Type: text/plain; charset=ISO-8859-1

curiosity, what is the mtu in the ipsec network? is netkey implemented
similarly to ppp, namely that it encapsulates traffic and thus drops below
a standard mtu?

On Mon, Dec 9, 2013 at 11:24 AM, Steve Gaarder <gaarder1@math.cornell.edu>wrote:

> I run a network of machines running Scientific Linux 6 (a Red Hat
> Enterprise clone).  We have both AFS and NFS file servers.  In an effort to
> add some security to NFS, we are using IPSEC.  I have discovered that
> IPSEC, specifically Red Hat's NETKEY protocol stack, sends OpenAFS
> performance through the floor.  To try this on an SL/RHEL/Centos box,
> install Openswan and set it up on an OpenAFS server and client according to
> these instructions:
>
> https://access.redhat.com/site/documentation/en-US/Red_
> Hat_Enterprise_Linux/6/html/Security_Guide/Host-To-Host_
> VPN_Using_Openswan.html
>
> Then try copying a large file from AFS to the client's local storage, e.g.
> with rsync --progress.  You will see performance steadily drop to miserable
> levels.
>
> If you switch the client to the KLIPS stack (by using the kernel module
> that comes with the Openswan source), things run fine.  It does not seem to
> matter which stack is on the server.
>
> Any ideas about what is going on?
>
> thanks,
>
> Steve Gaarder
> System Administrator, Dept of Mathematics
> Cornell University, Ithaca, NY, USA
> gaarder@math.cornell.edu
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
>

-- 
Derrick

--089e011603c6a46c8304ed1d1959
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">curiosity, what is the mtu in the ipsec network? is netkey=
 implemented similarly to ppp, namely that it encapsulates traffic and thus=
 drops below a standard mtu? </div><div class=3D"gmail_extra"> <d=
iv class=3D"gmail_quote">
On Mon, Dec 9, 2013 at 11:24 AM, Steve Gaarder &lt;<a hre=
f=3D"mailto:gaarder1@math.cornell.edu" target=3D"_blank">gaarder1@math.corn=
ell.edu</a>&gt; wrote: <blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I run a network of machines running Scientific Linux 6 (a Red Hat Enterpris=
e clone). =A0We have both AFS and NFS file servers. =A0In an effort to add =
some security to NFS, we are using IPSEC. =A0I have discovered that IPSEC, =
specifically Red Hat&#39;s NETKEY protocol stack, sends OpenAFS performance=
 through the floor. =A0To try this on an SL/RHEL/Centos box, install Opensw=
an and set it up on an OpenAFS server and client according to these instruc=
tions:

<br>
<a href=3D"https://access.redhat.com/site/documentation/en-US/Red_Hat_Enter=
prise_Linux/6/html/Security_Guide/Host-To-Host_VPN_Using_Openswan.html" tar=
get=3D"_blank">https://access.redhat.com/<u></u>site/documentation/en-US/Re=
d_<u></u>Hat_Enterprise_Linux/6/html/<u></u>Security_Guide/Host-To-Host_<u>=
</u>VPN_Using_Openswan.html</a><br>

Then try copying a large file from AFS to the client&#39;s local storage, e=
.g. with rsync --progress. =A0You will see performance steadily drop to mis=
erable levels. 
 
If you switch the client to the KLIPS stack (by using the kernel module tha=
t comes with the Openswan source), things run fine. =A0It does not seem to =
matter which stack is on the server. 
 
Any ideas about what is going on? 
 
thanks, 
 
Steve Gaarder 
System Administrator, Dept of Mathematics 
Cornell University, Ithaca, NY, USA 
<a href=3D"mailto:gaarder@math.cornell.edu" target=3D"_blank">gaarder@math.=
cornell.edu</a> 
_______________________________________________ 
OpenAFS-info mailing list 
<a href=3D"mailto:OpenAFS-info@openafs.org" target=3D"_blank">OpenAFS-info@=
openafs.org</a> 
<a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-info" target=
=3D"_blank">https://lists.openafs.org/mailman/listinfo/openafs-info<=
/a> 
 
</blockquote></div> -- Derrick
</div>

--089e011603c6a46c8304ed1d1959--