[openstack-dev] Openstack support for bump-in-the-wire functions

Farhad Sunavala fsbiz at yahoo.com
Mon Jun 6 21:39:36 UTC 2016


Hi Sean,
networking-sfc does not support bump-in-the-wire functions currently as I mentioned.The service functions are essentially L3 (ie. the MAC destination address is changed to the SF and the service function then sources the packet with its MAC address).
What I am looking for is bump-in-the-wire service functions that pass the original packetuntouched.
This is what networking-sfc does currently and does it really well.
A     SF      B|      |    |       |1    2   3      4-----------------OVS
A sends packet to B with dst MAC = B and src MAC = Aflow-classifier matches the packet and realizes it needs to be sent to SF (service function).networking-sfc changes the MAC DA to SF and send the packet to OF port 2.SF does its work on the packet and sends it out to port 3 with src MAC = SF.This is perfectly fine and normal operation and networking-sfc does it great.




Now, imagine if "SF" were a bump-in-the-wire function (ie. receives a packet, does its work onthe packet and then sends the packet unmodified to B).A     SF      B|      |    |       |1    2   3      4-----------------OVS

So, with bump-in-the-wire, following happensA sends packet to B with dst MAC = B and src MAC = A.flow-classifier matches the packet and realizes it needs to be sent to SF (service function).Packet is sent unmodified to SF (dst MAC=B and src MAC=A).on OP port 2.SF does its work on the packet and sends it to OF port 3 unmodified (dst MAC=B, and src MAC=A).
Now, following issues comes into play.1. bridge learning gone bad.On br-int (OVS), when the packet hits any flow with NORMAL action, it will learn the SRC MAC address of the packet and the port it arrived on.  First, it learnt that src MAC A is on port 1,when SF sends the packet back to port 3, br-int will now think that src MAC A is on port 3.
2. Infinite loop issues.BUM (broadcast/unicast/multicast) packets flooded to SF will essentially go in an infinite loopunless proper flows are inserted to avoid them being sent to SF.
This is not really a service chain issue but a basic issue of how to support bump-in-the-wire functionswith Openstack using OVS as the ML2 plugin.
thanks,Farhad.










 

    On Monday, June 6, 2016 1:43 PM, Sean M. Collins <sean at coreitpro.com> wrote:
 

 Take a look at the networking-sfc project.
-- 
Sean M. Collins


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160606/b658ae91/attachment.html>


More information about the OpenStack-dev mailing list