But if I understand nova network with FlatDHCP correctly, there is no such thing as a host without a floating IP. So if every instance is given a floating IP in Neutron in a similar fashion, then the lack of SNAT distribution would not matter in that case, correct?
On Fri, Apr 17, 2015 at 11:26 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > DVR probably still does satisfy the same requirements as nova multi-host, > because of the lack of SNAT masquerade distribution. > Neutron DVR distributes the floating IP and east-west traffic, but the > default gateway for each VM is still centralised, thus making the network > node a SPOF. > > Then from a data plane perspective the other aspect is that for DVR we > assume OVS while nova-network deployers would probably stick with Linux > Bridge. However this is a bit off topic here. > > I am not aware of other differences, at least feature-wise. From a > usability perspective the infrastructure for achieving functionality > equivalent to FlatDHCP can be set up by an admin (or provided by neutron > itself using some configuration switch), and the users could be completely > oblivious to that - ie: they can boot a VM and connect a floating IP to it > without ever using the "neutron" utility or calling the Neutron API. > > Salvatore > > > > > On 17 April 2015 at 20:11, Kevin Benton <blak...@gmail.com> wrote: > >> If the Neutron topology is configured to use a router connected to an >> external network and a shared network, will that achieve the same semantics >> as Nova with a FlatDHCP network? >> >> One of the last remaining items that I was aware of was ARP poisoning >> protection. At the end of Kilo, we added protection from that in OVS-based >> deployments.[1] >> >> Are there any other remaining major differences that we can fix on the >> Neutron side to make it a good replacement? >> >> 1. >> https://github.com/openstack/neutron/commit/483de6313fab5913f9e68eb24afe65c36bd9b623 >> >> -- >> Kevin Benton >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
