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" <[email protected]> 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 > [email protected] > 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 <[email protected]>: > >> 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 <[email protected]> >> 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 >>> [email protected] >>> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
