On Wed, Sep 14, 2016 at 11:22 AM, Liping Mao (limao) <li...@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 <choudharyvika...@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: 2016年9月14日 星期三 下午1:10 > > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal > > > > On Wed, Sep 14, 2016 at 10:33 AM, Vikas Choudhary < > choudharyvika...@gmail.com> wrote: > >> >> >> On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <li...@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 <choudharyvika...@gmail.com> >>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >>> Date: 2016年9月14日 星期三 上午11:50 >>> >>> To: OpenStack List <openstack-dev@lists.openstack.org> >>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal >>> >>> >>> >>> On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <li...@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 <li...@cisco.com> >>>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >>>> Date: 2016年9月13日 星期二 下午9:09 >>>> To: OpenStack List <openstack-dev@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.loughn...@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:li...@cisco.com <li...@cisco.com>] >>>> *Sent:* Tuesday, September 13, 2016 12:56 PM >>>> *To:* OpenStack Development Mailing List (not for usage questions) < >>>> openstack-dev@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.cough...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev