Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Hostigation LAX BGP Issues anyone? - Page 3
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.

Hostigation LAX BGP Issues anyone?

13»

Comments

  • @rds100 said: if you get rid of these messages

    Will rush off to edit /var/log/dmesg, they will be gone shortly ;)

    Thanked by 2craigb Maounique
  • @miTgiB yeah, works that way too ;-) If nobody noticed - it didn't happen ;-)

  • @rds100 said: If nobody noticed - it didn't happen

    Follows the same patterns as security through obscurity

  • SpiritSpirit Member
    edited October 2012

    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:

    net.ipv6.neigh.default.gc_thresh1 = 512
    net.ipv6.neigh.default.gc_thresh2 = 2048
    net.ipv6.neigh.default.gc_thresh3 = 4096
    
    # Force gc to clean-up quickly
    net.ipv4.neigh.default.gc_interval = 3600
    
    # Set ARP cache entry timeout
    net.ipv4.neigh.default.gc_stale_time = 3600
    
    # Setup DNS threshold for arp
    net.ipv4.neigh.default.gc_thresh3 = 4096
    net.ipv4.neigh.default.gc_thresh2 = 2048
    net.ipv4.neigh.default.gc_thresh1 = 1024

    sysctl -p (to reload new values)
    grep . /proc/sys/net/ipv6/neigh/default/gc_thresh* (to check old/new values)

    Thanked by 1fan
  • @Spirit said: am not sure if this is connected with issue above

    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.

  • SpiritSpirit Member
    edited October 2012

    @miTgiB said: Are you making those adjustments on a Xen/KVM system?

    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.

  • SpiritSpirit Member
    edited October 2012

    @rds100 said: @Spirit so why are you scanning their entire 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 :)

    Thanked by 1Spirit
  • 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

  • klikliklikli Member
    edited November 2012

    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.

  • @klikli said: Experience huge packet loss for now

    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?

    @cosmicgate said: fixed the arp table (from above) or something else.

    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.

    10/27/2012 01:58:04     00:01:00
    10/31/2012 06:54:46     00:01:21
    11/01/2012 14:01:53     00:05:35
    11/01/2012 14:14:26     00:02:33
  • 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

  • perennateperennate Member, Host Rep

    @tux said:
    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?

  • @perennate said:
    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:

    net.ipv6.neigh.default.gc_thresh1 = 4096
    net.ipv6.neigh.default.gc_thresh2 = 8182
    net.ipv6.neigh.default.gc_thresh3 = 8182
    
  • perennateperennate Member, Host Rep

    Yeah but why post here?

Sign In or Register to comment.