Re: [LARTC] neighbor table overflow

["Marco C. Coelho" <maillist1@argontech.net>]

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

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