What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

what does this mean?

cmillar6

Senior Member
Just upgraded to a DOCSIS 3.0 compliant modem from Comcast and I am now seeing this repeatedly in my system log, what does it mean?

May 8 20:02:24 kernel: Neighbour table overflow
 
Seems like your router is being exposed to a LOT of hosts. Could be your ISP connecting you to a busy node, and not filtering any of the noise coming from the other clients on the same node.

Google returned this page, which gives a lot of tips on how to troubleshoot it:

http://serverfault.com/questions/36...w-on-linux-hosts-related-to-bridging-and-ipv6

Google also returned this page which shows how the values can be raised:

http://www.zeroshell.org/forum/viewtopic.php?p=11804&sid=38a54a8667070bf1897178f3afd3c3a4
 
well the new modem brought ipv6 and disabling it on the router end eliminated the overflow errors in my system log. I'm struggling to understand the content of the links you provided, tired tonight, will try to apply the patches suggested tomorrow morning and re-enable ipv6.
 
I have been using the "increase gc thresholds in the ipv6 neighbour table" technique and it seems to work. Implementation is putting 3 lines in init-start:

Code:
echo 512 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
echo 1024 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
echo 2048 > /proc/sys/net/ipv6/neigh/default/gc_thresh3

But I wonder whether the "re-enable multicast snooping" is the better solution? The suggested implementation of that is

Code:
echo 1 > /sys/class/net/eth0/bridge/multicast_snooping

but the RT-N66u does not have a /sys/class/net/eth0/bridge directory, so I don't know whether this method is possible.
 
If increasing the three thresholds to these values fixes it, I might make them the new default values in the firmware. Since the lower-end device that I support has 128 MB of RAM, it shouldn't be a problem.
 
I raised the gc thresholds and that cut down on 90% of the errors in the logs. As suggested in the thread Merlin posted I doubled the values again to see if the will go away completely. If they still persist I will try the multicast_snooping, I have an AC66u so I hope it will work.
 
raising the gc thresholds to 512,2048,4096 solved the issue. Can somebody help me make these changes permanent as I lose them upon reboot?
 
I spoke to soon, just got the error after about an hour. I'm disabling ipv6 until I figure this out
 
Are you running any P2P client that might generate a LOT of connections? For some people that was what triggered it.

You could also try increasing all three thresholds on the ipv4 settings in addition to ipv6.
 
the errors go away when ipv6 is disabled so I haven't done anything with ipv4. No P2P clients running, all I did was move a few miles to PA from NJ. Ran ipv6 in New Jersey for a year with no problems.
 
Could be the ISP having a lot of chatter on their IPv6 network then, causing your modem to see a LOT of devices, creating entries for each of them in its arp table.
 
If increasing the three thresholds to these values fixes it, I might make them the new default values in the firmware. Since the lower-end device that I support has 128 MB of RAM, it shouldn't be a problem.
In an attempt to test that changing these values fixes the problem, I commented out the 3 lines from my init-start and rebooted, thus restoring the defaults.

I have not seen any neighbour table overflows in the 19 hours since I rebooted with the default values. So I can't draw a definitive conclusion yet. Perhaps Comcast has cleaned up my local IPv6 "neighbourhood."
 
In an attempt to test that changing these values fixes the problem, I commented out the 3 lines from my init-start and rebooted, thus restoring the defaults.

I have not seen any neighbour table overflows in the 19 hours since I rebooted with the default values. So I can't draw a definitive conclusion yet. Perhaps Comcast has cleaned up my local IPv6 "neighbourhood."

Ok, thanks for the update.

If any of you ever get that error message again, please try the commands listed in one of the two links I posted earlier to get a list of visible neighbours. See if indeed you can see a very long list. In my case, my router doesn't seem to see anyone but my ISP on the ipv4 LAN (and I don't have native IPv6 support to compare).
 
I see a long list even without the overflow warnings.

This shows the list:
Code:
ip -f inet6 route show cache
This shows the count:
Code:
ip -f inet6 route show cache | grep -v cache | wc -l
My result:
Code:
admin@RT-N66U:/tmp/home/root# ip -f inet6 route show cache | grep -v cache | wc -l
[B]648[/B]
Now I don't claim to fully understand all the parameters, but I guess I'm currently not seeing warnings because my 648 IPv6 visible neighbors is less than the default 1024 for the hard maximum of the ARP cache.

(You can use the same command with -f inet to show IPv4 only or with the -f option omitted to show neighbors in both stacks.)
 
I've got my ARP limit set to 4096 and I still see the neighbor table overflow errors
 
I've got my ARP limit set to 4096 and I still see the neighbor table overflow errors

Then you will have to live with it. Your ISP is exposing you to THAT many hosts, which doesn't sound normal to me, and there is little that can be done from your point of view to get rid of those errors.
 
Is this simply a result of IPv6? It makes sense that the number of neighbors would increase by an order of magnitude when everybody's IPv6 devices each has an IP address (as opposed to being hidden behind NAT in a router).
 
Is this simply a result of IPv6? It makes sense that the number of neighbors would increase by an order of magnitude when everybody's IPv6 devices each has an IP address (as opposed to being hidden behind NAT in a router).

I wonder however why a customer's fronting router would be exposed to everyone else. I would expect the ISP to have at least some firewall rules there, otherwise it would lead to some privacy/security issues.

It would be interesting to see if this is the same case with a different ISP.
 
Is this simply a result of IPv6? It makes sense that the number of neighbors would increase by an order of magnitude when everybody's IPv6 devices each has an IP address (as opposed to being hidden behind NAT in a router).


I had ipv6 running for months with the same ISP (Comcast) on my AC66u and never saw the neighbor table overflow errors. I then moved 50 miles to another state (PA) and switched to a different model cable modem and then I started seeing the neighbor table overflow errors. Perhaps it has something to do with the firmware on the modem.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top