[LARTC] neighbor table overflow

[Alexandru Dragoi]

Marco C. Coelho wrote:
>
> the ip route with a grep for link returns:
>
> snip** too long
> 64.202.227.198 dev ppp436  proto kernel  scope link  src 10.20.1.1
> 64.202.227.196 dev ppp421  proto kernel  scope link  src 10.20.1.1
> 64.202.227.197 dev ppp211  proto kernel  scope link  src 10.20.0.1
> 64.202.227.194 dev ppp13  proto kernel  scope link  src 10.20.1.1
> 64.202.227.192 dev ppp404  proto kernel  scope link  src 10.20.1.1
> 64.202.227.254 dev ppp194  proto kernel  scope link  src 10.20.1.1
> 64.202.227.253 dev ppp130  proto kernel  scope link  src 10.20.1.1
> 64.202.227.252 dev ppp243  proto kernel  scope link  src 10.20.1.1
> 64.202.227.249 dev ppp195  proto kernel  scope link  src 10.20.1.1
> 64.202.227.248 dev ppp254  proto kernel  scope link  src 10.20.1.1
> 64.202.227.247 dev ppp235  proto kernel  scope link  src 10.20.1.1
> 64.202.227.242 dev ppp78  proto kernel  scope link  src 10.20.1.1
> 64.202.227.240 dev ppp328  proto kernel  scope link  src 10.20.1.1
> 64.202.227.237 dev ppp44  proto kernel  scope link  src 10.20.1.1
> 64.202.227.236 dev ppp122  proto kernel  scope link  src 10.20.1.1
> 64.202.227.234 dev ppp316  proto kernel  scope link  src 10.20.1.1
> 64.202.227.232 dev ppp132  proto kernel  scope link  src 10.20.1.1
> 64.202.227.231 dev ppp104  proto kernel  scope link  src 10.20.0.1
> 64.202.227.226 dev ppp179  proto kernel  scope link  src 10.20.0.1
> 64.202.224.0/24 dev eth0  proto kernel  scope link  src 64.202.224.8
> 192.168.1.0/24 dev eth3  proto kernel  scope link  src 192.168.1.8
> 169.254.0.0/16 dev eth3  scope link

The one above must be deleted, many redhat-like distros attach
169.254.0.0/16.
>
> All the pppoe terminations (pppd) are shown, as well as the last three
> subnets.  I'll have to see where the 169.254.0.0/16 is coming from?
>
> mc
>
>
>
>
> Alexandru Dragoi wrote:
>> 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 at mailman.ds9a.nl
>>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>>
>>>>       
>>> _______________________________________________
>>> LARTC mailing list
>>> LARTC at mailman.ds9a.nl
>>> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>>>     
>>
>>
>>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> LARTC mailing list
> LARTC at mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>