Re: [ovs-dev] [OVN] SFC Day in the Life of Packet (with markdown)
Ben, I have added a pre-amble around why SFC and did some minor cleanup. Let me know if it makes sense and if you think more would help. Regards John Begin Markdown (Github Formatted) # Day in the life of a packet for service chains. ## SFC Rational The goal of adding service function chaining (SFC) to OVN/OVS is to enable a set of use cases, primarily in the security area. Additionally, any network function that needs to be inserted in the traffic path to inspect and/or enhance network payloads would be able to leverage this capability. A simple example would be video encoding/decoding or other forms of content enhancement. A primary goal of the SFC design is simplicity of both use and requirements on virtual network functions (VNF) that leverage the feature over extensive features. SFC provides the ability to insert any VNF into the path of traffic before a virtual workload (virtual machine or container) and apply policy. The only requirement on the VNF is that is support "bump in the wire" or transparent proxy networking. Not having the VNF participate in L2 or L3 networking enables scalable deployment of VNFs and leverages OVNs logical networking capabilities., e.g. if the VNF is moved from hypervisor A to hypervisor B there are no changes required in the VNF only in the OVN/OVS control plane. In large scale deployments this reduction in complexing becomes significant. ## Current Restrictions SFC does not require any additional metadata within OVN/OVS or does it insert any additional protocol headers such as proposed by IETF Network Service Headers (NSH), https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/. Consequently, SFC is a less feature rich solution, but as stated above it is much simpler to use and deploy. ### Supported Features * Arbitrary long chains of VNFs. * Only one chain per workload. * Uses flow classifier implemented in OVN/OVS. * SFC can only support a chain on egress (could support ingress by adding metadata in OVN/OVS). ### Not supported features (supported by NSH) * Arbitrary number of chains per workload. * Chains can be applied in both ingress and egress. * Complex logic with chain (enables graphs of VNFs). * Arbitrary flow classifiers can be used. ## Security Use Cases The primary use case for security VNFs for SFC is to provide visibility and protection for traffic flowing in an East-West direction between both virtual machines and containers. This is required to prevent sophisticated attacks known as Advanced Persistent Threats (APT), that enter a network at an area of weak security, through phishing, social engineering, connect business partner etc, and then move laterally through an organization to reach a high value target. Using SFC it enables organizations to deploy VNFs dynamically with their workloads and integrate security into the deployment process as there is no need to implement complicated L2/L3 networking just a simple insertion of a VNF before a new workload. Leveraging OVN/OVS enables the VNF to be deployed anywhere (does not need to be co-resident with the workload) and the support that OVN/OVS provides for CNM/CNI plugins extends the solution to containers as well as virtual machines. ## Design objectives * No requirements for VNFs to parse specific service chaining headers. Getting all VNF vendors to agree is hard and the additional overhead of additional encap/decap can be high. * Ideally existing VNF vendors can use the solution with no modifications to their VNFs. * No requirements for VNF to participate in networking as the issue of scale in dynamic networks becomes a major issue. Thousands of VMs/Containers and hundreds of VNFs are a problem to manage if the VNFs participate directly in the networking due to the rate of change and the need to maintain consistency. Use "bump in the wire" as the networking model for the VNFs. * Leverage features of the infrastructure as much as possible, e.g. match in OVS/OVN and in future load balancing and Geneve tunnel parameters. * Work with VNFs with one or two data interfaces * Follow the API model proposed by Openstack Networking-SFC project. ## Discussion of MAC Learning Issue There is an issue of a physical switch getting confused with MAC learning with the current approach. This problem arises when a packet exiting a service chain is delivered to a physical switch/network on its way to the final destination. The packet will come to the physical switch port with the source MAC address of the source application but will be coming from an OVS port attached to a VNF if simple forwarding rules are applied. The resolution to this issue is to send the packet back to the source application and send it to the original destination from there. This will address the MAC learning issue provided all the VNFs and the application the service chain is being applied to are virtual. There are two approaches to addressing the issue: 1. Re-circulate the
Re: [ovs-dev] [OVN] SFC Day in the Life of Packet (with markdown)
Ben, Thanks, I will add the additional info as requested. Regards John On 5/30/17, 10:49 AM, "Ben Pfaff" <b...@ovn.org> wrote: On Fri, May 26, 2017 at 05:38:11PM +0000, John McDowall wrote: > > At the request of several people I have put together a few use cases for day in the life of a packet for the service chain approach. I have written it up in markdown format as it is easier to review standalone (IMHO). Once everyone is happy with it I will move in to XML in ovn-architecture.7.xml. > > The following feedback would be useful: > > > 1. Is this the required level of detail? > 2. Any other use cases I should add? > 3. Other details that are missing? > > I have another patch ready to go that includes the latest comments from Mickey but it requires his pipeline extension patch. This is super-detailed, thank you! It is just the kind of information that I like to have as a reference. If I were going to suggest a way to improve it, I would add some introductory material that provides context for SFC and the kinds of applications that typically make use of it, as well as information on which of those applications this implementation does and does not target. I did not read any of this in detail. I'd like to hear feedback from other people who understand the purpose and context of SFC better, because I'm worried that a lot of my thoughts will be essentially nitpicking at the "micro" level without proper attention to the "macro" level. I'll have a look at Mickey's patch now. Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [OVN] SFC Day in the Life of Packet (with markdown)
At the request of several people I have put together a few use cases for day in the life of a packet for the service chain approach. I have written it up in markdown format as it is easier to review standalone (IMHO). Once everyone is happy with it I will move in to XML in ovn-architecture.7.xml. The following feedback would be useful: 1. Is this the required level of detail? 2. Any other use cases I should add? 3. Other details that are missing? I have another patch ready to go that includes the latest comments from Mickey but it requires his pipeline extension patch. Regards John Begin Markdown --- # Day in the life of a packet for service chains. ## Design objectives * No requirement for VNFs to parse specific service chaining headers. Getting all VNF vendors to agree is hard and the additional overhead of additional encap/decap can be high. * Ideally existing VNF vendors can use the solution with no modifications to their VNFs. * No requirements for VNF to participate in networking as the issue of scale in dynamic networks becomes a major issue. Thousands of VMs/Containers and hundreds of VNFs are a problem to manage if the VNFs participate directly in the networking due to the rate of change and the need to maintain consistency. Use "bump in the wire" as the networking model for the VNFs. * Leverage features of the infrastructure as much as possible, e.g. match in OVS/OVN and in future load balancing and Geneve tunnel parameters. * Work with VNFs with one or two data interfaces * Follow the API model proposed by Openstack Networking-SFC project. ## Limitations of Approach The above design objectives do place some constraints on the solution. * Each application port can only have one chain attached to it. * The direction of the chain can only be in one direction. The proposed direction is to the application port. * Path is linear not a graph so good for simpler use cases. ## Discussion of MAC Learning Issue There is an issue of a physical switch getting confused with MAC learning with the current approach. This problem arises when a packet exiting a service chain is delivered to a physical switch/network on its way to the final destination. The packet will come to the physical switch port with the source MAC address of the source application but will be coming from an OVS port attached to a VNF if simple forwarding rules are applied. The resolution to this issue is to send the packet back to the source application and send it to the original destination from there. This will address the MAC learning issue provided all the VNFs and the application the service chain is being applied to are virtual. There are two approaches to addressing the issue: 1. Re-circulate the packet back through the ingress pipeline when it exits the service chain starting at the stage after the service chain (S_SWITCH_IN_CHAIN). If the packet exits the virtual switch to the physical layer (switch) it will have the correct MAC Address for the port it enters the. switch. The issue with this approach is that any metadata accumulated in the stages before (S_SWITCH_IN_CHAIN) will be lost. 2. Re-circulate the packet back through the full ingress pipeline on its way to the original destination from the service chain. This will add a performance penalty to service chaining, but it ensures any metadata generated by the stages before S_SWITCH_IN_CHAIN is correctly dealt with. To skip the skip the S_SWITCH_IN_CHAIN stage the second time through a flag would be set in a register. This would enable the packet to traverse the ingress stages and go the original destination after going through the service chain. This approach adds a performance penalty as it requires the packet to traverse the stages before S_SWITCH_IN_CHAIN twice, but guarantees the metadata is correct after the service chain stage. ### Proposed Resolution While neither approach is ideal, the first approach is workable as there is no metadata that is required by the stages after S_SWITCH_IN_CHAIN, from the stages before S_SWITCH_IN_CHAIN. This might change in the future, at that point additional metadata could be propagated locally by the S_SWITCH_IN_CHAIN stage over GENEVE tunnels. The metadata would not be Network Service Header (NSH) metadata as it would be local to OVN/OVS and not exposed to the VNFs in the service chain. ## Proposed Stages in Switch Pipeline The new stages and their location in the switch ingress and egress pipelines are shown below. The two stages added are S_SWITCH_IN_CHAIN (stage 10) and S_SWITCH_OUT_CHAIN (stage 0). The later stage is a destination stage for the loopback to the initial source application to prevent looping. /* Logical switch ingress stages. */ \ PIPELINE_STAGE(SWITCH, IN, PORT_SEC_L2,0, "ls_in_port_sec_l2") \
[ovs-dev] [OVN] SFC Day in the Life of Packet
At the request of several people I have put together a few use cases for day in the life of a packet for the service chain approach. I have written it up in markdown format as it is easier to review standalone (IMHO). Once everyone is happy with it I will move in to XML in ovn-architecture.7.xml. The following feedback would be useful: 1. Is this the required level of detail? 2. Any other use cases I should add? 3. Other details that are missing? I have another patch ready to go that includes the latest comments from Mickey but it requires his pipeline extension patch. Regards John ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] OVN: Increasing size of Switch Ingress Pipeline Stage Table
With the addition of the DNS stages there are no entries left in the PIPELINE_STAGE, SWITCH IN table. I need one for SFC. As this is a core part of the infrastructure I do not want to make changes without advice from the core OVN team. What is the best approach? Regards John ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] ovn: SFC Patch V3
Mickey,
Thanks for the review. I need some help understanding a couple of things:
1) The proposed change, I could see the previous logic where we inserted
the flow back in the ingress pipeline just after the IN_CHAIN stage. The
changes you suggest seem to imply that the action is still insert after the
_IN_CHAIN stage but in the egress (OUT) pipeline. I am missing something here –
can you give me some more info?
+for (int ii = 0; ii < MFF_N_LOG_REGS; ii++) {
+ds_put_format(, "reg%d = 0; ", ii);
+}
+ds_put_format(, "next(pipeline=ingress, table=%d); };",
+ovn_stage_get_table(S_SWITCH_IN_CHAIN) + 1);
+ovn_lflow_add(lflows, od, S_SWITCH_IN_CHAIN, ingress_inner_priority,
+lcc_match, ds_cstr());
Replace the line above by:
ovn_lflow_add(lflows, od, S_SWITCH_OUT_SFC_LOOPBACK, 100,
lcc_match, ds_cstr());
2) I can try and put some checks in for loop avoidance. Can you think of
scenarios that would cause this, a badly configured port-pair could perhaps
cause it (if the eth egress of the port-pair was configured as the ingress
eth.) Any other scenarios that come to mind ?
Regards
John
From: Mickey Spiegel <mickeys@gmail.com>
Date: Monday, April 24, 2017 at 6:39 PM
To: John McDowall <jmcdow...@paloaltonetworks.com>
Cc: "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org>
Subject: Re: [ovs-dev] ovn: SFC Patch V3
On Mon, Apr 24, 2017 at 12:56 PM,
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote:
From: John McDowall
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
Fixed changes from Mickey's last review.
Changes
1) Fixed re-circulation rules
Still a few modifications required. See comments inline. I just typed some
stuff out, have not run, built, or tested anything.
2) Fixed match statement - match is only applied to beginnning of chain in
each direction.
3) Fixed array length of chain of VNFs. I have tested thi sup to three VNFs
in a chain and it looks like it works in both directions.
Areas to review
1) The logic now supports hair-pinnign the flow back to the original source to
ensure that the MAC learnign problem is addressed. I tested this using
ovn-trace - any better testing that I should do?
Current todo list
1) I have standalone tests need to add tests to ovs/ovn framework.
2) Load-balancing support for port-pair-groups
3) Publish more detailed examples.
4) Submit suggestions to change and shorted the CLI names.
Simple example using ovn-trace
#!/bin/sh
#
clear
ovn-nbctl ls-add swt1
ovn-nbctl lsp-add swt1 swt1-appc
ovn-nbctl lsp-add swt1 swt1-apps
ovn-nbctl lsp-add swt1 swt1-vnfp1
ovn-nbctl lsp-add swt1 swt1-vnfp2
ovn-nbctl lsp-set-addresses swt1-appc "00:00:00:00:00:01 192.168.33.1"
ovn-nbctl lsp-set-addresses swt1-apps "00:00:00:00:00:02 192.168.33.2"
ovn-nbctl lsp-set-addresses swt1-vnfp1 00:00:00:00:00:03
ovn-nbctl lsp-set-addresses swt1-vnfp2 00:00:00:00:00:04
#
# Configure Service chain
#
ovn-nbctl lsp-pair-add swt1 swt1-vnfp1 swt1-vnfp2 pp1
ovn-nbctl lsp-chain-add swt1 pc1
ovn-nbctl lsp-pair-group-add pc1 ppg1
ovn-nbctl lsp-pair-group-add-port-pair ppg1 pp1
ovn-nbctl lsp-chain-classifier-add swt1 pc1 swt1-appc "entry-lport"
"bi-directional" pcc1
#
ovn-sbctl dump-flows
#
# Run trace command
printf "\n-Flow 1 -\n\n"
ovn-trace --detailed swt1 'inport == "swt1-appc" && eth.src ==
00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'
printf "\n-Flow 2 -\n\n"
ovn-trace --detailed swt1 'inport == "swt1-vnfp1" && eth.src ==
00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'
printf "\n-Flow 3 -\n\n"
ovn-trace --detailed swt1 'inport == "swt1-apps" && eth.dst ==
00:00:00:00:00:01 && eth.src == 00:00:00:00:00:02'
printf "\n-Flow 4 -\n\n"
ovn-trace --detailed swt1 'inport == "swt1-vnfp2" && eth.dst ==
00:00:00:00:00:01 && eth.src == 00:00:00:00:00:02'
#
# Cleanup
#
ovn-nbctl lsp-chain-classifier-del pcc1
ovn-nbctl lsp-pair-group-del ppg1
ovn-nbctl lsp-chain-del pc1
ovn-nbctl lsp-pair-del pp1
ovn-nbctl ls-del swt1
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=IVGOl8me3C4dzw8GMHKoxCKC1PfFf10p5EcD8PIGmbI=TRwcbjVrcqErrFP_gC_ZK6axUelonie6aFWbgEx1tpI=>
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.
[ovs-dev] [ovs-dev, RFC] ovn: Revised support for service function chaining
This patch set is an alternative implementation of service function chaining (SFC) for OVS/OVN. The major change from the previous patch is that the overloading of the ACL stage in ovn-northd.c has been removed and replaced with additional logic in the CHAIN stage. This was done to improve modularity of the code as it was felt that overloading the ACL stage did not add a lot and made it hard to compose reusable SFCs. The new approach can still use the matching logic in OVN as a match argument has been added. This has not been fully implemented yet as it may need some error checking to ensure the match does not conflicit with the lport in the chain and the bi-directional case. The other major change is the logic for the final destination of the flows exiting the service chain. This has been simplified such that the rules in the chain stage determine when the flow is exiting the port-chain and then the flow just follows the normal path to the src or dst of the flow. Areas to review 1) Logic for delivering flow after it leaves the chain. I think it is now general and should work across subnets etc. 2) Do the command names make sense - currently rather long and complex. 3) Using the match to classify flows to a finer granularity is mainly useful for uni-directional flows but could lead to conflicits with bi-directional flows (I think) and suggestions on how to make this better would be appreciated. Current todo list 1) I have standalone tests need to add tests to ovs/ovn framework. 2) Add IPv6 support 3) Implement "match" in the CHAIN stage. 4) Load-balancing support for port-pair-groups 5) Publish more detailed examples. Simple test case using ovn-trace #!/bin/sh # clear ovn-nbctl ls-add swt1 ovn-nbctl lsp-add swt1 swt1-appc ovn-nbctl lsp-add swt1 swt1-apps ovn-nbctl lsp-add swt1 swt1-vnfp1 ovn-nbctl lsp-add swt1 swt1-vnfp2 ovn-nbctl lsp-set-addresses swt1-appc "00:00:00:00:00:01 192.168.33.1" ovn-nbctl lsp-set-addresses swt1-apps "00:00:00:00:00:02 192.168.33.2" ovn-nbctl lsp-set-addresses swt1-vnfp1 00:00:00:00:00:03 ovn-nbctl lsp-set-addresses swt1-vnfp2 00:00:00:00:00:04 # # Configure Service chain # ovn-nbctl lsp-pair-add swt1 swt1-vnfp1 swt1-vnfp2 pp1 ovn-nbctl lsp-chain-add swt1 pc1 ovn-nbctl lsp-pair-group-add pc1 ppg1 ovn-nbctl lsp-pair-group-add-port-pair ppg1 pp1 ovn-nbctl lsp-chain-classifier-add swt1 pc1 swt1-appc "exit-lport" "bi-directional" "" pcc1 # ovn-sbctl dump-flows # # Run trace command printf "\n-Flow 1 -\n\n" ovn-trace --detailed swt1 'inport == "swt1-appc" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02 && ip4.src == 192.168.33.1 && ip4.dst == 192.168.33.2' printf "\n-Flow 2 -\n\n" ovn-trace --detailed swt1 'inport == "swt1-vnfp1" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02 && ip4.src == 192.168.33.1 && ip4.dst == 192.168.33.2' printf "\n-Flow 3 -\n\n" ovn-trace --detailed swt1 'inport == "swt1-apps" && eth.dst == 00:00:00:00:00:01 && eth.src == 00:00:00:00:00:02 && ip4.dst == 192.168.33.1 && ip4.src == 192.168.33.2' printf "\n-Flow 4 -\n\n" ovn-trace --detailed swt1 'inport == "swt1-vnfp2" && eth.dst == 00:00:00:00:00:01 && eth.src == 00:00:00:00:00:02 && ip4.dst == 192.168.33.1 && ip4.src == 192.168.33.2' # # Cleanup # ovn-nbctl lsp-chain-classifier-del pcc1 ovn-nbctl lsp-pair-group-del ppg1 ovn-nbctl lsp-chain-del pc1 ovn-nbctl lsp-pair-del pp1 ovn-nbctl ls-del swt1 Co-authored-by: Flavio Fernandes Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html Signed-off-by: John McDowall --- ovn/northd/ovn-northd.8.xml | 60 ++- ovn/northd/ovn-northd.c | 293 ++- ovn/ovn-architecture.7.xml| 91 ovn/ovn-nb.ovsschema | 87 +++- ovn/ovn-nb.xml| 187 +++ ovn/utilities/ovn-nbctl.8.xml | 218 ovn/utilities/ovn-nbctl.c | 1133 + 7 files changed, 2042 insertions(+), 27 deletions(-) diff --git ovn/northd/ovn-northd.8.xml ovn/northd/ovn-northd.8.xml index ab8fd88..f80fcf6 100644 --- ovn/northd/ovn-northd.8.xml +++ ovn/northd/ovn-northd.8.xml @@ -362,7 +362,53 @@ -Ingress Table 7: from-lport QoS marking + Ingress Table 7: from-lport Port Chaining + + + Logical flows in this table closely reproduce those in the + QoS table in the OVN_Northbound database + for the from-lport direction. + + + + +For every port-chain a set of rules will be added to direct traffic +through the
Re: [ovs-dev] SFC patches for OVN
Jason, The SFC implementation expects the node ‘B’ to act as a bump in the wire, “BITW” VNF, i.e. it does not terminate the incoming packets and just passes them from one interface to another. What does your node ‘B” do ? Looking at your scripts you seem to be creating port-pairs for nodes A, B, and C. You only need a port-pair for the VNF and then use the ACL rule to direct traffic to the service chain. Regards John From: Shuaijun Zhang <szh...@research.ait.ie> Date: Tuesday, February 7, 2017 at 2:24 PM To: John McDowall <jmcdow...@paloaltonetworks.com> Cc: "fla...@flaviof.com" <fla...@flaviof.com>, "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, I have attached my setup scripts. The script is basically trying to repeat the demo in your presentation. Because I used docker-overlay, the switch/ports are created while creating the docker containers. That is why these port ID, MAC & IP are manually set in the script. Thanks, Jason On 7 February 2017 at 21:59, Shuaijun Zhang <szh...@research.ait.ie<mailto:szh...@research.ait.ie>> wrote: Hi John, Yes, the port security should be off, otherwise no packet will go through the ports. I double checked my setup, no port security is set to any ports, I also checked the code of ovn-docker-overlay-driver, there is no "lsp-set-port-security" used either in version 2.6.1 or master branch. Basically what I want to achieve is that: Initially message is from node A to node C, but I want the message to be processed by node B then sent to C. For example: a message "1234" is sent from A to C, C receives "1234". But I want the message pass to B first, B adds "56-edited by B" to the message, then C will receive the message "123456-edited by B". Regards, Jason On 7 February 2017 at 21:27, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote: Jason, It is usually set by default so it should return something – it has to be off for VNF ports though. What are you using for a VNF? I have used the docker-overlay driver and it did work – but not recently. Regards John From: Shuaijun Zhang <szh...@research.ait.ie<mailto:szh...@research.ait.ie>> Date: Tuesday, February 7, 2017 at 1:22 PM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> Cc: "fla...@flaviof.com<mailto:fla...@flaviof.com>" <fla...@flaviof.com<mailto:fla...@flaviof.com>>, "ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>" <ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, port-security isn't set for any port, "ovn-nbctl lsp-get-port-security PORTS" returns nothing. Do I need to turn it on for all the VNF ports? Thanks, Jason On 7 February 2017 at 20:51, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote: Jason, Did you turn off port-security for the VNF ports? Regards John From: Shuaijun Zhang <szh...@research.ait.ie<mailto:szh...@research.ait.ie>> Date: Tuesday, February 7, 2017 at 12:48 PM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>, "fla...@flaviof.com<mailto:fla...@flaviof.com>" <fla...@flaviof.com<mailto:fla...@flaviof.com>> Cc: "ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>" <ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, Flavio, I have applied the patches and tried it by following the demo (by Flavio) in the video below: https://www.youtube.com/watch?v=PUZzhRxc6iA<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DPUZzhRxc6iA=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=TAphJtiHLTXpDwCm-ZslrqDvvkGydXkW39KBGGVJWKo=> There is a problem is in my test: the ping message doesn't get replied. In the demo, I see that when computer_1 ping computer_2, you can see the message reaches the ports in the computer_3 and computer_1 can receive the reply. But in my test, message can reach to the ports (port pairs) in computer_3 too, but computer_1 doesn't receive the reply. The difference between my setup and the demo is that I used ovn-docker-overlay-driver to create/bind the ports, and the demo may use script (vagrant) to create/bind ports Steps in my setup: 1. setup the ovn+docker environment by https://github.com/openvswitch/ovs/blob/master/Documentation/howto/docker.rst<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_Documentation_howt
Re: [ovs-dev] SFC patches for OVN
Jason, It is usually set by default so it should return something – it has to be off for VNF ports though. What are you using for a VNF? I have used the docker-overlay driver and it did work – but not recently. Regards John From: Shuaijun Zhang <szh...@research.ait.ie> Date: Tuesday, February 7, 2017 at 1:22 PM To: John McDowall <jmcdow...@paloaltonetworks.com> Cc: "fla...@flaviof.com" <fla...@flaviof.com>, "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, port-security isn't set for any port, "ovn-nbctl lsp-get-port-security PORTS" returns nothing. Do I need to turn it on for all the VNF ports? Thanks, Jason On 7 February 2017 at 20:51, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote: Jason, Did you turn off port-security for the VNF ports? Regards John From: Shuaijun Zhang <szh...@research.ait.ie<mailto:szh...@research.ait.ie>> Date: Tuesday, February 7, 2017 at 12:48 PM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>, "fla...@flaviof.com<mailto:fla...@flaviof.com>" <fla...@flaviof.com<mailto:fla...@flaviof.com>> Cc: "ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>" <ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org>> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, Flavio, I have applied the patches and tried it by following the demo (by Flavio) in the video below: https://www.youtube.com/watch?v=PUZzhRxc6iA<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DPUZzhRxc6iA=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=TAphJtiHLTXpDwCm-ZslrqDvvkGydXkW39KBGGVJWKo=> There is a problem is in my test: the ping message doesn't get replied. In the demo, I see that when computer_1 ping computer_2, you can see the message reaches the ports in the computer_3 and computer_1 can receive the reply. But in my test, message can reach to the ports (port pairs) in computer_3 too, but computer_1 doesn't receive the reply. The difference between my setup and the demo is that I used ovn-docker-overlay-driver to create/bind the ports, and the demo may use script (vagrant) to create/bind ports Steps in my setup: 1. setup the ovn+docker environment by https://github.com/openvswitch/ovs/blob/master/Documentation/howto/docker.rst<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_Documentation_howto_docker.rst=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=SHGJ0-5GFfl0GzF8Q_F4SxKpkC7FEwWadV24v_K1wdk=> 2. create 7 containers on 4 hosts (c1 on host1, c2 on host2, c3 on host3, c4/c5/c6/c7 on host4), each container has one port bound. e.g. p1 on c1, p2 on c2 ... 3. Then I create pair ports, port groups, etc. same as in the demo. (p4 is the vnfa in the demo, p5 & p6 are the vnfb in the demo, p7 is vnfc). I can see that the "ovn-sbctl dump-flows" gives same rules as in the demo, ovn-trace results same as in the demo 4. Then ping from c1 to c2, the message shows in c4 (port pair "vnfa"), but c2 doesn't receive the ping msg, and c1 doesn't receive the reply. (I used "tcpdump" to monitor the eth interfaces) Do you have any idea about this problem? @Flavio, There may be something missing in my setup. So can I have the script you used in the demo to repeat your setup, if appropriate. Please. Thank you, Jason On 3 February 2017 at 20:58, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote: Jason, I checked it against top of the git tree. So just download the patch and clone the lastest and then $ git apply –directory=ovn If you have any questions/feedback let me know. Regards John ___ dev mailing list d...@openvswitch.org<mailto:d...@openvswitch.org> https://mail.openvswitch.org/mailman/listinfo/ovs-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=Fq8yDdsY-uYJ5RNltm7eW3zcgU5lQnukR-xj5WRVHJI=> -- Shuaijun (Jason) Zhang Senior Research Engineer Software Research Institute, Athlone Institute of Technology, IE Tel: +353 90 646 8196<tel:+353%2090%20646%208196> http://www.ait.ie/sri/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ait.ie_sri_=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_
Re: [ovs-dev] SFC patches for OVN
Jason, Did you turn off port-security for the VNF ports? Regards John From: Shuaijun Zhang <szh...@research.ait.ie> Date: Tuesday, February 7, 2017 at 12:48 PM To: John McDowall <jmcdow...@paloaltonetworks.com>, "fla...@flaviof.com" <fla...@flaviof.com> Cc: "ovs-dev@openvswitch.org" <ovs-dev@openvswitch.org> Subject: Re: [ovs-dev] SFC patches for OVN Hi John, Flavio, I have applied the patches and tried it by following the demo (by Flavio) in the video below: https://www.youtube.com/watch?v=PUZzhRxc6iA<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DPUZzhRxc6iA=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=TAphJtiHLTXpDwCm-ZslrqDvvkGydXkW39KBGGVJWKo=> There is a problem is in my test: the ping message doesn't get replied. In the demo, I see that when computer_1 ping computer_2, you can see the message reaches the ports in the computer_3 and computer_1 can receive the reply. But in my test, message can reach to the ports (port pairs) in computer_3 too, but computer_1 doesn't receive the reply. The difference between my setup and the demo is that I used ovn-docker-overlay-driver to create/bind the ports, and the demo may use script (vagrant) to create/bind ports Steps in my setup: 1. setup the ovn+docker environment by https://github.com/openvswitch/ovs/blob/master/Documentation/howto/docker.rst<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_Documentation_howto_docker.rst=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=SHGJ0-5GFfl0GzF8Q_F4SxKpkC7FEwWadV24v_K1wdk=> 2. create 7 containers on 4 hosts (c1 on host1, c2 on host2, c3 on host3, c4/c5/c6/c7 on host4), each container has one port bound. e.g. p1 on c1, p2 on c2 ... 3. Then I create pair ports, port groups, etc. same as in the demo. (p4 is the vnfa in the demo, p5 & p6 are the vnfb in the demo, p7 is vnfc). I can see that the "ovn-sbctl dump-flows" gives same rules as in the demo, ovn-trace results same as in the demo 4. Then ping from c1 to c2, the message shows in c4 (port pair "vnfa"), but c2 doesn't receive the ping msg, and c1 doesn't receive the reply. (I used "tcpdump" to monitor the eth interfaces) Do you have any idea about this problem? @Flavio, There may be something missing in my setup. So can I have the script you used in the demo to repeat your setup, if appropriate. Please. Thank you, Jason On 3 February 2017 at 20:58, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote: Jason, I checked it against top of the git tree. So just download the patch and clone the lastest and then $ git apply –directory=ovn If you have any questions/feedback let me know. Regards John ___ dev mailing list d...@openvswitch.org<mailto:d...@openvswitch.org> https://mail.openvswitch.org/mailman/listinfo/ovs-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=Fq8yDdsY-uYJ5RNltm7eW3zcgU5lQnukR-xj5WRVHJI=> -- Shuaijun (Jason) Zhang Senior Research Engineer Software Research Institute, Athlone Institute of Technology, IE Tel: +353 90 646 8196<tel:+353%2090%20646%208196> http://www.ait.ie/sri/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ait.ie_sri_=DwMFaQ=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=s87TOhGERTLi6KqWA4YqAE0g7VZUixH4B_iVh737Yxw=wXWts8zZeenowDVki0tfL2yzp_sNh9a_bWXWWNrXWCk=> ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-dev, RFC] ovn: support for service function chaining
Ben,
Thanks for the thorough review, I will update the code and resubmit the patch.
Any thoughts on the general approach to service chaining etc?
Regards
John
On 2/3/17, 2:10 PM, "Ben Pfaff" <b...@ovn.org> wrote:
On Thu, Feb 02, 2017 at 03:22:56PM -0800, jmcdow...@paloaltonetworks.com
wrote:
> From: John McDowall <jmcdow...@paloaltonetworks.com>
>
> This patchset is the first round at having Service Function Chaining
> functionality through OVN. The implementation is done entirely
> on the northbound side of OVN. It is a bump on the wire implementation,
> so no attempt is being made in keeping state while packets visit each
> hop of the chain. ACLs are used as the classifiers, with the augmentation
> of action SFC, as well as option column.
Thanks for working on this! Sorry it's taken so long to review.
cmp_port_pair_groups() treats two pair groups as equal if either one of
them has no keys, but this violates transitivity (see
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Comparison-5Fsort=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=D8WTzjM4eBLAIUSaMpsuNQPXOo94n7zg2ZjpkjdkW64=BhGNi3da1UI7sRkk29-zyejanKHyZPF_ac-fm2Ctnis=
). Example: if 0 is a pair
group with no keys and x and y are arbitrary pair groups, then this
function will conclude that x <= 0 and 0 <= y. By transitivity, we
would also have x <= y, but that's a contradiction because x and y are
arbitrary.
I suggest that empty pair groups should sort as less than nonempty ones,
e.g.:
@@ -2772,8 +2772,10 @@ cmp_port_pair_groups(const void *ppg1_, const void
*ppg2_)
const struct nbrec_logical_port_pair_group *ppg1 = *ppg1p;
const struct nbrec_logical_port_pair_group *ppg2 = *ppg2p;
-if (ppg1->n_sortkey == 0 || ppg2->n_sortkey == 0) {
-return 0;
+if (ppg1->n_sortkey == 0) {
+return ppg2->n_sortkey == 0 ? -1 : 0;
+} else if (ppg2->n_sortkey == 0) {
+return 1;
}
const int64_t key1 = ppg1->sortkey[0];
ovn-northd.c has some new uses of VLOG without rate-limiters. These
should probably be rate-limited, like most VLOG calls in ovn-northd.
VLOG messages shouldn't include a new-line since VLOG takes care of that
itself.
The code has lots of lines longer than the coding style suggested limit
of 79 columns.
Comments should generally begin with a capital letter and end with a
period.
In build_chain_classifier_entry(), qsort() is a remarkably expensive way
to find the smallest element in an array.
In build_chain_classifier_entry(), it's strange to have "" in the middle
of the string here:
ds_put_format(ds_action, "outport = %s;"" output;",
first_ovn_port->json_key);
In build_chain(), please don't comment out code:
//const uint16_t egress_inner_priority = 150;
In build_chain(), a lot of debug logging has escaped as VLOG_INFO calls.
In build_chain(), you can use xmemdup() instead of xmalloc() followed by
memcpy().
In build_chain(), I don't know why there's a line-splicing \ here:
VLOG_INFO("Warning: Currently lacking support for more
than one port-pair %"PRIuSIZE"\n", \
lppg->n_port_pairs);
Also, we'd usually just use VLOG_WARN instead of writing "Warning:".
In build_chain(), please always put {} around a conditional statement,
e.g. here:
if (!input_port_array[j] || !output_port_array[j])
obtainedAllNeededInfo = false;
Please wrap at 79 columns in ovn-architecture.7.xml as well.
I spent some time with the documentation. I worked on getting rid of
passive voice because it's often unclear, e.g. "something happens"
doesn't tell the reader who does it, but "The CMS does something" does.
I dropped a lot of the items from the life cycle that didn't seem
really relevant to VNFs (it seemed like they were mostly cut-and-paste).
Some of the introductory documentation confuses me though. The
following paragraph mentions about the OVN northbound database but it
seems to actually be about the southbound database. I don't think this
is the right place to explain the logical flows that SFC puts into the
southbound database; that should be in ovn-northd.8.xml instead. I
deleted the following paragraph but presumably it should be adapted for
ovn-nrothd.8.xml:
Service insertion is implemented by adding 4 new flow rules into the OVN
northbound database for
each VNF inserted. The rules are added into
Re: [ovs-dev] SFC patches for OVN
Jason, I checked it against top of the git tree. So just download the patch and clone the lastest and then $ git apply –directory=ovn If you have any questions/feedback let me know. Regards John ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage
Ah, my bad do you want me to create a single patch file?
Regards
John
On 1/31/17, 2:44 PM, "Ben Pfaff" <b...@ovn.org> wrote:
Now that I glance at the patch titles, I guess that the problem might be
that this patch depends on some of the later patches. In general, each
patch should apply, build, and test properly whether or not later
patches have been applied.
On Tue, Jan 31, 2017 at 10:03:21PM +0000, John McDowall wrote:
> Ben,
>
> Let me create a new patch set against the top of tree.
>
> Regards
>
> John
>
> On 1/31/17, 1:46 PM, "Ben Pfaff" <b...@ovn.org> wrote:
>
> On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote:
> > This is the major body of code that implements SFC. There is a new
L2 stage added to
> > perform the chaining operations and modifications to the ACL stage
to direct flows
> > to the service chain.
> >
> > Co-authored-by: Flavio Fernandes
> > Reported at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=VbhqfPkju3uYqy7303Bfbz0fgnSeIi6aYsQoRwIH1PU=
> > Reported at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMay_041359.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=vNieFlb8T7dsSygACJyaJiHvnrQDGCyox17covGw4Ns=
> >
> > Signed-off-by: John McDowall <jmcdow...@paloaltonetworks.com>
>
> I think that this has bit-rotted because I get tons of compiler errors
> trying to build it. I tried rewinding my repo to a point from
December
> but I still the same ones:
>
> ../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition
of type 'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of
'struct nbrec_logical_port_pair_group'
> ../ovn/northd/ovn-northd.c:2701:49: error: no member named
'options' in 'struct nbrec_acl'
> ../ovn/northd/ovn-northd.c:2713:37: error: no member named
'n_port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2714:30: error: no member named
'port_chains' in 'struct nbrec_logical_switch'
> ../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition
of type 'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded
from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded
from macro 'strcmp'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition
of type 'struct nbrec_logical_port_chain'
> /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded
from macro 'strcmp'
> /usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded
from macro '__string2_1bptr_p'
> ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of
'struct nbrec_logical_port_chain'
> ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition
of type 'struct nbrec
Re: [ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage
Ben, Let me create a new patch set against the top of tree. Regards John On 1/31/17, 1:46 PM, "Ben Pfaff" <b...@ovn.org> wrote: On Tue, Dec 27, 2016 at 02:11:43PM -0800, John McDowall wrote: > This is the major body of code that implements SFC. There is a new L2 stage added to > perform the chaining operations and modifications to the ACL stage to direct flows > to the service chain. > > Co-authored-by: Flavio Fernandes > Reported at: https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMarch_040381.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=VbhqfPkju3uYqy7303Bfbz0fgnSeIi6aYsQoRwIH1PU= > Reported at: https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddiscuss_2016-2DMay_041359.html=DwIBAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=0-H45ymu2qKdNfehkwCF8baQWBqDNhngIVaX4MlOpCQ=vNieFlb8T7dsSygACJyaJiHvnrQDGCyox17covGw4Ns= > > Signed-off-by: John McDowall <jmcdow...@paloaltonetworks.com> I think that this has bit-rotted because I get tons of compiler errors trying to build it. I tried rewinding my repo to a point from December but I still the same ones: ../ovn/northd/ovn-northd.c:2669:13: error: incomplete definition of type 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2669:37: error: incomplete definition of type 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2673:30: error: incomplete definition of type 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2674:30: error: incomplete definition of type 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2664:18: note: forward declaration of 'struct nbrec_logical_port_pair_group' ../ovn/northd/ovn-northd.c:2701:49: error: no member named 'options' in 'struct nbrec_acl' ../ovn/northd/ovn-northd.c:2713:37: error: no member named 'n_port_chains' in 'struct nbrec_logical_switch' ../ovn/northd/ovn-northd.c:2714:30: error: no member named 'port_chains' in 'struct nbrec_logical_switch' ../ovn/northd/ovn-northd.c:2716:39: error: incomplete definition of type 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:110:58: note: expanded from macro 'strcmp' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:111:74: note: expanded from macro 'strcmp' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from macro 'strcmp' /usr/include/i386-linux-gnu/bits/string2.h:53:28: note: expanded from macro '__string2_1bptr_p' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:113:28: note: expanded from macro 'strcmp' /usr/include/i386-linux-gnu/bits/string2.h:53:63: note: expanded from macro '__string2_1bptr_p' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:114:31: note: expanded from macro 'strcmp' ../ovn/northd/ovn-northd.c:2710:18: note: forward declaration of 'struct nbrec_logical_port_chain' ../ovn/northd/ovn-northd.c:2721:44: error: incomplete definition of type 'struct nbrec_logical_port_chain' /usr/include/i386-linux-gnu/bits/string2.h:117:28: note: expanded from macro 'strcmp' ../ovn/northd/ovn-northd.c:2710:18: note: forward
[ovs-dev] [RFC PATCH 2/5] OVN: SFC Implementation: New stage for SFC and modified ACL stage
This is the major body of code that implements SFC. There is a new L2 stage
added to
perform the chaining operations and modifications to the ACL stage to direct
flows
to the service chain.
Co-authored-by: Flavio Fernandes
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html
Signed-off-by: John McDowall <jmcdow...@paloaltonetworks.com>
---
ovn/northd/ovn-northd.c | 315 +---
1 file changed, 295 insertions(+), 20 deletions(-)
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index a28327b4d..8afc8a806 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -105,13 +105,14 @@ enum ovn_stage {
PIPELINE_STAGE(SWITCH, IN, PRE_LB, 4, "ls_in_pre_lb")\
PIPELINE_STAGE(SWITCH, IN, PRE_STATEFUL, 5, "ls_in_pre_stateful") \
PIPELINE_STAGE(SWITCH, IN, ACL,6, "ls_in_acl") \
-PIPELINE_STAGE(SWITCH, IN, QOS_MARK, 7, "ls_in_qos_mark") \
-PIPELINE_STAGE(SWITCH, IN, LB, 8, "ls_in_lb")\
-PIPELINE_STAGE(SWITCH, IN, STATEFUL, 9, "ls_in_stateful") \
-PIPELINE_STAGE(SWITCH, IN, ARP_ND_RSP,10, "ls_in_arp_rsp") \
-PIPELINE_STAGE(SWITCH, IN, DHCP_OPTIONS, 11, "ls_in_dhcp_options") \
-PIPELINE_STAGE(SWITCH, IN, DHCP_RESPONSE, 12, "ls_in_dhcp_response") \
-PIPELINE_STAGE(SWITCH, IN, L2_LKUP, 13, "ls_in_l2_lkup") \
+PIPELINE_STAGE(SWITCH, IN, CHAIN, 7, "ls_in_chain")\
+PIPELINE_STAGE(SWITCH, IN, QOS_MARK, 8, "ls_in_qos_mark")\
+PIPELINE_STAGE(SWITCH, IN, LB, 9, "ls_in_lb")\
+PIPELINE_STAGE(SWITCH, IN, STATEFUL, 10, "ls_in_stateful") \
+PIPELINE_STAGE(SWITCH, IN, ARP_ND_RSP,11, "ls_in_arp_rsp") \
+PIPELINE_STAGE(SWITCH, IN, DHCP_OPTIONS, 12, "ls_in_dhcp_options") \
+PIPELINE_STAGE(SWITCH, IN, DHCP_RESPONSE, 13, "ls_in_dhcp_response") \
+PIPELINE_STAGE(SWITCH, IN, L2_LKUP, 14, "ls_in_l2_lkup") \
\
/* Logical switch egress stages. */ \
PIPELINE_STAGE(SWITCH, OUT, PRE_LB, 0, "ls_out_pre_lb") \
@@ -2374,8 +2375,12 @@ build_pre_stateful(struct ovn_datapath *od, struct hmap
*lflows)
REGBIT_CONNTRACK_DEFRAG" == 1", "ct_next;");
}
+static bool
+build_chain_classifier_entry(struct ovn_datapath *od, struct hmap *ports,
+ const struct nbrec_acl *acl, struct ds
*ds_action);
+
static void
-build_acls(struct ovn_datapath *od, struct hmap *lflows)
+build_acls(struct ovn_datapath *od, struct hmap *lflows, struct hmap *ports)
{
bool has_stateful = has_stateful_acl(od);
@@ -2531,6 +2536,18 @@ build_acls(struct ovn_datapath *od, struct hmap *lflows)
ds_destroy();
}
+} else if (!strcmp(acl->action, "sfc")) {
+struct ds ds_action = DS_EMPTY_INITIALIZER;
+
+if (!build_chain_classifier_entry(od, ports, acl, _action)) {
+ds_put_format(_action, "drop;");
+}
+
+ovn_lflow_add(lflows, od, stage,
+ acl->priority + OVN_ACL_PRI_OFFSET,
+ acl->match, ds_cstr_ro(_action));
+
+ds_destroy(_action);
} else if (!strcmp(acl->action, "drop")
|| !strcmp(acl->action, "reject")) {
struct ds match = DS_EMPTY_INITIALIZER;
@@ -2641,6 +2658,262 @@ build_acls(struct ovn_datapath *od, struct hmap *lflows)
}
}
+static int
+cmp_port_pair_groups(const void *ppg1_, const void *ppg2_)
+{
+const struct nbrec_logical_port_pair_group *const *ppg1p = ppg1_;
+const struct nbrec_logical_port_pair_group *const *ppg2p = ppg2_;
+const struct nbrec_logical_port_pair_group *ppg1 = *ppg1p;
+const struct nbrec_logical_port_pair_group *ppg2 = *ppg2p;
+
+if (ppg1->n_sortkey == 0 || ppg2->n_sortkey == 0) {
+return 0;
+}
+
+const int64_t key1 = ppg1->sortkey[0];
+const int64_t key2 = ppg2->sortkey[0];
+
+if (key1 < key2) {
+return -1;
+} else if (key1 > key2) {
+return 1;
+} else {
+return 0;
+}
+}
+
+/*
+ * Build the rules to insert service chains
+ */
+static bool
+build_chain_classifier_entry(struct ovn_datapath *od, struct hmap *ports,
+ const struct nbrec_acl *acl, struct ds *ds_action
/*output*/)
+{
+/* TODO: match needs to explicitly i
[ovs-dev] [RFC PATCH 3/5] Included architecture of SFC in documentation
This a write up of the architecture. It needs updating bu the basics are correct. Co-authored-by: Flavio Fernandes Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html Reported at: https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html Signed-off-by: John McDowall <jmcdow...@paloaltonetworks.com> --- ovn/ovn-architecture.7.xml | 185 + 1 file changed, 185 insertions(+) diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index d96e4b141..73342f2e0 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -381,6 +381,13 @@ switch. Logical switches and routers are both implemented as logical datapaths. + + + Logical services are logical references to virtual network functions + (VNF). Adding a logical service requires adding steering rules to the OVN Northbound + database. These are the only rules necessary to implement traffic steering for VNFs. + The section below "Life Cycle of an inserted VNF" provides more details. + Life Cycle of a VIF @@ -536,6 +543,184 @@ + Life Cycle of an inserted Virtual Network Function (VNF) + + + OVN provides an abstraction to enable the insertion of an arbitrary virtual network + function (VNF) into the path of traffic to and from an application. A VNF is different + from an application VM in that it acts on traffic between applications, and im most + cases does not terminiate a flow. Proxy functions are an exception as they terminate the + flow from the src and create a new flow to the dst. Examples of VNF's are security functions, + load balancing, and traffic enhancement services, this is not a complete list. + + + The requirements on the VNF to be inserted are minimal, it must + act as a bump in the wire (BITW) and can have one or two virtual network + ports for traffic. If it has two network ports traffic is directed into one and out the other, + if it has only one port, then traffic is bi-directional. The requirement for the VNF to act as + a BITW removes the need for the VNF to participate in L3/L2 networking which provides + improved agility and reduces the coupling between OVN and the VNF. + + + The service insertion is implemented by adding 4 new flow rules into the ovn-nb database for + each VNF inserted. The rules are added into the last table in the ingress path (L2_LKUP). + The service insertion rules have a higher priority than the standard forwarding rules. + This means that they override the existing forwarding rules. There are four + new rules added for each insertion. Two ingress and two egress, The first ingress + rule sends all traffic destined for the application into the VNF ingress port and the + second rule takes all traffic destined to the application from the VNF egress port + to the application, the priorities are such that the second rule is always checked + first. In the egress direction the rules are similar if the traffic is from the + application it is sent to the VNF egress port and if if is from the application + and is from the VNF ingress port it is delivered to the destination. + + + + The steps in this example refer to the details of the OVN Northbound database schema. + There is a new table in the OVN Northbound database to support service insertion + called Services this contains the required information for each new + service inserted. The same service can be used for multiple applications, as + there is typically a n:1 relationship between applications and VNFs. A + single VNF may be part of several service insertions, but each one is logically + separate. + + + The steps in this example refer often to details of the OVN and OVN + Northbound database schemas. Please see ovn-sb(5) and + ovn-nb(5), respectively, for the full story on these + databases. The ovn-nb database has specific schema enhancements for the service + insertion function. The ovn-sb database has no schema changes for the + service insertion function. + + + The following steps are an overview to inserting a new VNF into the traffic path. + The sections below go into each step in more detail. + + + + The service insertion lifecycle begins when a CMS administrator creates a new + virtual network function (VNF) using the CMS user + interface or API. The CMS administrator creates the logical ports (ingress and egress) + for the VNF. If the CMS is Openstack this will create a reusable port-pair defining the + interface to the VNF. There is also typically a seperate management port for the VNF, + but that is not relevant to the service insertion workflow. A single VNF can + participate with several applications, either as a security VM, protecting multiple + applications or as a load balancer
[ovs-dev] [RFC PATCH 4/5] Extended schema to include port-chain, port-pair-groups, port-pairs and added ACL SFC action
Along with the changes to ovn-northd.c these are the corresponding
changes to the northbound database.
Co-authored-by: Flavio Fernandes
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040381.html
Reported at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-May/041359.html
Signed-off-by: John McDowall <jmcdow...@paloaltonetworks.com>
---
ovn/ovn-nb.ovsschema | 64 +---
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
index 39c7f991c..02af7622d 100644
--- a/ovn/ovn-nb.ovsschema
+++ b/ovn/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
{
"name": "OVN_Northbound",
-"version": "5.4.1",
-"cksum": "3485560318 13777",
+"version": "5.4.2",
+"cksum": "1524033812 14801",
"tables": {
"NB_Global": {
"columns": {
@@ -30,6 +30,16 @@
"refType": "strong"},
"min": 0,
"max": "unlimited"}},
+"port_chains": {"type": {"key": {"type": "uuid",
+ "refTable":
"Logical_Port_Chain",
+ "refType": "strong"},
+ "min": 0,
+ "max": "unlimited"}},
+"port_pairs": {"type": {"key": {"type": "uuid",
+ "refTable":
"Logical_Port_Pair",
+ "refType": "strong"},
+ "min": 0,
+ "max": "unlimited"}},
"acls": {"type": {"key": {"type": "uuid",
"refTable": "ACL",
"refType": "strong"},
@@ -98,6 +108,50 @@
"min": 0, "max": "unlimited"}}},
"indexes": [["name"]],
"isRoot": false},
+"Logical_Port_Chain": {
+"columns": {
+"name": {"type": "string"},
+"port_pair_groups": {"type": {"key": {"type": "uuid",
+ "refTable":
"Logical_Port_Pair_Group",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}},
+"last_hop_port": {"type": {"key": {"type": "uuid",
+ "refTable":
"Logical_Switch_Port",
+ "refType": "strong"},
+ "min": 0, "max": 1}},
+"external_ids": {
+"type": {"key": "string", "value": "string",
+ "min": 0, "max": "unlimited"}}},
+"isRoot": false},
+"Logical_Port_Pair_Group": {
+"columns": {
+"name": {"type": "string"},
+"port_pairs": {"type": {"key": {"type": "uuid",
+ "refTable":
"Logical_Port_Pair",
+ "refType": "strong"},
+ "min": 0, "max": "unlimited"}},
+"external_ids": {
+"type": {"key": "string", "value": "string",
+ "min": 0, "max": "unlimited"}},
+"sortkey": {"type": {"key": {"type": "integer"},
+ "min": 0, "max":
[ovs-dev] [RFC PATCH 0/5] OVN: SFC Implementation
This patchset is the first round at having Service Function Chaining functionality through OVN. The implementation is done entirely on the northbound side of OVN. It is a bump on the wire implementation, so no attempt is being made in keeping state while packets visit each hop of the chain. ACLs are used as the classifiers, with the augmentation of action SFC, as well as option column. The current implementation of traffic redirection to the service chain is implemented by adding an additional action 'sfc' to the ACL stage. This overloads the ACL stage and this might not be the best long term approach. Guidence on whether this is "good enough" for now would be appreciated. How to leverage load balancing is also an open issue. The current LB solution in OVN is L3 based. Suggestions on how to implement LB at L2 for SFC would also be appreciated. This is not yet ready to be merged, as it lacks unit tests and a rigorous code review. Nevertheless, it works fine if you take into account a number of limitations that include: * missing load balancer integration; * no ipv6 support; * chain spanning logical switches (not supported); * bidirectional chains (not implemented); * other suggestions? This is the code that was used for SFC demo and talk at OVSCon 2016. John McDowall (5): Added documentation for SFC ACL Action Added new stage for SFC and modified ACL stage to include sfc action Included architecture of SFC in documentation Extended schema to include port-chain, port-pair-groups, port-pairs and added ACL SFC action added code and documentation to extend ovn-nbctl for port-chain, port-pair-groups, port-pairs and ACL SFC action ovn/northd/ovn-northd.8.xml |5 + ovn/northd/ovn-northd.c | 315 ++- ovn/ovn-architecture.7.xml | 185 + ovn/ovn-nb.ovsschema| 64 +- ovn/ovn-nb.xml | 150 +++- ovn/utilities/ovn-nbctl.c | 1935 +++ 6 files changed, 2489 insertions(+), 165 deletions(-) -- 2.11.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
