Open Stack

Solved.

I should remove these entries

net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1

from sysctl.conf on compute nodes. I was previously testing the DVR
scenarios and these entries stayed on sysctl.conf file.

Just to post the resolution.

Tks.



- JLC

On Mon, May 16, 2016 at 4:35 PM, Jorge Luiz Correa <correajl at gmail.com>
wrote:

> Hi list! I'm having problems with tenant network and one of compute nodes.
> I think that could be something with the compute node management ip address.
>
> Context:
>
> I'm testing the network scenario "classic with openvswitch" described here:
>
>
> http://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html
>
> 1 controller node, 1 network node and 2 compute nodes.
>
> Compute node 1 has 4 interfaces:
>
> p3p1 - 192.168.0.1 (management network)
> p3p2 - 192.168.1.1 (tunnel network)
> p4p2 - no address (vlan network)
> em4 - no address (external network)
>
> When I create a tenant network with network address 192.168.0.0/24,
> instances launched on compute node 1 are having connectivity problem
> because they can't reach the network gateway 192.168.0.1.
>
> Openvswitch agent creates a qbr bridge with a tap and a qvb interface. The
> instance has the address 192.168.0.5. When I try to ping 192.168.0.1 from
> this instance (its gateway), it doesn't work. With tcpdump I can see
> instance making the ARP request 'who has 192.168.0.1'. However, the first
> answer is from bridge qvb, using the bridge mac address. The correct would
> be the interface from virtual router, as I can see on compute node 2.
>
> I think the IP address 192.168.0.1 on the management interface is making,
> for some reason, the bridge reply as if it was the gateway of tenant
> network.
>
> This just occur with this address 192.168.0.1! If I create the tenant
> subnet with address 172.16.0.0/24 everything works great. Or, if I change
> the default setting for gateway address, make the gateway has another IP
> like 192.168.0.254, everything works fine too.
>
> Can someone help me? Are there some configuration with sysctl to solve
> this? Somewhere to verify?
>
> Tks!
>
> - JLC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160517/da0b39a0/attachment.html>