[
https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
B Wyatt closed TS-1075.
-----------------------
Resolution: Fixed
Fix Version/s: (was: 3.3.0)
3.1.4
I've added 2 workarounds and opted against an "explicit-random" solution. The
two workarounds are:
proxy.config.cop.source_port [port num] - this configuration allows you to
dictate the _source_ port that cop will bind to before executing its socket
based tests. It defaults to 0 which results in the old behavior of
auto-assigned ports
proxy.config.http.use_client_source_port [0/1] - this configuration allows the
user to dictate whether active connections to origin servers should use the
same port that the incoming client used when contacting the proxy. Like
use_client_target_addr it is only respected in transparent (TPROXY) deployments
where the information is available and the concept makes sense.
NOTE!!! use of the client source port can cause issues with stateful firewalls
on whatever infrastructure is redirecting traffic to a TPROXY Trafficserver as
the client->proxy and proxy->OS connections will be 5-tuple identical.
For solutions that have the quantity of connections necessary for this issue to
manifest, you may have to move stateful firewalls such that they see only one
side of the intercepted traffic and not both.
commit : 9f831282f05cb12bc3332522bfd46c47a4e97c52
commit date: Fri, 11 May 2012 19:14:40 +0000 (14:14 -0500)
> Port range bottleneck in transparent proxy mode
> -----------------------------------------------
>
> Key: TS-1075
> URL: https://issues.apache.org/jira/browse/TS-1075
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.0.1
> Environment: Centos 5.6, kernel 2.6.39.2 compiled with TPROXY support
> ATS compiled as: ./configure --enable-tproxy
> Reporter: Danny Shporer
> Assignee: B Wyatt
> Fix For: 3.1.4
>
> Attachments: ports.patch
>
>
> The Linux TPROXY stack only takes into account the local addresses when using
> dynamic bind (bind without specifying a specific port). This limits the port
> range to only the local range (around 30K by default and can be extended to
> around 64K) - this together with the TIME-WAIT Linux method of releasing
> ports causes a bottleneck).
> One symptom of this is that traffic_cop cannot open a connection to the
> server to monitor it (it gets error 99 - address already in use) and kills
> it.
> Another issue is when opening the connection to the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
