Hi, Sure, if you look at this method:
def _check_fixed_ips_and_address_pairs_no_overlap(self, context, port): address_pairs = self.get_allowed_address_pairs(context, port['id']) for fixed_ip in port['fixed_ips']: for address_pair in address_pairs: if (fixed_ip['ip_address'] == address_pair['ip_address'] and port['mac_address'] == address_pair['mac_address']): raise addr_pair.AddressPairMatchesPortFixedIPAndMac() it checks that the allowed_address_pairs don't overlap with fixed_ips and mac_address on the port. The only reason we do this additional check is that having the same fixed_ip and mac_address pair as an allowed_address_pair would have no effect since the fixed_ip/mac on the port inherently allows that traffic through. Best, Aaron On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula < yprav...@avinetworks.com> wrote: > Hi Aaron, > > In OVS and ML2 plugins, on port-update, there is a check to make sure that > allowed-address-pairs and fixed-ips don't overlap. Can you please explain > why that is needed? > > ------------- icehouse final: neutron/plugins/ml2/plugin.py ------------ > > 677 elif changed_fixed_ips: > > 678 self._check_fixed_ips_and_address_pairs_no_overlap( > > 679 context, updated_port) > ----------------------- > > Thanks, > Praveen > > > On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen <aro...@nicira.com> wrote: > >> Hi Ian, >> >> For shared networks if the network is set to port_security_enabled=True >> then the tenant will not be able to remove port_security_enabled from their >> port if they are not the owner of the network. I believe this is the >> correct behavior we want. In addition, only admin's are able to create >> shared networks by default. >> >> I've created the following blueprint >> https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs and >> doc: >> https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich >> will provide us a way to do this. It would be awesome if you could >> check it out and let me know what you think. >> >> Thanks, >> >> Aaron >> >> >> On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <ijw.ubu...@cack.org.uk>wrote: >> >>> On 10 July 2013 21:14, Vishvananda Ishaya <vishvana...@gmail.com> wrote: >>> >> It used to be essential back when we had nova-network and all tenants >>> >> ended up on one network. It became less useful when tenants could >>> >> create their own networks and could use them as they saw fit. >>> >> >>> >> It's still got its uses - for instance, it's nice that the metadata >>> >> server can be sure that a request is really coming from where it >>> >> claims - but I would very much like it to be possible to, as an >>> >> option, explicitly disable antispoof - perhaps on a per-network basis >>> >> at network creation time - and I think we could do this without >>> >> breaking the security model beyond all hope of usefulness. >>> > >>> > Per network and per port makes sense. >>> > >>> > After all, this is conceptually the same as enabling or disabling >>> > port security on your switch. >>> >>> Bit late on the reply to this, but I think we should be specific on >>> the network, at least at creation time, on what disabling is allowed >>> at port level (default off, may be off, must be on as now). Yes, it's >>> exactly like disabling port security, and you're not always the >>> administrator of your own switch; if we extend the analogy you >>> probably wouldn't necessarily want people turning antispoof off on an >>> explicitly shared-tenant network. >>> -- >>> Ian. >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev