Open Stack

Yes, there's really a need for mechanisms of high availability like
corosync, vrrp etc. Another simple example: we have two servers with the
active/standby HA configuration  (for example keepalived + haproxy) and we
have third-party monitoring system for these servers. The monitoring system
gets some load metrics and when one of the servers is unavailable, the
monitoring system scales architecture (adds new server to cluster) in this
way saving the HA architecture. In your case, this monitoring system must
do the following steps: create new instance, add new instance's MAC address
to allowed_address_pairs and only after that reconfigure all other nodes.
Otherwise cluster will not work. The solution to the problem is simple -
disable the prevent ARP spoofing mechnism.

Ok, we may used port_security options for this network with the HA cluster.
For this case we must reconfigure our monitoring systems, create
allowed_address_pairs for all current servers and (it's hardest) train our
users how that done.

Currently, we don't use the prevent ARP spoofing option
(prevent_arp_spoofing = False) and honestly I don't understand why this
option is enabled as default in private networks. Each such network belongs
to one user, who controls all instances. Who would decide to perform a MITM
attack in his own network?

2018-03-19 12:53 GMT+03:00 Kevin Benton <kevin at benton.pub>:

> Do you need to spoof arbitrary addresses? If not (i.e. a set you know
> ahead of time), you can put entries in the allowed_address_pairs field of
> the port that will allow you to send traffic using other MAC/IPs.
>
> On Mar 19, 2018 8:42 PM, "Vadim Ponomarev" <ponomarev at selectel.ru> wrote:
>
> Hi,
>
> I support, that is a problem. It's unclear, how after removing the option
> prevent_arp_spoofing, I can manage the prevent ARP spoofing mechanism.
> Example: I use security groups but I don't want to use ARP spoofing
> protection. How do I can disable the protection?
>
> 2018-03-14 10:26 GMT+03:00 Tatiana Kholkina <holkina at selectel.ru>:
>
>> Sure, there is an ability to enable ARP spoofing for the port/network,
>> but it is impossible to make it enabled by default for all ports.
>> It looks a bit complicated to me and I think it would be better to have
>> an ability to set default port security via config file.
>>
>> Best regards,
>> Tatiana
>>
>> 2018-03-13 15:10 GMT+03:00 Claudiu Belu <cbelu at cloudbasesolutions.com>:
>>
>>> Hi,
>>>
>>> Indeed ARP spoofing is prevented by default, but AFAIK, if you want it
>>> enabled for a port / network, you can simply disable the security groups on
>>> that neutron network / port.
>>>
>>> Best regards,
>>>
>>> Claudiu Belu
>>>
>>> ------------------------------
>>> *From:* Татьяна Холкина [holkina at selectel.ru]
>>> *Sent:* Tuesday, March 13, 2018 12:54 PM
>>> *To:* openstack-dev at lists.openstack.org
>>> *Subject:* [openstack-dev] [neutron] Prevent ARP spoofing
>>>
>>> Hi,
>>> I'm using an ocata release of OpenStack where the option
>>> prevent_arp_spoofing can be managed via conf. But later in pike it was
>>> removed and it was decided to prevent spoofing by default.
>>> There are cases where security features should be disabled. As I can see
>>> now we can use a port_security option for these cases. But this option
>>> should be set for a particular port or network on create. The default value
>>> is set to True [1] and itt is impossible to change it. I'd like to
>>> suggest to get default value for port_security [2] from config option.
>>> It would be nice to know your opinion.
>>>
>>> [1] https://github.com/openstack/neutron-lib/blob/
>>> stable/queens/neutron_lib/api/definitions/port_security.py#L21
>>> [2] https://github.com/openstack/neutron/blob/stable/
>>> queens/neutron/objects/extensions/port_security.py#L24
>>>
>>> Best regards,
>>> Tatiana
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Vadim Ponomarev
> Developer of network automation department at Selectel Ltd.
>
> ----
> This message may contain confidential information that can't be
> distributed without the consent of the sender or the authorized person Selectel
> Ltd.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Vadim Ponomarev
Developer of network automation department at Selectel Ltd.

----
This message may contain confidential information that can't be distributed
without the consent of the sender or the authorized person Selectel Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180319/4c8e4093/attachment-0001.html>