Please help! I've got a stumper of a networking problem and none of the solutions I have found through Google work! I'm hoping that those on this forum who know more than I do may be able to assist.
Let me begin by saying that I got LAGG with LACP working beautifully on my system and running stably for about 2 days. I am running a fully patched version of FreeBSD 10.2. Below are the relevant lines of my /etc/rc.conf file that initially got IPv4 and IPv6 working for me on lagg0:
With this configuration and setting up LACP on my switch, I had IPv4 and IPv6 working on lagg0 for about 2 days. Then last night my server decided it was no longer connected to the network. I still have no idea what happened as one minute it was working normally and the next minute it was unreachable via SSH, SMB, ping/ICMP, or any other protocol. I still haven't figured out what happened. However, logcheck gave me the following log entries from the relevant time that looked "suspicious":
Rebooting the server restored network connectivity, but caused another one to rear it's ugly head. My logs are now flooded with the following error message that is generated every three seconds:
That errorr message has been generated every three seconds since I rebooted the server to restore network connectivity. I'm not sure if solving one problem created the other, or if the two are related. As a secondary issue, IPv6 now no longer works on my server. For example using the command
used to generate a ton of responses but now just results in 100% packet loss.
I've Googled the current error message that is flooding my logs. The search results seem to indicate that that there may be some issues with how FreeBSD handles neighbor solicitations for IPv6. However, all the search results are 1-2 years old. See, for example, the following links:
https://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255579.html
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/068934.html
https://reviews.freebsd.org/D1835
Unfortunately, these results are unhelpful for two reasons. First, the suggested work around of:
does absolutely nothing on my system. My logs are still flooded with the error message every 3 seconds after changing that kernel value. Second, it seems that the issue those links describe was patched last year, so I may be facing an entirely different problem.
At this point, I'm at my wit's end and am desperate for help. My logs are unreadable (and therefore useless) due to the flood of NS/DAD error messages. I've modified the sysctl variable described above with no success. I've rebooted the server several time without success. And I've Googled and Googled some more for other possible solution (or at least a current description of the underlying problem) without success.
Please help!
Let me begin by saying that I got LAGG with LACP working beautifully on my system and running stably for about 2 days. I am running a fully patched version of FreeBSD 10.2. Below are the relevant lines of my /etc/rc.conf file that initially got IPv4 and IPv6 working for me on lagg0:
Code:
#LACP Config
ifconfig_re0="up"
ifconfig_re1="up"
cloned_interfaces="lagg0"
ifconfig_lagg0="up laggproto lacp laggport re0 laggport re1 DHCP"
ifconfig_lagg0_ipv6="inet6 accept_rtadv"With this configuration and setting up LACP on my switch, I had IPv4 and IPv6 working on lagg0 for about 2 days. Then last night my server decided it was no longer connected to the network. I still have no idea what happened as one minute it was working normally and the next minute it was unreachable via SSH, SMB, ping/ICMP, or any other protocol. I still haven't figured out what happened. However, logcheck gave me the following log entries from the relevant time that looked "suspicious":
Code:
Feb 27 22:07:18 zeus kernel: re1: watchdog timeout
Feb 27 22:07:18 zeus kernel: re1: link state changed to DOWN
Feb 27 22:07:21 zeus kernel: re1: link state changed to UP
Feb 27 22:07:21 zeus devd: Executing '/etc/rc.d/dhclient quietstart re1'
Feb 27 22:09:59 zeus nmbd[837]: [2016/02/27 22:09:59.487166, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Feb 27 22:09:59 zeus nmbd[837]: Packet send failed to 192.168.1.255(137) ERRNO=Network is downRebooting the server restored network connectivity, but caused another one to rear it's ugly head. My logs are now flooded with the following error message that is generated every three seconds:
Code:
zeus kernel: lagg0: a looped back NS message is detected during DAD for [IPv6 ADDRESS REDACTED]. Another DAD probes are being sent.That errorr message has been generated every three seconds since I rebooted the server to restore network connectivity. I'm not sure if solving one problem created the other, or if the two are related. As a secondary issue, IPv6 now no longer works on my server. For example using the command
Code:
ping6 www.google.comused to generate a ton of responses but now just results in 100% packet loss.
I've Googled the current error message that is flooding my logs. The search results seem to indicate that that there may be some issues with how FreeBSD handles neighbor solicitations for IPv6. However, all the search results are 1-2 years old. See, for example, the following links:
https://lists.freebsd.org/pipermail/freebsd-questions/2014-January/255579.html
https://lists.freebsd.org/pipermail/svn-src-head/2015-March/068934.html
https://reviews.freebsd.org/D1835
Unfortunately, these results are unhelpful for two reasons. First, the suggested work around of:
Code:
sysctl net.inet6.ip6.dad_count=0does absolutely nothing on my system. My logs are still flooded with the error message every 3 seconds after changing that kernel value. Second, it seems that the issue those links describe was patched last year, so I may be facing an entirely different problem.
At this point, I'm at my wit's end and am desperate for help. My logs are unreadable (and therefore useless) due to the flood of NS/DAD error messages. I've modified the sysctl variable described above with no success. I've rebooted the server several time without success. And I've Googled and Googled some more for other possible solution (or at least a current description of the underlying problem) without success.
Please help!