TCP time_wait and port exhaustion for servers
marka at isc.org
Wed Dec 5 22:39:29 UTC 2012
Mark Andrews writes:
> In message <CAP-guGVSMXgt-xhnqC191-Mfh2-W38Gg5mZf1MegCgwObVKK-Q at mail.gmail.com
> William Herrin writes:
> > On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews <marka at isc.org> wrote:
> > > In message <CAP-guGW6oXo=UfTfg+SDiFjB4=qxPShO+YfK6vxnLkCC58PvgQ at mail.gmail
> > om>,
> > > William Herrin writes:
> > >> The thing is, Linux doesn't behave quite that way.
> > >>
> > >> If you do an anonymous connect(), that is you socket() and then
> > >> connect() without a bind() in the middle, then the limit applies *per
> > >> destination IP:port pair*. So, you should be able to do 30,000
> > >> connections to 192.168.1.1 port 80, another 30,000 connections to
> > >> 192.168.1.2 port 80, and so on.
> > >
> > > The socket api is missing a bind + connect call which restricts the
> > > source address when making the connect. This is needed when you
> > > are required to use a fixed source address.
> > Hi Mark,
> > There are ways around this problem in Linux. For example you can mark
> > a packet with iptables based on the uid of the process which created
> > it and then you can NAT the source address based on the mark. Little
> > messy but the tools are there.
> And not available to the ordinary user. Nameservers potentially run
> into this limit. This is something The OpenGroup need to address when
> updating the next revision of the socket api in POSIX.
Even a "LATEBINDPORT" setsockopt call would do so that bind() on
ties down the source address not the source address and port.
> > Anyway, Ray didn't indicate that he needed a fixed source address
> > other than the one the machine would ordinarily choose for itself.
> But he didn't say it wasn't required either.
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG