"Not enough resources" message

Hi,
We have a network sitting behind an Iptables firewall. The gateway
firewall is running on RH 8.0 with kernel 2.4-20. We have a problem
that we never get any DNS name resolution in less than two tries. We
have observed the following messages in our /var/log/messages. Is it
someway related with the our DNS hassle?
.............................
Apr 21 17:07:44 kernel: NET: 1167 messages suppressed.
Apr 21 17:07:44 kernel: Neighbour table overflow.
Apr 21 17:07:49 kernel: NET: 1084 messages suppressed.
Apr 21 17:07:49 kernel: Neighbour table overflow.
Apr 21 17:07:54 kernel: NET: 872 messages suppressed.
Apr 21 17:07:54 kernel: Neighbour table overflow.
Apr 21 17:07:55 named[587]: client 68.142.251.133#51902: error sending
response: not enough free resources
Apr 21 17:07:57 named[587]: client 68.142.251.133#50982: error sending
response: not enough free resources
Apr 21 17:07:59 kernel: NET: 1108 messages suppressed.
Apr 21 17:07:59 kernel: Neighbour table overflow.
...................
Any pointers shall be appreciated.
Thanks in advance
Gaur

(E-Mail Removed) wrote:
> Hi,
> We have a network sitting behind an Iptables firewall. The gateway
> firewall is running on RH 8.0 with kernel 2.4-20. We have a problem
> that we never get any DNS name resolution in less than two tries. We
> have observed the following messages in our /var/log/messages. Is it
> someway related with the our DNS hassle?
> ............................
> Apr 21 17:07:44 kernel: NET: 1167 messages suppressed.
> Apr 21 17:07:44 kernel: Neighbour table overflow.
> Apr 21 17:07:49 kernel: NET: 1084 messages suppressed.
> Apr 21 17:07:49 kernel: Neighbour table overflow.
> Apr 21 17:07:54 kernel: NET: 872 messages suppressed.
> Apr 21 17:07:54 kernel: Neighbour table overflow.
> Apr 21 17:07:55 named[587]: client 68.142.251.133#51902: error sending
> response: not enough free resources
> Apr 21 17:07:57 named[587]: client 68.142.251.133#50982: error sending
> response: not enough free resources
> Apr 21 17:07:59 kernel: NET: 1108 messages suppressed.
> Apr 21 17:07:59 kernel: Neighbour table overflow.
> ..................
> Any pointers shall be appreciated.
> Thanks in advance
> Gaur

We had similar problems on some of our firewalls.

There are 2 possible points to have a closer look :

1. the size of the connectiontraking table is too small

check current setting (our firewalls have a "default" of 65528, depends on RAM)
cat /proc/sys/net/ipv4/ip_conntrack_max
and check the current size
cat /proc/net/ip_conntrack | wc -l

if the current size is almost equal to the maximum setting increase by factor of
about 4
echo 262140 >/proc/sys/net/ipv4/ip_conntrack_max

_or_

2. Increase the size of the arp tables !

echo 1024 >/proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 4096 >/proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 8192 >/proc/sys/net/ipv4/neigh/default/gc_thresh3
# (defaults 128 512 1024)

You might add entries to /etc/rc.local or adjust /etc/sysctl.conf to set the
correct parameters.

I think the first solution solved the "Neighbour table overflow" problem.

Bye,
Lothar

On 21 Apr 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, (E-Mail Removed) wrote:

>We have a network sitting behind an Iptables firewall. The gateway
>firewall is running on RH 8.0 with kernel 2.4-20.

The last kernel errata for Red Hat 8.0 was 2.4.20-30.8.legacy from February
2004 - about two months before even legacy support ended. You really should
be using something more modern.

>We have observed the following messages in our /var/log/messages. Is it
>someway related with the our DNS hassle?

Could be - what does /sbin/arp -a show? "Neighbour table overflow"
means that your arp table is getting saturated. This _could_ also
relate to a loopback problem. Also look at the routing table. Are you
trying to support a dense network locally (meaning more that a thousand
hosts or so)? If you've got the kernel source installed, look in
'/path/to/kernel/source/net/ipv4/route.c' for the limits you set.

Old guy

On Fri, 21 Apr 2006 04:23:33 -0700, gaurms wrote:

> Hi,
> We have a network sitting behind an Iptables firewall. The gateway
> firewall is running on RH 8.0 with kernel 2.4-20. We have a problem that
> we never get any DNS name resolution in less than two tries. We have
> observed the following messages in our /var/log/messages. Is it someway
> related with the our DNS hassle? ............................
> Apr 21 17:07:44 kernel: NET: 1167 messages suppressed. Apr 21 17:07:44
> kernel: Neighbour table overflow. Apr 21 17:07:49 kernel: NET: 1084
> messages suppressed. Apr 21 17:07:49 kernel: Neighbour table overflow. Apr
> 21 17:07:54 kernel: NET: 872 messages suppressed. Apr 21 17:07:54 kernel:
> Neighbour table overflow. Apr 21 17:07:55 named[587]: client
> 68.142.251.133#51902: error sending response: not enough free resources
> Apr 21 17:07:57 named[587]: client 68.142.251.133#50982: error sending
> response: not enough free resources
> Apr 21 17:07:59 kernel: NET: 1108 messages suppressed. Apr 21 17:07:59
> kernel: Neighbour table overflow. ..................
> Any pointers shall be appreciated.
> Thanks in advance
> Gaur

Hello.

1) RH 8.0 is an Old system. Nothing being perfect on this earth, there are
bugs on this software. And there are some of these bugs without patches...

Ref :
http://secunia.com/product/447/

2) RH 8 being a "general purpose OS", a lot of service are provided.
Fine if all such services are disabled.
But I could still recommend using a specialized firewall distributions.
I list a few here. I recommend none more than the other.
You choose according to your own selection factors...

Refs :

Redwall :
http://www.redwall-firewall.com/

MoonWall :
http://www.m0n0.ch/wall/

Smoothwall :
http://smoothwall.org/

IPCop :
http://www.ipcop.org/


Hope it help...

Lothar Roth wrote:
> (E-Mail Removed) wrote:
> > Hi,
> > We have a network sitting behind an Iptables firewall. The gateway
> > firewall is running on RH 8.0 with kernel 2.4-20. We have a problem
> > that we never get any DNS name resolution in less than two tries. We
> > have observed the following messages in our /var/log/messages. Is it
> > someway related with the our DNS hassle?
> > ............................
> > Apr 21 17:07:44 kernel: NET: 1167 messages suppressed.
> > Apr 21 17:07:44 kernel: Neighbour table overflow.
> > Apr 21 17:07:49 kernel: NET: 1084 messages suppressed.
> > Apr 21 17:07:49 kernel: Neighbour table overflow.
> > Apr 21 17:07:54 kernel: NET: 872 messages suppressed.
> > Apr 21 17:07:54 kernel: Neighbour table overflow.
> > Apr 21 17:07:55 named[587]: client 68.142.251.133#51902: error sending
> > response: not enough free resources
> > Apr 21 17:07:57 named[587]: client 68.142.251.133#50982: error sending
> > response: not enough free resources
> > Apr 21 17:07:59 kernel: NET: 1108 messages suppressed.
> > Apr 21 17:07:59 kernel: Neighbour table overflow.
> > ..................
> > Any pointers shall be appreciated.
> > Thanks in advance
> > Gaur
>
> We had similar problems on some of our firewalls.
>
> There are 2 possible points to have a closer look :
>
> 1. the size of the connectiontraking table is too small
>
> check current setting (our firewalls have a "default" of 65528, depends on RAM)
> cat /proc/sys/net/ipv4/ip_conntrack_max
> and check the current size
> cat /proc/net/ip_conntrack | wc -l
>
> if the current size is almost equal to the maximum setting increase by factor of
> about 4
> echo 262140 >/proc/sys/net/ipv4/ip_conntrack_max
>
> _or_
>
> 2. Increase the size of the arp tables !
>
> echo 1024 >/proc/sys/net/ipv4/neigh/default/gc_thresh1
> echo 4096 >/proc/sys/net/ipv4/neigh/default/gc_thresh2
> echo 8192 >/proc/sys/net/ipv4/neigh/default/gc_thresh3
> # (defaults 128 512 1024)
>
> You might add entries to /etc/rc.local or adjust /etc/sysctl.conf to set the
> correct parameters.
>
> I think the first solution solved the "Neighbour table overflow" problem.
>
> Bye,
> Lothar
Many thanks,
No more messages about neighbour overflows. Now observing and trying to
access the slow dns problem affects by these changes.
Karmath