<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 28 March 2015 at 00:41, Steve Wormley <span dir="ltr"><<a href="mailto:openstack@wormley.com" target="_blank">openstack@wormley.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>So, I figured I'd weigh in on this as an employee of a nova-network using company.<br><br></div>Nova-network allowed us to do a couple things simply. <br><br></div>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.<br></div>2. Floating IPs managed at each compute node(multi-host) and via the standard nova API calls.<br></div>3. Access to our instances via their private IP addresses from inside the company(see 1)<br><br></div>Our forklift replacement to neutron(as we know we can't 'migrate') is at the following state.<br></div>2 meant we can't use pure provider VLAN networks so we had to wait for DVR VLAN support to work.<br></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I'm always confused when I see operators mention that provider VLANs can't be used in a Neutron configuration. While at my former employer we had that setup with Grizzly, and also note that any instance attached to a VLAN tagged tenant network did not go via the L3 agent... the traffic was tagged and sent directly from the compute node onto the VLAN.</div><div><br></div><div>All we had to do to make this work was to allow VLAN tagged networks and the cloud admin had to setup the provider network with the appropriate VLAN tag.</div></div>
</div></div>