Re: [ovs-discuss] [openstack-dev] [ovn] [[l3-agent] connectivity to external network
On Thu, Nov 3, 2016 at 3:31 PM, Murali R wrote: > The scope of question is using neutron L3 services with OVN. The problem > is when a router created, there is no implicit internal interface created > between the router instance and the external bridge. > To be honest, support of the Neutron L3 agent was only a transitional thing while we bootstrapped OVN. It was only useful while the corresponding features were added to OVN. Once we merge [1], I don't see any reason to keep support of the L3 agent any longer and plan to remove support for it and the corresponding CI jobs. My suggestion would be to try to do what you need using OVN's L3 support. [1] https://review.openstack.org/#/c/346646/ -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN SFC: Changes to include ACL based classifiers
On Wed, Nov 2, 2016 at 11:29 AM, Flavio Fernandes wrote: > > > On Nov 1, 2016, at 1:30 PM, Flaviof wrote: > > > > > > > > On Tue, Nov 1, 2016 at 1:05 PM, John McDowall < > jmcdow...@paloaltonetworks.com>wrote: > > So we would have something like: > > > > > > > > $ ovn-nbctl acl-add sw0 to-lport 1003 'outport == "sw0-port1" && ip' > sfc-action sfc-stage external_ids:lsp_chain_id=”chain-id” > > > > > > > > The chain-id would be passed as metadata with the packet to the > ls_in_chain stage where it would be processed according to the current > state of its in/out ports in the chain. > > > > > > > > Where sfc is the stage and the action – would the SFC ACL Table have any > other action other than SFC? It seems a little redundant – not sure if > there is a better way though. > > > > > > > > > > Right. If I understood correctly, the sfc-stage is optional and may be > something we > > may add later on to ACLs. For now, having it all in a sigle stage will > not invalidate > > that effort. > > > > Using the example comand, my main 'focus' is actually in regards to what > else goes as > > external_ids. I can see that besides 'lsp_chain_id', we will need > 'last_hop_port', and > > possibly 'bidirectional'. Sounds right? > > > > I will send an email with a proposed schema+xml on this shortly. > > It's a pretty simple change [1], as expected. :) Does that jive well with > the changes > you had in mind? A small caveat here is in regards to additional attributes > the chain needs in order to create the end to end rules. That includes > 'chain_uuid', > 'last_hop_port' at a minimum. Other than using 'external_ids', I cannot > see where else > to provide them. Any better ideas? > Well defined options that OVN will interpret usually go into a column called "options", so I would add that instead of using external_ids. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN SFC: Changes to include ACL based classifiers
On Tue, Nov 1, 2016 at 11:09 AM, Flaviof wrote: > [cc: John, Louis, Farhad, Russell] > > Hi folks, > > Picking up from where we left off at the summit [1], I took > a stab at the nb schema changes to represent what I > understood Russell and others saying on how we could > use a secondary table of ACLs to serve as the SFC > classifiers: [2]. > What I had in mind was proceeding with a proposal like this one where we change ACLs to have multiple stages. This patch proposed two, but I think we later talked about extending it to have more (8 perhaps?). http://openvswitch.org/pipermail/dev/2016-July/076674.html Then if SFC was an ACL action, you could put it in any stage of ACLs you want, with other things before or after as desired. Does it look right to you? If so, I will start making the > changes to incorporate that and obsolete the classifier based > code [3]. I'm not sure if I will be able to migrate to this new > table in time for the talk at OVSCon [4], but I will try. > > Thanks, > > -- flaviof > > [1]: https://etherpad.openstack.org/p/r.f7cebb215b63ae657d91a28ab0da42bf > <https://etherpad.openstack.org/p/networking-ovn-ocata-summit> > > [2]: https://github.com/doonhammer/ovs/pull/3/commits/ > b10224a07de2970358eb5e105146ef1d5f5eca6d > > [3]: https://github.com/doonhammer/ovs/pull/3/commits/ > 2ebea7881c523dd356cd043a24531c268bddf6b4#diff- > 2c35162acf6ad144624954fdc4c3d9f4R2505 > > [4]: http://sched.co/8aZE > > > > ___ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > > -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn]Is there a plan for ovn-chassis-types
On Fri, Oct 21, 2016 at 2:26 AM, Dong Jun wrote: > Some time it doesn't need all chassis to schedule gateway routers on, > only gateway chassis are needed. > Is there already a plan for adding ovn-chassis-types in OpenvSwitch > external-ids and populating it to south DB external-ids? OVN doesn't do gateway scheduling. It relies on something external to do that. Are you talking about this in the context of OpenStack? If so, I do remember talking about this but it's not done. It seems reasonable though. Our scheduling right now is just a basic start. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovn intro documentation
On Tue, Oct 4, 2016 at 4:46 PM, Dustin Spinhirne wrote: > All, > > In the spirit of the 2.6 release I've put together a documentation series > on OVN. > > http://blog.spinhirne.com/p/blog-series.html#introToOVN > > I tend to get blind to my own tpyos and errrors when writing these things, > so if anyone spots anything which is horribly wrong then please feel free > to contact me directly. I hope that these are useful for people who are > just getting started with OVN. > This is really great stuff. Thank you! Would you be interested in trying to incorporate this content into the OVN documentation? A user oriented tutorial would be a great addition. The tutorial we have right now is a bit more developer oriented [1]. I think most people really want something like what you've written. Your content also covers much more of the feature set. [1] https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn][neutron] networking-ovn 1.0.0 release (newton) -- port-security
On Tue, Oct 11, 2016 at 2:47 PM, Murali R wrote: > Hi, > > Please clarify if port security is required to be enabled with newton > release when installing OVN. The install.rst says it must be. In many of my > use cases I want to disable port security which is how I do currently with > devstack. I would like to know if either ovn or neutron will have > contentions if port-security disabled at neutron server. > You can disable it. There's no problem with that. It will just disable related features: L2 and L3 port security and security groups. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovs-dev] OVN: Limiting the impact of a compromised chassis
On Fri, Jul 15, 2016 at 1:53 PM, Lance Richardson wrote: > I've been doing some investigation into the "Limiting the impact of > a compromised chassis" issue described in ovn/TODO. These are some initial > thoughts, posting here for feedback and any other ideas folks might have > about how we should go about solving this part of the issue. > > The fact that we're heading towards using etcd for OVN might make some > of this moot, on the other hand it might be some time before that happens > and this security issue will need to be addressed in order for OVN to be > viable in some use cases. > I've been thinking about whether it still makes sense to work on this before migrating to etcd. Since the etcd timeline is unclear, and this issue is a blocker for some people in the meantime, I think it's worth proceeding, at least with scoping the work. If we can come up with a detailed proposal, we can hopefully get a better idea of how much work it would be and if it's worth the short term effort. > One problem that needs to be solved for any potential solution to the > compromised chassis issue is how to determine the identity of clients > connecting to the OVN southbound DB server. For example, it would be > desirable for ovn-northd and ovn-sbctl to have one set of access privileges > for reading and updating the SB database while ovn-controller and > ovn-controller-vtep have a different and more limited set of access > privileges. In order to implement this it would be necessary to know for > each transaction the type of client attempting it. For more fine-grained > access control, it will also be necessary to determine the actual identity > (e.g. chassis name or UUID) of each connected client. > > Since ovsdb-server already has support for SSL client authentication, one > semi-obvious approach might be to: >- Configure the SB ovsdb-server to only accept unix and SSL connections > (ovn-northd and ovn-sbctl would likely use unix:file connections, > where > access can be controlled via file system permissions, whereas > ovn-controller > instances would use SSL). >- Generate signed client certificates for each chassis/gateway, > encoding the > chassis/gateway name in the certificate's "organizational unit" field. >- In cases where ovn-northd or ovn-sbctl might have to connect to the SB > database server over a network, client certificates could be generated > with e.g. the OU field set to "ovn-northd" or "ovn-sbctl" as > appropriate. >- For each new SSL connection, ovsdb-server would record the client type > and name contained in the client-provided certificate. >- The recorded client type and name could then be used in a (to be > defined > separately) ACL implementation. > > Some questions: > > - Will this work, and are there any obvious holes? > - Might PKI management be too burdensome in large deployments? > - Is there a better way? > If we need identify for each chassis, this does seem like a good approach. I was imagining we'd do it with SSL, but hadn't thought through details yet. The other option is if we can change ovn-controller to where it is only a read-only client of the southbound database. In that case, perhaps ovsdb-server wouldn't need to know identity, and instead could have a port open that only accepts connections with read-only access to the database. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovs-dev] Compiler warnings with gcc 6.1 (On Fedora 24)
On Tue, Jul 5, 2016 at 1:10 AM, Numan Siddique wrote: > > > > > > > > OK. > > > > If you have time and the inclination, please feel free to experiment a > > bit with the definition of BUILD_ASSERT_TYPE to see if you can make it > > work without warnings. > > > > Thanks for the pointers. I will give it a try. > Hi, Numan. I'm using Fedora 24 and I don't see these warnings. I'm not sure what's different. $ gcc --version gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3) -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN hardware gateway(s)?
On Fri, Jul 15, 2016 at 9:20 AM, Kenneth Østrup wrote: > Greetings, > > For the past months I've been testing and reading about OVN as a cloud > agnostic networking platform for a project I am working on. OVN is exactly > what I've been looking for and I'm really impressed with all the work that > has been done while still keeping simplicity in the core of the design. > > In the OVN talk at OpenStack Summit in Austin, it was mentioned that there > was an OVN gateway running on a bare-metal switch. I'd really like to know > more about this, how it is implemented and if there is a current working > prototype? > This is related to the use of ovn-controller-vtep and TOR switches that support the hardware_vtep OVSDB schema. It provides an L2 gateway into a physical network. "Life cycle of a VTEP gateway" in the ovn-architecture man page may be of interest to you. There is also the capability to have software L2 or L3 gateways on a server running ovn-controller. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] etcd for OVN status update (was: Re: more about etcd (can it support big transactions and many monitors?))
On Thu, Jul 7, 2016 at 3:15 PM, Andy Zhou wrote: > Another consideration is that we'd be able to make use of ovsdb features, >> but at the expense of not be able to use etcd features directly. An >> example is authorization. This is a v2 API doc, but: >> >> https://coreos.com/etcd/docs/latest/auth_api.html >> >> I was thinking we might be able to build a solution for the "Limiting the >> impact of a compromised chassis" item in ovn/TODO using etcd capabilities. >> If we put ovsdb in front of it, we still have to solve this in ovsdb. >> >> This is a very good point. May be it is another +1 for #2? Or you have > some other approach in mind? > Yes, +1 for #2. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] etcd for OVN status update (was: Re: more about etcd (can it support big transactions and many monitors?))
On Thu, Jul 7, 2016 at 2:44 PM, Andy Zhou wrote: > On Thu, Jul 7, 2016 at 11:37 AM, Han Zhou wrote: > >> Hi Andy, >> >> Sorry #1 seems not clear to me. It sounds like a etcd cluster running >> behind a ovsdb-server cluster? Then what would be the HA mechanism for the >> ovsdb-server layer? >> > > Yes, your understanding is correct, expect ovsdb-servers do not form a > cluster, they only connect to etcd servers. > > etcd servers form the HA cluster. All ovsdb-servers maintain connections > to the leader etcd server. OVSDB servers do not store > transactions, they essentially translate ovsdb protocol into etcd gRPC > protocol. > Would you be able to run N copies of ovsdb-server in this case? Another consideration is that we'd be able to make use of ovsdb features, but at the expense of not be able to use etcd features directly. An example is authorization. This is a v2 API doc, but: https://coreos.com/etcd/docs/latest/auth_api.html I was thinking we might be able to build a solution for the "Limiting the impact of a compromised chassis" item in ovn/TODO using etcd capabilities. If we put ovsdb in front of it, we still have to solve this in ovsdb. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] problem about OVN in 'overlay' mode
On Thu, Jul 7, 2016 at 11:05 AM, Guru Shetty wrote: > > > On 7 July 2016 at 08:18, Taekho Nam wrote: > >> I'm following some command for set up OVN in 'overlay' mode in this >> documents. >> (https://github.com/openvswitch/ovs/blob/master/INSTALL.Docker.md) >> >> But, I'v faced some problems. >> >> When I typed >> >> ovn-docker-overlay-driver --detach, I can see following ImportError. >> >> >> >> root@ubuntu:~# ovn-docker-overlay-driver --detach >> Traceback (most recent call last): >> File "/usr/local/bin/ovn-docker-overlay-driver", line 27, in >> import ovs.dirs >> ImportError: No module named ovs.dirs >> > > This mainly comes because OVS python modules do not exist in the system. > This looks like a documentation gap in OVS. Usually, if you are installing > it via debian, it comes from the package 'python-openvswitch'. You can also > install it via pip. I think it is: > > pip install python-openvswitch > # pip install ovs You can also install via pip from source. # cd python/ # pip install . > > > > >> >> >> >> To solve this problem, I checked many possible thing that can cause this >> problem. >> However I couldn't. >> >> >> I think that there are some problems in process that set up Open vSwitch. >> >> I've installed Open vSwitch using this document. >> (https://github.com/openvswitch/ovs/blob/master/INSTALL.md) >> It will works well. >> >> How can I solve this problem, Could you recommend solution? >> >> Best regards, >> Taekho Nam. >> >> >> >> ___ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >> > > ___ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > > -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN usage with VMs
On Sun, Apr 24, 2016 at 10:01 PM, Troy wrote: > Dear all, > > It's really a shame that I cannot complete my job. So I have to ask for > help here. > > I installed the OVN and run the northd and controller successfully. Also > ,I added the fail_mode(secure) in br-int. > Then, I followed the setup.sh of env1 of OVN-Tutorial.md. > > ovn-nbctl lswitch-add sw0 > ovn-nbctl lport-add sw0 sw0-port1 > ovn-nbctl lport-add sw0 sw0-port2 > > ovn-nbctl lport-set-addresses sw0-port1 fe:54:00:a6:6f:5a > ovn-nbctl lport-set-addresses sw0-port2 fe:54:00:88:27:ce > > ovn-nbctl lport-set-port-security sw0-port1 fe:54:00:a6:6f:5a > ovn-nbctl lport-set-port-security sw0-port2 fe:54:00:88:27:ce > > ovs-vsctl add-port br-int vnet0 -- set Interface vnet0 > external_ids:iface-id=sw0-port1 > ovs-vsctl add-port br-int vnet1 -- set Interface vnet1 > external_ids:iface-id=sw0-port2 > > In this test, I have two VMs, and the "vnet0" and "vnet1" is the dev in > host., the "fe:54:00:xx:xx:xx" are these dev's macaddress. But I find the > OVN didn't work. whatever I do, the two VMs always cannot communicate with > each other. > And i run " $ ovn-sbctl show", it didn't show anything. I guess in the > last step, I didn't add the set options in the OVS. > > At the same time, I run the ovs-ofctl show, it suggest:(different from the > tutorial book) > > root@troy-PC:~# ovs-ofctl show br-int > + ovs-ofctl show br-int > OFPT_FEATURES_REPLY (xid=0x2): dpid:0e36a9dd1f40 > n_tables:254, n_buffers:256 > capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP > actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src > mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst > 4(vnet1): addr:fe:54:00:88:27:ce > config: 0 > state: 0 > current:10MB-FD COPPER > speed: 10 Mbps now, 0 Mbps max > 5(vnet0): addr:fe:54:00:a6:6f:5a > config: 0 > state: 0 > current:10MB-FD COPPER > speed: 10 Mbps now, 0 Mbps max > LOCAL(br-int): addr:0e:36:a9:dd:1f:40 > config: PORT_DOWN > state: LINK_DOWN > speed: 0 Mbps now, 0 Mbps max > OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 > > I want to use the OVN to control the two VMs network(just like iptables to > control the connection behaviors). But in the guide book and examples, they > use it in sandbox and doesn't add any VMs, if possible, could you give me > some guidance about the OVN usage with VMs please? > I don't know of any docs that show this in detail. The closest I'm aware of is documentation on the OpenStack integration, which sets up VMs with OVN. http://docs.openstack.org/developer/networking-ovn/testing.html http://docs.openstack.org/developer/networking-ovn/refarch.html -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] How to use OVN without sandbox?
On Tue, Jul 5, 2016 at 10:21 AM, Taekho Nam wrote: > Hello, I'm a student studying about OVN. > > I already completed all kinds of tutorials in github. > (https://github.com/openvswitch/ovs/tree/master/tutorial) > > But environment and configuration for each tutorial are made in sandbox > automatically. > Now I want to make environment and set configuration for OVN without > sandbox. > However I don't know how to do that. > > Somebody can give some guideline for OVN without sandbox. > I really want to know how to use it outside of sandbox. > > Please let me know. > There are a couple of options that are document. One is to use the OVN integration for OpenStack: http://docs.openstack.org/developer/networking-ovn/testing.html There is also Docker integration: https://github.com/openvswitch/ovs/blob/master/INSTALL.Docker.md -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] etcd for OVN status update (was: Re: more about etcd (can it support big transactions and many monitors?))
On Fri, Jul 1, 2016 at 1:59 PM, Andy Zhou wrote: > >> A single, dedicated etcd client handling every other transaction sounds >> like it could be a scale bottleneck. What do you think? >> > > Yeah, this is not ideal. Suggestions are welcome. > I don't have any suggestions right now... > In OVN-SB use case, transactions are usually only issued by northd, write > update should not, at least in theory, be > the performance bottleneck. > At least for OpenStack, the most frequent operation will be creating or deleting logical ports. Each results in a transaction from both ovn-northd and ovn-controller right now. ovn-northd updates logical flows and creates a Port_Binding row (at least). ovn-controller updates the Port_Binding row to bind the port to a chassis. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] etcd for OVN status update (was: Re: more about etcd (can it support big transactions and many monitors?))
On Wed, Jun 29, 2016 at 6:38 PM, Andy Zhou wrote: > > > On Wed, Jun 22, 2016 at 10:43 AM, Ben Pfaff wrote: > >> On Wed, Jun 22, 2016 at 01:56:17AM -0700, Andy Zhou wrote: >> > 3. How should the OVN databases be arranged within etcd? There are >> > >multiple possibilities: >> > > >> > >- Define OVSDB bindings to etcd and implement those bindings in the >> > > OVSDB client libraries (C and Python). >> > > >> > >- Define OVSDB bindings to etcd and implement those bindings in the >> > > OVSDB server (so that ovsdb-server uses etcd as a storage layer). >> > > >> > >- Define a native etcd schema for OVN SB (and probably NB) database >> > > and make ovn-controller and ovn-northd use it natively. >> > >> > >> > > >> > It would be nice to be able to reuse current schema definition. #3 >> option >> > makes this not a >> > hard requirement, but having schema is much nicer to maintain changes >> over >> > release -- for example, upgrade due to schema version changes. >> > >> > Both #1 and #2 option above require us to figure out how DB, TABLE and >> > COLUMNS are logically map to >> > a key value store. Just for discussion purpose, Let's say the keys are >> in >> > the format of db/table//column. >> > >> > >> > OVSDB supports complex value types such as set and maps, Those can also >> be >> > supported with the following >> > format: db/table//column/set-key (with a fixed value, say, >> > "set") or db/table//column/map-key >> > >> > To optimize certain key range queries (i.e. the benefits that can be >> > realized by conditional monitoring), we can declare >> > certain columns to be prefix of the . One possible way is to >> > enhance current schema definition to add a "priority" >> > field for each column. "normal" columns, by default have the lowest >> > priority. When C1 has a higher priority than C2, and both >> > have non default priority, The etcd key layout can be: >> > db/table/c1/c2//columns. >> > >> > With this key layout, rows that matches a particular c1 value (or c1 && >> c2) >> > to be "watched". This is not as general as the conditional monitoring, >> but >> > may be sufficient for OVN SB's current use cases. >> > >> > Enforcing constrains expressed in schema can be tricky for #1, some of >> the >> > possible solutions are: >> > >> > The value constrains expressed by the schema are not going to enforced >> by >> > etcd. One possible solution here is >> > to have all clients that issues transactions enforce constrains before >> > issuing. >> > >> > References integrity can also be enforced by the client. Logically, we >> can >> > have a dedicated client that enforces referential integrity, >> > (It can be combined into one of the clients in practice). Ideally we >> would >> > like to both original transaction + reference integrity changes appears >> as >> > one transaction to the client (at least the clients of the idl layer). >> This >> > may need additional logic OVN needs to build that >> > not currently provided by etcd -- I don't know if this is a deal >> breaker. >> > >> > To me, #2 seems to make overall system more complex and less efficient >> than >> > #1. >> >> Thanks for all the thoughts! I agree with all of these ideas, at least >> at first glance. They are very close to what I was thinking too. It's >> good that we're on the same page. >> > > This is one possible way to implement reference integrity with etcd: > > * DB wide versioning. > > Assign a key db/version that stores db wide transaction id. Assume the id > starts with 0. Any client issued transaction on the DB should also include > this key; A transaction will increase its value by 1; Any etcd client > transaction > will always bring this version number from even to an odd number. > > No further transaction can be issued until "db/version"'s value become > even. > > * A dedicated client enforces referential integrity > > There is a dedicated etcd client whose job is to enforce referential > integrity. > It starts to run when the version number is odd, commit the next > transaction > that "fixes" the etcd. The version number is increased even if there is > nothing > to fix. > > In the HA setup, referential integrity checking clients should run on the > same machines > that run etcd. Only the etcd client that runs on the same machine as the > etcd leader > will actively enforce referential integrity. Other clients will be > running in standby mode, > and only become active when its local etcd server become the leader. > > Will this work? > A single, dedicated etcd client handling every other transaction sounds like it could be a scale bottleneck. What do you think? -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [OVN] different ways to bind lports
On Saturday, June 18, 2016, Hui Kang wrote: > Hi, > I saw there are two commands binding logical ports to hypervisor in OVN > tutorial scripts > > ovs-vsctl add-port br-int lport1 -- set Interface lport1 > external_ids:iface-id=sw0-port1[1] > > ovn-sbctl lport-bind sw0-port3 fakechassis [2] > > Is there any difference between them? Thanks. > > - Hui > > [1] > https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env3/setup.sh#L36 > [2] > https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env3/setup.sh#L43 > > Yes, ovn-controller normally does this automatically. The case where ovn-sbctl does it is because we are simulating a fake other hypervisor and manually do a step that ovn-controller on that hypervisor would have done. Russell -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] HA proposal for current OVN release cycle (was: etcd for OVN status update (was: Re: more about etcd (can it support big transactions and many monitors?)))
Thank you for the detailed updates on your progress! On Fri, Jun 17, 2016 at 2:18 PM, Ben Pfaff wrote: > My proposal is this: > > 1. Postpone the OVN etcd vs. Raft decision to the next release cycle in >6 months. This will give etcd and its underlying infrastructure time >to mature, and in the alternative it will give proper time to >implement Raft in OVSDB. > > 2. Prioritize getting HPE's OVSDB replication patches into this current >cycle. I do not think I've seen a revision of the patches since >March, so the first step would be to ask for a new version, and in >the alternative I'll take a look at revising them myself. > > Comments? > This sounds quite reasonable to me. Roughly given choices of: a) branch in July with active/passive HA for OVSDB b) aim for etcd or ovsdb+raft, but no HA when we branch in July c) aim for etcd or ovsdb+raft, and delay release until properly ready I am definitely in favor of (a). I think it's important to put out some regular releases that show our progress. Active/passive HA is still a significant upgrade over the current state. Having that and an on time release is still a successful milestone in my book. As briefly mentioned in the meeting today, one of our big questions will be whether OVN is still experimental or not. I'd love to take off the experimental label. To do so, I think we either need to be confident that the northbound interface won't change (will remain OVSDB), or that we can provide a reasonable automated migration path from OVSDB to etcd. On the surface, providing a migration seems reasonable enough. Thanks, -- Russell Bryant -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] more about etcd (can it support big transactions and many monitors?)
On Fri, Jun 10, 2016 at 5:08 PM, Ben Pfaff wrote: > I've obtained a little more information from a conversation on Twitter > with Xiang Li, a CoreOS developer, see below. > > On Fri, Jun 10, 2016 at 01:14:29PM -0700, Ben Pfaff wrote: > > This leaves me with the following discussion questions: > > > > - Is lack of non-amd64 support a blocker? It's going to suck for > > me, because I do my development on i386 specifically to introduce > > diversity (I find bugs that others don't because they're all on > > amd64). Also, we've lately had people actually making sure that > > the testsuite passes on non-x86-64, so there seems to be real > > interest there. > > Xiang says that to support non-x86-64 architectures, they would need > someone to take responsibility for maintaining them. > > I still don't know whether this is a blocker. > Another way to look at this is that etcd has gained a huge amount of traction, at least in the modern app infrastructure / container space. This wouldn't be a limitation we would be accepting alone. If the demand is really there, we wouldn't be alone in needing to solve it. I wouldn't consider it a blocker. > > > - Can etcd handle big transactions? > > Xiang says that there's a 1 MB limit on transactions by default, which > can be increased. This is probably not a blocker. > > > - Can etcd handle a sufficient number of notify registrations? > > Xiang says that etcd can handle at least a million notify registrations. > This is probably not a blocker. > This all sounds very promising! Do you have any thoughts on next steps? a detailed look at how our existing schemas and some example transactions would be mapped to etcd? My gut reaction is that this is probably the right direction unless we can identify blockers. If we get to the point of a migration, I'd be willing to join an effort of locking a small group in a room to do the migration as quick as possible to help keep OVN on track. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] MTU considerations for OVN
On Tue, May 3, 2016 at 6:50 PM, Matt Kassawara wrote: > Jesse, > > I'm resurrecting this thread after a fairly lengthy discussion of MTU with > Ben at the recent OpenStack summit. Have you given the topic any further > thought toward implementation in a reasonable way? Can you elaborate on the > architectural limitations? At the moment, the OpenStack implementation of > OVN doesn't use DPDK. > One minor point here: The OpenStack driver for OVN can optionally make use of OVS-DPDK. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] NAT Action Support in openvswitch
On Tue, Apr 5, 2016 at 6:46 AM, Aswin S wrote:
> Hi,
>
> I was exploring the NAT action support added in OVS. I compiled the master
> and installed the OVS(2.5.9). But when I add bridge I could see the info
> does not support ct_state_nat in the log
>
>
> 2016-04-05T20:16:08.625Z|00012|ofproto_dpif|INFO|system@ovs-system:
> Datapath supports ct_zone
> 2016-04-05T20:16:08.625Z|00013|ofproto_dpif|INFO|system@ovs-system:
> Datapath supports ct_mark
> 2016-04-05T20:16:08.625Z|00014|ofproto_dpif|INFO|system@ovs-system:
> Datapath supports ct_label
> 2016-04-05T20:16:08.625Z|00015|ofproto_dpif|INFO|system@ovs-system:
> Datapath does not support ct_state_nat
>
> Also when I try to add a flow with NAT action, it is throwing
> OFPBAC_BAD_TYPE error
>
> sudo ovs-ofctl add-flow br-int
> table=0,in_port=1,ip,action=ct"("commit,zone=1,nat"("src=10.1.1.240-10.1.1.255"))",2
> OFPT_ERROR (xid=0x4): OFPBAC_BAD_TYPE
> OFPT_FLOW_MOD (xid=0x4):
> (***truncated to 64 bytes from 128***)
>
> Am I missing anything? My kernel version is 3.13.
>
Yes. You're missing kernel support. It is not yet available for the
in-tree kernel module.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn4nfv]
On Thu, Mar 31, 2016 at 1:15 PM, John McDowall < jmcdow...@paloaltonetworks.com> wrote: > > I was hoping to have a broad informal meetup at Openstack Summit – I agree > with keeping everything in the open. I was hoping to get some additional > use cases from interested parties as it will help focus our efforts. > That sounds great. Don't let me hold you back from doing so by not being there. I know that there are several other people interested in this. > I will work on the four items – a good plan. I assume that for 2 we are > proposing an additional table in the ovn-nb – table 4 in the ingress path? > Yes, I think so, anyway. > For the more distributed cases I see three scenarios: > >1. All applications and VNF's in the same subnet – this currently >works with no problems. >2. Application being inserted and VNF’s in the same subnet and other >applications on remote subnets – I think this will work with some changes >to support routing. >3. VNF’s in a subnet and applications on different subnets. We >discussed this internally and can see this is a valid use case; user might >want to centralize all VNF’s for management/admin or specific hardware >allocation reasons, though “network tromboning" would be an issue. I think >it could be addressed with some additional parameters but I have not dug >into it deeply yet. >4. Any others? > > That sounds reasonable to me. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn4nfv]
I won't be at the OpenStack Summit this time around. I'm happy to jump on the phone sometime for quick clarifications if needed, but in general I think it's best if we keep discussion in public as much as possible. I want to make sure we include whoever else is interested. I certainly don't have all the answers. :-) I feel like we have a lot of good ideas, and our instincts are saying we can do this, but I know we have some details missing. I'd also like to feel reasonably confident that the solution we come up with more generally supports other uses of the networking-sfc API. What I'd like to see as a next step is a detailed end-to-end design for a simple use case that shows: 1) A sample use of the networking-sfc API 2) How we would reflect that in the OVN_Northbound database 3) An explanation of the logical flows we would generate to implement what was specified in OVN_Northbound 4) Docs on the "Life Cycle of a Packet through a Service Chain". In ovn-architecture(7), there are several very detailed "Life Cycle" sections. I feel this functionality could really benefit from a detailed walkthrough. I feel like I had a pretty good idea of how this could work if all the ports were on the same logical switch. I never figured out allowing ports in the chain to exist on separate logical switches. It'd be nice to include that in the sample. Or is that limitation a reasonable one to accept as a first cut? If so, we might be able to move quickly on a first iteration based on the work I had done before. -- Russell Bryant On Wed, Mar 30, 2016 at 1:13 PM, John McDowall < jmcdow...@paloaltonetworks.com> wrote: > Russell, > > Let me try and answer your questions: > >1. I looked at the networking-sfc API ( >http://docs.openstack.org/developer/networking-sfc/api.html#rest-api) >and I think we can fit into it pretty easily. I would use the neutron >port-pair-create and use the service-function-parameters option to pass in >a type indicating service insertion and the application-id that the service >would be inserted to. Port-pair-groups could be used to do simple chain – I >think but needs more investigation. >2. Yes, also interested in service insertion outside of Openstack, I >implemented a set of ovn-nbctl commands to enable insertion outside of >openstack. I have really used Openstack as the centralized management > plane. >3. As a “legacy” vendor :-), we would rather remain unaware of the NSH >headers, though we would change if we can see good use cases that require >the VNF to participate in the service chain. > > I assume you will be at the Openstack Summit in Austin perhaps we could do > a f2f there. > > Would like to ask everyone on the list about potential use cases so we can > make sure we can address the widest audience. > > Regards > > John > > From: Russell Bryant > Date: Tuesday, March 29, 2016 at 6:06 AM > To: John McDowall > Cc: Ben Pfaff , "discuss@openvswitch.org" < > discuss@openvswitch.org> > Subject: Re: [ovs-discuss] [ovn4nfv] > > On Mon, Mar 28, 2016 at 6:56 PM, John McDowall < > jmcdow...@paloaltonetworks.com> wrote: > >> Russell, >> >> Thanks of taking the time to provide a detailed response. Let me try and >> answer your questions, and ask a few on my own. >> >>1. Yes, I want to continue working through this as we see it really >>important to enable easy service insertion at scale. Think of the problem >>of how to deploy hundreds of VNF’s that can be scaled up/down with no >>manual intervention. >> >> > Fantastic. :-) > >> >>1. The Neutron API I created was done for much the same reason as >>your prototype - seeing how hard it was and making sure I could get >>something to work. Creating and supporting yet another API is rarely a >> good >>idea and so aligning with the networking-sfc API is the right thing to do. >>I have had a few off-line conversations with that team and will continue >> to >>try and fit this under that umbrella as it evolves. >> >> Great! Do you have specific issues with their API? I'd be interested to > hear about what changes you think should be made. > >> >>1. I agree with you idea of a separate table, once again I just took >>what I could see was the shortest path to get something working for a >>prototype. I will take a look at your code and see how to implement an >>extra table. >> >> I totally understand. A prototype of something working is a great way to > get the conversation going! > > >> >>1. The issue with routing be
Re: [ovs-discuss] [ovn4nfv]
> it is where we are seeing a need for simplicity and speed. > > A typical use case we see a lot of is protecting east-west traffic, when > an application is deployed, security is deployed with it to protect it, and > when the application is removed, security is removed. The goal here is to > deploy a “zero trust” security model. We have deployed a similar > architecture very successfully with VMWare’s NSX product, we would now like > to figure out how to do it in the open source environment. > > We would prefer to be transparent to networking “bump in the wire” as this > simplifies the interaction between the controller (OVN) and the VNF. The > only information that is shared is the logical in and out ports for the > VNF. Hence configuration requires less interactions between the networking > infrastructure and the VNF/Controller, moving the VNF or application also > becomes easier. It becomes a simple API interaction with minimal shared > state between OVN and the VNF. > > Does this make sense, it is just my rough attempt at breaking down the use > cases into a more specific set of cases we can solve? > That's a nice breakdown. I like the focus on the simpler case. I always like when a feature can be broken down into smaller useful iterations. >From an OpenStack POV, I always come back to "what API are we implementing?". You mention that networking-sfc is built in support of #1. Do you think it can also support #2, or do you think another API is more appropriate? If networking-sfc works, are there some reasonable limitations we can put in place to get a first version out? Do you have interest in this functionality in OVN outside of OpenStack? > Also what other use cases should we consider? > There seems to be some industry interest in NSH based SFC. It's not supported by OVS yet, but it should be on our radar. I suppose it just comes back to eventually wanting to support SFC-aware VNFs that expect some metadata. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn4nfv]
On Fri, Mar 25, 2016 at 11:43 AM, Ben Pfaff wrote: > Russell, you had some thoughts about SFC in OVN. I had the impression > that the approach you had in mind was more powerful than what John is > suggesting here, yet still not very complicated. I think you said that > you weren't going forward with it for now because other things were > higher priority. Do you have any comments for John? Yes, I'm sorry for being so slow to respond here. Thanks for sharing your work, John! I did indeed do a prototype. I was trying to see how difficult it would be to implement OpenStack Neutron's "networking-sfc" API. The code is here: https://github.com/russellb/ovs/commits/chaining It's not documented and testing was very minimal. It added a new table to OVN_Northbound for defining port chains. > $ ovn-nbctl lport-chain-list sw0 This listed the port chains defined on the logical switch "sw0". > lport-chain b5c37a7e-ffcb-4d19-bbd4-1e253d9e17a5 > match (inport == "sw0-port8" && ip && tcp && tcp.dst == 80) This is the traffic classifier. It defined the traffic to match on and send into the chain. I'd like to see something like this included in whatever solution we go with. > lport-pair c9c80cab-dade-4f29-847d-1e1d9959927a > outport 0c103dfa-ed5e-49db-944a-538e16ed0e87 (sw0-port1-101) > inport 0c103dfa-ed5e-49db-944a-538e16ed0e87 (sw0-port1-101) > lport-pair 6e0e19b7-55fe-41b6-81e1-14a29e5b5250 > outport d43e9e3d-0303-4929-8284-dc6c6cb76cc1 (sw0-port2-101) This defined the port chain. We'd start by sending the packet to sw0-port1-101. When it came back into sw0 from sw0-port1-101, we would send it to sw0-port2-101. I'd like to support N ports in the chain. It doesn't seem like supporting an arbitrary list is much more difficult than just 1 or 2. The primary limitation was that all ports on a chain had to be on the same logical switch. It sounds like your proposal is L2 focused, as well. I figured my prototype needs to be re-done to be L3 focused, instead. I never got to figuring out exactly what that would look like. If we're forwarding it to a new L3 destination, we need to remember the original destination IP as well. This could really use a detailed proposal that explains exactly how a packet is processed at each point in the network, along with whatever limitations and caveats we accept for a first iteration. I'd like to go back and better understand how networking-sfc proposed doing all of this. I see that in your proposal, you're focused on legacy VNFs that wouldn't have any knowledge of the chaining. That means we wouldn't be concerned with chain metadata in and out of VNFs. Maybe that's an easier place to start. I had proposed using nested ports as a way to identify which chain a packet is associated with. It's identical to how we define container ports that reside in a VM. It's a single VIF with many child ports. Each child port has a VLAN ID associated with it. That VLAN ID is the additonal piece of context we need. I added code in my branch to support MPLS for this as well, since networking-sfc was doing that. You mentioned hooking in at table 3. In current code, that's the logical switch pre-ACL table. I was thinking a new table after ACLs made sense. That way some traffic could be filtered out using ACLs and only hit a service chain after that point for deeper analysis if needed. You mention a new, custom REST API in OpenStack for this. I'd like to avoid that as best we can. The networking-sfc project is the closest thing to what we need. I'd like to see if we can use that, or help evolve it to something that would work for OVN. Hopefully that's helpful. I do still think this is something we should work out for OVN, so I'd be happy to continue to provide feedback if you're willing to keep working on it. Thanks, -- Russell Bryant On Mon, Mar 21, 2016 at 09:16:18PM +, John McDowall wrote: > > As a VNF vendor we have been looking at ways to enable customers to > simply > > scale up (and down) VNF’s in complex virtual networks at scale. Our goal > > is to help accelerate the deployment of SDN and VNF’s and more > > specifically enable zero-trust security at scale for applications. This > > requires the easy and fast deployment of Next Generation Firewalls (and > > other VNF¹s) into the traffic path of any application. > > > > Over the last several weeks we have created a prototype that implements > > a simple VNF insertion approach. Before we do additional work we have a > > couple of questions for the community: > > > > Questions > > ‹ > > > > 1. This approach has the advantage of being very simple and works w
Re: [ovs-discuss] [ovn4nfv]
On Fri, Mar 25, 2016 at 11:43 AM, Ben Pfaff wrote: > Russell, you had some thoughts about SFC in OVN. I had the impression > that the approach you had in mind was more powerful than what John is > suggesting here, yet still not very complicated. I think you said that > you weren't going forward with it for now because other things were > higher priority. Do you have any comments for John? Yes, I'm sorry for being so slow to respond here. Thanks for sharing your work, John! I did indeed do a prototype. I was trying to see how difficult it would be to implement OpenStack Neutron's "networking-sfc" API. The code is here: https://github.com/russellb/ovs/commits/chaining It's not documented and testing was very minimal. It added a new table to OVN_Northbound for defining port chains. > $ ovn-nbctl lport-chain-list sw0 This listed the port chains defined on the logical switch "sw0". > lport-chain b5c37a7e-ffcb-4d19-bbd4-1e253d9e17a5 > match (inport == "sw0-port8" && ip && tcp && tcp.dst == 80) This is the traffic classifier. It defined the traffic to match on and send into the chain. I'd like to see something like this included in whatever solution we go with. > lport-pair c9c80cab-dade-4f29-847d-1e1d9959927a > outport 0c103dfa-ed5e-49db-944a-538e16ed0e87 (sw0-port1-101) > inport 0c103dfa-ed5e-49db-944a-538e16ed0e87 (sw0-port1-101) > lport-pair 6e0e19b7-55fe-41b6-81e1-14a29e5b5250 > outport d43e9e3d-0303-4929-8284-dc6c6cb76cc1 (sw0-port2-101) This defined the port chain. We'd start by sending the packet to sw0-port1-101. When it came back into sw0 from sw0-port1-101, we would send it to sw0-port2-101. I'd like to support N ports in the chain. It doesn't seem like supporting an arbitrary list is much more difficult than just 1 or 2. The primary limitation was that all ports on a chain had to be on the same logical switch. It sounds like your proposal is L2 focused, as well. I figured my prototype needs to be re-done to be L3 focused, instead. I never got to figuring out exactly what that would look like. If we're forwarding it to a new L3 destination, we need to remember the original destination IP as well. This could really use a detailed proposal that explains exactly how a packet is processed at each point in the network, along with whatever limitations and caveats we accept for a first iteration. I'd like to go back and better understand how networking-sfc proposed doing all of this. I see that in your proposal, you're focused on legacy VNFs that wouldn't have any knowledge of the chaining. That means we wouldn't be concerned with chain metadata in and out of VNFs. Maybe that's an easier place to start. I had proposed using nested ports as a way to identify which chain a packet is associated with. It's identical to how we define container ports that reside in a VM. It's a single VIF with many child ports. Each child port has a VLAN ID associated with it. That VLAN ID is the additonal piece of context we need. I added code in my branch to support MPLS for this as well, since networking-sfc was doing that. You mentioned hooking in at table 3. In current code, that's the logical switch pre-ACL table. I was thinking a new table after ACLs made sense. That way some traffic could be filtered out using ACLs and only hit a service chain after that point for deeper analysis if needed. You mention a new, custom REST API in OpenStack for this. I'd like to avoid that as best we can. The networking-sfc project is the closest thing to what we need. I'd like to see if we can use that, or help evolve it to something that would work for OVN. Hopefully that's helpful. I do still think this is something we should work out for OVN, so I'd be happy to continue to provide feedback if you're willing to keep working on it. Thanks, -- Russell Bryant On Mon, Mar 21, 2016 at 09:16:18PM +, John McDowall wrote: > > As a VNF vendor we have been looking at ways to enable customers to > simply > > scale up (and down) VNF’s in complex virtual networks at scale. Our goal > > is to help accelerate the deployment of SDN and VNF’s and more > > specifically enable zero-trust security at scale for applications. This > > requires the easy and fast deployment of Next Generation Firewalls (and > > other VNF¹s) into the traffic path of any application. > > > > Over the last several weeks we have created a prototype that implements > > a simple VNF insertion approach. Before we do additional work we have a > > couple of questions for the community: > > > > Questions > > ‹ > > > > 1. This approach has the advantage of being very simple and works w
Re: [ovs-discuss] Ubuntu PPA for OVS master?
On Tue, Mar 22, 2016 at 3:51 PM, Matt Kassawara wrote: > I looked within the last couple of months... most of them stick with > stable branches or are stale. > Thanks, Matt. That's what I saw, as well. There's a particularly high value test case for OVN that has this as a requirement, so I think we'll need to create one. I have no idea what I'm doing, but I'll see if I can get something going. :-) -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
[ovs-discuss] Ubuntu PPA for OVS master?
Is anyone aware of an Ubuntu PPA based on the master branch of OVS? Someone is interested in using one for OVN testing, Thanks, -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] compile problem with 3.13.0-83-generic (was: installing datapath-dkms deb package fails on 3.13.0-83-generic kernel)
I tested it successfully with 3.13.0-83-generic on Ubuntu trusty. I also acked the patch. Thanks! -- Russell Bryant On Mon, Mar 21, 2016 at 12:46 PM, Jesse Gross wrote: > I sent out a patch that I believe should fix this: > http://openvswitch.org/pipermail/dev/2016-March/068150.html > > However, I don't have this exact kernel running anywhere so I only > tested that it doesn't break other kernels. Would one of you mind > trying it out? As long as it builds cleanly, I'm reasonably confident > that it should be OK. > > On Mon, Mar 21, 2016 at 5:56 AM, Russell Bryant wrote: > > I believe this is caused by backports done for this bug: > > > > https://bugs.launchpad.net/nova/+bug/1463911 > > > > -- > > Russell Bryant > > > > On Mon, Mar 21, 2016 at 5:16 AM, Russell Bryant wrote: > >> > >> FWIW, this issue has broken OpenStack CI with OVN. It was also reported > >> here: > >> > >> http://openvswitch.org/pipermail/dev/2016-March/067987.html > >> > >> On Thu, Mar 17, 2016 at 9:27 AM, Ben Pfaff wrote: > >>> > >>> Hi Zoltán. It looks like this is really a build problem against a > >>> particular kernel instead of anything to do with Debian packaging. I'm > >>> concerned that the kernel developers might skip over it because it > >>> sounds packaging-specific, so I'm following up with an updated subject > >>> line. > >>> > >>> On Thu, Mar 17, 2016 at 04:03:54PM +, Zoltán Balogh wrote: > >>> > Hi, > >>> > > >>> > Recently, I upgraded to Linux kernel version 3.13.0-83-generic from > >>> > version 3.13.0-79-generic. Then I rebuilt the debian packages and > tried to > >>> > install them. Installing the datapath-dkms package failed. > >>> > > >>> > make -C /lib/modules/3.13.0-83-generic/build > >>> > M=/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux > modules > >>> > make[1]: Entering directory > `/usr/src/linux-headers-3.13.0-83-generic' > >>> > CC [M] > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c: > >>> > In function 'ovs_fragment': > >>> > > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3: > >>> > warning: passing argument 1 of 'v6ops->fragment' from incompatible > pointer > >>> > type [enabled by default] > >>> >v6ops->fragment(skb->sk, skb, ovs_vport_output); > >>> >^ > >>> > > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3: > >>> > note: expected 'struct sk_buff *' but argument is of type 'struct > sock *' > >>> > > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3: > >>> > warning: passing argument 2 of 'v6ops->fragment' from incompatible > pointer > >>> > type [enabled by default] > >>> > > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3: > >>> > note: expected 'int (*)(struct sk_buff *)' but argument is of type > 'struct > >>> > sk_buff *' > >>> > > >>> > > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3: > >>> > error: too many arguments to function 'v6ops->fragment' > >>> > make[2]: *** > >>> > > [/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o] > >>> > Error 1 > >>> > make[1]: *** > >>> > > [_module_/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux] Error > >>> > 2 > >>> > make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-83-generic' > >>> > make: *** [default] Error 2 > >>> > make: Leaving directory > >>> > `/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux' > >>> > > >>> > I compared the include/linux/netfilter_ipv6.h files of the two > kernel > >>> > sources: > >>> > > >>> > diff > >>> > > /usr/src/linux-headers-3.13.0-83-generic/include/linux/netfilter_ipv6.h > >>> > &g
Re: [ovs-discuss] compile problem with 3.13.0-83-generic (was: installing datapath-dkms deb package fails on 3.13.0-83-generic kernel)
I believe this is caused by backports done for this bug:
https://bugs.launchpad.net/nova/+bug/1463911
--
Russell Bryant
On Mon, Mar 21, 2016 at 5:16 AM, Russell Bryant wrote:
> FWIW, this issue has broken OpenStack CI with OVN. It was also reported
> here:
>
> http://openvswitch.org/pipermail/dev/2016-March/067987.html
>
> On Thu, Mar 17, 2016 at 9:27 AM, Ben Pfaff wrote:
>
>> Hi Zoltán. It looks like this is really a build problem against a
>> particular kernel instead of anything to do with Debian packaging. I'm
>> concerned that the kernel developers might skip over it because it
>> sounds packaging-specific, so I'm following up with an updated subject
>> line.
>>
>> On Thu, Mar 17, 2016 at 04:03:54PM +, Zoltán Balogh wrote:
>> > Hi,
>> >
>> > Recently, I upgraded to Linux kernel version 3.13.0-83-generic from
>> version 3.13.0-79-generic. Then I rebuilt the debian packages and tried to
>> install them. Installing the datapath-dkms package failed.
>> >
>> > make -C /lib/modules/3.13.0-83-generic/build
>> M=/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux modules
>> > make[1]: Entering directory `/usr/src/linux-headers-3.13.0-83-generic'
>> > CC [M]
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o
>> > /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:
>> In function 'ovs_fragment':
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> warning: passing argument 1 of 'v6ops->fragment' from incompatible pointer
>> type [enabled by default]
>> >v6ops->fragment(skb->sk, skb, ovs_vport_output);
>> >^
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> note: expected 'struct sk_buff *' but argument is of type 'struct sock *'
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> warning: passing argument 2 of 'v6ops->fragment' from incompatible pointer
>> type [enabled by default]
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> note: expected 'int (*)(struct sk_buff *)' but argument is of type 'struct
>> sk_buff *'
>> >
>> /var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.c:730:3:
>> error: too many arguments to function 'v6ops->fragment'
>> > make[2]: ***
>> [/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux/actions.o]
>> Error 1
>> > make[1]: ***
>> [_module_/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux]
>> Error 2
>> > make[1]: Leaving directory `/usr/src/linux-headers-3.13.0-83-generic'
>> > make: *** [default] Error 2
>> > make: Leaving directory
>> `/var/lib/dkms/openvswitch/2.5.0.dpdk2.2/build/datapath/linux'
>> >
>> > I compared the include/linux/netfilter_ipv6.h files of the two kernel
>> sources:
>> >
>> > diff
>> /usr/src/linux-headers-3.13.0-83-generic/include/linux/netfilter_ipv6.h
>> /usr/src/linux-headers-3.13.0-79-generic/include/linux/netfilter_ipv6.h
>> > 28d27
>> > < int (*fragment)(struct sk_buff *skb, int (*output)(struct
>> sk_buff *));
>> >
>> > It seems the new struct member fragment was introduced in nf_ipv6_ops
>> in version 3.13.0-83-general:
>> >
>> > /*
>> > * Hook functions for ipv6 to allow xt_* modules to be built-in even
>> > * if IPv6 is a module.
>> > */
>> > struct nf_ipv6_ops {
>> > int (*chk_addr)(struct net *net, const struct in6_addr *addr,
>> > const struct net_device *dev, int strict);
>> > int (*fragment)(struct sk_buff *skb, int (*output)(struct sk_buff
>> *));
>> > };
>> >
>> > While the ovs code defines fragment with three arguments in
>> netfilter_ipv6.h and ip6_route.h:
>> >
>> > #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
>> > /* Try to minimise changes required to the actions.c code for calling
>> IPv6
>> > * fragmentation. We can keep the fragment() API mostly the same,
>> except that
>> > * the callback parameter needs to be in the form that older kernels
>> accept.
>> > * We don't backport the other ipv6_ops as they're currently unused by
>> OVS. */
>> > struct ovs_nf_ipv6_ops {
>> > int (*fragment)(struct sock *sk, struct sk_buff
Re: [ovs-discuss] compile problem with 3.13.0-83-generic (was: installing datapath-dkms deb package fails on 3.13.0-83-generic kernel)
_ipv6_ops(void)
> > {
> > return NULL;
> > }
> > #endif
> > #define nf_get_ipv6_ops ovs_nf_get_ipv6_ops
> >
> > ---
> >
> > #ifndef HAVE_NF_IPV6_OPS_FRAGMENT
> > #ifdef OVS_FRAGMENT_BACKPORT
> > int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
> >int (*output)(OVS_VPORT_OUTPUT_PARAMS));
> > #else
> > static inline int rpl_ip6_fragment(struct sock *sk, struct sk_buff *skb,
> > int (*output)(struct sk_buff *))
> > {
> > kfree_skb(skb);
> > return -ENOTSUPP;
> > }
> > #endif /* OVS_FRAGMENT_BACKPORT */
> > #define ip6_fragment rpl_ip6_fragment
> > #endif /* HAVE_NF_IPV6_OPS_FRAGMENT */
> >
> > Best regards,
> > Zoltán
> >
> > ___
> > discuss mailing list
> > discuss@openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN flow problem
On Thu, Mar 17, 2016 at 9:30 AM, Ben Pfaff wrote: > On Thu, Mar 17, 2016 at 04:23:35AM -0400, Marcin Mirecki wrote: > > I'm have a problem with OVN. > > I'm using a build version of master, last commit was: > a36bb33445acdbc5bfc30ecab8408dac9a99913e > > > > > > I have ovn up and running, but it looks like it is generating the ovs > flows incorrectly. > > (you can fast forward to the PROBLEMS section at the bottom of the email) > > > > > > I have a ovs/ovn env with one vm acting as a switch (a simple setup just > to demonstrate the problem), two nics that need to be bridged: > > > > VM > > -- > > || > > |ovn/ovs | > > <--ens8 <--->ens9 --> > > || > > -- > > (keeping it as simple as possible to make it less complicated) > > > > I'm setting it up: > > ovn-nbctl lswitch-add sw0 > > ovn-nbctl lport-add sw0 lport8 > > ovn-nbctl lport-add sw0 lport9 > > > > ovs-vsctl add-port br-int ens8 -- set Interface ens8 > external_ids:iface-id=lport8 > > ovs-vsctl add-port br-int ens9 -- set Interface ens9 > external_ids:iface-id=lport9 > > It looks like you didn't tell OVN the lports' MAC addresses, with > lport-set-addresses. It needs that information to do switching (or you > can tell it "unknown"). I've seen this before when helping debug setups. It would be nice to help catch this somehow and flag that configuration is incomplete, but I haven't come up with any specific ideas. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Compatibility of OVS 2.4 with DPDK 2.2
On Friday, March 4, 2016, Vivek Gupta wrote: > Do we have DPDK integrated OVS branch in Git? > There's no special branch for it. It's in the main branches (master and release branches). -- Russell -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Port security in OVS
On Wed, Feb 24, 2016 at 5:58 AM, Anudattu 2 wrote: > Thanks a lot for your reply, we believe as you said it can be implemented > in OVS. > > We are planning to involve in OVS contribution, we are going to start on > port security implementation in OVS. > > Any guidelines from your side are much appreciated. > I think the point was that OVS already provides the functionality necessary for a consumer of OVS to implement port security. As one example, you could look at the flows that OVN generates for its port security functionality. Other consumers of OVS do similar things. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb behavior under ovn management plane scaling
On 01/28/2016 05:25 PM, Andy Zhou wrote: > > > On Thu, Jan 28, 2016 at 11:35 AM, Ryan Moats <mailto:rmo...@us.ibm.com>> wrote: > > As promised on today's OVN IRC meeting... > > We're in the process of testing OVN at scale as well as looking at > the performance of the various planes of OVN. > > One of the initial management plane scaling tests is to > > 1. Create OpenStack external etwork x1 with IPv4 subnet xs1 (we > aren't testing the data plane, so we don't have to worry about NAT) > 2. Replicate the following template 400 times > a. Create OpenStack project p(i) and then in p(i): > b. create a network n1 and assign an IPv4 subnet s1 to it > c. create a router, assign an interface to s1 and set the router's > external gateway to xs1 > d. launch a compute instance i1, attached to n1 > > [in a network line diagram: i1 -- n1(s1) -- r1 -- x1(xs1)] > > When doing this with on a four VM cloud (each VM has four CPU cores > and 16 GB of memory), we are seeing the steps "assign an interface > to s1" and "set the router's external gateway to xs1" take longer > amounts of time as the number of templates increases. > > Looking at the ovsdb server logs during this test, one can break > down OVN_Northbound operations into three buckets: > (1) pure insert operations > (2) operations that combine and insert and an update > (3) pure update operations > > Data from buckets (1) and (2) were combined and plotted in > http://ibin.co/2V2VVrQYDKyI - The vertical axis is in seconds, and > the horizontal axis is "transaction during the test", so while I > can't tell you exactly where in the test a particular point > occurred, one can look at the graph and say with some level > of confidence that inserting rows into a table isn't all that > expensive an operation. > > Data from bucket (3) was plotted as http://ibin.co/2V2Vjb9rVqUK - > Again, the vertical axis is in seconds, and the horizontal axis is > "transaction during the test". All of these operations are updates > to port state in the Logical_Ports table and I read this plot as > saying that as we have more and more ports in the Logical_Ports > table, update operations can take longer and longer. Given the OVN > scale I am looking at (the current test cloud is 125 hypervisors), > any linearity in time (even via increased variability) is something > I'd like to see if we can improve... > > Thanks for sharing the data. The master branch supports "monitor2" and > "update2" JSONRPC messages. Do you know if they are being used? That's the default unless you explicitly turn it off, right? -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb behavior under ovn management plane scaling
On 01/28/2016 03:36 PM, Ryan Moats wrote: > Yes, that was the first bottleneck we hit and we've taken the work > that led to your RFC and gone looking for the next bottleneck, which > now appears to be communications between the networking-ovn plugin > and ovn-northd. The first step in that path is from the plugin to > ovsdb-server, so I view my initial post as one facet of the > problem... OK, thanks. What behavior are you seeing between the Neutron plugin and the northbound database exactly that makes it the bottleneck? Is neutron-server maxed out trying to keep up with the request load? or ovsdb-server? or? Also, are you running multiple Neutron API workers? -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovsdb behavior under ovn management plane scaling
On 01/28/2016 02:35 PM, Ryan Moats wrote: > As promised on today's OVN IRC meeting... > > We're in the process of testing OVN at scale as well as looking at the > performance of the various planes of OVN. > > One of the initial management plane scaling tests is to > > 1. Create OpenStack external etwork x1 with IPv4 subnet xs1 (we aren't > testing the data plane, so we don't have to worry about NAT) > 2. Replicate the following template 400 times > a. Create OpenStack project p(i) and then in p(i): > b. create a network n1 and assign an IPv4 subnet s1 to it > c. create a router, assign an interface to s1 and set the router's > external gateway to xs1 > d. launch a compute instance i1, attached to n1 > > [in a network line diagram: i1 -- n1(s1) -- r1 -- x1(xs1)] > > When doing this with on a four VM cloud (each VM has four CPU cores and > 16 GB of memory), we are seeing the steps "assign an interface to s1" > and "set the router's external gateway to xs1" take longer amounts of > time as the number of templates increases. > > Looking at the ovsdb server logs during this test, one can break down > OVN_Northbound operations into three buckets: > (1) pure insert operations > (2) operations that combine and insert and an update > (3) pure update operations > > Data from buckets (1) and (2) were combined and plotted in > http://ibin.co/2V2VVrQYDKyI - The vertical axis is in seconds, and the > horizontal axis is "transaction during the test", so while I can't tell > you exactly where in the test a particular point occurred, one can look > at the graph and say with some level > of confidence that inserting rows into a table isn't all that expensive > an operation. > > Data from bucket (3) was plotted as http://ibin.co/2V2Vjb9rVqUK - Again, > the vertical axis is in seconds, and the horizontal axis is "transaction > during the test". All of these operations are updates to port state in > the Logical_Ports table and I read this plot as saying that as we have > more and more ports in the Logical_Ports table, update operations can > take longer and longer. Given the OVN scale I am looking at (the current > test cloud is 125 hypervisors), any linearity in time (even via > increased variability) is something I'd like to see if we can improve... Thanks a lot for your work and for sharing your results. When it comes to working on OVN performance, I'd like to make sure we're working on the most important things. Analysis and optimization work can take a lot of time, so it's best if we focus on the bottlenecks. My understanding based on the IBM scale testing so far was that it appeared ovn-controller was the first bottleneck hit. We also dug into it and determined it was logical flow processing taking the bulk of the time. I was under the impression that ovsdb-server was actually doing great. Is your experience different? How do your results relate to the performance of the rest of the system? Thanks, -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovn-nbctl does not support logical router
On 01/28/2016 03:59 AM, Na Zhu wrote: > Hi, > > Since OVN already supports logical router, i think should also add > logical router support to command ovn-nbctl. Do you have specific command suggestions? We've discussed adding logical routers to the "show" command. I think that makes sense, but it hasn't been done yet. For creating/modifying them, you can actually do it using the generic db command support that is now included. Here is an example test script that I use with ovs-sandbox. It creates 2 logical switches with 1 port on each switch. It then connects the two logical switches together with a logical router. ovn-nbctl lswitch-add sw0 ovn-nbctl lport-add sw0 sw0-port1 ovn-nbctl lport-set-addresses sw0-port1 "50:54:00:00:00:01 192.168.0.2" ovn-nbctl lswitch-add sw1 ovn-nbctl lport-add sw1 sw1-port1 ovn-nbctl lport-set-addresses sw1-port1 "50:54:00:00:00:03 11.0.0.2" ovn-nbctl create Logical_Router name=lr0 lrp_uuid=`ovn-nbctl \ -- --id=@lrp create Logical_Router_port name=lrp0 \ network=192.168.0.1/24 mac='"00:00:00:00:ff:01"' \ -- add Logical_Router lr0 ports @lrp \ -- lport-add sw0 lrp0-attachment` ovn-nbctl set Logical_port lrp0-attachment type=router \ options:router-port=$lrp_uuid \ addresses='"00:00:00:00:ff:01"' lrp_uuid=`ovn-nbctl \ -- --id=@lrp create Logical_Router_port name=lrp1 \ network=11.0.0.1/24 mac='"00:00:00:00:ff:02"' \ -- add Logical_Router lr0 ports @lrp \ -- lport-add sw1 lrp1-attachment` ovn-nbctl set Logical_port lrp1-attachment type=router \ options:router-port=$lrp_uuid \ addresses='"00:00:00:00:ff:02"' ovs-vsctl add-port br-int lport1 -- set Interface lport1 external_ids:iface-id=sw0-port1 ovn-sbctl chassis-add fakechassis geneve 127.0.0.1 ovn-sbctl lport-bind sw1-port1 fakechassis -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [OVN][OpenStack] - scaling broadcast/multicast on tunnels without multicast support?
On 01/13/2016 02:11 PM, Guru Shetty wrote: > > > On 13 January 2016 at 11:06, Kevin Benton <mailto:blak...@gmail.com>> wrote: > > Hi, > > I looked through the list and see that someone already asked about > multicast addresses as a target for VXLAN tunnels[1]. Since it's not > supported, what is the suggestion to prevent broadcast/multicast > traffic in a tenant's network from wiping out the network due to the > duplication cost? > > This is something the current OVS plugin for Neutron in OpenStack > suffers from and it seems OVN will have the same issue as far as I > can tell. > > > Assuming I understood your statement correctly, with OVN, only one > broadcast packet goes in the tunnel and then it gets replicated in the > hypervisor. So the load is on the CPU instead of the network. 1 copy per hypervisor, right? meaning if a logical switch has at least 1 logical port across 100 hypervisors, it will be sent out 100 times. > For example, without severely rate-limiting or completely blocking > broadcast/multicast, a tenant network with 100 VMs on it can max out > a 10 Gbps interface adapter with a 100 mbps broadcast/multicast stream. > > 1. http://openvswitch.org/pipermail/discuss/2015-December/019632.html -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovs-dpctl-top
On 01/07/2016 05:38 PM, Arik wrote: > Hi, I've installed RDO, and I'm trying to work with ovs-dpctl-top. > When I execute ovs-dpctl-top, I get the following error. > > |Traceback (most recent call last): File "/usr/bin/ovs-dpctl-top", line > 1297, in sys.exit(main()) File "/usr/bin/ovs-dpctl-top", line > 1289, in main flows_top(args) File "/usr/bin/ovs-dpctl-top", line 1198, > in flows_top flows_read(ihdl, flow_db) File "/usr/bin/ovs-dpctl-top", > line 600, in flows_read flow_db.flow_line_add(line) File > "/usr/bin/ovs-dpctl-top", line 995, in flow_line_add > self.flow_event(fields_dict, stats_old_dict, stats_dict) File > "/usr/bin/ovs-dpctl-top", line 1087, in flow_event matches = > flow_aggregate(fields_dict, stats_new_dict) File > "/usr/bin/ovs-dpctl-top", line 583, in flow_aggregate field, stats_dict) > File "/usr/bin/ovs-dpctl-top", line 250, in element_ipv4_get > element_show = fmt % (field_type, element["src"], element["dst"]) > KeyError: 'src'||| > > |ovs-dpctl-top --version 2.4.0| Can you share the output of 'ovs-dpctl dump-flows' ? -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] monitor2 support in python idl
On 01/04/2016 10:29 AM, Numan Siddique wrote: > Hi, > > I have started working on supporting the monitor2 support in python idl. > Please let me know if some one has already started working on it, so that I > can stop my work. I'm not aware of any other work on that, but it would be good to post this to the dev list, as well. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] OVN: missing chassis and flows
On 12/08/2015 02:35 PM, Yoshio Turner wrote: > In the OVN tutorial > (https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md), > the "simple two-port setup" example works fine for me from within the > sandbox environment. > > I'm looking for pointers to help debug a similar setup I created outside > the sandbox, using veth interfaces for lport1 and lport2. After running > the setup.sh script, the OVN_Southbound database Chassis table is empty > for some reason. Also, flow tables 0, 32, 33, 34 are missing from > br-int. Packets sent between the two ports are dropped due to "no > match". I'm running on Ubuntu 15.10 with Ubuntu kernel 4.2.0-18-generic, > and OVS master branch fetched on Dec 4 > (commit 6422372c103d280450eb400ed7fe955b74deeb2a). If the Chassis table is missing, you probably missed some ovn-controller configuration. Check the ovn-controller log file. It probably is giving an error. The configuration is documented in the ovn-controller man page. http://openvswitch.org/support/dist-docs/ovn-controller.8.html Here's what ovs-sandbox does: ovs-vsctl set open . external-ids:ovn-remote=unix:"$sandbox"/db.sock ovs-vsctl set open . external-ids:ovn-encap-type=geneve ovs-vsctl set open . external-ids:ovn-encap-ip=127.0.0.1 You need to set those values as appropriate. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] [ovn] : ovn-northd not updating the south db when some new flows added in the code and restarted.
On Fri, Nov 20, 2015 at 6:16 AM, Numan Siddique wrote:
> Hi,
>
> I am seeing an issue with ovn-northd where in it is not updating the south
> db when I applied the "ovn: support ARP response for known IPs"
> patch from Han Zhou add restarted the ovn-northd.
>
> I didn't see the flows related to ARP getting reflected in the south db.
> It only got reflected when I updated the north db from neutron like
> creating a new port or restarting
> the ovn-northd again.
>
> By putting some prints, I could see that
> ovsdb_idl_txn_commit(ctx.ovnsb_txn) is returning TXN_ERROR after which it
> is blocked in poll_block().
> until some update happens in north db.
>
> The issue is not seen all the time. But only when ovsdb_idl_txn_commit
> returns TXN_ERROR.
>
> The below code is fixing the issue. Wanted to get the comments from the
> reviewers if it is the right fix or
> the problem lies some where else. Also not sure if there are any side
> effects because of the below fix.
>
> ---
> ovn/northd/ovn-northd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 8fe0c2c..1c3821f 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -1990,7 +1990,8 @@ main(int argc, char *argv[])
> }
>
> if (ovnnb_seqno == ovsdb_idl_get_seqno(ovnnb_idl) &&
> -ovn_seqno == ovsdb_idl_get_seqno(ovnsb_idl)) {
> +ovn_seqno == ovsdb_idl_get_seqno(ovnsb_idl)
> +&& !ovnnb_changes_pending) {
> ovsdb_idl_wait(ovnnb_idl);
> ovsdb_idl_wait(ovnsb_idl);
> if (ctx.ovnnb_txn) {
>
I'm not sure what the transaction error is, but this patch seems correct.
There's actually some common code we could use that would replace all of
this. First we had ovn-northd, then ovn-controller, and then
ovn-controller-vtep. ovn-controller-vtep was modeled largely on
ovn-controller and some common code was split out. In particular, see the
ovsdb_idl_loop_* functions. It seems like we should refactor the main loop
ovn-northd to use that.
--
Russell Bryant
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] SFC using OVN
On 11/09/2015 01:18 PM, v_d...@dell.com wrote: >> My original thought was a new table of chains. Each chain has a list of >> service endpoints (originally i had this as logical ports, but it'd need >> to be IP or MAC addresses, I guess). A chain would also have a match >> defined in the same syntax used by ACLs. I imagined the implementation >> in a separate logical flow table. > > Would the IP or MAC addresses be on same logical network or outside it? Everything is on the table. My guess is that in both cases, it could be either. An L2 destination could be on the same logical network, or on a physical network on the other side of a vtep logical-to-physical gateway. An L3 destination just has to be route-able from the current logical network, so it could be either. >> I wonder how much of this OPNFV has specified? This seems like the >> perfect sort of thing OPNFV can help specify and work with upstream >> projects to get implemented. > >>> Yes, I think so too. > > Will be at OPNFV summit to get clarity on SFC requirements. Great, thanks. I'd like to get started on a design doc that starts to capture the details. It may still be a few weeks before I can get back to it, though. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] SFC using OVN
On 11/03/2015 04:01 PM, Ben Pfaff wrote: > On Tue, Nov 03, 2015 at 03:45:45PM -0500, Russell Bryant wrote: >> In the meantime, we can be working on how to model this properly in >> OVN_Northbound, as well as trying to work out a reasonable >> implementation based on Geneve. The modeling in my prototype isn't >> expressive enough. > > The model that I proposed in Tokyo was to make redirection through a > chain one of the possible actions for ACLs in the OVN_Northbound > database. (I'm not claiming this is original or inspired; maybe you had > the same idea.) And have the chain be a list of parameters to the action? My original thought was a new table of chains. Each chain has a list of service endpoints (originally i had this as logical ports, but it'd need to be IP or MAC addresses, I guess). A chain would also have a match defined in the same syntax used by ACLs. I imagined the implementation in a separate logical flow table. I guess both sound like the same thing, really. It's just a matter of how strictly the data gets structured in OVN_Northbound. Doing it in ACLs sounds pretty convenient and actually makes good sense when thinking about where this fits into the logical flow stages. > Parameters would be needed, and that's probably the harder part. I > don't know what the universe of reasonable ways to redirect through a > service includes. I believe we mentioned that redirecting to an IP > address or a MAC address are both expected to be supported. But that > leaves a lot of questions, such as: > > * Would each service be expected to be able to send the packet > directly to the next service? Or would it just bounce it back > to OVN and OVN would redirect it again? > > * Would the services be able to preserve arbitrary Geneve (or > NSH) metadata that OVN attaches to packets, so that it can be > passed back to OVN on exit from the services? > > * Do the services themselves live in logical networks or are > they identified by IP address (etc.) on a physical network? > > Some of these might have obvious answers to people who work in the area > of NFV or SFC. Good questions. So far I haven't done a great job guessing correctly when I've tried to guess the answers to things like this. :-) FWIW, it seems the API proposed for Neutron (networking-sfc) proposes the services as members of logical networks. You specify the chain in terms of logical ports in that API. I wonder how much of this OPNFV has specified? This seems like the perfect sort of thing OPNFV can help specify and work with upstream projects to get implemented. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] SFC using OVN
On 11/03/2015 03:13 PM, Ben Pfaff wrote: > On Nov 3, 2015 11:57 AM, "Ben Pfaff" <mailto:b...@nicira.com>> wrote: >> >> On Tue, Oct 27, 2015 at 01:14:42AM -0500, v_d...@dell.com wrote: >> > I am currently exploring Service Function Chaining (SFC) >> > implementation using OVN and would like to hear thoughts from the >> > community. >> > >> > Has anyone implemented Service Function Chaining using OVN project and >> > would be willing to share his/her experiences? There are proposals for >> > adding NSH header as well as leveraging MPLS headers (interim solution >> > for lack of NSH support) for SFC but can someone more experienced in >> > this topic share if those modifications are really necessary for real >> > world SFC use cases? >> > >> > With the native support for L2 overlays and ACLs inherently built into >> > OVN, I am wondering if we are better off creating point to point >> > overlay networks between the VNFs and using ACLs for traffic >> > classification. Or is there more to it than that? >> >> Justin, Russell, Thomas, and I brainstormed together about SFC a bit in >> Tokyo. There was a brief discussion related to the topic on the >> openstack-dev list last week as well (see the thread >> "[neutron][networking-sfc] API clarification questions"). Thomas built >> a strawman prototype, I believe, though as I understand it the >> conversation on openstack-dev meant that it implemented an inadequate >> model. >> >> I don't know what the immediate plans are, but I expect that there'll be >> a place for SFC in OVN. > > Correction: Russell wrote the prototype. > Yeah, I tried to build a prototype but it's inadequate for a few reasons, so it needs a do-over. I think I understand the problem better, at least. :-) I basically modeled it as a chain of logical ports all on the same logical switch. If those constraints were valid, we can send the packet through a chain without having to modify the source/dest IP, or even the source/dest MAC. We need to support more interesting chains, which means we need to pass around some additional metadata. We can do that with Geneve. We also need to expose some metadata about the chain into the VM (VNF) itself. There's lots of ways we could do that, but there seems to be more momentum behind NSH for this for whatever reason. We can actually decouple how we pass metadata between hosts from how we communicate chain related metadata in/out of a VNF. If NSH gets into OVS, we can use it for SFC as well. It probably makes sense to add NSH as a generic encap for OVN. We could also use it only to pass metadata in/out of a VNF if we wanted. In the meantime, we can be working on how to model this properly in OVN_Northbound, as well as trying to work out a reasonable implementation based on Geneve. The modeling in my prototype isn't expressive enough. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] ovscon 2015 scheduling proposal: Nov. 16-17
On 05/28/2015 11:05 AM, Ben Pfaff wrote: > I'm thinking about scheduling this year's OVS conference for Nov. 16 and > 17. Any comments? I haven't verified that the space is available on > those days yet, so this is a very tentative idea. I don't know of any conflicts on those dates, but if possible it would be awesome if it got shifted by 1 or 2 days so that it didn't require traveling over the weekend. -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
Re: [ovs-discuss] Error in building Latest OVS in Fedora
On 03/27/2015 05:46 AM, Radhakrishnan, Sharmila wrote: > Hi All, > > I did a fresh clone for OVS today on Fedora21 machine(kernel - > 3.17.8-300.fc21.x86_64). > > > > I configured it to > > ./configure --with-linux=/lib/modules/3.17.8-300.fc21.x86_64/build > > > > And when I ran ‘make’ I get the below error: > > > > make[4]: Entering directory '/usr/src/kernels/3.17.8-300.fc21.x86_64' > > CC [M] /usr/src/ovs/datapath/linux/actions.o > > CC [M] /usr/src/ovs/datapath/linux/datapath.o > > /usr/src/ovs/datapath/linux/datapath.c: In function ‘dp_init’: > > /usr/src/ovs/datapath/linux/datapath.c:2268:10: error: macro "__DATE__" > might prevent reproducible builds [-Werror=date-time] > >VERSION); > > ^ Add the following to your 'make' command: $ make EXTRA_CFLAGS="-Wno-error=date-time" -- Russell Bryant ___ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
