[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