"dev" <dev-boun...@openvswitch.org> wrote on 07/12/2016 09:54:46 PM:
> From: Farhad Sunavala <fs...@yahoo.com> > To: "dev@openvswitch.org" <dev@openvswitch.org> > Date: 07/12/2016 09:55 PM > Subject: [ovs-dev] SFC ACL and Flow Classifier > Sent by: "dev" <dev-boun...@openvswitch.org> > > Hi John: > Please see inline for FS: > Message: 3 > Date: Tue, 12 Jul 2016 22:32:58 +0000 > From: John McDowall <jmcdow...@paloaltonetworks.com> > To: "dev@openvswitch.org" <dev@openvswitch.org> > Subject: [ovs-dev] SFC ACL and Flow Classifier > Message-ID: <d3a968e2.6225%jmcdow...@paloaltonetworks.com> > Content-Type: text/plain; charset="iso-8859-1" > > > Based on Ryan's suggestions, here is my proposal for implementing > the SFC flowClassifier as ACLs. I wanted to get some feedback before > I get into another round of changes in the code. > > Currently I have implemented SFC by adding a new table (ls_in_chain) > in the ova-stage of ovn-northd.c as follows: > > /* Logical switch ingress stages. */ \ > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_L2, 0, "ls_in_port_sec_l2") \ > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_IP, 1, "ls_in_port_sec_ip") \ > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_ND, 2, "ls_in_port_sec_nd") \ > PIPELINE_STAGE(SWITCH, IN, PRE_ACL, 3, "ls_in_pre_acl") \ > PIPELINE_STAGE(SWITCH, IN, ACL, 4, "ls_in_acl") \ > PIPELINE_STAGE(SWITCH, IN, ARP_RSP, 5, "ls_in_arp_rsp") \ > PIPELINE_STAGE(SWITCH, IN, CHAIN, 6, "ls_in_chain") \ > PIPELINE_STAGE(SWITCH, IN, L2_LKUP, 7, "ls_in_l2_lkup") \ Unfortunately, you need to revisit the current table makeup because it's a bit different now and I'm not 100% sure where I'd put the chain > In that table I insert four rules, two for the ingress direction and > two for the egress direction. The pseudo code for the rules is as follows: > > Ingress Direction > > Rule 1: Priority 100: if [ dst_ip == flow classifier source ] then > [send to first input port of chain] > FS: So, this rule will be applied to all compute hosts. networking- > sfc forces user to input --logical-source-port so that you can > narrow down the source of the incoming traffic and apply the rule to > only that host. While that is a potential optimization, I'd save it for a later day. > Also, just matching on dst_ip is too general. Why not match on the > entire classifier?What is there are 2 types of traffic going to > destinationand they have to be chained differently? E.g. TCP and > UDP traffic need to be chained differently. Yes, matching should be on the whole classifier... > > Rule 2: Priority 150: if [ dst_ip == flow classifier source && > in_port == chain out_port ] then [send to next chain in_port] > (if out_port is last port-pair in ingress direction then send to > flow classifier source port) > > FS: OK.Same comment as above for matching on the entire flow classifier. Once I'm in the flow chain, I'm not quite sure why I need to keep matching the flow classifier... > > Egress Direction > > Rule 3: Priority 125: if [ src_ip == flow classifier source ] then > [send to first output port of chain] > FS: I think I follow what you are trying to do (reverse direction > chaining) but I'm not too clear. > > What if my flow-classifier is as follows:ip.src = 192.168.0.3, > ip.dst = 192.168.0.4, and service function in the chain is 192.168.0.5 > A packet matching ip.dst will hit on ingress chain, set logical > destination index to in_port of sf1 and then progress to egress > chain. Here is will hit the egress rule and get redirected to > out_portof sf1. Or is my understanding incorrect ? I would think it would be easier to code a reverse direction chain as a second set of flow classifiers with the appropriate fields reversed. > Rule 4 Priority 150: if [src_ip == flow classifier source && in_port > == chain in_port ] then [send to next chain out_port] > ( if in_port is in last port-pair in egress direction then send to > final destination ) > > FS: Same comment as above. Ditto my above comment as well. > The design goal is to have Rule 1 and 3 be set as ACL rules, where > the ACL is the flow-classifier for the SFC. > > I propose to remove Rule 1 and 3 from the ls-in-chain table and add > a new ACL action "sfc" so that rules like: > > acl-add lsw0 to-lport 1000 'eth.type == 0x1236 && inport == app-port' sfc > > Will direct the flows into the service chain. > > The SFC action will resubmit the flow to the ls-in-chain table (OVS > table 22 in my current implementation), including the to/from info > to direct to rule 2 or 4. > This approach has the advantage of using any parameter to classify > flows that is supported by OVS/OVN. > > The only area that users need to be careful about is the priority > setting in the ACL rule. If not set correcyl the sfc rule could be > skipped but that is a normal issue with ACL rules. You'll need to look at the current form of the tables as things have gotten different with the addition of LB and stateful processing... Otherwise, modulo my comments above, I'm ok with this... Ryan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
