[
https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273963#comment-13273963
]
Danny Shporer commented on TS-1075:
-----------------------------------
Thank you for handling this issue. I appreciate the thorough and professional
approach.
I have a comment regarding the 2nd workaround:
Since the 5-tuples are identical in both the client stream and OS stream, those
2 streams would have to come in to the Trafficserver box on separate network
devices and be routed by the kernal (Iptables in Linux case) to different ports
on the local device for Trafficserver to open sockets on. This requires that
the 2 streams be completely separated in the organization network
infrastructure. This is not always the case in real life deployments.
I think using a random source port for the OS stream in order to make the
5-tuples different will make deployment much easier. I do agree that
gettimeofday is not a cheap way to achieve this and there are probably cheaper
ways.
> 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
