Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Aug 2000 18:42:43 -0700
From:      Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To:        Jim C <jim@carroll.com>
Cc:        Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, freebsd-stable@FreeBSD.ORG
Subject:   Re: ipnat fails under load 
Message-ID:  <200008290142.e7T1gmo17318@cwsys.cwsent.com>
In-Reply-To: Your message of "Mon, 28 Aug 2000 09:39:33 EDT." <39AA6B95.AC60A031@carroll.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <39AA6B95.AC60A031@carroll.com>, Jim C writes:
> This is a multi-part message in MIME format.
> --------------973EB21760BF1973F199A04D
> Content-Type: text/plain; charset=iso-8859-15
> Content-Transfer-Encoding: 7bit
> 
> Cy Schubert - ITSD Open Systems Group wrote:
> > 
> > In message <Pine.BSF.4.21.0008252052260.3518-100000@fatbastard.zialink.c
> > om>, tu
> > cka writes:
> > > You can add me to the list of people who have problems with ipfilter
> > > under load. 
> > 
> > What's your configuration?  Could you list your IPF and NAT rules?
> > 
> > Next time you have a "freeze", issue ipfstat -s and ipfstat -sl.  If
> > you're using statefull filtering, could it be that your state table has
> > filled.
> 
> I suspect this is in fact the case.  Here's my thinking.
> 
> ipnat runs flawlessly for a time.  Usually this time is at least several
> days, often it is several weeks.  Without warning (no log messages or
> errors on the console), it will begin "re-using" old nat entries.
> 
> What I mean by re-using, is that rather then create a new outbound
> connection (ie: begin w/ SYN) when a client session calls for it, it
> sends an ACK message to the destination (as though the session were a
> continuation).  The remote site has no record of a current session, and
> sends back RST messages.
> 
> My theory is that ipnat thinks it has run out of table entries, and
> begins re-using slots, but does NOT correctly re-initialize the slot
> before using it.  Here is our configuration:
> 
> # uname -a
> FreeBSD core1.hck.carroll.com 3.4-STABLE FreeBSD 3.4-STABLE #1: Fri May
> 19 12:33:18 EDT 2000    
> jim@core1.hck.carroll.com:/usr/src/sys/compile/ROUTER  i386
> 
> # cat /etc/rc.local
> /usr/sbin/ipnat -CF
> /usr/sbin/ipnat -f /etc/rc.nat
> 
> # cat /etc/rc.nat
> map de0 10.0.0.0/8 -> 0/32 portmap tcp/udp 1025:65000

No IPF rules, just NAT rules.

Try adding after your existing NAT rule:

map de0 10.0.0.0/8 -> 0/32

FreeBSD 3.4 came with IPF 3.3.8 (or 7).  Darren has made a number of 
tweaks to the state code and NAT code.  You might want to see if IPF 
3.4.9 + the NAT patch posted last week or IPF 3.3.18 might help or ask 
this question on the IP Filter mailing list.


Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
Team Leader, Sun/DEC Team   Internet:  Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008290142.e7T1gmo17318>