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 < yprav...@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 <aaronoro...@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 < >> 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-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.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 >> >> > > _______________________________________________ > 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
