Re: [LARTC] neighbor table overflow

[Alexandru Dragoi <alex@zoomnet.ro>]

Marco C. Coelho wrote:
>
> This box is doing a lot.  It terminates 1000 PPPoE connections,
> provides traffic shaping using TC/HTB, authenticates all users via
> Radius.  It also runs OSPF routing for the internal network.  Looking
> at a simple route output I see all the PPP connections coming through
> the box, and due to the OSPF I also see the rest of my network
> announcements.  The only strange things are:
>
> 1.  The last man working on this box had mistakenly edited the hosts
> file and added the machine name and complete domain name to the local
> host 127.0.0.1 name.  It should only be pointed to the eth0
> interface.   I have changed this.
>
> 2.  The route output is making an announcement
>
>    64.0.0.0        argontech.net   255.0.0.0       UG    20    
> 0        0 eth0

This doesn't look dangerous for your problem, I was only talking about
directly connected networks:

# ip route |grep link

>
> My public IP space is a /20 within that space, not the whole Class A. 
> I have not found which box is announcing this within my network yet.
>
>
>
>
>
> Jeff Welling wrote:
>>
>>> On 10/23/07 06:56, Alexandru Dragoi wrote:
>>>> What about checking your routing table? you may have link routes
>>>> for massive subnets (like 85.0.0.0/8 or 140.20.0.0/16). Some
>>>> programs prefer to use "standard" netmask of classes A and B.
>>>
>>> I'm betting that the OP has other things going on seeing has how
>>> s/he mentioned PPPoE, which to my knowledge is a layer 2 protocol,
>>> and thus not subject to typical routing scenarios.  In essence the
>>> OP could have thousands of PPPoE connections terminating on one
>>> system with the ARP cache having to deal with where to send traffic
>>> to which MAC address. There is not a lot of room for routing in such
>>> a scenario.
>>>
>> I agree with Peter's suggestion, arpd.  I ran into the neighbor table
>> overflow problem recently, at the hands of our ISP.  I was in the
>> process of recompiling the kernel and mucking with arpd (I couldn't
>> get it to run/start properly) when the problem disappeared as quickly
>> as it showed up.  Lucky for me, this was some kind of ISP problem, I
>> was able to determine that much through `tcpdump -i X -n arpd`.
>>
>> My 'two cents' is that you try arpd, I did a bit of looking when I
>> came across that problem and it seemed to be the last ditch effort
>> when changing the gc threshold had no effect.  Wasn't able to confirm
>> that it worked for sure though.
>>
>> Cheers.
>> _______________________________________________
>> LARTC mailing list
>> LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc