New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Will rush off to edit /var/log/dmesg, they will be gone shortly
@miTgiB yeah, works that way too ;-) If nobody noticed - it didn't happen ;-)
Follows the same patterns as security through obscurity
I am getting "Neighbour table overflow" disconnections/logs filled with more and more LEB providers lately too. I am not sure if this is connected with issue above however adding/editing next values to sysctl.conf (/etc/sysctl.conf) in my case seems to solved those issues:
sysctl -p (to reload new values)
grep . /proc/sys/net/ipv6/neigh/default/gc_thresh* (to check old/new values)
Sure looks connected, I based my adjustment off this post http://www.vyatta.org/forum/viewtopic.php?p=53428
Not seeing any issues since adjusting
net.ipv4.neigh.default.gc_thresh3 = 8192
But actually making the adjustment from the Vyatta config.
Are you making those adjustments on a Xen/KVM system? I don't see how you could on OpenVZ, and still wonder how effective it would be on a bridged container if you are dropping an arp entry on the gateway.
You're correct. It was Evorack xen and Edis (IPv6 interruptions only) KVM. Evorack confirmed this issue and solution above solved it.
@Spirit so why are you scanning their entire network? ;-) Such an error would appear if you have large network routed directly to eth0 (connected) and you try to ping many different IPs from this connected network.
Issue was mass mailed and solution suggested by one of my hosts (evorack). I don't actually care for background but I appreciated Evorack solution I shared above.
@Spirit just kidding, don't get offended, please
And for those who want to see "Neighbor table overflow" on their own KVM/Xen VPS - here is an easy way to reproduce it:
ip r a 10.0.0.0/8 dev eth0
nmap -sP 10.0.0.0/8
Then check in dmesg
Experience huge packet loss for now, 60% based on 5 pings with lg.he.net and, on my PC:
Packets: Sent = 94, Received = 63, Lost = 31 (32% loss),
Improved now, tag removed
well mine doesn't report anymore dropouts after tim fixed the arp table (from above) or something else.
Your post time lines up with a DDoS that came in and from the look of my graph, lasted about 10-15 minutes, does this sound about right with your experience?
Increasing the arp table size limit is the last adjustment I've made. A few that have been plagued with the issue have all reported success, as you have here. So back to growing so we can see how to break the network in a new way
It's been much better lately. Had a few network disruptions today, but before that had about 3 good days without network problems.
I have XEN VPS from Prometeus and I see "ipv6: Neighbour table overflow" message many times on dmesg log but I can't see same message my another KVM based server from same provider.
@Maounique @Prometeus
So, submit a ticket? Why post in this year-old thread?
Maybe other people have same problem. I have already posted ticket (770898) and Prometeus suggest adjust /etc/sysctl.conf with following values:
Yeah but why post here?