Also, If you are running this configuration you should be aware of the following bug:
https://bugs.launchpad.net/neutron/+bug/1274034 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). ____________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 1/8/15, 9:50 AM, "Kris G. Lindgren" <klindg...@godaddy.com> wrote: > > >On 1/8/15, 4:34 AM, "Antonio Messina" <antonio.s.mess...@gmail.com> wrote: > >>On Thu, Jan 8, 2015 at 12:12 PM, gustavo panizzo (gfa) <g...@zumbi.com.ar> >>wrote: >>> >>> >>> On 01/08/2015 07:01 PM, Antonio Messina wrote: >>>> >>>> On Thu, Jan 8, 2015 at 11:53 AM, gustavo panizzo (gfa) >>>><g...@zumbi.com.ar> >>>> wrote: >>> >>> >>>>> >>>>> i may be wrong as i haven't tested that on juno, but in icehouse and >>>>> havana >>>>> 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 >>>> *any* >>>> 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 >>>icehouse >>> (2014.1.2) worked fine, i've upgraded it to juno but i haven't test >>>that yet >> >>Thank you, I will test it further. >> >>> do you run more than one l3 agent? are you floating ips configured on >>>br-ex? >>> 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 >>my fingers... >> >>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 >router. > >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 (4.2.2.1) >-> floating ip (8.8.8.8) -> 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 8.8.8.8. So you will never establish a tcp >connection. > >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. > >> >>.a. >> >>-- >>antonio.s.mess...@gmail.com >>antonio.mess...@uzh.ch +41 (0)44 635 42 22 >>S3IT: Service and Support for Science IT http://www.s3it.uzh.ch/ >>University of Zurich >>Winterthurerstrasse 190 >>CH-8057 Zurich Switzerland >> >>_______________________________________________ >>OpenStack-operators mailing list >>OpenStack-operators@lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators