Open Stack

It sounds like you want to be able to allocate and manage floating ips out of a neutron subnet and attach them to vms in that same subnet? No router needed? Sounds useful.

Would probably need different quotas. Since they arent "public" floating ips.

Maybe floating ip quotas should be seperated by subnet id? This would help anyway when you have multiple external networks.

Thanks,
Kevin

________________________________
From: Kevin Benton
Sent: Saturday, March 28, 2015 1:57:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work

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.

Cheers,
Kevin Benton

On Fri, Mar 27, 2015 at 5:41 PM, Steve Wormley <openstack at wormley.com<mailto:openstack at wormley.com>> wrote:
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://OpenStack-dev-request@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/40734539/attachment.html>