[openstack-dev] [Openstack] [openstack][neutron] problems accesing metadata on OVS VLAN mode (havana)

Salvatore Orlando sorlando at nicira.com
Fri Nov 15 22:59:04 UTC 2013

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


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 -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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/7a9d766c/attachment.html>

More information about the OpenStack-dev mailing list