<div dir="ltr">Hi, all,<div><br></div><div>I encounter some problems when using Octavia. After installing octavia with devstack, I create a load balancer named lb1 (VIP: 10.0.1.9, IP of VRRP port: 10.0.1.3) for a subnet (<a href="http://10.0.1.0/24">10.0.1.0/24</a>), then a listener, a pool, and two members. All the resources are created successfully. The two members (VMs) reside in the same subnet, whose IP are 10.0.1.6 and 10.0.1.7, respectively. To simulate a web server in each VM, I run "while true; do echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $VM_IP" | sudo nc -l -p 80;done" to listen on port 80 and return the VM's IP if the request is accepted. I run "sudo ip netns exec qdhcp-XXXX curl -v $VM_IP" to send requests to VMs, the "web servers" in VMs work (already added corresponding security rules to the VMs). Then I tried to run "sudo ip netns exec qdhcp-XXXX curl -v $VIP" to send requests, the VMs do not respond, and finally returns a timeout error.</div><div><br></div><div>The configuration details in local.conf are as follows.</div><div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">[[local|localrc]]</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">DATABASE_PASSWORD=password</font></i></div><div><i><font color="#666666">RABBIT_PASSWORD=password</font></i></div><div><i><font color="#666666">SERVICE_PASSWORD=password</font></i></div><div><i><font color="#666666">SERVICE_TOKEN=password</font></i></div><div><i><font color="#666666">ADMIN_PASSWORD=password</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">HOST_IP=192.168.56.9</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">LOGFILE=/opt/stack/logs/stack.sh.log</font></i></div><div><i><font color="#666666">VERBOSE=True</font></i></div><div><i><font color="#666666">LOG_COLOR=True</font></i></div><div><i><font color="#666666">SCREEN_LOGDIR=/opt/stack/logs</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666"># Neutron LBaaS</font></i></div><div><i><font color="#666666">enable_plugin neutron-lbaas <a href="https://github.com/openstack/neutron-lbaas.git">https://github.com/openstack/neutron-lbaas.git</a></font></i></div><div><i><font color="#666666">enable_plugin octavia <a href="https://github.com/openstack/octavia.git">https://github.com/openstack/octavia.git</a></font></i></div><div><i><font color="#666666">ENABLED_SERVICES+=,q-lbaasv2</font></i></div><div><i><font color="#666666">ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">disable_service horizon</font></i></div><div><i><font color="#666666">disable_service tempest</font></i></div></div><div><br></div><div>To investigate the source of the error, I logon to the amphora. The details of interfaces of amphora_haproxy network namespace are as follows.</div><div><br></div><div><div><i><font color="#666666">1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1</font></i></div><div><i><font color="#666666">    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00</font></i></div><div><i><font color="#666666">3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP group default qlen 1000</font></i></div><div><i><font color="#666666">    link/ether fa:16:3e:42:bf:d9 brd ff:ff:ff:ff:ff:ff</font></i></div><div><i><font color="#666666">    inet <a href="http://10.0.1.3/24">10.0.1.3/24</a> brd 10.0.1.255 scope global eth1</font></i></div><div><i><font color="#666666">       valid_lft forever preferred_lft forever</font></i></div><div><i><font color="#666666">    inet <a href="http://10.0.1.9/24">10.0.1.9/24</a> brd 10.0.1.255 scope global secondary eth1:0</font></i></div><div><i><font color="#666666">       valid_lft forever preferred_lft forever</font></i></div><div><i><font color="#666666">    inet6 fe80::f816:3eff:fe42:bfd9/64 scope link</font></i></div><div><i><font color="#666666">       valid_lft forever preferred_lft forever</font></i></div></div><div><br></div><div>So I run "sudo ip netns exec amphora-haproxy tcpdump -i eth1 -nn 'tcp'" to check whether amphora receive the request. The details are as follows.</div><div><br></div><div><div><i><font color="#666666">tcpdump: verbose output suppressed, use -v or -vv for full protocol decode</font></i></div><div><i><font color="#666666">listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes</font></i></div><div><i><font color="#666666">^C06:11:49.048973 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594, win 28200, options [mss 1410,sackOK,TS val 28032309 ecr 0,nop,wscale 7], length 0</font></i></div><div><i><font color="#666666">06:11:50.031976 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594, win 28200, options [mss 1410,sackOK,TS val 28032559 ecr 0,nop,wscale 7], length 0</font></i></div><div><i><font color="#666666">06:11:52.026565 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594, win 28200, options [mss 1410,sackOK,TS val 28033060 ecr 0,nop,wscale 7], length 0</font></i></div><div><i><font color="#666666">06:11:56.002577 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594, win 28200, options [mss 1410,sackOK,TS val 28034062 ecr 0,nop,wscale 7], length 0</font></i></div><div><i><font color="#666666">06:12:03.909721 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594, win 28200, options [mss 1410,sackOK,TS val 28036064 ecr 0,nop,wscale 7], length 0</font></i></div></div><div><br></div><div>Based on the trace, we can see that amphora do receive the request, but haproxy does not send handshake datagram to respond. Then, to see whether haproxy in the amphora listens on the right IP and port, I print /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg in the console and see the following info.</div><div><br></div><div><div><i><font color="#666666"># Configuration for lb1</font></i></div><div><i><font color="#666666">global</font></i></div><div><i><font color="#666666">    daemon</font></i></div><div><i><font color="#666666">    user nobody</font></i></div><div><i><font color="#666666">    log /dev/log local0</font></i></div><div><i><font color="#666666">    log /dev/log local1 notice</font></i></div><div><i><font color="#666666">    stats socket /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57.sock mode 0666 level user</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">defaults</font></i></div><div><i><font color="#666666">    log global</font></i></div><div><i><font color="#666666">    retries 3</font></i></div><div><i><font color="#666666">    option redispatch</font></i></div><div><i><font color="#666666">    timeout connect 5000</font></i></div><div><i><font color="#666666">    timeout client 50000</font></i></div><div><i><font color="#666666">    timeout server 50000</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">frontend ec5ee7c5-7474-424f-9f44-71b338cf3e57</font></i></div><div><i><font color="#666666">    option httplog</font></i></div><div><i><font color="#666666">    bind <a href="http://10.0.1.9:80">10.0.1.9:80</a></font></i></div><div><i><font color="#666666">    mode http</font></i></div><div><i><font color="#666666">    default_backend 40537c80-979d-49c9-b3ae-8504812c0f42</font></i></div><div><i><font color="#666666"><br></font></i></div><div><i><font color="#666666">backend 40537c80-979d-49c9-b3ae-8504812c0f42</font></i></div><div><i><font color="#666666">    mode http</font></i></div><div><i><font color="#666666">    balance roundrobin</font></i></div><div><i><font color="#666666">    server 73dc9a1d-1e92-479b-a6f3-8debd0ea17b8 <a href="http://10.0.1.6:80">10.0.1.6:80</a> weight 1</font></i></div><div><i><font color="#666666">    server 4cdca33f-9cde-4ac2-a5bd-550d3e65f0f2 <a href="http://10.0.1.7:80">10.0.1.7:80</a> weight 1</font></i></div></div><div><br></div><div>Next, I print the info of all the running haproxy process in the console and copy it below.</div><div><br></div><div><div><i><font color="#666666">root      2367  0.0  0.0   4228   740 ?        Ss   07:14   0:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid</font></i></div><div><i><font color="#666666">haproxy   2370  0.0  0.5  37692  5340 ?        S    07:14   0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds</font></i></div><div><i><font color="#666666">haproxy   2371  0.0  0.0  37692   924 ?        Ss   07:14   0:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds</font></i></div><div><i><font color="#666666">root      2471  0.0  0.0   4228   636 ?        Ss   07:14   0:00 /usr/sbin/haproxy-systemd-wrapper -f /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/ec5ee7c5-7474-424f-9f44-71b338cf3e57.pid -L A2GNEZ_IsG5HmdyY2LmdG3LSOco</font></i></div><div><i><font color="#666666">nobody    2477  0.0  0.5  37676  5824 ?        S    07:14   0:00 /usr/sbin/haproxy -f /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/ec5ee7c5-7474-424f-9f44-71b338cf3e57.pid -L A2GNEZ_IsG5HmdyY2LmdG3LSOco -Ds</font></i></div><div><i><font color="#666666">nobody    2478  0.1  0.3  37676  3140 ?        Ss   07:14   0:01 /usr/sbin/haproxy -f /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg -f /var/lib/octavia/haproxy-default-user-group.conf -p /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/ec5ee7c5-7474-424f-9f44-71b338cf3e57.pid -L A2GNEZ_IsG5HmdyY2LmdG3LSOco -Ds</font></i></div><div><i><font color="#666666">ubuntu    2485  0.0  0.1  12916  1092 pts/0    S+   07:36   0:00 grep --color=auto haproxy</font></i></div></div><div><br></div><div>I run strace to trace the activities of all the above processes. When sending request to the VIP, none of the above processes takes action to receive the datagram. The details are omitted, since they give little information.</div><div><br></div><div>Above all, I think the haproxy fail to receive the ingress traffic from the IP and port it listens on.</div><div><br></div><div>What do you think? Look forward to your valuable comments. Thank you.</div><div><br></div><div>Best regards,</div><div>Yipei</div></div>