Re: [LARTC] neighbor table overflow

[Alexandru Dragoi <alex@zoomnet.ro>]

Marco C. Coelho wrote:
> Looking into it further an ip route shows:
>
> 64.0.0.0/8 via 64.202.224.1 dev eth0  proto zebra  metric 20 equalize
This /8 doesn't affect the neighbor table. There must be a problem on
the site that announce it
>
> So the 64.0.0.0 announce is coming into this box through OSPF  (zebra)
>
> The 169.254.0.0/16 is being automajically added through the sysconfig
> network scripts.  I'm looking into why.
>
> In either case I still don't see why these entries would make the
> neighbor table overflow.  Could it have been the previous fix to the
> hosts file?
Well, when somebody try to make traffic with somebody from
169.254.0.0/16 throught you, your server will ask for arp on eth3, and
most probably will record an <incomplete> entry in arp table. Virii and
others can make this worse. Another quick fix is to drop arps from/to
169.254.0.0/16 with arptables.
>
> mc
>
> Alexandru Dragoi wrote:
>> 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@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
>>>   
>>>     
>>
>>
>>   

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