Re: [ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

> Hello Ramu > > Can you describe your configuration for this test failure when logical > switch > arp responders are skipped for logical switch "router type" ports ? > I know the existing OVN tests (both system and non-system) pass either way. > > Thanks Darre

[ovs-dev] [PATCH v3] ovn-vtep: fix arping from vtep-gw physical port

, potentially, multiple hypervisors could independently respond. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/northd/ovn-northd.8.xml | 5 +++-- ovn/northd/ovn-northd.c | 5 - 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/ovn/northd/ovn-northd.8.xml

Re: [ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

-if (!strcmp(op->nbsp->type, "localnet")) { +/* Skip arp responder if the logical switch inport is not + * associated with a local VIF or a l2gateway port */ +if ((strcmp(op->nbsp->type, "")) && +(strcmp(op->nbsp->type, "l2gateway"))) {

[ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

, potentially, multiple hypervisors could independently respond. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/northd/ovn-northd.8.xml | 4 ++-- ovn/northd/ovn-northd.c | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/ovn/northd/ovn-northd.8.xml

Re: [ovs-dev] [PATCH] ovn-vtep: fix arping from vtep-gw physical port

> > Does the following diff work on your system? > > > diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml > index 7797417..4f1cd89 100644 > --- a/ovn/northd/ovn-northd.8.xml > +++ b/ovn/northd/ovn-northd.8.xml > @@ -421,8 +421,8 @@ > > > > -Priority-100

[ovs-dev] [PATCH] ovn-vtep: fix arping from vtep-gw physical port

treatment must be similar to the arps coming in from the localnet port - which is to skip the arp responder table. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/northd/ovn-northd.8.xml | 3 ++- ovn/northd/ovn-northd.c | 3 ++- 2 files changed, 4 insertions(+), 2 del

[ovs-dev] procfs interface to openvswitch kernel module to help debugging

Hi, I dont see a /proc filesystem based interface to help debug the openvswitch kernel module. Some of the knobs that may be useful are: a) debug knobs for stats (for those stats are not already reported), b) control knobs like: stop/start forwarding on the fast-path etc. Such an interface would

Re: [ovs-dev] [PATCH] ovn: fix ovn-northd leaks in build_acl

wrote: > > On Fri, Aug 19, 2016 at 9:06 PM, Ramu Ramamurthy <ramu.ramamur...@gmail.com> > wrote: >> >> From: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> >> >> The following leaks are due to missing ds_destroy in a few >> places in build_acl. >> &g

[ovs-dev] [PATCH] ovn: fix ovn-northd leaks in build_acl

-string.c:142) by 0x40D505: build_acls (ovn-northd.c:2346) by 0x40D505: build_lswitch_flows.constprop.36 (ovn-northd.c:2472) by 0x4072D9: build_lflows (ovn-northd.c:3845) by 0x4072D9: ovnnb_db_run (ovn-northd.c:3971) by 0x4072D9: main (ovn-northd.c:4375) Signed-off-by: Ramu

[ovs-dev] [PATCH v2] ovn: log dhcp responses for debugging

-01T18:16:22Z|00018|binding|INFO|Releasing lport eee1a9af-7513-4540-9385-9e3972bfca05 from this chassis. 2016-09-01T18:16:22Z|00019|binding|INFO|Releasing fa:16:3e:01:c3:4a 10.0.0.7 fd93:b509:aa46:0:f816:3eff:fe01:c34a Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- v1->v2:

[ovs-dev] [PATCH] ovn: log dhcp responses at INFO for debugging

to be at low rate normally. Logs appear like this: 2016-09-01T00:08:16Z|00014|pinctrl|INFO|DHCPOFFER fa:16:3e:25:b0:78 10.0.0.5 2016-09-01T00:08:16Z|00015|pinctrl|INFO|DHCPACK fa:16:3e:25:b0:78 10.0.0.5 Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/pinctrl.c | 6 +++

[ovs-dev] [PATCH] ovn: add lsp-deletion and bcast-flow removal tests for localnet

From: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> Add 2 tests for scenarios around lsp-deletion and flow removal which have escaped current unit tests. This test depends on the following patch: "ovn-controller: Back out incremental processing" and passes after applying it, but

[ovs-dev] [PATCH] ovn: fix northd leaks in build_acl

From: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> The following leaks are due to missing ds_destroy in a few places in build_acl. 5,850 bytes in 50 blocks are definitely lost in loss record 93 of 93 at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-li

[ovs-dev] [PATCH] ovn: fix ovn-northd leaks in build_acl

From: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> The following leaks are due to missing ds_destroy in a few places in build_acl. 5,850 bytes in 50 blocks are definitely lost in loss record 93 of 93 at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-li

Re: [ovs-dev] [PATCH v2] pinctrl: Fix memory leak for NAT IPs in send_garp_run().

ome of the data. This fixes the problem. > > CC: Chandra S Vejendla <csvej...@us.ibm.com> > Reported-by: Ramu Ramamurthy <ramu.ramamur...@gmail.com> > Fixes: 8439c2ebd823 ("ovn: Support for GARP for NAT IPs via localnet") > Signed-off-by: Ben Pfaff <b...@ovn.org>

[ovs-dev] [bug] ovn: make check-valgrind issues

The following are among many reported by "make check-valgrind" on the ovn tests. The ones in pinctrl.c and binding.c seem real. 2246/valgrind.28645-==28647== 1,496 bytes in 22 blocks are definitely lost in loss record 175 of 179 2246/valgrind.28645-==28647==at 0x4C29BFD: malloc (in

[ovs-dev] [PATCH] ovn: fix valgrind leak

From: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> This commit fixes the following leak found by check-valgrind in the test: "send gratuitous arp for nat ips in localnet" sset gets allocated but not destroyed. valgrind.14154-==14157== 1,892 bytes in 44 blocks are definitely lost

Re: [ovs-dev] [PATCH v7] ovn-northd: Add logical flows to support native DHCPv4

t; > - A logical flow which implements the DHCP reponder by sending >the DHCPv4 reply back to the inport once the 'put_dhcp_opts' action >is applied. > > Signed-off-by: Numan Siddique <nusid...@redhat.com> > Co-authored-by: Ben Pfaff <b...@ovn.org> &g

Re: [ovs-dev] [PATCH v7] ovn-northd: Add logical flows to support native DHCPv4

Tested to work end-to-end with openstack. On Sat, Jul 23, 2016 at 5:49 AM, Numan Siddique wrote: > OVN implements a native DHCPv4 support which caters to the common > use case of providing an IP address to a booting instance by > providing stateless replies to DHCPv4

Re: [ovs-dev] [PATCH v5] ovn-northd: Add logical flows to support native DHCPv4

Tested-By: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> with corresponding openstack patch. Is there a mechanism to rate-limit the rate of broadcast dhcp-requests ? This is useful when there are untrusted vifs requesting dhcp. I sent dhcp-requests from a namespace at a high rate (100

Re: [ovs-dev] [PATCH v4] ovn-northd: Add logical flows to support native DHCPv4

Tested-By: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> against the corresponding (rebased) openstack patch: https://review.openstack.org/#/c/243174/ Hence, Acked-By: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> On Sun, Jul 3, 2016 at 8:54 PM, Numan Siddique <nusid...@redhat.co

Re: [ovs-dev] [PATCH v10 2/2] ovn-northd: Add logical flows to support native DHCP

I tested and verified this patchset using the corresponding WIP openstack dhcp patch. native-dhcp works end-to-end as advertized - I tested with the default dhcp-options that are used when VMs boot. On Mon, Jun 6, 2016 at 10:49 PM, Numan Siddique wrote: > OVN implements a

Re: [ovs-dev] [PATCH v8 2/2] ovn-northd: Add logical flows to support native DHCP

Numan, I tested this patchset along with the corresponding WIP ml2 native-dhcp openstack patch. It looks good to me, On Tue, May 24, 2016 at 11:04 AM, Numan Siddique wrote: > OVN implements a native DHCP support which caters to the common > use case of providing an IP

Re: [ovs-dev] [PATCH v7 1/2] ovn-controller: Add 'put_dhcp_opts' action in ovn-controller

Tested-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> I tested this patchset to work end-to-end with openstack (with the corresponding WIP openstack patch). > +/* Check that the DHCP Message Type (opt 53) is present or not with > + * valid values - DHCP_MSG_DISCOVER or DHCP

Re: [ovs-dev] [PATCH v5 2/2] ovn: Add logical flows to support native DHCP

> The reason for not adding the flow in IN_ACL is because the CMS can add > flows to allow or drop DHCP traffic on a logical port if it wants to. In > the case of OpenStack networking-ovn, it is adding the below flows for each > logical port. > > table=4( ls_in_acl), priority= 2002,

Re: [ovs-dev] [PATCH] pinctrl: Fix "sparse" warning.

Darrell, Ben, Thanks for the fix, The warning was introduced by my patch "send GARP on localnet" In the future, I will run my changes through sparse (and possibly clang) to detect such problems prior to sharing a patch. ovn/controller/pinctrl.c:609:39: warning: incorrect type in assignment

Re: [ovs-dev] [PATCH v5 2/2] ovn: Add logical flows to support native DHCP

Tested-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> I tested v5 of this patchset to work end-to-end with openstack (using your openstack changes which are also under review). The options tested include dns-server and classless-static-route. A question I have is why you program these o

[ovs-dev] [PATCH RFC] ovn: localnet ports deleted, recreated sometimes after restart

/testsuite.dir/2035/hv/br-int.mgmt: connected 2016-04-28T18:35:42.460Z|00027|rconn|INFO|unix:/home/ovs/ovs/tests/testsuite.dir/2035/hv/br-int.mgmt: connected 2016-04-28T18:35:42.460Z|00028|ovsdb_idl|INFO|ovsdb_idl_row_create: Now, the transaction is complete Signed-off-by: Ramu Ramamurthy

Re: [ovs-dev] [PATCH v1 2/2] ovn: Send garp on localnet

> > Is there an equivalent of GARP for IPv6? > The "Unsolicited Neighbor Advertisement" seems to be the equivalent of GARP for IPv6. http://tools.ietf.org/html/rfc2461#section-7.2.6 The problem motivating this fix was seen with IPv4 though. ___ dev

[ovs-dev] [PATCH v2 2/2] ovn: send garp on localnet

/networking-ovn/+bug/1545897 Reported-by: Kyle Mestery <mest...@mestery.com> Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/ovn-controller.c | 2 +- ovn/controller/pinctrl.c| 244 +++- ovn/controller/pinctrl.h

[ovs-dev] [PATCH v2 1/2] ovn: Move extract_lport_addresses

Move the function extract_lport_addresses to a file in ovn/lib since that function can be used by ovn-controller also to parse addresses stored in the mac column of the port_binding table. Currently that function is used only in ovn_northd. Signed-off-by: Ramu Ramamurthy <ramu.rama

[ovs-dev] [PATCH v2 0/2] ovn: send garp on localnet

The first patch refactors the function extract_lport_addresses so that it can be used in ovn-northd and in ovn-controller. The second patch depends on the first patch, and implements the functionality to send gratuitous arps on localnet. Changes v1->v2: Changes per code-review: * send

Re: [ovs-dev] [PATCH v2 RFC] ovn: Support native dhcp using 'continuations'

Tested-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> Numan, I tested this patch to work on devstack+ovn without the openstack-plugin, with manual configuration. Notes: 1) In ovn/utilities/ovn-nbctl.c, usage() Can you add a help string to ovn-nbctl for the new command lswitch-get-dhcp-o

Re: [ovs-dev] [PATCH RFC] ovn: distributed logical port for VM metadata access

On Mon, Apr 18, 2016 at 2:55 PM, Aaron Rosen wrote: > I like this idea as well. > > The one question I have with is is how we should determine which ip address > to select for the 'distributed' port? Aaron, Thanks for your review, and feedback. We can use the dhcp-port

Re: [ovs-dev] [PATCH RFC] ovn: distributed logical port for VM metadata access

> > neutron-ovn-metadata would be something we maintain in our OpenStack plugin > repo (networking-ovn), right? > Russell, Thanks for your review and feedback, neutron-ovn-metadata would be maintained in networking-ovn repo. > I like this proposal. It suggests adding only the minimal amount of

Re: [ovs-dev] [PATCH RFC] ovn: distributed logical port for VM metadata access

> This is an interesting proposal. The alternative, which strikes me as a > terrible idea, would be to somehow implement a TCP/IP stack and HTTP > server inside OVS. > > Does there need to be a single metadata server per hypervisor, or one > per logical switch per hypervisor? > Ben, Thanks for

Re: [ovs-dev] [PATCH v1 RFC] ovn: Support native dhcp using 'continuations'

> +/* dhcp options */ > +shash_init(_opt_symtab); > +dhcp_opt_expr_symtab_add_field(_opt_symtab, "offerip", 0, > + DHCP_OPT_TYPE_IP4); > +dhcp_opt_expr_symtab_add_field(_opt_symtab, "netmask", 1, > +

Re: [ovs-dev] [PATCH v1 1/2] ovn: Move extract_lport_addresses

On Mon, Apr 11, 2016 at 6:12 PM, Ben Pfaff <b...@ovn.org> wrote: > On Sun, Apr 03, 2016 at 09:49:03PM -0400, Ramu Ramamurthy wrote: >> Move the function extract_lport_addresses to a file >> in ovn/lib since that function can be used by ovn-controller also >> to parse

Re: [ovs-dev] [PATCH v1 2/2] ovn: Send garp on localnet

On Mon, Apr 11, 2016 at 6:29 PM, Ben Pfaff <b...@ovn.org> wrote: > On Sun, Apr 03, 2016 at 09:49:04PM -0400, Ramu Ramamurthy wrote: >> In some usecases such as VM migration or when VMs reuse IP addresses, >> VMs become unreachable externally because >> external switches/

Re: [ovs-dev] [PATCH v1 2/2] ovn: Send garp on localnet

On Tue, Apr 12, 2016 at 9:37 AM, Darrell Ball <dlu...@gmail.com> wrote: > Ramu > > High level comment earlier that still applies: > > 1) garp reply is still being used rather than garp request >garp replies are more likely to be dropped or explicitly filtered so gar

[ovs-dev] [PATCH RFC] ovn: distributed logical port for VM metadata access

27 --state_path=/opt/stack/data/neutron --metadata_port=80 --metadata_proxy_user=1001 --metadata_proxy_group=1001 --debug --verbose Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/binding.c | 73 +-- ovn/controller

Re: [ovs-dev] [PATCH v2] ovn: Add software l2 gateway.

On Mon, Apr 4, 2016 at 5:58 AM, Russell Bryant wrote: > This patch implements one approach to using ovn-controller to implement > a software l2 gateway between logical and physical networks. > > A new logical port type called "gateway" is introduced here. It is very > close to

Re: [ovs-dev] [PATCH v1 RFC] ovn: Support native dhcp using 'continuations'

> @@ -89,10 +89,11 @@ enum ovn_stage { > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_L2,0, "ls_in_port_sec_l2") \ > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_IP,1, "ls_in_port_sec_ip") \ > PIPELINE_STAGE(SWITCH, IN, PORT_SEC_ND,2, "ls_in_port_sec_nd") \ > -

[ovs-dev] [PATCH v1 2/2] ovn: Send garp on localnet

/networking-ovn/+bug/1545897 Reported-by: Kyle Mestery <mest...@mestery.com> Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/ovn-controller.c | 2 +- ovn/controller/pinctrl.c| 217 +++- ovn/controller/pinctrl.h

[ovs-dev] [PATCH v1 1/2] ovn: Move extract_lport_addresses

Move the function extract_lport_addresses to a file in ovn/lib since that function can be used by ovn-controller also to parse addresses stored in the mac column of the port_binding table. Currently that function is used only in ovn_northd. Signed-off-by: Ramu Ramamurthy <ramu.rama

Re: [ovs-dev] [PATCH RFC 0/3] - send garp on localnet

> > On a separate but related topic, northd programs localnet to not respond to > regular > arp requests coming from the network via a localnet port. > > How can IP traffic be initiated from a VM outside OVN control or from the > physical network to a VM inside OVN controlled HV, connected via a

Re: [ovs-dev] [PATCH RFC 2/3] send garp on localnet

On Thu, Mar 31, 2016 at 12:33 PM, Numan Siddique wrote: >> >> +/* Add a new vif to announce garps */ >> +static void >> +send_garp_add(const struct sbrec_port_binding *binding_rec, >> + int ofport) >> +{ >> +int i; >> +for (i = 0; i < binding_rec->n_mac;

Re: [ovs-dev] [PATCH RFC 0/3] - send garp on localnet

> > Why did you choose to use reply packets ? > > request packets are less likely to be rejected by external networks > and I think thats discussed in the RFC > > I wanted to use the GARP request, but found a problem. OVN currently programs flows to respond to gratuitous arp requests from VMs,

[ovs-dev] [PATCH RFC 3/3] garp generate test

add a test to validate garp generation on localnet Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- tests/ovn.at | 61 1 file changed, 61 insertions(+) diff --git a/tests/ovn.at b/tests/ovn.at index f2ceba3..7

[ovs-dev] [PATCH RFC 2/3] send garp on localnet

Generate gratuitous ARP replies when a logical port on a localnet gets added. Such gratuitous arps help to update the mac-port bindings and arp-caches of external switches and routers on the localnet. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/ovn-contro

[ovs-dev] [PATCH RFC 1/3] refactor extract_lport_addresses

Move the function extract_lport_addresses under ovn/lib since that function can be used by ovn-controller also to parse addresses stored in the mac column of the port_binding table. Currently that funtion is used only in ovn_northd. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.

[ovs-dev] [PATCH RFC 0/3] - send garp on localnet

Problem: When a VM comes up with interface on localnet, external switches on the broadcast segment have to update their port->mac mappings and routers have to update their arp caches. This normally happens when the VM initiates traffic. on the localnet interface. But in some scenarios, when the

Re: [ovs-dev] [PATCH] ovn-controller: add restart test

On Wed, Mar 23, 2016 at 4:23 PM, Ben Pfaff <b...@ovn.org> wrote: > On Tue, Mar 22, 2016 at 04:37:16PM -0700, Ramu Ramamurthy wrote: >> > This adds a test for this invariant for a specific test case, which is >> > useful. However, I believe that this should be a unive

Re: [ovs-dev] [PATCH] ovn-controller: add restart test

> This adds a test for this invariant for a specific test case, which is > useful. However, I believe that this should be a universal invariant > for ovn-controller, so that at any time if ovn-controller is restarted > gracefully after it has converged, it should preserve these flows. Is > that

[ovs-dev] [PATCH v6 3/3] ovn: Add doc for zone-id external-id on iface record

Update documentation for the new external-id in the interface record of ovsdb. The key consists if the string "ovn-zone-id" concatenated with the logical port id, and the value is the zone-id. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/ovn-

[ovs-dev] [PATCH v6 2/3] ovn: Add a restart test

Add a test to validate that a restart of the ovn-controller will program zoneids consistently on ports. Flows before restart are compared against flows after restart to detect problems with ofports or zone-ids. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- tes

[ovs-dev] [PATCH v6 1/3] ovn: Assign zone-id consistently

. Reported-by: Russell Bryant <russ...@ovn.org> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1538696 Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/binding.c | 157 ++- 1 file changed, 141 insertions(+),

[ovs-dev] [PATCH v6 0/3] ovn: Assign zoneid consistently

Changes v5 to v6 * updates per code-review * handle child-ports and localnet ports * add a test * update docs ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] ovn: broadcast packets dropped with "drop recirc action"

On 2016-03-15 11:16, Andy Zhou wrote: On Mon, Mar 14, 2016 at 12:11 PM, Ramu Ramamurthy < srama...@linux.vnet.ibm.com> wrote: When a logical switch (localnet) has lots of ports on a hypervisor, I find that broadcast packets from one of the ports is only forwarded to a subset of the

Re: [ovs-dev] ovn: broadcast packets dropped with "drop recirc action"

On 2016-03-16 16:35, Andy Zhou wrote: On Wed, Mar 16, 2016 at 4:00 PM, Ramu Ramamurthy < srama...@linux.vnet.ibm.com> wrote: On 2016-03-15 11:16, Andy Zhou wrote: On Mon, Mar 14, 2016 at 12:11 PM, Ramu Ramamurthy < srama...@linux.vnet.ibm.com> wrote: When a logical switch (l

Re: [ovs-dev] ovn: broadcast packets dropped with "drop recirc action"

On 2016-03-15 11:16, Andy Zhou wrote: On Mon, Mar 14, 2016 at 12:11 PM, Ramu Ramamurthy < srama...@linux.vnet.ibm.com> wrote: When a logical switch (localnet) has lots of ports on a hypervisor, I find that broadcast packets from one of the ports is only forwarded to a subset of the

[ovs-dev] ovn: broadcast packets dropped with "drop recirc action"

When a logical switch (localnet) has lots of ports on a hypervisor, I find that broadcast packets from one of the ports is only forwarded to a subset of the other ports, and the kernel module shows the message - "kernel: openvswitch: ovs-system: deferred action limit reached, drop recirc action"

Re: [ovs-dev] [PATCH] ovn-controller: add restart test

> What I would probably do is submit them together: the zone-ids fix + this > test case that helps test it. If you take out your "xyz" change, will this > test fail currently? > > If i take out the change which masks the zone-ids, this test fails on master because, zone-ids dont match before and

Re: [ovs-dev] [PATCH] ovn-controller: add restart test

> > Does this depend on your zone-ids fix? Do you have another rev of that > coming? > Russell, This test does not depend on the zone-id fix, because it replaces zone-ids on flows with a dummy string "xyz". It passes on the master as is. I will send the next revision of the zone-id fix soon,

[ovs-dev] [PATCH] ovn-controller: add restart test

Add a test to validate that a restart of the ovn-controller will program flows in table 0 consistently. Flows before restart are compared against flows after restart to detect problems with ofports or zone-ids. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- tes

[ovs-dev] [PATCH] ovn-controller: race between binding-run and patch-run for localnet ports

ion. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/patch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ovn/controller/patch.c b/ovn/controller/patch.c index 753ce3e..cfae613 100644 --- a/ovn/controller/patch.c +++ b/ovn/controller/patch.c

Re: [ovs-dev] [ovs-dev, v5] ovn-controller: Assign zone-id consistently

Thanks for your review! > > From this part of the patch, it looks like external-ids:zone-id is > accepted even if there are duplicates, or if the value is not valid. I > think that it should reject such cases: > > With that in mind, update_local_zone_ids() should also update >

[ovs-dev] [RFC] OVN: Support Static Route

Reported-At: https://bugs.launchpad.net/networking-ovn/+bug/1539347 Reported-By: na...@cn.ibm.com Co-Authored-By: na...@cn.ibm.com,rua...@cn.ibm.com --- openstack-neutron (CMS) allows the configuration of "static-routes" on a router as shown below. neutron router-update --route

Re: [ovs-dev] [PATCH v5] ovn-controller: Assign zone-id consistently

> > > Unfortunately, I thought of another issue that complicates this whole > approach. A single interface does not necessarily map to a single > logical port and zone ID. We support sub-ports, initially aimed at > modelling containers in VMs. That means we need to track N different > zone IDs

[ovs-dev] [PATCH v5] ovn-controller: Assign zone-id consistently

rom that record Reported-by: Russell Bryant <russ...@ovn.org> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1538696 Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- Changes v3 to v4: update as per code-review * simplify code to update zone-id o

[ovs-dev] [PATCH v4] ovn-controller: Assign zone-id consistently

rom that record Reported-by: Russell Bryant <russ...@ovn.org> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1538696 Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- Changes v3 to v4: update as per code-review * simplify code to update zone-id only when ne

[ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

rom that record Reported-by: Russell Bryant <russ...@ovn.org> Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1538696 Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- Changes v1 to v2 * add check for null br-int Changes v2 to v3 * updates per code-review

[ovs-dev] [PATCH] ovn-controller: Assign zone-ids consistently

-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/binding.c | 70 +++- 1 file changed, 63 insertions(+), 7 deletions(-) diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c index ce9cccf..28adcef 100644 ---

Re: [ovs-dev] [PATCH] ovn-controller: Assign zone-ids consistently

Resend (apologies) as the mailer mangled spaces on the patch. Signed-off-by: Ramu Ramamurthy <ramu.ramamur...@us.ibm.com> --- ovn/controller/binding.c | 70 +++- 1 file changed, 63 insertions(+), 7 deletions(-) diff --git a/ovn/cont

Re: [ovs-dev] [PATCH] ovn-controller: Assign zone-ids consistently

On 2016-02-08 11:12, Russell Bryant wrote: On 02/08/2016 02:00 PM, Ramu Ramamurthy wrote: Resend (apologies) as the mailer mangled spaces on the patch. Can you try posting with the git-send-email utility? I am posting again from a better behaved mailer

[ovs-dev] ovs segments frames when transmitting to veth

Problem: - We are running centos 7.2 (ovs-kernel module from distribution) with OVS 2.3.1. Large tcp frames (> 30Kbytes gro'd) are coming into a vxlan-tunnel port and switched by an ovs-bridge onto a veth port vxlan-tunnel--(gro'd tcp frames sized > 30K)-->OVS-bridge--(frames

Re: [ovs-dev] ovs segments frames when transmitting to veth

On 2016-01-13 16:22, Jesse Gross wrote: On Wed, Jan 13, 2016 at 3:51 PM, Ramu Ramamurthy <srama...@linux.vnet.ibm.com> wrote: Problem: - We are running centos 7.2 (ovs-kernel module from distribution) with OVS 2.3.1. Large tcp frames (> 30Kbytes gro'd) are coming int

Re: [ovs-dev] [PATCH RFC] - vxlan udp csum and openstack ovs performance

On 2015-08-27 18:26, Jesse Gross wrote: On Thu, Aug 27, 2015 at 5:46 PM, Ramu Ramamurthy srama...@linux.vnet.ibm.com wrote: We found that enabling UDP checksums for vxlan triggers GRO on the receiver, and boosts the vxlan performance to 8+ Gbps. Hence, we want to enable vxlan csum for OVS

[ovs-dev] [PATCH RFC] - vxlan udp csum and openstack ovs performance

posting again, since the earlier emailer mangles email addresses. Overview: We are running openstack kilo with neutron OVS using intel 10G adapters (br kx4 dual-port, 82599es). neutron OVS is using vxlan tunnels. We are using RHEL 7.1 (which uses the 3.x kernel). Openvswitch kernel