[Openstack] Lack of iptables rule in DVR network scenario when using floating IPs is causing packets' drop

Jorge Luiz Correa correajl at gmail.com
Fri Apr 15 13:41:18 UTC 2016


I'm using the DVR network scenario described in
http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html.
My installation was based on Ubuntu Install guide.

I've an external network, flat, with public IPs.
I've a project with a tenant network and subnet, one virtual router that
connects this subnet to the external net.

I've launched one VM connected to the tenant network (172.16.0.0/24). The
IPs address are (ports on this subnet):

172.16.0.1 - network:router_interface_distributed
172.16.0.2 - network:dhcp
172.16.0.5 - compute:nova <- this is the VM

Then I associated a Floating IP of external network to this VM, lets say
A.B.C.D (a public IP address).

>From an external network host I'm trying to ping A.B.C.D. It doesn't work.
So, I follow the packet path inside the virtual interfaces and bridges, as
shown in attached image.

On iptables of compute host where this VM is running we can see
(summarized):

FORWARD -> neutron-openvswi-FORWARD -> neutron-openvswi-sg-chain ->
neutron-openvswi-i7a7a669c-3 -> neutron-openvswi-sg-fallback -> DROP

iptables -L -Z -n -v

iptables -L -n -v

Chain *FORWARD* (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
   24  2016 neutron-openvswi-FORWARD  all  --  *      *
0.0.0.0/0
0.0.0.0/0

Chain *neutron-openvswi-FORWARD* (1 references)
 pkts bytes target     prot opt in     out     source
destination
   24  2016 neutron-openvswi-sg-chain  all  --  *      *
0.0.0.0/0
0.0.0.0/0  PHYSDEV match --physdev-out tap7a7a669c-3f --physdev-is-bridged
/* Direct traffic from the VM interface to the security group chain. */
    0     0 neutron-openvswi-sg-chain  all  --  *      *
0.0.0.0/0
0.0.0.0/0  PHYSDEV match --physdev-in tap7a7a669c-3f --physdev-is-bridged
/* Direct traffic from the VM interface to the security group chain. */

Chain *neutron-openvswi-sg-chain *(2 references)
 pkts bytes target                          prot opt in     out
source      destination
   24  2016 neutron-openvswi-i7a7a669c-3    all  --  *      *
0.0.0.0/0   0.0.0.0/0            PHYSDEV match --physdev-out tap7a7a669c-3f
--physdev-is-bridged /* Jump to the VM specific chain. */
    0     0 neutron-openvswi-o7a7a669c-3    all  --  *      *
0.0.0.0/0   0.0.0.0/0            PHYSDEV match --physdev-in tap7a7a669c-3f
--physdev-is-bridged /* Jump to the VM specific chain. */
    0     0 ACCEPT                          all  --  *      *
0.0.0.0/0   0.0.0.0/0

Chain *neutron-openvswi-i7a7a669c-3* (1 references)
 pkts bytes target     prot opt in     out     source
destination
    0     0 RETURN     all  --  *      *       0.0.0.0/0
0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated
with a known session to the RETURN chain. */
    0     0 RETURN     udp  --  *      *       172.16.0.2
0.0.0.0/0            udp spt:67 udp dpt:68
    0     0 RETURN     all  --  *      *       0.0.0.0/0
0.0.0.0/0            match-set NIPv43c228055-2735-4339-b9a8- src
    0     0 DROP       all  --  *      *       0.0.0.0/0
0.0.0.0/0            state INVALID /* Drop packets that appear related to
an existing connection (e.g. TCP ACK/FIN) but do not have an entry in
conntrack. */
   24  2016 *neutron-openvswi-sg-fallback*  all  --  *      *
0.0.0.0/0            0.0.0.0/0            /* Send unmatched traffic to the
fallback chain. */

Chain* neutron-openvswi-sg-fallback* (2 references)
 pkts bytes target     prot opt in     out     source
destination
   24  2016 *DROP*       all  --  *      *       0.0.0.0/0
0.0.0.0/0            /* Default drop rule for unmatched traffic. */


I think that in neutron-openvswi-i7a7a669c-3 should exist some RETURN rule
using the 172.16.0.5 IP address.

Some idea? Is this really a problem (bug?) or am I doing something wrong?

Thanks for any help!

- JLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160415/a3fae328/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dvr_floatingips_debug.png
Type: image/png
Size: 166233 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160415/a3fae328/attachment.png>


More information about the Openstack mailing list