Hi Apollon, On Fri, Apr 11, 2014 at 05:37:00PM +0300, Apollon Oikonomopoulos wrote: > Hi, > > While experimenting with counters in a dual-stack setup, I noticed that > src_inc_gpc0 does not seem to work for IPv4 clients looked up against > type ipv6 stick-tables. The following configuration: > > global > log 127.0.0.1 local0 > user haproxy > group haproxy > stats socket /var/run/haproxy.sock user root group root level admin > > frontend test > mode http > bind 127.0.0.1:8888 > bind ::1:8888 > stick-table type ipv6 size 1k expire 1h store gpc0,http_req_rate(5m) > tcp-request connection track-sc0 src > redirect prefix http://example.com if { src_inc_gpc0 ge 0 } > > with a 1.5-dev22 instance and the following scenario: > > $ for i in {1..4}; do curl -6 http://localhost:8888/; done > $ for i in {1..4}; do curl -4 http://localhost:8888/; done > > yields these results: > > $ echo show table test | sudo socat STDIO /var/run/haproxy.sock > # table: test, type: ipv6, size:1024, used:2 > 0x17efd50: key=::1 use=0 exp=3596869 gpc0=4 http_req_rate(300000)=4 > 0x17effb0: key=::ffff:127.0.0.1 use=0 exp=3598516 gpc0=0 > http_req_rate(300000)=4 > > Notice that while the http_req_rate is properly calculated in both cases, gpc0 > is not incremented for the mapped IPv4 client. Using sc0_inc_gpc0 on the > other hand works as expected. > > Any ideas?
Yes, I just checked and found that src_* use addr_to_stktable_key() which only returns a pointer to the original address based on its family and does not consider the table's type to perform a conversion. We'd need to extend the function to support an output key type to provide a matching result. Regards, Willy
