HAProxy 1.5-dev7 attempting to connect to real server port of twice virtual server port

From: Nick Chalk <nick#loadbalancer.org>
Date: Wed, 21 Sep 2011 16:30:05 +0100

Afternoon all.

We have come across an interesting problem with HAProxy 1.5-dev7: with the config below, the proxy attempts to connect to a real server port of twice the virtual server's port.

listen v1

	mode http
	balance leastconn
	server backup backup
	option httpclose
	option redispatch
	option abortonclose
	maxconn 40000
	log global
	option httplog
	server r41  weight 1  check port 80  inter 2000  rise 2
 fall 3 minconn 0 maxconn 0

In this example, the client's requests to are forwarded to

A bit of digging in the source has led to the assign_server_address() function in backend.c, in particular the following section:

                 if (target_srv(&s->target)->state & SRV_MAPPORTS) {
                        int base_port;

                        if (!(s->be->options & PR_O_TRANSP) &&
!(s->flags & SN_FRT_ADDR_SET))

/* First, retrieve the port from the incoming
connection */ base_port = get_host_port(&s->req->prod->addr.c.to);
/* Second, assign the outgoing connection's port */
base_port += get_host_port(&s->req->prod->addr.s.to); set_host_port(&s->req->cons->addr.s.to, base_port); }

cfg_parse_listen() appears to set the SRV_MAPPORTS flag, as there is no destination port specified in the server directive. The proxy therefore uses the port from s->req->prod->addr.c.to plus s->req->prod->addr.s.to. With the configuration above, both of these structure elements have the value 80, resulting in a destination port of 160.

At that point, I hit a dead end in my understanding of the code. It would appear that either s->req->prod->addr.c.to or s->req->prod->addr.s.to are holding the wrong port value, or one of these structures is being used incorrectly in the sum.

Any pointers for further investigation would be appreciated.


Nick Chalk.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
Received on 2011/09/21 17:30

This archive was generated by hypermail 2.2.0 : 2011/09/21 17:45 CEST