Re: neighbor table overflow | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
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@xxxxxxxxxxxxxxx >> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >> > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc