Open Stack

A couple of things to check, 

by default DVR is not enabled, therefore make sure that’s on. 

if you have more than one hypervisor, then check where the instance is booted and see if there is a router there, which should have the floating ip address and iptables will have a map for the 1to1 SNAT - DNAT and DNAT to SNAT. 

Ciao, 
Remo 
> On Apr 15, 2016, at 09:41, Jorge Luiz Correa <correajl at gmail.com> wrote:
> 
> I'm using the DVR network scenario described in http://docs.openstack.org/liberty/networking-guide/scenario-dvr-ovs.html <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 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>   0.0.0.0/0 <http://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 <http://0.0.0.0/0>   0.0.0.0/0 <http://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 <http://0.0.0.0/0>   0.0.0.0/0 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>            udp spt:67 udp dpt:68
>     0     0 RETURN     all  --  *      *       0.0.0.0/0 <http://0.0.0.0/0>            0.0.0.0/0 <http://0.0.0.0/0>            match-set NIPv43c228055-2735-4339-b9a8- src
>     0     0 DROP       all  --  *      *       0.0.0.0/0 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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 <http://0.0.0.0/0>            0.0.0.0/0 <http://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
> !DSPAM:1,5710f455154911543464705! <dvr_floatingips_debug.png>_______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> !DSPAM:1,5710f455154911543464705!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160415/cd8b2f6b/attachment.html>