0

Last week, we enabled IPv6 on our Authoritative DNS Servers and the corresponding Glue Records on our registrar for our domain's name servers, and we added AAAA records for our own website. This roll-out went without a hitch, and we're now serving up our website natively on IPv6.

This weekend, we added an IPv6 address to one of our client's dedicated servers, made sure Apache was configured for IPv6, and added that IP address to their own DNS zone file.

Since then, our Nagios monitoring of the URL (http://www.allgirlsallowed.org) has been complaining with:

CRITICAL - Socket timeout after 10 seconds

We have confirmed that the website is fully operational and that DNS is configured correctly, although external tools (such as Pingdom's website tests and http://www.downforeveryoneorjustme.com) have mixed results (Pingdom says it is working fine, Down for Everyone says it is down).

In our investigation, we've noticed several dozen TIME_WAITs coming from the same IPv6 address (which is in our same /64 block and is an IP operated by the hosting provider).

Now I do understand that a TIME_WAIT status means the connection is actually closed and that the process will go away shortly. That said, this is the only weird thing I've been able to find on the server. We've also seen a sustained increased load (~0.5, even when there's 0 current visitors).

What concerns me is that we haven't seen this behavior on our other IPv6-enabled servers (although granted, our other IPv6 servers probably receive a lot less traffic than this particular client).

Is there anything you would suggest I look into? Obviously I could go back in and disabled IPv6, but that's a crap-out. I want to identify the issue and address it head-on.

1
  • I can access your site just fine via both IPv4 and IPv6. You should probably look more closely into your Nagios server. As for downforeveryone... that site has never worked reliably for me. I'm surprised anybody uses it at all. And the TIME_WAITs are probably irrelevant to anything. Sep 30, 2013 at 15:50

1 Answer 1

0

Michael - Thanks for your response. I believe I've found the cause of the Nagios complaints, as well as the gazillion TIME_WAITs I was seeing (as I just made a change to /etc/sysconfig/network-scripts/ifcfg-eth0), although I don't understand why that would have made a difference, and I don't understand why that fixed the issue.

The issue was that the server is pulling down a DHCP address for IPv6 (we hadn't set it specifically in ifcfg-eth0). That said, we DID include the following line in that file:

IPV6INIT=no

It wasn't until a few minutes ago until I compared this file, line-by-line, with the file on another one of our servers running IPv6, as the problematic server was continuing to have issues, continued to have WAY more TIME_WAITs than I thought were correct, continued to have a high load, and the client was complaining that their website was extremely slow (and sometimes down earlier today).

I found that I had inserted this IPV6INIT line into their file when I had not inserted that line into the file on our other servers with IPv6 enabled.

As soon as I removed that line, and restarted the network service, all of the TIME_WAITs disappeared, server load dropped, and Nagios immediately issued a "Recovery" alert for the Critical status it had been constantly complaining about for the past 3 days.

We'll continue to monitor things closely on our end, but looks like the issue is resolved.

1
  • Yes, that would be a bad option to add on a dual-stack host... Oct 2, 2013 at 16:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .