[openstack-dev] [Kuryr] IPVLAN data path proposal

Vikas Choudhary choudharyvikas16 at gmail.com
Wed Sep 14 06:33:17 UTC 2016


On Wed, Sep 14, 2016 at 11:22 AM, Liping Mao (limao) <limao at cisco.com>
wrote:

> You have a valid point regarding ipvlan support in newer kernel versions
>> but IIUC overlay mode might not help if nic has a limit on max number of
>> macs that it supports in hardware.
>>
>    for example: http://www.brocade.com/content/html/en/
> configuration-guide/fastiron-08030b-securityguide/GUID-
> ED71C989-6295-4175-8CFE-7EABDEE83E1F.html
> <http://www.brocade.com/content/html/en/configuration-guide/fastiron-08030b-securityguide/GUID-ED71C989-6295-4175-8CFE-7EABDEE83E1F.html>
> Thanks vikas point out this.  Yes, It may cause problem if the mac of
> containers expose to hardware switch.
> In overlay case, AFAIK, hw should not learn container mac as it is in
> vxlan(gre) encapsulation.
>

gotcha, thanks Liping.

What is your opinion on the unicast macs limit that some drivers impose
which can enable promiscous mode on the vm if macvlan interfaces cross a
certain limit and thus may result into performance degradation by accepting
all the multicast/broadcast traffic within subnet ?

ipvlan has problems with dhcp and ipv6. I think its a topic worth
discussing.

-Vikas

>
>
> Regards,
> Liping Mao
>
> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: 2016年9月14日 星期三 下午1:10
>
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>
>
>
> On Wed, Sep 14, 2016 at 10:33 AM, Vikas Choudhary <
> choudharyvikas16 at gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <limao at cisco.com>
>> wrote:
>>
>>> > Though, not the best person to comment on macvlan vs ipvlan, one
>>> limitation of macvlan is that on physical interfaces, maximum possible
>>> number of random mac generations may not cope-up with large number of
>>> containers on same vm.
>>>
>>> Thanks, yes, it is a limitation, Vikas.
>>> This happened if you use vlan as tenant network. If tenant network use
>>> overlay mode, maybe it will be a little bit better for the mac problem.
>>> The reason why I mention macvlan can be one of choice is because ipvlan
>>> need a very new kernel , it maybe a little bit hard to use in prod
>>> env(AFAIK).
>>>
>>
>> You have a valid point regarding ipvlan support in newer kernel versions
>> but IIUC overlay mode might not help if nic has a limit on max number of
>> macs that it supports in hardware.
>>
>    for example: http://www.brocade.com/content/html/en/configuration-
> guide/fastiron-08030b-securityguide/GUID-ED71C989-
> 6295-4175-8CFE-7EABDEE83E1F.html
> <http://www.brocade.com/content/html/en/configuration-guide/fastiron-08030b-securityguide/GUID-ED71C989-6295-4175-8CFE-7EABDEE83E1F.html>
>
>>
>>
>
>>
>>
>>>
>>> Regards,
>>> Liping Mao
>>>
>>> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
>>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Date: 2016年9月14日 星期三 上午11:50
>>>
>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>>
>>>
>>>
>>> On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <limao at cisco.com>
>>> wrote:
>>>
>>>> Hi Ivan and Gary,
>>>>
>>>> maybe we can use macvlan as ipvlan need very new kernel.
>>>> allow-address-pairs can aslo allow different mac in vm.
>>>> Do we consider macvlan here? Thanks.
>>>>
>>>
>>> Though, not the best person to comment on macvlan vs ipvlan, one
>>> limitation of macvlan is that on physical interfaces, maximum possible
>>> number of random mac generations may not cope-up with large number of
>>> containers on same vm.
>>>
>>>
>>>>
>>>> Regards,
>>>> Liping Mao
>>>>
>>>> From: Liping Mao <limao at cisco.com>
>>>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>>> Date: 2016年9月13日 星期二 下午9:09
>>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>>>
>>>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>>>
>>>> Hi Gary,
>>>>
>>>> I mean maybe that can be one choice in my mind.
>>>>
>>>> Security Group is for each neutron port,in this case,all the docker on
>>>> one vm will share one neutron port(if I understand correct),then they will
>>>> share the security group on that port,it is not per container per security
>>>> group,not sure how to use security group in this case?
>>>>
>>>> Regards,
>>>> Liping Mao
>>>>
>>>> 在 2016年9月13日,20:31,Loughnane, Gary <gary.loughnane at intel.com> 写道:
>>>>
>>>> Hi Liping,
>>>>
>>>>
>>>>
>>>> Thank you for the feedback!
>>>>
>>>>
>>>>
>>>> Do you mean to have disabled security groups as an optional
>>>> configuration for Kuryr?
>>>>
>>>> Do you have any opinion on the consequences/acceptability of disabling
>>>> SG?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gary
>>>>
>>>>
>>>>
>>>> *From:* Liping Mao (limao) [mailto:limao at cisco.com <limao at cisco.com>]
>>>> *Sent:* Tuesday, September 13, 2016 12:56 PM
>>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>>> openstack-dev at lists.openstack.org>
>>>> *Subject:* Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>>>
>>>>
>>>>
>>>> Hi Ivan,
>>>>
>>>>
>>>>
>>>> It sounds cool!
>>>>
>>>>
>>>>
>>>> for security group and allowed address pair,
>>>>
>>>> Maybe we can disable port-security,because all the docker in one vm
>>>> will share one security group on the vm port. I'm not sure how to use sg
>>>> for each docker,maybe just disable port-security can be one of the
>>>> choice. then do not need allowed address pairs in this case.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Lipimg Mao
>>>>
>>>>
>>>> 在 2016年9月12日,19:31,Coughlan, Ivan <ivan.coughlan at intel.com> 写道:
>>>>
>>>>
>>>>
>>>> *Overview*
>>>>
>>>> Kuryr proposes to address the issues of double encapsulation and
>>>> exposure of containers as neutron entities when containers are running
>>>> within VMs.
>>>>
>>>> As an alternative to the vlan-aware-vms and use of ovs within the VM,
>>>> we propose to:
>>>>
>>>> -          Use allowed-address-pairs configuration for the VM neutron
>>>> port
>>>>
>>>> -          Use IPVLAN for wiring the Containers within VM
>>>>
>>>>
>>>>
>>>> In this way:
>>>>
>>>> -          Achieve efficient data path to container within VM
>>>>
>>>> -          Better leverage OpenStack EPA(Enhanced Platform Awareness)
>>>> features to accelerate the data path (more details below)
>>>>
>>>> -          Mitigate the risk of vlan-aware-vms not making neutron in
>>>> time
>>>>
>>>> -          Provide a solution that works on existing and previous
>>>> openstack releases
>>>>
>>>>
>>>>
>>>> This work should be done in a way permitting the user to optionally
>>>> select this feature.
>>>>
>>>>
>>>>
>>>>
>>>> *Required Changes*
>>>>
>>>> The four main changes we have identified in the current kuryr codebase
>>>> are as follows:
>>>>
>>>> ·         Introduce an option of enabling “IPVLAN in VM” use case.
>>>> This can be achieved by using a config file option or possibly passing a
>>>> command line argument. The IPVLAN master interface must also be identified.
>>>>
>>>> ·         If using “IPVLAN in VM” use case, Kuryr should no longer
>>>> create a new port in Neutron or the associated VEth pairs. Instead, Kuryr
>>>> will create a new IPVLAN slave interface on top of the VM’s master
>>>> interface and pass this slave interface to the Container netns.
>>>>
>>>> ·         If using “IPVLAN in VM” use case, the VM’s port ID needs to
>>>> be identified so we can associate the additional IPVLAN addresses with the
>>>> port. This can be achieved by querying Neutron’s show-port function and
>>>> passing the VMs IP address.
>>>>
>>>> ·         If using “IPVLAN in VM” use case, Kuryr should associate the
>>>> additional IPVLAN addresses with the VMs port. This can be achieved using
>>>> Neutron’s allowed-address-pairs flag in the port-update function. We
>>>> intend to make use of Kuryr’s existing IPAM functionality to request these
>>>> IPs from Neutron.
>>>>
>>>>
>>>>
>>>> *Asks*
>>>>
>>>> We wish to discuss the pros and cons.
>>>>
>>>> For example, containers exposure as proper neutron entities and the
>>>> utility of neutron’s allowed-address-pairs is not yet well understood.
>>>>
>>>>
>>>>
>>>> We also wish to understand if this approach is acceptable for kuryr?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *EPA*
>>>>
>>>> The Enhanced Platform Awareness initiative is a continuous program to
>>>> enable fine-tuning of the platform for virtualized network functions.
>>>>
>>>> This is done by exposing the processor and platform capabilities
>>>> through the management and orchestration layers.
>>>>
>>>> When a virtual network function is instantiated by an Enhanced Platform
>>>> Awareness enabled orchestrator, the application requirements can be more
>>>> efficiently matched with the platform capabilities.
>>>>
>>>> http://itpeernetwork.intel.com/openstack-kilo-release-is-sha
>>>> ping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>>>>
>>>> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>>>>
>>>> https://www.brighttalk.com/webcast/12229/181563/epa-features
>>>> -in-openstack-kilo
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ivan….
>>>>
>>>> --------------------------------------------------------------
>>>> Intel Research and Development Ireland Limited
>>>> Registered in Ireland
>>>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>>>> Registered Number: 308263
>>>>
>>>> This e-mail and any attachments may contain confidential material for
>>>> the sole use of the intended recipient(s). Any review or distribution by
>>>> others is strictly prohibited. If you are not the intended recipient,
>>>> please contact the sender and delete all copies.
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> 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
>>>>
>>>> --------------------------------------------------------------
>>>> Intel Research and Development Ireland Limited
>>>> Registered in Ireland
>>>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>>>> Registered Number: 308263
>>>>
>>>> This e-mail and any attachments may contain confidential material for
>>>> the sole use of the intended recipient(s). Any review or distribution by
>>>> others is strictly prohibited. If you are not the intended recipient,
>>>> please contact the sender and delete all copies.
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> 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.op
>>>> enstack.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.op
>>> enstack.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/20160914/b20e7723/attachment.html>


More information about the OpenStack-dev mailing list