Hi,

I have completely missed this discussion as it does not have quantum/Neutron in 
the subject (modify it now)
I think that the security group is the right place to control this.
I think that this might be only allowed to admins.

Let me explain what we need which is more than just disable spoofing.

1.       Be able to allow MACs which are not defined on the port level to 
transmit packets (for example VRRP MACs)== turn off MAC spoofing

2.       Be able to allow IPs which are not defined on the port level to 
transmit packets (for example, IP used for HA service that moves between an HA 
pair) == turn off IP spoofing

3.       Be able to allow broadcast message on the port (for example for VRRP 
broadcast) == allow broadcast.


Regards,
                -Sam.


From: Aaron Rosen [mailto:aro...@nicira.com]
Sent: Friday, July 19, 2013 3:26 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Chalenges with highly available service VMs

Yup:
I'm definitely happy to review and give hints.
Blueprint:  
https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit

https://review.openstack.org/#/c/19279/  < patch that merged the feature;
Aaron

On Thu, Jul 18, 2013 at 5:15 PM, Ian Wells 
<ijw.ubu...@cack.org.uk<mailto:ijw.ubu...@cack.org.uk>> wrote:
On 18 July 2013 19:48, Aaron Rosen 
<aro...@nicira.com<mailto:aro...@nicira.com>> wrote:
> Is there something this is missing that could be added to cover your use
> case? I'd be curious to hear where this doesn't work for your case.  One
> would need to implement the port_security extension if they want to
> completely allow all ips/macs to pass and they could state which ones are
> explicitly allowed with the allowed-address-pair extension (at least that is
> my current thought).
Yes - have you got docs on the port security extension?  All I've
found so far are
http://docs.openstack.org/developer/quantum/api/quantum.extensions.portsecurity.html
and the fact that it's only the Nicira plugin that implements it.  I
could implement it for something else, but not without a few hints...
--
Ian.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Reply via email to