Open Stack

Hi Praveen,

I think we should fix the update_method instead to properly check for this.
I don't see any advantage to allow the fixed_ips/mac to be in the
allowed_address_pairs since they are explicitly allowed. What's your
motivation for changing this?

Aaron


On Mon, May 19, 2014 at 4:05 PM, Praveen Yalagandula <
ypraveen at avinetworks.com> wrote:

> Hi Aaron,
>
> Thanks for the prompt response.
>
> If the overlap does not have any negative effect, can we please just
> remove this check? It creates confusion as there are certain code paths
> where we do not perform this check. For example, the current code does NOT
> perform this check when we are updating the list of allowed-address-pairs
> -- I can successfully assign an existing fixed IP address to the
> allowed-address-pairs. The check is being performed on only one code path -
> when assigning fixed IPs.
>
> If it sounds right to you, I can submit my patch removing this check.
>
> Thanks,
> Praveen
>
>
>
> On Mon, May 19, 2014 at 12:32 PM, Aaron Rosen <aaronorosen at gmail.com>wrote:
>
>> 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-pairsand 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20140520/a2891ee5/attachment.html>