[openstack-dev] [Kuryr] IPVLAN data path proposal
Liping Mao (limao)
limao at cisco.com
Wed Sep 14 05:52:53 UTC 2016
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.
Regards,
Liping Mao
From: Vikas Choudhary <choudharyvikas16 at gmail.com<mailto:choudharyvikas16 at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: 2016年9月14日 星期三 下午1:10
To: OpenStack List <openstack-dev at lists.openstack.org<mailto: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<mailto:choudharyvikas16 at gmail.com>> wrote:
On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <limao at cisco.com<mailto: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<mailto:choudharyvikas16 at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: 2016年9月14日 星期三 上午11:50
To: OpenStack List <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto:limao at cisco.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: 2016年9月13日 星期二 下午9:09
To: OpenStack List <openstack-dev at lists.openstack.org<mailto: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<mailto: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]
Sent: Tuesday, September 13, 2016 12:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org<mailto: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<mailto: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-shaping-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<mailto: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<mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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/4a9e1602/attachment.html>
More information about the OpenStack-dev
mailing list