[
https://issues.apache.org/jira/browse/TS-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285842#comment-13285842
]
B Wyatt commented on TS-1075:
-----------------------------
Can you describe the routing set up you have that requires the 2 streams to
have separate network devices? The one-wire/interface test case I had, had no
problems routing this with a very naive set up. Iptables and the kernel were
able to properly distinguish the 5-tuple because for a given source/dest order
packets were either INGRESS or EGRESS, not both. I did run into issues when
directly attached to a NAT'ing router as the stateful connection tracking saw
both sides of the connection, but frankly if you have a next-hop stateful
firewall, its port limit will be the bottleneck in a TPROXY environment that
has port-space per intercepted IP.
I am not opposed to rolling a random solution, but even that solution will have
port collisions at the network level as there is no way to guarantee the random
port TS will pick will not be the next port the client uses. Practically, it
would be a low chance error, but at the connection counts needed to exercise
this issue you would probably see it.
My preference is for regular but distinct ports rather than random to avoid
accidental local collisions in the port space for a given transparent IP (TS
handles ::bind failures on ::connect, but it will count it against your
connection retries and ultimately the OS for congestion handling). For
instance rotating the client port number by N so that you always get the same
proxy port for a given client port.
Thoughts?
> 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
