[openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

Kevin Benton blak111 at gmail.com
Sat Mar 28 08:57:23 UTC 2015

This is a use case that we probably need a better equivalent of on the
Neutron side. It would be great if you could clarify a few things to make
sure I understand it correctly.

You want floating IPs at each compute node, and DVR with VLAN support got
you close. Are the floating IPs okay being on a different network/VLAN?

Which address do you expect the source to be when an instance communicates
outside of its network (no existing connection state)? You mentioned having
the L3 agent ARP for a different gateway, do you still want the floating IP
translation to happen before that? Is there any case where it should ever
be via the private address?

The header mangling is to make up for the fact that traffic coming to the
floating IP gets translated by the L3 agent before it makes it to the
instance so there is no way to distinguish whether the floating IP or
private IP was targeted. Is that correct?

Thanks for posting this.

Kevin Benton

On Fri, Mar 27, 2015 at 5:41 PM, Steve Wormley <openstack at wormley.com>

> So, I figured I'd weigh in on this as an employee of a nova-network using
> company.
> Nova-network allowed us to do a couple things simply.
> 1. Attach openstack networks to our existing VLANs using our existing
> firewall/gateway and allow easy access to hardware such as database servers
> and storage on the same VLAN.
> 2. Floating IPs managed at each compute node(multi-host) and via the
> standard nova API calls.
> 3. Access to our instances via their private IP addresses from inside the
> company(see 1)
> Our forklift replacement to neutron(as we know we can't 'migrate') is at
> the following state.
> 2 meant we can't use pure provider VLAN networks so we had to wait for DVR
> VLAN support to work.
> Now that that works, I had to go in and convince Neutron to let me
> configure my own gateways as the next hop instead of the central SNAT
> gateway's assigned IP. This also required making it so the distributed L3
> agents could do ARP for the 'real' gateway on the subnet.
> Item 3 works fine until a floating IP is assigned. For nova-network this
> was trivial connection tracked routing sending packets that reached an
> instance via its private IP back out the private VLAN and everything else
> via the assigned public IP.
> Neutron, OVS and the various veth connections between them means I can't
> use packet marking between instances and the router NS, between that and a
> whole bunch of other things we had to borrow some IP header bits to track
> where a packet came in so if a response to that connection hit the DVR
> router it could be sent back out the private network.
> And for the next week I get to try and make this all python code so we can
> actually finally test it without hand crafted iptables and OVS rules.
> For our model most of the Neutron features are wasted, but as we've been
> told that nova-network is going away we're going to figure out how to make
> Neutron work going forward.
> -Steve Wormley
> Not really speaking for my employer
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150328/4d37aedb/attachment.html>

More information about the OpenStack-dev mailing list