[Openstack-operators] Small openstack
Kris G. Lindgren
klindgren at godaddy.com
Fri Jan 9 19:25:35 UTC 2015
Also, If you are running this configuration you should be aware of the
And the corresponding fix: https://review.openstack.org/#/c/141130/
Basically - Neutron security group rules do nothing to protect against arp
spoofing/poisoning from vm's. So its possible under a shared network
configuration for a vm to arp for another vm's ip address and temporarily
knock that vm offline. The above commit - which is still a WIP adds
ebtable rules to allow neutron to filter protocols other than IP (eg arp).
Senior Linux Systems Engineer
On 1/8/15, 9:50 AM, "Kris G. Lindgren" <klindgren at godaddy.com> wrote:
>On 1/8/15, 4:34 AM, "Antonio Messina" <antonio.s.messina at gmail.com> wrote:
>>On Thu, Jan 8, 2015 at 12:12 PM, gustavo panizzo (gfa) <gfa at zumbi.com.ar>
>>> On 01/08/2015 07:01 PM, Antonio Messina wrote:
>>>> On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa)
>>>><gfa at zumbi.com.ar>
>>>>> i may be wrong as i haven't tested that on juno, but in icehouse and
>>>>> i've setup external/provider networks one for each tenant
>>>> Ah, ok, this is the point. What I would like to have instead is
>>>> 1) one big external network with routable, private IPs, to be used by
>>>> tenant (where any tenant can plug ports)
>>> neutron net-create --shared should do the trick
>>I guess the problem is that I was creating *external* _and_ *shared*
>>network, but if I don't want to use floating IPs from that network I
>>probably don't need the network to be external, right?
>Correct. We have our "external networks" (private ip) only configured as
>shared so any vm from any tenant can create a port on it. External means
>it's meant to be plugged into a router/l3 agent.
>>>> 3) small external networks dedicated to a tenant
>>> neutron net-create --tenant-id XXXXX-XXXXXX
>>> i've made that mix (also add tenantn networks) in my lab running
>>> (2014.1.2) worked fine, i've upgraded it to juno but i haven't test
>>Thank you, I will test it further.
>>> do you run more than one l3 agent? are you floating ips configured on
>>> i think if you fix the policy.json on nova you should get it working
>>I currently have only 1 l3-agent running, but it's suboptimal. I would
>>like to have L3-HA for the floating IPs and DVR for the shared and
>>tenant networks, but as far as I know it's not currently supported. I
>>plan to deploy the production cloud after Kilo release, and crossing
>>Floating IPs are currently configured on br-ex.
>You have floating ips working under this configuration?
>If so then that means you are using the neutron router as the gateway for
>all of your vm's and not the gateway provided by your network device. As
>soon as you created a router and attached the the shared network to it the
>router got configured with the gateway address that you configured in your
>network. You may want to make sure that you don¹t have traffic flapping
>between your real network gateway and your neutron gateway on your l3
>The reason why floating ip's won't work under this configuration (using a
>real network device for the gateway) is the fact that the floating ip is
>applied at the router as a nat so the traffic flows like: Client (126.96.36.199)
>-> floating ip (188.8.131.52) -> external port on router -> The router changes
>the destination IP from the floating ip to the private IP of the vm
>(172.23.2.40) and send the traffic out to the vm via the routers
>connection on the shared network. The VM responds to the client traffic
>which is not in its subnet directly to the default gateway (172.23.0.1).
>The gateway (if it is a neutron gateway) will then undo the nat and send
>the traffic back to the client.
>Where this breaks down with a physical network gateway is when the traffic
>from the VM is sent to the real network gateway - the gateway doesn't know
>anything about the nat and does not re-map the vm ip to the floating ip.
>IE The client ip never gets changed to the floating ip and sent back to
>the client IP. The Response would be seen as coming directly from
>172.23.2.40, instead of 184.108.40.206. So you will never establish a tcp
>If you have this working somehow - please let me know. When we attempted
>to run this configuration we ran into the above issues with floating ips
>when using a real gateway on a network device.
>Note: this is also why you need to create your shared network with a
>specific router to the metadata service. Most likely on your real network
>gateway you haven't added a route for 169.254.169.254 to a specific ip.
>>antonio.s.messina at gmail.com
>>antonio.messina at uzh.ch +41 (0)44 635 42 22
>>S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/
>>University of Zurich
>>CH-8057 Zurich Switzerland
>>OpenStack-operators mailing list
>>OpenStack-operators at lists.openstack.org
More information about the OpenStack-operators