Re: [LARTC] neighbor table overflow

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

[-- Attachment #1.1: Type: text/plain, Size: 4632 bytes --]


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

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
>>     
>
>
>   

[-- Attachment #1.2: Type: text/html, Size: 6012 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

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