Mike Silbersack recently announced a plan to change the FreeBSD default ephemeral port range from 1024-5000 to 49152-65535. A debate on the usefulness of this change followed. During that debate, Mike explained:
"The ephemeral port range determines the maximum number of simultaneous outbound connections that you can have. As pointed out in a PR (I don't recall the # offhand), our low limit was probably the reason that FreeBSD ran out of steam before the other OSes in the sysadmin benchmark last year."
This greatly increases the outgoing pool, from 3,976 ports to 16,383 ports. You can find information on changing the ephemeral port range in FreeBSD here (allowing you to locally revert the upcoming change if it causes you problems). The same document provides instructions for Linux, OpenBSD, Solaris, Windows and many other operating systems, too.
From: Mike Silbersack
To: stable AT FreeBSD.ORG
Subject: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 21:16:54 -0600 (CST)
FYI, I will be changing the ephemeral port range from 1024-5000 to
49152-65535 later this week on -stable. (The change was committed to
current a week or two ago now.)
99.9% percent of people should not notice the change, and need not worry
about it; 49152-65535 is the RFC sanctioned ephemeral port range, and is
already used by NetBSD, Solaris, MacOS X, and others.
The only case in which you may have to take action is when you have
configured a firewall such that you are allowing packets from [1024-5000]
and denying others. In that case, you will have to instead allow
[49152-65535] after upgrading. If you have a firewall setup which uses
nat or simply allows all outgoing connections, you should not be affected,
and need not worry.
Thanks,
Mike "Silby" Silbersack
From: Jacques A. Vidrine
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 15:48:40 -0600
Mike,
Please do not change this setting in -STABLE. Was this discussed
elsewhere?
I am strongly against a change that would cause existing machines to
suddenly start using a different port range during a -STABLE upgrade.
Cheers,
--
Jacques A. Vidrine
From: Mike Silbersack
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 22:00:27 -0600 (CST)
Yes, I asked on -net. All I heard was that other OSes have already made
the switch, nothing negative. If this really is going to cause problems,
it's better that we find out now rather than wait until 4.6-release. (I
don't believe it will cause problems, in any case.)
Mike "Silby" Silbersack
From: Jacques A. Vidrine
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 16:10:56 -0600
On Wed, Apr 03, 2002 at 10:00:27PM -0600, Mike Silbersack wrote:
> Yes, I asked on -net. All I heard was that other OSes have already made
> the switch, nothing negative.
I don't disagree with the change itself. I actually very often
twiddle the port range for specific applications using the
IP_PORTRANGE socket option, or for an entire system using the
net.inet.ip.portrange sysctls.
> If this really is going to cause problems,
> it's better that we find out now rather than wait until 4.6-release. (I
> don't believe it will cause problems, in any case.)
I disagree. Some people running -STABLE will be behind firewalls
which they don't administrate. After updating one day [1], they may
suddenly have network applications failing in strange ways. For some
people, it will be very hard to track down the problem.
Why do you feel you must change this in the -STABLE branch? What
benefit is it to the users of -STABLE?
I don't object outright to merging the change during 4.6-RELEASE code
slush, although I think that it is a gratuitous change for a minor
release bump.
Cheers,
--
Jacques A. Vidrine
From: Mike Silbersack
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 22:31:20 -0600 (CST)
On Wed, 3 Apr 2002, Jacques A. Vidrine wrote:
> I disagree. Some people running -STABLE will be behind firewalls
> which they don't administrate. After updating one day [1], they may
> suddenly have network applications failing in strange ways. For some
> people, it will be very hard to track down the problem.
Far more sweeping changes have been made to -stable in the past. If
someone does experience failing outbound connections, I'm sure they can
re-read UPDATING, ask on a mailing list, or just go back to their previous
kernel until they figure it out.
Actually, I still have to go get permission from Warner to touch
UPDATING. I'll go do that now.
Mike "Silby" Silbersack
From: Jacques A. Vidrine
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 16:35:55 -0600
Of course. But this particular change is gratuitous. Do not merge it
to -STABLE, please. Instead, wait for 4.6. What's the hurry?
--
Jacques A. Vidrine
From: Mike Silbersack
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 22:53:25 -0600 (CST)
As we have a RELENG_4_5 branch, I see no reason that I should hold off on
the change. It's mostly unimportant, not gratuitous.
Mike "Silby" Silbersack
From: Garance A Drosihn
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 19:57:08 -0500
At 10:53 PM -0600 4/3/02, Mike Silbersack wrote:
>As we have a RELENG_4_5 branch, I see no reason that I should
>hold off on the change. It's mostly unimportant, not gratuitous.
I agree that if this change is going to go into stable at all,
then now is probably as good a time as any.
What I don't see is why this must be made to -stable at all.
What would be the consequences if we simply left RELENG_4
with the same port-range that it's always had? Note that
this is not a complaint on my part, it is only a request for
more information.
In a different message, Mike Silbersack wrote:
>Far more sweeping changes have been made to -stable in the past.
>If someone does experience failing outbound connections, I'm
>sure they can re-read UPDATING, ask on a mailing list, or just
>go back to their previous kernel until they figure it out.
Chances are pretty good that they would not notice any such
problems until after they have done the "installworld" step,
and thus it is not necessarily a simple matter to "just go
back" to their previous kernel.
We have made far more sweeping changes in the past. We had
reasons for doing those changes when we did them. I would
feel a little better about making this change to -stable if
we knew what important (time-critical) issue that it was
fixing.
--
Garance Alistair Drosehn
From: Mike Silbersack
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Thu, 4 Apr 2002 01:07:13 -0600 (CST)
On Wed, 3 Apr 2002, Garance A Drosihn wrote:
> What I don't see is why this must be made to -stable at all.
> What would be the consequences if we simply left RELENG_4
> with the same port-range that it's always had? Note that
> this is not a complaint on my part, it is only a request for
> more information.
The ephemeral port range determines the maximum number of simultaneous
outbound connections that you can have. As pointed out in a PR (I don't
recall the # offhand), our low limit was probably the reason that FreeBSD
ran out of steam before the other OSes in the sysadmin benchmark last
year.
Normally I wouldn't change settings to tune for a benchmark, but there is
no functional downside to this change. As Jacques points out, many
sysadmins with busy servers _already_ make this change, as have a few
other OSes.
> Chances are pretty good that they would not notice any such
> problems until after they have done the "installworld" step,
> and thus it is not necessarily a simple matter to "just go
> back" to their previous kernel.
Sure it is. After an installkernel you always have kernel.old sitting
around.
This isn't a big deal, guys. Go find something better to make a fuss
about.
Mike "Silby" Silbersack
From: Jacques A. Vidrine
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Wed, 3 Apr 2002 19:18:07 -0600
On Thu, Apr 04, 2002 at 01:07:13AM -0600, Mike Silbersack wrote:
> The ephemeral port range determines the maximum number of simultaneous
> outbound connections that you can have. As pointed out in a PR (I don't
> recall the # offhand), our low limit was probably the reason that FreeBSD
> ran out of steam before the other OSes in the sysadmin benchmark last
> year.
This falls in the same category as any other system tuning for
questionable benchmarks. It is certainly not a compelling reason to
break things.
> Normally I wouldn't change settings to tune for a benchmark, but there is
> no functional downside to this change. As Jacques points out, many
> sysadmins with busy servers _already_ make this change, as have a few
> other OSes.
And it is a good change --- for a new operating system release.
> Sure it is. After an installkernel you always have kernel.old sitting
> around.
You don't need the old kernel, anyway. You can just use the sysctl
knobs.
> This isn't a big deal, guys. Go find something better to make a fuss
> about.
Thanks for your consideration,
--
Jacques A. Vidrine
From: Brandon S. Allbery
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: 04 Apr 2002 00:28:20 -0500
On Wed, 2002-04-03 at 20:18, Jacques A. Vidrine wrote:
> This falls in the same category as any other system tuning for
> questionable benchmarks. It is certainly not a compelling reason to
> break things.
So, how many other -stable users already change this via sysctl because
the default is too low? I do; and the default seems ridiculously low to
me.
> And it is a good change --- for a new operating system release.
The idea of deferring a change like this to the next release instead of
letting it get some testing first seems Bad to me.
--
brandon s allbery
On Wed, Apr 03, 2002 at 10:53:25PM -0600, Mike Silbersack wrote:
> As we have a RELENG_4_5 branch, I see no reason that I should hold off on
> the change. It's mostly unimportant, not gratuitous.
Well, Mike, I don't think I can put it more strongly. If you are
insistent about making this change, I cannot stop you. I wish you
would not.
If it is not gratuitous, pray tell what benefit this change will
bring. It will certainly snag a minority of folks, and that makes it
a bad idea as far as I am concerned.
On Wed, Apr 03, 2002 at 04:09:56PM -0800, Michael Sierchio wrote:
> It isn't stable -- gratuitously updating on
> a weekly or daily basis is for hobbyists. It's known to break things now
> and then.
We try very hard _not_ to break things. We break things only when
there is a compelling reason to break them. Not because we just feel
like it.
> The idea of holding pending MFCs until we're in RC stage is far worse.
As I implied in an earlier message, I would prefer that it never be
merged to 4.x.
> If you're interested in stability, you'll track RELENG_4_5, as Mike
> suggests.
I don't track RELENG_4_5. I _maintain_ the RELENG_4_5 and other
security branches.
On Wed, Apr 03, 2002 at 07:57:08PM -0500, Garance A Drosihn wrote:
> Chances are pretty good that they would not notice any such
> problems until after they have done the "installworld" step,
> and thus it is not necessarily a simple matter to "just go
> back" to their previous kernel.
Yes, it is worse. It probably will not happen until the run
application X --- perhaps an ICQ client, or an FTP server, or
whatever. It will fail, and for some people it will cost time to
determine the cause and to repair it. This is not /so/ bad for
someone tracking -STABLE, except that the whole problem can and should
be avoided.
> I would
> feel a little better about making this change to -stable if
> we knew what important (time-critical) issue that it was
> fixing.
BSD has used the low range ports ``forever''. There is absolutely no
time-critical reason to change the default now.
I don't think I'll be posting on the issue again, as the length of the
thread will soon be disproportionate to the subject's importance, if
it isn't already. :-)
Cheers,
--
Jacques A. Vidrine
From: Lamont Granquist
Subject: Re: Heads up, a bit: ephemeral port range changes
Date: Thu, 4 Apr 2002 01:10:44 -0800 (PST)
On Wed, 3 Apr 2002, Jacques A. Vidrine wrote:
> If it is not gratuitous, pray tell what benefit this change will
> bring. It will certainly snag a minority of folks, and that makes it
> a bad idea as far as I am concerned.
Well, I may be a bit grumpy tonight, but anyone who gets snagged by this
is being pretty stupid. If you're writing firewall rules you should
expect ephemeral ports to be anywhere between 1024-65535. If you're
tweaking for specific OS implementations then you should expect to have
to retest and retweak when you make OS upgrades.
Meanwhile, it should help the less clueful people who don't know anything
about ephemeral portranges run their benchmarks *and* their applications.
I've run into portrange limitations with production applications numerous
times and had to tweak these settings. I expect that my experience is not
unique.
> We try very hard _not_ to break things. We break things only when
> there is a compelling reason to break them. Not because we just feel
> like it.
I think that overall on the balance sheet this is fixing something, not
breaking it. And it brings FreeBSD into compliance with standards.
> As I implied in an earlier message, I would prefer that it never be
> merged to 4.x.
Putting on my System Engineer hat and looking at this from a very
conservative IT perspective I don't see what the big deal is. If you're
that paranoid about stability you should run any new OS candidate through
a battery of qualification tests to weed out problems like this.
The ATA merge is much more problematic from a system stability
perspective.
> Yes, it is worse. It probably will not happen until the run
> application X --- perhaps an ICQ client, or an FTP server, or
> whatever. It will fail, and for some people it will cost time to
> determine the cause and to repair it. This is not /so/ bad for
> someone tracking -STABLE, except that the whole problem can and should
> be avoided.
Yes, but it prevents someone filling up all 4000 ephemeral ports with
sockets stuck in TIME_WAIT and having to troubleshoot and futz with
reassigning these defaults themselves. That seems like the right
problem to be avoiding rather than trying to work around firewall admins
who either don't know what they're doing or who have too much free time
on their hands.
> BSD has used the low range ports ``forever''. There is absolutely no
> time-critical reason to change the default now.
I consider the current portrange broken. I consider anyone bit by
changing the current portrange to themselves be broken. Seems like a fine
change for "-STABLE" to me.
> I don't think I'll be posting on the issue again, as the length of the
> thread will soon be disproportionate to the subject's importance, if
> it isn't already. :-)
Yeah, agreed.