Hi Praveen, I think there is some confusion here. This function doesn't check if there is any overlap that occurs within the cidr block. It only checks that the fixed_ips+mac don't overlap with an allowed address pair. In your example if the host has an ip_address of 10.10.1.1 and you want to allow any ip in 10.10.1.0/24 to pass through the port you can just add a rule for 10.10.1.0/24 directly without having to break it up.
Aaron On Tue, May 20, 2014 at 11:20 AM, Praveen Yalagandula < yprav...@avinetworks.com> wrote: > Hi Aaron, > > The main motivation is simplicity. Consider the case where we want to > allow ip cidr 10.10.1.0/24 to be allowed on a port which has a fixed IP > of 10.10.1.1. Now if we do not want to allow overlapping, then one needs to > add 8 cidrs to get around this - (10.10.1.128/25, 10.10.1.64/26, > 10.10.1.32/27, ....10.10.1.0/32); which makes it cumbersome. > > In any case, allowed-address-pairs is ADDING on to what is allowed because > of the fixed IPs. So, there is no possibility of conflict. The check will > probably make sense if we are maintaining denied addresses instead of > allowed addresses. > > Cheers, > Praveen > > > On Tue, May 20, 2014 at 9:34 AM, Aaron Rosen <aaronoro...@gmail.com>wrote: > >> 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 >> >> > > _______________________________________________ > 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