Open Stack

I'm Maximiliano Venesio from MercadoLibre and i have been working with
Alejandro in this issue.

In order to answer your last questions :

We are injecting the iptables PREROUTING rule directly to the compute node
(host machine), as is configured and working in essex.
regarding the question about if the metadata server knows how to route the
packets back to the tenant network, the problem that we are having now is
that the NATed packet is not passing out trough the bridge, so never hits
the metadata server, that in our case, is the controller node that is
running in a different physical server.

When we try to reach the metadata directly from the VM to the controller IP
port 8775, we can get the metadata info perfectly. So we think that the
problem is with the PREROUTING rule using the 169.254.169.254, or some
issue between the bridge and the veth pairs.

Regarding the integration with neutron + nova + OVS, we are not using
service_neutron_metadata_proxy, but i think that it comes disabled by
default. As i have understood the  service_neutron_metadata_proxy is used
with the network node and we are not using any network node or L3 agent or
DHCP agent.
We just configured LibvirtHybridOVSBridgeDriver to have nova-compute
working with OpenVswitch and the neutron-openvswitch-agent to connect
neutron with the compute node.

Yes, its really strange since we can see the packet passing trough the tap
interface , then matching the iptables rule, and finally coming to the
qbrXXX with the NAT rule applied but it never pass from the bridge to the
qvbXXXX or qvoXXX, and we can't see any iptables rule dropping the package.
So we are using tcpdump in all the steps tap bridge and veth and it works
fine in the first two.

Just to clarify some details about our setup, we are injecting the ip and
the gateway to the VM using flat_injected and flat_network_bridge, and we
are using one of our cloud core switches as a default gw.



Thanks in advanced



*Maximiliano Venesio *
#melicloud CloudBuilders
Arias 3751, Piso 7 (C1430CRG)
Ciudad de Buenos Aires - Argentina
Cel: +549(11) 15-3770-1853
Tel : +54(11) 4640-8411


On Fri, Nov 15, 2013 at 7:59 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> Hi Alejandro,
>
> As we've already discussed the topic over IRC, let me add something else
> on your setup:
> - no dhcp agent, no l3 agent
> - IP configuration injected into instances
> (I'm disclosing this information since it's already been disclosed on IRC
> whose logs are publicly accessible anyway)
>
> Comments inline
>
> Regards,
> Salvatore
>
>
> On 15 November 2013 23:38, Alejandro Comisario <
> alejandro.comisario at mercadolibre.com> wrote:
>
>> Hi guys, we are deploying:
>>
>> havana + OVS on vlan mode + neutron using this EXACT production schema :
>>
>>
>> http://docs.openstack.org/network-admin/admin/content/figures/2/figures/under-the-hood-scenario-2-ovs-compute.png
>>
>> Since we are using this schema, im gonna reffer about devices as they are
>> named in the picture.
>> When an instance gets created, the network defined uses the GW where the
>> vlan is created on a switch, so when the VM tries to access any other
>> network packets go through all the taps, and bridges inside de compute and
>> get to the default gw where it gets routed.
>>
>> Regarding metadata, the instances cant access the metadata, so i issue
>> the regular DNAT iptables rule to be able to acces it :
>>
>> iptables -t nat -A neutron-openvswi-PREROUTING  -d 169.254.169.254/32 -p
>> tcp -m tcp --dport 80 -j DNAT --to-destination [CONTROLLER-IP]:8775
>>
>>
> Are you injecting this rule into the instances or into the host machine?
> In any case I think this will cause the packet received by the metadata
> server to have the SRC IP of the VM instance, which is on a tenant network.
> Does the metadata server know how to route packets back to tenant networks?
>
>
>> I see the original package exit the TAP, the DNATED package incoming the
>> qbrXXX but the package never hits the qvbXXXX interface and we dont have
>> an idea why, since it doesnt seems to be an iptables issue.
>>
>
> I would add to the potential issues that nova might expect you to run
> neutron metadata proxies/agent if service_neutron_metadata_proxy is true.
> However, I think that can be turned off, and anyway you're now
> experiencing a connectivity problem.
>
> It is really strange that a packet gets lost in the bridge, unless the
> host has some iptables rule which will end up dropping the packet.
> I don't know how tcpdump works with veths, so perhaps I would check if the
> packets makes it into br-int.
>
>
>
>
>
>> can anyone help me ?
>> * alejandrito @catintheroof*
>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/c213e2c8/attachment.html>