<div dir="ltr">Hi, <div><br></div><div>Sure, if you look at this method: </div><div><br></div><div><div> def _check_fixed_ips_and_address_pairs_no_overlap(self, context, port): </div><div> address_pairs = self.get_allowed_address_pairs(context, port['id']) </div>
<div> for fixed_ip in port['fixed_ips']: </div><div> for address_pair in address_pairs: </div><div> if (fixed_ip['ip_address'] == address_pair['ip_address'] </div>
<div> and port['mac_address'] == address_pair['mac_address']): </div><div> raise addr_pair.AddressPairMatchesPortFixedIPAndMac() </div>
<div> </div></div><div><br></div><div>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. </div>
<div><br>Best, </div><div><br>Aaron</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 12:22 PM, Praveen Yalagandula <span dir="ltr"><<a href="mailto:ypraveen@avinetworks.com" target="_blank">ypraveen@avinetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Aaron,<div><br></div><div>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?</div>
<div><br></div><div>------------- icehouse final: neutron/plugins/ml2/plugin.py ------------</div>
<div>
<p><span>677 </span> <span>elif</span> changed_fixed_ips:</p>
<p><span>678 </span> self._check_fixed_ips_and_address_pairs_no_overlap(</p>
<p><span>679 </span> context, updated_port)</p></div><div>-----------------------</div><div><br>Thanks,</div><div>Praveen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen <span dir="ltr"><<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Hi Ian, <br><br></div>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. <br>
<br>I've created the following blueprint <a href="https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs" target="_blank">https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs</a> and doc: <a href="https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharing</a> which 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.<br>
<br>Thanks, <br><br></div>Aaron<br>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 10 July 2013 21:14, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>> wrote:<br>
>> It used to be essential back when we had nova-network and all tenants<br>
>> ended up on one network. It became less useful when tenants could<br>
>> create their own networks and could use them as they saw fit.<br>
>><br>
>> It's still got its uses - for instance, it's nice that the metadata<br>
>> server can be sure that a request is really coming from where it<br>
>> claims - but I would very much like it to be possible to, as an<br>
>> option, explicitly disable antispoof - perhaps on a per-network basis<br>
>> at network creation time - and I think we could do this without<br>
>> breaking the security model beyond all hope of usefulness.<br>
><br>
> Per network and per port makes sense.<br>
><br>
> After all, this is conceptually the same as enabling or disabling<br>
> port security on your switch.<br>
<br>
</div>Bit late on the reply to this, but I think we should be specific on<br>
the network, at least at creation time, on what disabling is allowed<br>
at port level (default off, may be off, must be on as now). Yes, it's<br>
exactly like disabling port security, and you're not always the<br>
administrator of your own switch; if we extend the analogy you<br>
probably wouldn't necessarily want people turning antispoof off on an<br>
explicitly shared-tenant network.<br>
<div><div>--<br>
Ian.<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>