Maintained by: NLnet Labs

[Unbound-users] IPv6 Crash

K Storbeck
Wed Feb 24 10:36:17 CET 2010


Hello Fellow Unbound users,

I've had problems with version 1.4.1 on ipv6 too. After some (within an
hour) time, 2 of the 3 configured threads are eating up 100% cpu, and
the gathering of statistics through the command channel are failing
(i.e. I can connect to the port, but nothing happens).

Our config:
server:
        interface: <v4 management ip>
        interface: <v6 management ip>
        interface: <v4 public anycast ip>
        interface: <v6 public anycast ip>

        access-control: <prefix> allow
	[more access-controls]

        verbosity: 1
        statistics-interval: 30
        statistics-cumulative: yes
        extended-statistics: yes
        num-threads: 3
        outgoing-interface: <v4 management ip>
        outgoing-interface: <v6 management ip>
        outgoing-range: 16384
        num-queries-per-thread: 16384
        rrset-cache-size: 3G
        do-daemonize: no
        chroot: ""

remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 953
        server-key-file: "/etc/unbound/unbound_server.key"
        server-cert-file: "/etc/unbound/unbound_server.pem"
        control-key-file: "/etc/unbound/unbound_control.key"
        control-cert-file: "/etc/unbound/unbound_control.pem"

I'm in need of some suggestions too on how to debug this problem.

Kind regards,

Kai

Chris Gotstein wrote:
> I've recently installed unbound onto 3 FreeBSD 8.0 AMD64 servers.  All
> are running the exact same unbound version and config, except 1 server
> that is doing IPv6.  Unbound crashes about every 24 hours on the server
> that is running IPv6.  If i remove the IPv6 address and set do ipv6 to
> no, then it runs without any issues.  As soon as i set it back to IPv6,
> the crashes start.  I'm running the latest version of unbound from the
> ports system, 1.4.1.  The config is very basic, using some of the tweaks
> suggested from the unbound website for high-volume servers.  Any
> suggestions on what i can do to debug this?
>