Open Stack

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 <
ypraveen at 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 <arosen at 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.ubuntu at cack.org.uk>wrote:
>>
>>> On 10 July 2013 21:14, Vishvananda Ishaya <vishvananda at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/e5293592/attachment.html>