Re: [ovs-discuss] RFC: incremental computation for OVN with DDlog
On Fri, Nov 2, 2018 at 10:44 AM Ben Pfaff wrote: > > I was asked in an OVN meeting to send out an email talking about what > we're working on to make ovn-northd and ovn-controller faster. Here's > my summary. Thanks Ben for the great summary! I just have some *minor* comments on the background part. > > OVN is essentially a stack of compilers. At the top, the CMS dumps > some configuration into the northbound database (NDBB). Then: > > 1. ovn-northd centrally translates the high-level NBDB description >into logical flows in the southbound database (SBDB). > > 2. ovn-controller, on each HV, translates the SBDB logical flows >into "physical" (OpenFlow) flows for the local hypervisor and >passes them to ovs-vswitchd. > > 3. ovs-vswitchd translates OpenFlow flows into datapath flows on >demand as traffic appears. > > Currently, OVN implements steps 1 and 2 with code that translates all > input to output in one go. When any of the input changes, it > re-translates all of it. This is fine for small deployments, but it > scales poorly beyond about 1000 hypervisors, at which point each > translation step begins to take multiple seconds. Larger deployments > call for incremental computation, in which a small change in the input > requires only a small amount of computation to yield a small change in > the output. The conclusion is true, but I'd like to comment about the scale number "1000 hypervisors". In fact number of logical objects impacts more than number of hypervisors in terms of the compute for translations. E.g. with 64 lports per hypervisor, a deployment of 100 hypervisors is big enough to see scale problems, both compute latency and high CPU cost on hypervisors. > > It is difficult to implement incremental computation in C. For > ovn-controller, two attempts have been made already. The first attempt, > in 2016, increased code complexity without similar benefit > (https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/078272.html). > A recent approach, by Han Zhou shows a much bigger improvement, but it > also increases complexity greatly and definitely makes maintenance more > difficult. I think my approach is less complex and more maintainable than the 2016 attempt, but I do agree it is still not easy to maintain in the long run comparing with the DDlog proposal. Maybe this is not important at all :) (As a reference, here is the branch that is rebased on 2.10: https://github.com/hzhou8/ovs/tree/ip12_rebase_on_2.10) I completely support the DDlog approach as a general solution to both northd and ovn-controller. My approach was implementing index and joins by hand, while DDlog will just do it automatically with the engine, which will be far more maintainable. Thanks, Han ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] It is possible build a Loop Topology using In-band mode without stp ?
Hi All I am trying to build a triangle topology as shown below but using in-band mode In my attempts I only get this topology working when I enable STP (spanning-tree) directly in openVswitch (ovs-vsctl set Bridge br1 stp_enable=true) or when I open the loop, to wait the controller communication to be established and close the loop again. Im using raspberry pi 3 as openvswitch with OVS 2.3.0. When I try to use Ryu app as ofctl_rest.py, simple_switch.py , simple_switch_stp.py or rest_route.py running in-band mode without stp the behavior of the switches is unpredictable. When I use theses same Ryu app running a out-of-band mode the switches works normally. I am setting inband networking communication with the command ip addr add 192.168.128.5/24 dev br1 (my controller stays in this same network), each switch has three interfaces eth0, eth1 e eth2, about it, which one the switch will be use to communicate when I set the ip directly in the bridge ? Anyone knows if is possible to build a loop topology in in-band mode without enable STP ? Ryu Controller | s2 / \ H1 -s1 s3 --- H2 Thanks ! Henrique ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] How to match the VLAN VID of frames tunneled to a VXLAN port?
Oh. It makes logical sense to match on dl_type=0x8100 for VLAN match but it isn't how OpenFlow (or Open vSwitch) works. Glad you got it working. On Sun, Nov 04, 2018 at 12:32:52PM +0100, Alan Kayahan wrote: > Your response made me doubt the simple things so I tried some > combinations. Removed the match dl_type=0x8100 from the rule and it > worked. Following is how the rule looks like now. > > cookie=0x0, duration=20.297s, table=0, n_packets=7, n_bytes=614, > priority=10,tun_id=0x32,in_port="VXLAN-02_01",dl_vlan=100 > actions=pop_vlan,output:"Host-eth0" > > dl_type had always been a habitual OF precondition for me for VLAN > operations. Enjoy your weekend Ben! > > Alan > On Sun, Nov 4, 2018 at 6:06 AM Ben Pfaff wrote: > > > > Hmm, VLAN match should work fine for that case. I'm surprised that > > there are problems. > > > > On Sun, Nov 04, 2018 at 05:37:05AM +0100, Alan Kayahan wrote: > > > Thanks for the response Ben. > > > If I am understanding the document correctly, the packets coming in > > > from the host (classified as Flow1 on page 29) in Switch A are tagged > > > with VLAN100, then tunneled to O3 (SwitchB's IP address) with a VNI ID > > > 50. So there is only 1 VLAN field and that is the inner (the VLAN > > > field of the frame encapsulated in the VXLAN tunnel), which I need to > > > match on. > > > > > > Alan > > > On Sat, Nov 3, 2018 at 4:25 PM Ben Pfaff wrote: > > > > > > > > On Sat, Nov 03, 2018 at 06:45:08AM +0100, Alan Kayahan wrote: > > > > > Hello, > > > > > > > > > > I am trying to build a simplified version of the "sample L2 > > > > > transparent network service chaining implementation" described in > > > > > section 6 of this document > > > > > https://www.opennetworking.org/wp-content/uploads/2014/10/L4-L7_Service_Function_Chaining_Solution_Architecture.pdf. > > > > > > > > > > My simplifications: > > > > > 1) 3 OVS bridges on 3 nodes > > > > > 2) Just a single flow and a single chain to steer without bypassing > > > > > any service. > > > > > 3) No 5-tuple matching, just in_port > > > > > 4) VXLAN remoteIPs are hardcoded, key=flow, and attached as a port to > > > > > the bridge > > > > > > > > > > Problem: Matching the VLAN field inbound to a VXLAN port doesn't work. > > > > > > > > Do you expect the VLAN field to match the inner or outer VLAN? It will > > > > actually match the inner VLAN? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Docker & Open vSwitch question.
I guess by "patch" you mean "patch ports" . I think you will need to bring VLANs into the solution to accomplish what you are describing. My Orabuntu-LXC software ( https://github.com/gstanden/orabuntu-lxc ) uses a scheme of this type. HTH Gilbert On Sat, Nov 3, 2018, 9:15 AM Kevin Swagger wrote: > > > I am trying to have two separate networks each with an OVS bridge. I have > a few docker containers connected to each bridge. I used a command like > "ovs-docker add-port ovs-br1 eth1 container1 " to connect the docker > containers to the bridges. I tried creating my own docker network that all > the containers used and when I removed the patch connection between the two > bridges the containers could still communicate. When I created two separate > docker networks the containers could not communicate to the other network > of containers. Is there a way I can accomplish my goal? > > > > I want the two Open vSwitch bridges to be able to communicate by a patch. > I want the docker containers to only communicate over the patch and if I > remove the patch I want the containers to not be able to communicate. > > > > Thank you > > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] How to match the VLAN VID of frames tunneled to a VXLAN port?
Your response made me doubt the simple things so I tried some combinations. Removed the match dl_type=0x8100 from the rule and it worked. Following is how the rule looks like now. cookie=0x0, duration=20.297s, table=0, n_packets=7, n_bytes=614, priority=10,tun_id=0x32,in_port="VXLAN-02_01",dl_vlan=100 actions=pop_vlan,output:"Host-eth0" dl_type had always been a habitual OF precondition for me for VLAN operations. Enjoy your weekend Ben! Alan On Sun, Nov 4, 2018 at 6:06 AM Ben Pfaff wrote: > > Hmm, VLAN match should work fine for that case. I'm surprised that > there are problems. > > On Sun, Nov 04, 2018 at 05:37:05AM +0100, Alan Kayahan wrote: > > Thanks for the response Ben. > > If I am understanding the document correctly, the packets coming in > > from the host (classified as Flow1 on page 29) in Switch A are tagged > > with VLAN100, then tunneled to O3 (SwitchB's IP address) with a VNI ID > > 50. So there is only 1 VLAN field and that is the inner (the VLAN > > field of the frame encapsulated in the VXLAN tunnel), which I need to > > match on. > > > > Alan > > On Sat, Nov 3, 2018 at 4:25 PM Ben Pfaff wrote: > > > > > > On Sat, Nov 03, 2018 at 06:45:08AM +0100, Alan Kayahan wrote: > > > > Hello, > > > > > > > > I am trying to build a simplified version of the "sample L2 > > > > transparent network service chaining implementation" described in > > > > section 6 of this document > > > > https://www.opennetworking.org/wp-content/uploads/2014/10/L4-L7_Service_Function_Chaining_Solution_Architecture.pdf. > > > > > > > > My simplifications: > > > > 1) 3 OVS bridges on 3 nodes > > > > 2) Just a single flow and a single chain to steer without bypassing any > > > > service. > > > > 3) No 5-tuple matching, just in_port > > > > 4) VXLAN remoteIPs are hardcoded, key=flow, and attached as a port to > > > > the bridge > > > > > > > > Problem: Matching the VLAN field inbound to a VXLAN port doesn't work. > > > > > > Do you expect the VLAN field to match the inner or outer VLAN? It will > > > actually match the inner VLAN? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
