Hi Jan, Thank you for your reply, it is very interesting. As the subject shows, we are interested in finding traffic processing/routing solution for Telco clouds, i.e. NFV (vEPC, vCPE, vDPI, etc.). Pure L3 oriented implementation of Calico seems very attractive. Many VNFs use SR-IOV to improve throughput, decrease latency, as you correctly noticed.
We are trying to avoid usage of any additional devices/services/instances, because of, obviously, additional forwarding point/PoF, and to be able to implement software-only solution, which would be able to work in any environment. I'm not sure I understand you correctly about "refactor of the Felix daemon into separated services". Could you please detail this? The main problem I see here is a host has to be a gateway for all VLANs, allowed on SR-IOV VF, attached to VM. VM puts VLAN tags on traffic by itself, thus the host has to be in these VLANs in order to intercept ARP requests. It is still unclear for me how to make BGP peering with e.g. RR in that case. And how to isolate traffic of the VLANs. Usually in Telco networks, there are several VRFs which are used for different types of traffic (e.g. Internet, internal signaling, billing, etc.). How does Calico propose handling such setups? Using security policies with firewalling all "cross-vrf" traffic? Thank you. Regards, Anton. 2015-11-03 12:20 GMT+03:00 Jan Ivar Beddari <jani...@beddari.net>: > On 11/03/2015 09:58 AM, Anton Rozhkov wrote: > > Hi everybody, > > > > I'd like to know whether Project Calico supports workloads, which use > > SR-IOV VF interfaces for traffic forwarding. > Hi Anton, > > no, at the moment it does not. But as far as I know our group is one of > several interested users, and I've just come home from OpenStack Summit in > Tokyo where this was a hot topic for us. In short, we are researching a > design where SR-IOV "VLAN channels" are used as Neutron subports - in our > use case, this would be done by running a Felix daemon in the control pane > of our Cumulus-based L3 switches. The idea is to then route all traffic > using the hardware router on the switch. Calico or Felix does not support > this configuration yet but as far as we can see the model supports it well, > and implementing it should be possible even with limited resources. > > If you don't have the option of running Felix on the switch control pane > it becomes a larger task, but still doable. A refactor of the Felix daemon > into separated services would make this easier. > > A solution that uses SR-IOV to connect instances to a routed fabric seems > like it will enable more latency-bound workloads for us. We got quite some > interest from internal research/science projects on this. Really interested > in any more information you could provide about your use case. > > best regards, > Jan Ivar Beddari, UH IaaS (Norwegian academic community cloud) >
_______________________________________________ calico-tech mailing list calico-tech@lists.projectcalico.org http://lists.projectcalico.org/mailman/listinfo/calico-tech_lists.projectcalico.org
