Open Stack

Just to be clear, it's not random. It follows a masking pattern so it is
possible to know which address a given VNI will use. And if you use a /8
prefix the VNIs will have a straightforward 1:1 mapping to multicast
addresses.
On Jun 6, 2016 01:35, "Jiří Kotlín" <jiri.kotlin at ultimum.io> wrote:

> Hi,
>
> yes sorry - I was not concrete enough and the RFE should really be
> reworded.
>
> Our goal is to have the  ability to control vni-multicast address
> distribution somehow, not randomly.
>
> Considering multiple addresses support is already implemented in linux
> bridge agent, I suppose implementing this feature should not cause any
> problems.
>
> Thanks a lot for this hint and reply, I have tested the CIDR feature, but
> forgot to mention this in RFE.
>
> Jiří Kotlín
> Developer
>
> Ultimum Technologies s.r.o.
> Na Poříčí 1047/26, 11000 Praha 1
> Czech Republic
>
> +420 602 288 358
> jiri.kotlin at ultimum.io
> https://ultimum.io <http://ultimum.io>
>
> linkedin <https://www.linkedin.com/company/ultimum-technologies> | twitter
> <https://twitter.com/ultimumtech> | facebook
> <https://www.facebook.com/ultimumtechnologies/timeline> | google+
> <https://plus.google.com/+Ultimumtechnologies001/posts>
>
> 2016-06-06 9:36 GMT+02:00 Kevin Benton <kevin at benton.pub>:
>
>> The linux bridge agent does support using multiple VXLAN groups. You can
>> specify a prefix for 'vxlan_group' and the VNIs will be spread across the
>> multicast addresses in that prefix.[1]
>>
>> The only difference between that and what your RFE proposes is specific
>> control over which multicast address is associated with each VNI. If that
>> is a specific requirement, then the RFE needs to be reworded because that
>> is the only difference between your proposal and what we have now for Linux
>> Bridge.
>>
>>
>> 1.
>> https://github.com/openstack/neutron/blob/d8ae9cf4755416ca65108112a60e8b2e67607daf/neutron/plugins/ml2/drivers/linuxbridge/agent/common/config.py#L34-L42
>>
>> On Mon, Jun 6, 2016 at 12:06 AM, Jiří Kotlín <jiri.kotlin at ultimum.io>
>> wrote:
>>
>>> Hi linuxbridge experts,
>>>
>>> the ability to define multiple VXLAN groups can be very useful in
>>> practice. Is there any design rationale why the vxlan_group was considered
>>> a single attribute?
>>>
>>> More info is in this RFE:
>>> https://bugs.launchpad.net/bugs/1579068
>>>
>>> Thank you in advance for any help you can provide.
>>>
>>>
>>> Jiří Kotlín
>>> Developer
>>>
>>> Ultimum Technologies s.r.o.
>>> Na Poříčí 1047/26, 11000 Praha 1
>>> Czech Republic
>>>
>>> +420 602 288 358
>>> jiri.kotlin at ultimum.io
>>> https://ultimum.io <http://ultimum.io>
>>>
>>> linkedin <https://www.linkedin.com/company/ultimum-technologies> |
>>> twitter <https://twitter.com/ultimumtech> | facebook
>>> <https://www.facebook.com/ultimumtechnologies/timeline> | google+
>>> <https://plus.google.com/+Ultimumtechnologies001/posts>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160606/a81ccdf0/attachment.html>