We use http-request set-mark directive to add a mark to inform routing decisions.
But now we’re trying to check backend connections with the following:
But that tcp-check isn’t getting
marked at all (obvious since we mark it using
http-request set-mark) but we can’t seem to find a way to have those checks have the same mark as the requests.
Since without those mark the routing decision is wrong, the backend is always declared as DOWN…which wouldn’t happen if we could properly either mark the connection or have our source IP address set like we asked here:
Is there any way to achieve the Netfilter
mark for TCP checks?
According to the documentation the
http-request set-mark only applies that mark to the client packet, not the server one.
Are you sure that marks work correctly on the server packets?
You’re right: We’re just getting the client-facing con
marked…which doesn’t do what we need.
We need either a
mark or a
tos on the backend-facing conn…which doesn’t seem to be possible using haproxy
Can’t you just use
iptables to mark packets going to a particular destination?
ip rule and route based on the destination IP?)
ip rule can’t be used because the backend has a dynamic DNS entry, so no.
And using iptables seems problematic for the same reason. That’s why I wanted to either
set-tos the outgoing connection using haproxy.
Then it means that the HAProxy is doing a DNS request from time-to-time to resolve the new IP of the server. Therefore you could do the same, namely create a cron-job that tries to resolve the IP and configure
iptables (perhaps via
If you configure the connection timeout of the server long enough, more than the frequency of your “check script”, you won’t loose any requests, just face some “hickups” from time-to-time when the actual IP changes.
However if you depend on the TOS or
set-mark for packets towards the server it means you have a different routing table for those servers. Then can’t you “jump” the traffic from HAProxy to that server based on the source IP of the TCP connection?
For example you could configure source with
<addr> to a particular IP, then move all the packets based on that source address via
ip rule to a different table, and in the end make a SNAT (or
-j masquarade) to “fix” the source IP if needed.