[openstack-dev] [Openstack] [openstack][neutron] problems accesing metadata on OVS VLAN mode (havana)
sorlando at nicira.com
Fri Nov 15 22:59:04 UTC 2013
As we've already discussed the topic over IRC, let me add something else on
- 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)
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 :
> 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:
> Post to : openstack at lists.openstack.org
> Unsubscribe :
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev