Openvpn tap uses 99% cpu time

[Jeremy Chadwick]

On Wed, Mar 14, 2007 at 03:11:58PM +0200, Emile Coetzee wrote:
> Since the latest updates to sys/net/if_tap.c (I suspect) in 6.2-STABLE
> my openvpn tap server is using up all available CPU time (99%)
> effectively killing the box. 
>
> I replicated this on a second machine which was about 3 weeks behind
> with a cvsup to the latest from RELENG_6 and after rebuilding the kernel
> it does the same thing.
>
> I have portupgraded openvpn to the latest release (openvpn-2.0.6_7), but
> this had not made any difference. Is anyone else experiencing similar
> problems?

I haven't seen this on either end of our OpenVPN setup.  Ours:

endpoint A:

FreeBSD eos.sc1.parodius.com 6.2-STABLE FreeBSD 6.2-STABLE #0: Thu Mar  8 10:41:09 PST 2007

openvpn-2.0.6_7     Secure IP/Ethernet tunnel daemon

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether 2e:2e:ec:9c:76:02
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto stp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0
        member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        member: bge1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ether 00:bd:22:14:00:00
        Opened by PID 36044

endpoint B:

FreeBSD medusa.parodius.com 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Aug  5 09:36:02 PDT 2006

openvpn-2.0.6_4     Secure IP/Ethernet tunnel daemon

bridge0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        ether e6:7a:00:c2:48:e5
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: tap0 flags=3<LEARNING,DISCOVER>
        member: em1 flags=3<LEARNING,DISCOVER>
tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ether 00:bd:a4:27:00:00
        Opened by PID 849


One thing I am noticing, however, is that on endpoint A the pid tap0
claims to be associated with is incorrect.  My guess is that this is due
to some fork() stuff that's going on.  tap0 claims the wrong pid, but
the pidfile has the correct pid.

eos# ps -auxw | grep 36044
eos#
eos# ps -auxw | grep openvpn
root    36048  0.0  0.1  3248  2644  ??  Ss    7:03AM   0:00.02 /usr/local/sbin/openvpn --cd ...
eos# cat /var/run/openvpn.pid
36048

While on endpoint B:

medusa# ps -auxw | grep 849
root      849  0.0  0.2  3604  2268  ??  Ss    3Feb07   2:18.63 /usr/local/sbin/openvpn --cd ...
medusa# cat /var/run/openvpn.pid
849


-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                        http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP: 4BD6C0CB |