[ovs-dev] [PATCH v5 2/3] ovn: Gratuitous ARP for centralized NAT rules on a distributed router

[Mickey Spiegel]

This patch extends gratuitous ARP support for NAT addresses so that it
applies to centralized NAT rules on a distributed router, in addition to
the existing gratuitous ARP support for NAT addresses on gateway routers.
Centralized NAT rules have type other than "dnat_and_snat", or have type
"dnat_and_snat" but do not specify external_mac or logical_port.  These
NAT rules apply on the redirect-chassis.

Gratuitous ARP packets for centralized NAT rules on a distributed router
are only generated on the redirect-chassis.  This is achieved by extending
the syntax for "options:nat-addresses" in the southbound database,
allowing the condition 'is_chassis_resident("LPORT_NAME")' to be appended
after the MAC and IP addresses.  This condition is automatically inserted
by ovn-northd when the northbound "options:nat-addresses" is set to
"router" and the peer is a distributed gateway port.

A separate patch will be required to support gratuitous ARP for
distributed NAT rules that specify logical_port and external_mac.  Since
the MAC address differs and the logical port often resides on a different
chassis from the redirect-chassis, these addresses cannot be included in
the same "nat-addresses" string as for centralized NAT rules.

Signed-off-by: Mickey Spiegel 
---
 ovn/controller/pinctrl.c | 115 ---
 ovn/lib/ovn-util.c   |  38 +---
 ovn/lib/ovn-util.h   |   2 +
 ovn/northd/ovn-northd.c  |  52 +++--
 ovn/ovn-nb.xml   |  38 +---
 ovn/ovn-sb.xml   |  32 +
 tests/ovn.at |  75 +++
 7 files changed, 310 insertions(+), 42 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index b342189..e564a30 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -37,6 +37,7 @@
 #include "lib/dhcp.h"
 #include "ovn-controller.h"
 #include "ovn/actions.h"
+#include "ovn/lex.h"
 #include "ovn/lib/logical-fields.h"
 #include "ovn/lib/ovn-dhcp.h"
 #include "ovn/lib/ovn-util.h"
@@ -1048,8 +1049,12 @@ send_garp_update(const struct sbrec_port_binding 
*binding_rec,
  ld->localnet_port->logical_port));
 
 volatile struct garp_data *garp = NULL;
-/* Update GARP for NAT IP if it exists. */
-if (!strcmp(binding_rec->type, "l3gateway")) {
+/* Update GARP for NAT IP if it exists.  Consider port bindings with type
+ * "l3gateway" for logical switch ports attached to gateway routers, and
+ * port bindings with type "patch" for logical switch ports attached to
+ * distributed gateway ports. */
+if (!strcmp(binding_rec->type, "l3gateway")
+|| !strcmp(binding_rec->type, "patch")) {
 struct lport_addresses *laddrs = NULL;
 laddrs = shash_find_data(nat_addresses, binding_rec->logical_port);
 if (!laddrs) {
@@ -1173,6 +1178,7 @@ get_localnet_vifs_l3gwports(const struct ovsrec_bridge 
*br_int,
 if (!iface_rec->n_ofport) {
 continue;
 }
+/* Get localnet port with its ofport. */
 if (localnet) {
 int64_t ofport = iface_rec->ofport[0];
 if (ofport < 1 || ofport > ofp_to_u16(OFPP_MAX)) {
@@ -1181,6 +1187,7 @@ get_localnet_vifs_l3gwports(const struct ovsrec_bridge 
*br_int,
 simap_put(localnet_ofports, localnet, ofport);
 continue;
 }
+/* Get localnet vif. */
 const char *iface_id = smap_get(_rec->external_ids,
 "iface-id");
 if (!iface_id) {
@@ -1202,24 +1209,105 @@ get_localnet_vifs_l3gwports(const struct ovsrec_bridge 
*br_int,
 
 const struct local_datapath *ld;
 HMAP_FOR_EACH (ld, hmap_node, local_datapaths) {
-if (!ld->has_local_l3gateway) {
+if (!ld->localnet_port) {
 continue;
 }
 
+/* Get l3gw ports.  Consider port bindings with type "l3gateway"
+ * that connect to gateway routers (if local), and consider port
+ * bindings of type "patch" since they might connect to
+ * distributed gateway ports with NAT addresses. */
 for (size_t i = 0; i < ld->ldatapath->n_lports; i++) {
 const struct sbrec_port_binding *pb = ld->ldatapath->lports[i];
-if (!strcmp(pb->type, "l3gateway")
-/* && it's on this chassis */) {
+if ((ld->has_local_l3gateway && !strcmp(pb->type, "l3gateway"))
+|| !strcmp(pb->type, "patch")) {
 sset_add(local_l3gw_ports, pb->logical_port);
 }
 }
 }
 }
 
+static bool
+pinctrl_is_chassis_resident(const struct lport_index *lports,
+const struct sbrec_chassis *chassis,
+const char *port_name)
+{
+const struct sbrec_port_binding *pb
+= 

[ovs-dev] [PATCH v5 3/3] ovn: Gratuitous ARP for distributed NAT rules

[Mickey Spiegel]

This patch extends gratuitous ARP support for NAT addresses so that it
applies to distributed NAT rules on a distributed logical router.
Distributed NAT rules have type "dnat_and_snat" and specify
'external_mac' and 'logical_port'.

Gratuitous ARP packets for distributed NAT rules are only generated on
the chassis where the 'logical_port' specified in the NAT rule resides.
Gratuitous ARPs are issued for the 'external_ip' address, resolving to
the 'external_mac'.

Since the MAC address varies for each distributed NAT rule, a separate
'nat_addresses' string must be generated for each distributed NAT rule.
For this reason, in the southbound 'Port_Binding',
'options:nat-addresses' is replaced by a 'nat_addresses' column that
can have an unlimited number of instances.  In order to allow for
upgrades, pinctrl in the ovn-controller can work off either the
'nat_addresses' column (if present), or 'options:nat-addresses'
otherwise.

Signed-off-by: Mickey Spiegel 
---
 NEWS |   1 +
 ovn/controller/pinctrl.c | 108 +--
 ovn/northd/ovn-northd.c  |  85 +
 ovn/ovn-sb.ovsschema |   9 ++--
 ovn/ovn-sb.xml   |  17 ++--
 tests/ovn.at |  45 +---
 6 files changed, 185 insertions(+), 80 deletions(-)

diff --git a/NEWS b/NEWS
index 00c9106..ec8572a 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,7 @@ Post-v2.7.0
  "dot1q-tunnel" port VLAN mode.
- OVN:
  * Make the DHCPv4 router setting optional.
+ * Gratuitous ARP for NAT addresses on a distributed logical router.
- Add the command 'ovs-appctl stp/show' (see ovs-vswitchd(8)).
 
 v2.7.0 - 21 Feb 2017
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index e564a30..50b010a 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -1056,21 +1056,23 @@ send_garp_update(const struct sbrec_port_binding 
*binding_rec,
 if (!strcmp(binding_rec->type, "l3gateway")
 || !strcmp(binding_rec->type, "patch")) {
 struct lport_addresses *laddrs = NULL;
-laddrs = shash_find_data(nat_addresses, binding_rec->logical_port);
-if (!laddrs) {
-return;
-}
-int i;
-for (i = 0; i < laddrs->n_ipv4_addrs; i++) {
-char *name = xasprintf("%s-%s", binding_rec->logical_port,
-laddrs->ipv4_addrs[i].addr_s);
-garp = shash_find_data(_garp_data, name);
-if (garp) {
-garp->ofport = ofport;
-} else {
-add_garp(name, ofport, laddrs->ea, laddrs->ipv4_addrs[i].addr);
+while (laddrs = shash_find_and_delete(nat_addresses,
+  binding_rec->logical_port)) {
+int i;
+for (i = 0; i < laddrs->n_ipv4_addrs; i++) {
+char *name = xasprintf("%s-%s", binding_rec->logical_port,
+laddrs->ipv4_addrs[i].addr_s);
+garp = shash_find_data(_garp_data, name);
+if (garp) {
+garp->ofport = ofport;
+} else {
+add_garp(name, ofport, laddrs->ea,
+ laddrs->ipv4_addrs[i].addr);
+}
+free(name);
 }
-free(name);
+destroy_lport_addresses(laddrs);
+free(laddrs);
 }
 return;
 }
@@ -1304,6 +1306,42 @@ extract_addresses_with_port(const char *addresses,
 }
 
 static void
+consider_nat_address(const char *nat_address,
+ const struct sbrec_port_binding *pb,
+ struct sset *nat_address_keys,
+ const struct lport_index *lports,
+ const struct sbrec_chassis *chassis,
+ struct shash *nat_addresses)
+{
+struct lport_addresses *laddrs = xmalloc(sizeof *laddrs);
+char *lport = NULL;
+if (!extract_addresses_with_port(nat_address, laddrs, )
+|| (!lport && !strcmp(pb->type, "patch"))) {
+free(laddrs);
+if (lport) {
+free(lport);
+}
+return;
+} else if (lport) {
+if (!pinctrl_is_chassis_resident(lports, chassis, lport)) {
+free(laddrs);
+free(lport);
+return;
+}
+free(lport);
+}
+
+int i;
+for (i = 0; i < laddrs->n_ipv4_addrs; i++) {
+char *name = xasprintf("%s-%s", pb->logical_port,
+laddrs->ipv4_addrs[i].addr_s);
+sset_add(nat_address_keys, name);
+free(name);
+}
+shash_add(nat_addresses, pb->logical_port, laddrs);
+}
+
+static void
 get_nat_addresses_and_keys(struct sset *nat_address_keys,
struct sset *local_l3gw_ports,
const struct lport_index *lports,
@@ 

[ovs-dev] [PATCH v5 1/3] ovn: Fix options:router-port in Gratuitous ARP tests

[Mickey Spiegel]

In two of the Gratuitous ARP tests, "options:router-port"
is not set correctly.  This does not currently affect
validity of the tests since the next line resets
"options:router-port" to the correct value.

Reported-by: Guruchuran Shetty 
Signed-off-by: Mickey Spiegel 
---
 tests/ovn.at | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/ovn.at b/tests/ovn.at
index bbbec90..8b7ba12 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -5266,7 +5266,7 @@ ovn-nbctl create Logical_Router name=lr0 
options:chassis=hv1
 # Add router port to gateway router
 ovn-nbctl lrp-add lr0 lrp0 f0:00:00:00:00:01 192.168.0.1/24
 ovn-nbctl lsp-add ls0 lrp0-rp -- set Logical_Switch_Port lrp0-rp \
-type=router options:router-port=lrp0-rp addresses='"f0:00:00:00:00:01"'
+type=router options:router-port=lrp0 addresses='"f0:00:00:00:00:01"'
 # Add nat-address option
 ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0 
nat-addresses="f0:00:00:00:00:01 192.168.0.2"
 
@@ -5314,7 +5314,7 @@ ovn-nbctl create Logical_Router name=lr0 
options:chassis=hv1
 # Add router port to gateway router
 ovn-nbctl lrp-add lr0 lrp0 f0:00:00:00:00:01 192.168.0.1/24
 ovn-nbctl lsp-add ls0 lrp0-rp -- set Logical_Switch_Port lrp0-rp \
-type=router options:router-port=lrp0-rp addresses='"f0:00:00:00:00:01"'
+type=router options:router-port=lrp0 addresses='"f0:00:00:00:00:01"'
 # Add nat-address option
 ovn-nbctl lsp-set-options lrp0-rp router-port=lrp0 nat-addresses="router"
 # Add NAT rules
-- 
1.9.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 4/7] dpif-netlink-rtnl: add VXLAN creation support

[Joe Stringer]

On 16 March 2017 at 13:22, Eric Garver  wrote:
> Creates VXLAN devices using rtnetlink and tunnel metadata.
>
> Co-Authored-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Eric Garver 
> ---



> +static int
> +dpif_netlink_rtnl_vxlan_destroy(const char *name)
> +{
> +return dpif_netlink_rtnl_destroy(name);
> +}

Looks like this function doesn't add anything---caller can just call
dpif_netlink_rtnl_destroy() directly?

Same feedback for other tunnels.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 0/7] create tunnel devices using rtnetlink interface

[Joe Stringer]

On 16 March 2017 at 15:10, Eric Garver  wrote:
> This series adds support for the creation of tunnels using the rtnetlink
> interface. This will open the possibility for new features and flags on those
> vports without the need to change vport compatibility code.
>
> Support for STT and LISP have not been added because these are not upstream 
> yet,
> so we don't know how the interface will be like upstream. And there are no
> features in the current drivers right now we could make use of.
>
> Note: This work originally started by Thadeu Lima de Souza Cascardo.
>
> Testing:
>   - kernel 4.9.3, in-tree datapath
> - rtnetlink successfully creates devices
>   - kernel 4.2.8, in-tree datapath
> - rtnetlink is tried, but fails due to no COLLECT_METADATA support
> - genetlink successfully creates devices
>   - kernel 4.2.8, out-of-tree datapath
> - rtnetlink is not tried
> - genetlink successfully creates devices

Thanks for submitting this, Eric. I haven't had a chance to actually
try it out beyond running through my regular tester environment with
'make check-kernel', which is all green (it uses out-of-tree in most
cases, then regular upstream devices for a net-next kernel).

I have some fairly minor suggestions that you'll see on a few of the
patches but I'd expect the next version should be good to merge.

Cheers,
Joe
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 2/7] dpif-netlink: break up code that creates compat ports

[Joe Stringer]

On 16 March 2017 at 15:10, Eric Garver  wrote:
> This breaks up creating compat ports so we can reuse some of the code to
> create ports with rtnetlink.
>
> Co-authored-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Eric Garver 

Acked-by: Joe Stringer 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Fwd: In OVS2.6 userspace datapath, ARP handling for non-tunnel packet?

[Darrell Ball]

On 3/23/17, 2:59 PM, "ovs-dev-boun...@openvswitch.org on behalf of Joo Kim" 
 wrote:

Folks,

Anybody knows  about this ARP behavior in ovs2.6?   -thanks-


-- Forwarded message --
From: Joo Kim 
Date: Wed, Mar 22, 2017 at 3:58 AM
Subject: In OVS2.6 userspace datapath, ARP handling for non-tunnel packet?
To: ovs-dev@openvswitch.org


Hello,

Looks like build_tunnel_send() (which, I understand, is for tunnel
packet)   sends ARP request on the fly (using tnl_send_arp_request() )
when there is no ARP cache.

Then,  how about  ARP handling for NON-tunnel packet (=> which does not
call build_tunnel_send () )?Does it send arp request?

Not by default

 (In the code, I
don't find that kind of code)

I think you are referring to resolving the hop b/w HVs, without using tunnels
to connect said HVs, while using routing forwarding.

In this case, the expected use is for there to be a rule installed to send the 
original
packet to a controller, which would construct the arp request, send it back 
down to the switch,
have the arp reply (another rule) sent to it and later installing the binding 
rule.
This involves packet-ins/outs.



#0  build_tunnel_send (xport=0xdbab10, tunnel_odp_port=3,
flow=0x7fffb778, ctx=0x7fff9ac0)
 at ofproto/ofproto-dpif-xlate.c:2946
 #1  compose_output_action__ (ctx=ctx@entry=0x7fffa160, ofp_port=2,
xr=xr@entry=0x0,
 check_stp=check_stp@entry=true) at ofproto/ofproto-dpif-xlate.c:
3243
 #2  0x005d7bb2 in compose_output_action (xr=0x0,
ofp_port=,
 ctx=0x7fffa160) at ofproto/ofproto-dpif-xlate.c:3308
 #3  output_normal (ctx=ctx@entry=0x7fffa160,
out_xbundle=out_xbundle@entry=0xd96200,
 vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:1958
 #4  0x005d81f6 in xlate_normal_flood (ctx=ctx@entry
=0x7fffa160,
 in_xbundle=in_xbundle@entry=0xd9b3e0, vlan=vlan@entry=0) at
ofproto/ofproto-dpif-xlate.c:2401
 #5  0x005d89ad in xlate_normal (ctx=0x7fffa160) at
ofproto/ofproto-dpif-xlate.c:2604
 #6  xlate_output_action (ctx=ctx@entry=0x7fffa160, port=,
 max_len=, may_packet_in=may_packet_in@entry=true)
 at ofproto/ofproto-dpif-xlate.c:3981
 #7  0x005d51ee in do_xlate_actions (ofpacts=ofpacts@entry=
0xd99ae8,
 ofpacts_len=ofpacts_len@entry=16, ctx=ctx@entry=0x7fffa160)
 at ofproto/ofproto-dpif-xlate.c:4781
 #8  0x005da384 in xlate_actions (xin=xin@entry=0x7fffb770,
 xout=xout@entry=0x7fffbb00) at ofproto/ofproto-dpif-xlate.c:
5618
 #9  0x005cec3c in upcall_xlate (wc=0x7fffce58,
odp_actions=0x7fffc680,
 upcall=0x7fffbaa0, udpif=0xd479b0) at
ofproto/ofproto-dpif-upcall.c:1102
 #10 process_upcall (udpif=udpif@entry=0xd479b0, upcall=upcall@entry=
0x7fffbaa0,
 odp_actions=odp_actions@entry=0x7fffc680, wc=wc@entry
=0x7fffce58)
___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=grsVZ3eXMxJ9_ta4SIIRRhFhYcRMDJ0x3XzWaI7xSV8=DP1FHEMujvEevhithC2uOnBMI0o8ph5_C1xrAoKJQ2E=
 






___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 3/7] dpif-netlink: code to create/destroy tunnel ports via rtnetlink

[Joe Stringer]

On 16 March 2017 at 15:10, Eric Garver  wrote:
> In order to be able to add those tunnels, we need to add code to create
> the tunnels and add them as NETDEV vports. And when there is no support
> to create them, we need to fallback to compatibility code and add them
> as tunnel vports.
>
> When removing those tunnels, we need to remove the interfaces as well,
> and detecting the right type might be important, at least to distinguish
> the tunnel vports that we should remove and the interfaces that we
> shouldn't.
>
> Co-authored-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Eric Garver 
> ---
>  lib/automake.mk |  3 +++
>  lib/dpif-netlink-rtnl.c | 59 
> +
>  lib/dpif-netlink-rtnl.h | 47 +++
>  lib/dpif-netlink.c  | 52 +++
>  lib/dpif-netlink.h  |  2 ++
>  5 files changed, 154 insertions(+), 9 deletions(-)
>  create mode 100644 lib/dpif-netlink-rtnl.c
>  create mode 100644 lib/dpif-netlink-rtnl.h
>
> diff --git a/lib/automake.mk b/lib/automake.mk
> index b266af13e4c7..73706529de5a 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -352,6 +352,8 @@ if LINUX
>  lib_libopenvswitch_la_SOURCES += \
> lib/dpif-netlink.c \
> lib/dpif-netlink.h \
> +   lib/dpif-netlink-rtnl.c \
> +   lib/dpif-netlink-rtnl.h \
> lib/if-notifier.c \
> lib/if-notifier.h \
> lib/netdev-linux.c \
> @@ -382,6 +384,7 @@ if WIN32
>  lib_libopenvswitch_la_SOURCES += \
> lib/dpif-netlink.c \
> lib/dpif-netlink.h \
> +   lib/dpif-netlink-rtnl.h \
> lib/netdev-windows.c \
> lib/netlink-conntrack.c \
> lib/netlink-conntrack.h \
> diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
> new file mode 100644
> index ..1f816feee569
> --- /dev/null
> +++ b/lib/dpif-netlink-rtnl.c
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (c) 2017 Red Hat, Inc.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at:
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#include 
> +
> +#include "dpif-netlink-rtnl.h"
> +#include "dpif-netlink.h"
> +
> +
> +int
> +dpif_netlink_rtnl_port_create(struct netdev *netdev)
> +{
> +switch (netdev_to_ovs_vport_type(netdev_get_type(netdev))) {
> +case OVS_VPORT_TYPE_VXLAN:
> +case OVS_VPORT_TYPE_GRE:
> +case OVS_VPORT_TYPE_GENEVE:
> +case OVS_VPORT_TYPE_NETDEV:
> +case OVS_VPORT_TYPE_INTERNAL:
> +case OVS_VPORT_TYPE_LISP:
> +case OVS_VPORT_TYPE_STT:
> +case OVS_VPORT_TYPE_UNSPEC:
> +case __OVS_VPORT_TYPE_MAX:
> +default:
> +return EOPNOTSUPP;
> +}
> +return 0;
> +}
> +
> +int
> +dpif_netlink_rtnl_port_destroy(const char *name OVS_UNUSED, const char *type)
> +{
> +switch (netdev_to_ovs_vport_type(type)) {
> +case OVS_VPORT_TYPE_VXLAN:
> +case OVS_VPORT_TYPE_GRE:
> +case OVS_VPORT_TYPE_GENEVE:
> +case OVS_VPORT_TYPE_NETDEV:
> +case OVS_VPORT_TYPE_INTERNAL:
> +case OVS_VPORT_TYPE_LISP:
> +case OVS_VPORT_TYPE_STT:
> +case OVS_VPORT_TYPE_UNSPEC:
> +case __OVS_VPORT_TYPE_MAX:
> +default:
> +return EOPNOTSUPP;
> +}
> +return 0;
> +}
> diff --git a/lib/dpif-netlink-rtnl.h b/lib/dpif-netlink-rtnl.h
> new file mode 100644
> index ..5fef314a20f6
> --- /dev/null
> +++ b/lib/dpif-netlink-rtnl.h
> @@ -0,0 +1,47 @@
> +/*
> + * Copyright (c) 2017 Red Hat, Inc.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at:
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#ifndef DPIF_NETLINK_RTNL_H
> +#define DPIF_NETLINK_RTNL_H 1
> +
> +#include 
> +
> +#include "netdev.h"
> +
> +/* Declare these to keep sparse happy. */
> +int dpif_netlink_rtnl_port_create(struct netdev *netdev);
> +int dpif_netlink_rtnl_port_destroy(const char *name OVS_UNUSED,
> + 

Re: [ovs-dev] [PATCH v4 2/2] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Chandran, Sugesh]

Hi Ben,
Not a problem, Thank you for your reply.
Will send out the next version of patch after the merge.


Regards
_Sugesh


> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Saturday, March 25, 2017 12:31 PM
> To: Chandran, Sugesh 
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v4 2/2] tunneling: Avoid recirculation on
> datapath by computing the recirculate actions at translate time.
> 
> Sorry I forgot to respond earlier, thanks for the reminder.  I've now
> responded directly to the previous message.
> 
> On Sat, Mar 25, 2017 at 04:52:39AM +, Chandran, Sugesh wrote:
> > Can anyone have a look and let me know the comments/suggestions?
> >
> >
> > Regards
> > _Sugesh
> >
> > > -Original Message-
> > > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > > boun...@openvswitch.org] On Behalf Of Chandran, Sugesh
> > > Sent: Wednesday, March 8, 2017 1:52 PM
> > > To: 'Ben Pfaff' 
> > > Cc: d...@openvswitch.org
> > > Subject: Re: [ovs-dev] [PATCH v4 2/2] tunneling: Avoid recirculation
> > > on datapath by computing the recirculate actions at translate time.
> > >
> > > Hi Ben,
> > > Please find my answer below.
> > > Regards
> > > _Sugesh
> > >
> > >
> > > > -Original Message-
> > > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > > Sent: Tuesday, March 7, 2017 6:07 PM
> > > > To: Chandran, Sugesh 
> > > > Cc: d...@openvswitch.org; Gray, Mark D ;
> > > > jan.scheur...@ericsson.com; ja...@ovn.org; Zoltán Balogh
> > > > 
> > > > Subject: Re: [PATCH v4 2/2] tunneling: Avoid recirculation on
> > > > datapath by computing the recirculate actions at translate time.
> > > >
> > > > On Thu, Feb 09, 2017 at 03:41:54PM +, Sugesh Chandran wrote:
> > > > > Openvswitch datapath recirculates packets for tunneling, i.e.
> > > > > the incoming packets are encapsulated at first pass. Further
> > > > > actions are applied on encapsulated packets on the second pass
> > > > > after
> > > recirculating.
> > > > > The proposed patch compute and append the post tunnel actions at
> > > > > the time of translation itself instead of recirculating at datapath.
> > > > > These actions are solely depends on tunnel attributes so there
> > > > > is no need of
> > > > datapath recirculation.
> > > > > By avoiding the recirculation at datapath, the patch offers upto
> > > > > 30% performance improvement for VxLAN tunneling in our testing.
> > > > > The action execution logic is using the new CLONE action to
> > > > > define the packet cloning when the actions are combined. The
> > > > > lenght in the CLONE action specifies the size of nested action set.
> > > > >
> > > > > Also fixing the test suites failures that are introduced by
> > > > > CLONE action in tunneling except the ovn test case 2299.
> > > >
> > > > I guess by this you mean that this test still consistently fails?
> > > >   2301: ovn -- 1 LR with distributed router gateway port FAILED
> > > > (ovn.at:6658)
> > > >
> > > > What's the plan for that, presumably we can't apply a patch that
> > > > causes test failures?
> > > [Sugesh] : The test case is failing due to the missing datapath rule.
> > > With our limited knowledge on the OVN and OVS UT setup, Here are our
> > > findings, The tunnel(in the test case its geneve) create two rules
> > > in the datapath for packet forwarding.
> > > The proposed patch is combining them into single rule to avoid the
> > > recirculation and speed up the packet processing.
> > > The failing test case is trying to send packets directly to the
> > > outer bridge to match on nonexistent second rule.
> > > Should we comment out this output validation in the test case?
> > > Please let me know your inputs on this? Also looking for help from
> > > OVN experts who can suggest a fix for the same?
> > >
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > dev mailing list
> > > d...@openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 2/2] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Chandran, Sugesh]

Regards
_Sugesh


> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Saturday, March 25, 2017 12:30 PM
> To: Chandran, Sugesh 
> Cc: d...@openvswitch.org; Gray, Mark D ;
> jan.scheur...@ericsson.com; ja...@ovn.org; Zoltán Balogh
> 
> Subject: Re: [PATCH v4 2/2] tunneling: Avoid recirculation on datapath by
> computing the recirculate actions at translate time.
> 
> On Wed, Mar 08, 2017 at 08:51:38PM +, Chandran, Sugesh wrote:
> > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > Sent: Tuesday, March 7, 2017 6:07 PM
> > > To: Chandran, Sugesh 
> > > Cc: d...@openvswitch.org; Gray, Mark D ;
> > > jan.scheur...@ericsson.com; ja...@ovn.org; Zoltán Balogh
> > > 
> > > Subject: Re: [PATCH v4 2/2] tunneling: Avoid recirculation on
> > > datapath by computing the recirculate actions at translate time.
> > >
> > > On Thu, Feb 09, 2017 at 03:41:54PM +, Sugesh Chandran wrote:
> > > > Openvswitch datapath recirculates packets for tunneling, i.e.
> > > > the incoming packets are encapsulated at first pass. Further
> > > > actions are applied on encapsulated packets on the second pass after
> recirculating.
> > > > The proposed patch compute and append the post tunnel actions at
> > > > the time of translation itself instead of recirculating at
> > > > datapath. These actions are solely depends on tunnel attributes so
> > > > there is no need of
> > > datapath recirculation.
> > > > By avoiding the recirculation at datapath, the patch offers upto
> > > > 30% performance improvement for VxLAN tunneling in our testing.
> > > > The action execution logic is using the new CLONE action to define
> > > > the packet cloning when the actions are combined. The lenght in
> > > > the CLONE action specifies the size of nested action set.
> > > >
> > > > Also fixing the test suites failures that are introduced by CLONE
> > > > action in tunneling except the ovn test case 2299.
> > >
> > > I guess by this you mean that this test still consistently fails?
> > >   2301: ovn -- 1 LR with distributed router gateway port FAILED
> > > (ovn.at:6658)
> > >
> > > What's the plan for that, presumably we can't apply a patch that
> > > causes test failures?
> > [Sugesh] : The test case is failing due to the missing datapath rule.
> > With our limited knowledge on the OVN and OVS UT setup, Here are our
> > findings, The tunnel(in the test case its geneve) create two rules in the
> datapath for packet forwarding.
> > The proposed patch is combining them into single rule to avoid the
> recirculation and speed up the packet processing.
> > The failing test case is trying to send packets directly to the outer 
> > bridge to
> match on nonexistent second rule.
> > Should we comment out this output validation in the test case?
> > Please let me know your inputs on this? Also looking for help from OVN
> experts who can suggest a fix for the same?
> 
> If I understand correctly, the now-failing check in the test case is checking 
> for
> an implementation detail that has changed.  If that's true, then I think it
> would be reasonable to remove that check.
[Sugesh] Yes, Indirectly its trying to check the implementation that has been 
changed.
Will remove  this validation with comments and send out the next version of 
patch.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/5] system-traffic: Add 802.1ad related tests

[Joe Stringer]

On 17 March 2017 at 15:13, Joe Stringer  wrote:
> On 17 March 2017 at 14:47, Ben Pfaff  wrote:
>> On Fri, Mar 17, 2017 at 04:13:10PM -0400, Eric Garver wrote:
>>> This series add tests for 802.1ad and dot1q-tunnel.
>>>
>>> Eric Garver (5):
>>>   system-common-macros: Add macro to check for 802.1ad support.
>>>   system-traffic: 802.1ad: Add conntrack ping tests for CVLANs.
>>>   system-traffic: 802.1ad: Add vlan_limit test case.
>>>   system-traffic: 802.1ad: Add push/pop test cases.
>>>   system-traffic: 802.1ad: Add dot1q-tunnel test case.
>>
>> Joe, do you mind reviewing this series?  I do not know much about the
>> system tests.
>
> Sure. I'll start by trying it out in my test enviroment for a variety
> of platforms, then report back and review.

LGTM, applied to master. Thanks!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Fix flow setup/delete race.

[Joe Stringer]

On 21 March 2017 at 08:51, Paul Blakey  wrote:
>
> On 20/03/2017 23:08, Joe Stringer wrote:
>>
>> If a handler thread takes a long time to set up a set of flows, it is
>> possible for one of the installed flows to be dumped and scheduled
>> for deletion by a revalidator thread before the handler is able to
>> transition the ukey into an operational state---Between the
>> dpif_operate() above this function and the ukey lock / transition logic
>> modified by this patch.
>>
>> Only transition the ukey for the flow if it wasn't already transitioned
>> to a later state by a revalidator thread.
>>
>> Fixes: 54ebeff4c03d ("upcall: Track ukey states.")
>> Reported-by: Paul Blakey 
>> Signed-off-by: Joe Stringer 
>> ---
>>  ofproto/ofproto-dpif-upcall.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
>> index 07086ee385cc..0854807e4482 100644
>> --- a/ofproto/ofproto-dpif-upcall.c
>> +++ b/ofproto/ofproto-dpif-upcall.c
>> @@ -1404,7 +1404,7 @@ handle_upcalls(struct udpif *udpif, struct upcall
>> *upcalls,
>>  ovs_mutex_lock(>mutex);
>>  if (ops[i].dop.error) {
>>  transition_ukey(ukey, UKEY_EVICTED);
>> -} else {
>> +} else if (ukey->state < UKEY_OPERATIONAL) {
>>  transition_ukey(ukey, UKEY_OPERATIONAL);
>>  }
>>  ovs_mutex_unlock(>mutex);
>>
>
>
> Tested-by: Paul Blakey 

Thanks for the confirmation, I applied this to master and branch-2.7.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Fix flow setup/delete race.

[Joe Stringer]

On 21 March 2017 at 02:44, Paul Blakey  wrote:
>
>
> On 21/03/2017 10:04, Paul Blakey wrote:
>>
>>
>>
>> On 20/03/2017 23:08, Joe Stringer wrote:
>>>
>>> If a handler thread takes a long time to set up a set of flows, it is
>>> possible for one of the installed flows to be dumped and scheduled
>>> for deletion by a revalidator thread before the handler is able to
>>> transition the ukey into an operational state---Between the
>>> dpif_operate() above this function and the ukey lock / transition logic
>>> modified by this patch.
>>>
>>> Only transition the ukey for the flow if it wasn't already transitioned
>>> to a later state by a revalidator thread.
>>>
>>> Fixes: 54ebeff4c03d ("upcall: Track ukey states.")
>>> Reported-by: Paul Blakey 
>>> Signed-off-by: Joe Stringer 
>>> ---
>>>  ofproto/ofproto-dpif-upcall.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/ofproto/ofproto-dpif-upcall.c
>>> b/ofproto/ofproto-dpif-upcall.c
>>> index 07086ee385cc..0854807e4482 100644
>>> --- a/ofproto/ofproto-dpif-upcall.c
>>> +++ b/ofproto/ofproto-dpif-upcall.c
>>> @@ -1404,7 +1404,7 @@ handle_upcalls(struct udpif *udpif, struct
>>> upcall *upcalls,
>>>  ovs_mutex_lock(>mutex);
>>>  if (ops[i].dop.error) {
>>>  transition_ukey(ukey, UKEY_EVICTED);
>>> -} else {
>>> +} else if (ukey->state < UKEY_OPERATIONAL) {
>>>  transition_ukey(ukey, UKEY_OPERATIONAL);
>>>  }
>>>  ovs_mutex_unlock(>mutex);
>>>
>>
>> Hi Joe,
>> As per other thread, I think there is a trouble locking the mutex in
>> case there is no error, as the flow is installed it can be removed
>> entirely by revalidator's revalidate/sweep:
>>
>> Here is the timing:
>>
>> Handler installs the flow
>> Handler thread is scheduled out before trying to lock the mutex
>> Revalidators revalidate dump the installed flow and decide to evict it
>> Revalidators evict the flow (push_dp_ops in revalidate)
>> Revalidator sweep delete the ukey ukey_delete(umap, ukey);
>> Revalidator calling ukey_delete postpones ukey_delete__ to free the ukey
>> and mutex
>> Handler thread is scheduled again and tries to acquire the freed lock.
>>
>> Is this correct?
>> If so, and I didn't miss something, I've suggested a alternate patch in
>> the other thread (only lock the mutex and transition to EVICTED in case
>> of an ops[i] error, leave OEPRATIONAL for dump)
>>
>
> Hi,
> The above timing/scheduling can't happen as the actual freeing of the ukey
> (ukey_delete__) is postponed after the handler returns from handle_upcalls.
> I've missed that with the other thread's patch because it used xsleep as you
> said which calls ovsrcu_quiesce_start. With sleep instead it seems to be
> postponed to after poll_block in the handler thread runs (and we don't have
> references there anymore).
>
> I don't know how the handler thread actually signals it doesn't have any
> references to the ukey anymore, can you expand on that mechanism?

Hi Paul,

Thanks for testing this out. I've been a bit busy last week so didn't
get a chance to respond.

The handler thread will not quiesce while installing a flow, so it is
guaranteed to be within the same RCU "locked" period. Until it
quiesces, any RCU-protected structures must not be freed. It adds the
ukey into the cmap which makes it available to be read from other
threads, and retains a reference to it. The revalidator will dump the
flow, lookup the entry and find it, then apparently decide to delete
the ukey. It removes the ukey from the cmap right now, but it is not
allowed to actually free it until the next RCU grace period. The
revalidator thread may continue on and reach an RCU grace period,
quiesce, and then from that thread's perspective it should be fine to
free the ukey. However, all threads must quiesce before any of the
memory currently referenced can be freed. So the handler thread must
finish dealing with this upcall then quiesce before the ukey will be
freed. Finally, once the handler quiesces, both threads have reached
the end of that RCU "locked" period and the RCU thread may go through
and clean up the ukey.

I hope that clears things up?

Cheers,
Joe
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] New custom Message - unknown OpenFlow message

[Adam]

Zitat von Ben Pfaff :


On Mon, Mar 27, 2017 at 09:08:32PM +0200, Adam Paul Rzyska wrote:

Hello,

in the last weeks I tried to exchange custom openflow messages (type
experimenter) between a controller (ONOS) and a switch (Open vSwitch). The
controller sends a really simple of-msg:

struct my_custom_struct : of_nicira_header {
 uint8_t version;
 uint8_t type == 4;
 uint16_t length;
 uint32_t xid;
 uint32_t experimenter == 0x2320;
 uint32_t subtype == 0x0080;
 };

In wireshark and OVS it is possible to see, that the switch receives my
custom messages. I've added ofpraw and oftype in ofp-msgs.h. My
request_method have been added to ofproto.c and also into the switch case.
It works fine with a simple VLOG_INFO() output. Every time the switch
receive my custom message a VLOG_INFO-message pops up into the logging file
of OVS. But as soon as I'm trying to implement a reply/replies a error
occurs, which crash's the vswichd (demon). This results in disconnecting the
switch from the controller.

Error message: 2017-02-05T12:09:02Z|00225|ofp_msgs|WARN|unknown OpenFlow
message (version 4, type 19, stat 0, vendor 0x2320, subtype 80)

I know exactly where it happens, but I don't know why... It starts with
ofpmp_init() in my method.


Can you post a backtrace from GDB?  Have you tried running ovs-vswitchd
under valgrind?


I've installed OVS on a tp-link router which has not enough space for  
things like gdb or make. If it's necessary I would expand the disk  
space with an additional usb stick.


So, do I run gdb like: gdb   ?

Never heard of valgrind, but found the ovs documentation  
http://docs.openvswitch.org/en/latest/topics/testing/.


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] sandbox: use ssl for ovn-controller to sb db connection

[Russell Bryant]

On Thu, Mar 23, 2017 at 12:23 PM, Lance Richardson  wrote:
> When SSL support is available, use SSL for the ovn-controller
> to southbound database connection. When configured without
> SSL, unix socket connections are used.
>
> Signed-off-by: Lance Richardson 
> ---
>  tutorial/automake.mk |  3 ++-
>  tutorial/ovs-sandbox | 42 --
>  2 files changed, 38 insertions(+), 7 deletions(-)

Tested and it's working fine for me.  Thanks for the patch.  I applied
this to master.

-- 
Russell Bryant
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC 5/5] ovn-sbctl: support setting rbac role for remote connections

[Lance Richardson]

Add support for specifying rbac "role" when setting remote
connection configuration in southbound database.

Signed-off-by: Lance Richardson 
---
 ovn/utilities/ovn-sbctl.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/ovn/utilities/ovn-sbctl.c b/ovn/utilities/ovn-sbctl.c
index 4e3cbad..654a2fb 100644
--- a/ovn/utilities/ovn-sbctl.c
+++ b/ovn/utilities/ovn-sbctl.c
@@ -861,6 +861,7 @@ pre_connection(struct ctl_context *ctx)
 ovsdb_idl_add_column(ctx->idl, _sb_global_col_connections);
 ovsdb_idl_add_column(ctx->idl, _connection_col_target);
 ovsdb_idl_add_column(ctx->idl, _connection_col_read_only);
+ovsdb_idl_add_column(ctx->idl, _connection_col_role);
 }
 
 static void
@@ -878,8 +879,10 @@ cmd_get_connection(struct ctl_context *ctx)
 SBREC_CONNECTION_FOR_EACH(conn, ctx->idl) {
 char *s;
 
-s = xasprintf("%s %s", conn->read_only ? "read-only" : "read-write",
-   conn->target);
+s = xasprintf("%s role=\"%s\" %s",
+  conn->read_only ? "read-only" : "read-write",
+  conn->role,
+  conn->target);
 svec_add(, s);
 free(s);
 }
@@ -920,6 +923,7 @@ insert_connections(struct ctl_context *ctx, char 
*targets[], size_t n)
 struct sbrec_connection **connections;
 size_t i, conns=0;
 bool read_only = false;
+char *role = "";
 
 /* Insert each connection in a new row in Connection table. */
 connections = xmalloc(n * sizeof *connections);
@@ -930,6 +934,9 @@ insert_connections(struct ctl_context *ctx, char 
*targets[], size_t n)
 } else if (!strcmp(targets[i], "read-write")) {
 read_only = false;
 continue;
+} else if (!strncmp(targets[i], "role=", 5)) {
+role = targets[i] + 5;
+continue;
 } else if (stream_verify_name(targets[i]) &&
pstream_verify_name(targets[i])) {
 VLOG_WARN("target type \"%s\" is possibly erroneous", targets[i]);
@@ -938,6 +945,7 @@ insert_connections(struct ctl_context *ctx, char 
*targets[], size_t n)
 connections[conns] = sbrec_connection_insert(ctx->txn);
 sbrec_connection_set_target(connections[conns], targets[i]);
 sbrec_connection_set_read_only(connections[conns], read_only);
+sbrec_connection_set_role(connections[conns], role);
 conns++;
 }
 
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC 3/5] ovsdb: add support for role-based access controls

[Lance Richardson]

Add suport for ovsdb RBAC (role-based access control). This includes:

   - Support for new "--rbac " command-line option to
 ovsdb-server, to specify the RBAC roles table to be used.

 This table has one row per role, with each row having a
 "name" column (role name) and a "permissions" column (map of
 table name to UUID of row in separate permission table.) The
 permission table has one row per access control configuration,
 with columns:
  "name" - name of table to which this row applies
  "authorization" - set of column names and column:key pairs
to be compared against client ID to
determine authorization status
  "insert_delete" - boolean, true if insertions and
authorized deletions are allowed.
  "update"- Set of columns and column:key pairs for
which authorized updates are allowed.
   - Support for a new "role" column in the remote configuration
 table.
   - Logic for applying the RBAC role and permission tables, in
 combination with session role and client id, to determine
 whether operations modifying database contents should be
 permitted.

Signed-off-by: Lance Richardson 
---
 lib/jsonrpc.c  |  10 ++
 lib/jsonrpc.h  |   2 +
 ovsdb/automake.mk  |   2 +
 ovsdb/execution.c  |  38 ++-
 ovsdb/jsonrpc-server.c |   6 +-
 ovsdb/jsonrpc-server.h |   1 +
 ovsdb/mutation.c   |  11 +-
 ovsdb/mutation.h   |   6 +-
 ovsdb/ovsdb-server.c   |  70 -
 ovsdb/ovsdb-tool.c |   2 +-
 ovsdb/ovsdb-util.c |  40 +++
 ovsdb/ovsdb-util.h |   3 +
 ovsdb/ovsdb.h  |   1 +
 ovsdb/rbac.c   | 279 +
 ovsdb/rbac.h   |  26 +
 ovsdb/trigger.c|   8 +-
 ovsdb/trigger.h|   5 +-
 tests/test-ovsdb.c |   7 +-
 18 files changed, 503 insertions(+), 14 deletions(-)
 create mode 100644 ovsdb/rbac.c
 create mode 100644 ovsdb/rbac.h

diff --git a/lib/jsonrpc.c b/lib/jsonrpc.c
index a0ade9c..2fae057 100644
--- a/lib/jsonrpc.c
+++ b/lib/jsonrpc.c
@@ -1005,6 +1005,16 @@ jsonrpc_session_get_name(const struct jsonrpc_session *s)
 return reconnect_get_name(s->reconnect);
 }
 
+const char *
+jsonrpc_session_get_id(const struct jsonrpc_session *s)
+{
+if (s->rpc && s->rpc->stream) {
+return stream_get_peer_id(s->rpc->stream);
+} else {
+return NULL;
+}
+}
+
 /* Always takes ownership of 'msg', regardless of success. */
 int
 jsonrpc_session_send(struct jsonrpc_session *s, struct jsonrpc_msg *msg)
diff --git a/lib/jsonrpc.h b/lib/jsonrpc.h
index 982017a..6a82954 100644
--- a/lib/jsonrpc.h
+++ b/lib/jsonrpc.h
@@ -130,5 +130,7 @@ void jsonrpc_session_set_probe_interval(struct 
jsonrpc_session *,
 int probe_interval);
 void jsonrpc_session_set_dscp(struct jsonrpc_session *,
   uint8_t dscp);
+const char *jsonrpc_session_get_id(const struct jsonrpc_session *);
+
 
 #endif /* jsonrpc.h */
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index c218bf5..ac0f741 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -24,6 +24,8 @@ ovsdb_libovsdb_la_SOURCES = \
ovsdb/monitor.h \
ovsdb/query.c \
ovsdb/query.h \
+   ovsdb/rbac.c \
+   ovsdb/rbac.h \
ovsdb/replication.c \
ovsdb/replication.h \
ovsdb/row.c \
diff --git a/ovsdb/execution.c b/ovsdb/execution.c
index e2d320e..2c9ca3d 100644
--- a/ovsdb/execution.c
+++ b/ovsdb/execution.c
@@ -32,6 +32,7 @@
 #include "table.h"
 #include "timeval.h"
 #include "transaction.h"
+#include "rbac.h"
 
 struct ovsdb_execution {
 struct ovsdb *db;
@@ -39,6 +40,8 @@ struct ovsdb_execution {
 struct ovsdb_txn *txn;
 struct ovsdb_symbol_table *symtab;
 bool durable;
+const char *role;
+const char *id;
 
 /* Triggers. */
 long long int elapsed_msec;
@@ -97,6 +100,7 @@ lookup_executor(const char *name, bool *read_only)
 struct json *
 ovsdb_execute(struct ovsdb *db, const struct ovsdb_session *session,
   const struct json *params, bool read_only,
+  const char *role, const char *id,
   long long int elapsed_msec, long long int *timeout_msec)
 {
 struct ovsdb_execution x;
@@ -126,6 +130,8 @@ ovsdb_execute(struct ovsdb *db, const struct ovsdb_session 
*session,
 x.txn = ovsdb_txn_create(db);
 x.symtab = ovsdb_symbol_table_create();
 x.durable = false;
+x.role = role;
+x.id = id;
 x.elapsed_msec = elapsed_msec;
 x.timeout_msec = LLONG_MAX;
 results = NULL;
@@ -305,6 +311,13 @@ ovsdb_execute_insert(struct ovsdb_execution *x, struct 
ovsdb_parser *parser,
 return error;
 }
 
+if (!ovsdb_rbac_insert(table, x->role, x->id)) {
+return ovsdb_syntax_error(parser->json,
+

[ovs-dev] [RFC 4/5] ovn: add rbac tables to ovn southbound schema

[Lance Richardson]

Add rbac "roles" and "permissions" tables to ovn southbound
database schema.

Signed-off-by: Lance Richardson 
---
 ovn/northd/ovn-northd.c | 190 
 ovn/ovn-sb.ovsschema|  26 ++-
 ovn/ovn-sb.xml  |  39 ++
 3 files changed, 253 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 8c8f16b..412c04d 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -5442,6 +5442,182 @@ check_and_add_supported_dhcpv6_opts_to_sb_db(struct 
northd_context *ctx)
 hmap_destroy(_opts_to_add);
 }
 
+static const char *rbac_chassis_auth[] =
+{"chassis"};
+static const char *rbac_chassis_update[] =
+{"nb_cfg", "external_ids", "encaps", "vtep_logical_switches"};
+
+static const char *rbac_encap_auth[] =
+{"chassis"};
+static const char *rbac_encap_update[] =
+{"type", "options", "ip"};
+
+static const char *rbac_port_binding_auth[] =
+{""};
+static const char *rbac_port_binding_update[] =
+{"chassis"};
+
+static const char *rbac_mac_binding_auth[] =
+{""};
+static const char *rbac_mac_binding_update[] =
+{"logical_port", "ip", "mac", "datapath"};
+
+static struct rbac_perm_cfg {
+const char *table;
+const char **auth;
+int n_auth;
+bool insdel;
+const char **update;
+int n_update;
+const struct sbrec_rbac_permission *row;
+} rbac_perm_cfg[] = {
+{
+"Chassis",
+rbac_chassis_auth,
+ARRAY_SIZE(rbac_chassis_auth),
+true,
+rbac_chassis_update,
+ARRAY_SIZE(rbac_chassis_update),
+NULL
+},{
+"Encap",
+rbac_encap_auth,
+ARRAY_SIZE(rbac_encap_auth),
+true,
+rbac_encap_update,
+ARRAY_SIZE(rbac_encap_update),
+NULL
+},{
+"Port_Binding",
+rbac_port_binding_auth,
+ARRAY_SIZE(rbac_port_binding_auth),
+false,
+rbac_port_binding_update,
+ARRAY_SIZE(rbac_port_binding_update),
+NULL
+},{
+"MAC_Binding",
+rbac_mac_binding_auth,
+ARRAY_SIZE(rbac_mac_binding_auth),
+true,
+rbac_mac_binding_update,
+ARRAY_SIZE(rbac_mac_binding_update),
+NULL
+},
+{NULL}
+};
+
+static bool
+ovn_rbac_validate_perm(const struct sbrec_rbac_permission *perm)
+{
+struct rbac_perm_cfg *pcfg;
+int i, j, n_found;
+
+for (pcfg = rbac_perm_cfg; pcfg->table; pcfg++) {
+if (!strcmp(perm->table, pcfg->table)) {
+break;
+}
+}
+if (!pcfg->table) {
+return false;
+}
+if (perm->n_authorization != pcfg->n_auth ||
+perm->n_update != pcfg->n_update) {
+return false;
+}
+if (perm->insert_delete != pcfg->insdel) {
+return false;
+}
+/* verify perm->authorization vs. pcfg->auth */
+n_found = 0;
+for (i = 0; i < pcfg->n_auth; i++) {
+for (j = 0; j < perm->n_authorization; j++) {
+if (!strcmp(pcfg->auth[i], perm->authorization[j])) {
+n_found++;
+break;
+}
+}
+}
+if (n_found != pcfg->n_auth) {
+return false;
+}
+
+/* verify perm->update vs. pcfg->update */
+n_found = 0;
+for (i = 0; i < pcfg->n_update; i++) {
+for (j = 0; j < perm->n_update; j++) {
+if (!strcmp(pcfg->update[i], perm->update[j])) {
+n_found++;
+break;
+}
+}
+}
+if (n_found != pcfg->n_update) {
+return false;
+}
+
+/* Success, db state matches expected state */
+pcfg->row = perm;
+return true;
+}
+
+static void
+ovn_rbac_create_perm(struct rbac_perm_cfg *pcfg,
+ struct northd_context *ctx,
+ const struct sbrec_rbac_role *rbac_role)
+{
+struct sbrec_rbac_permission *rbac_perm;
+
+rbac_perm = sbrec_rbac_permission_insert(ctx->ovnsb_txn);
+sbrec_rbac_permission_set_table(rbac_perm, pcfg->table);
+sbrec_rbac_permission_set_authorization(rbac_perm,
+pcfg->auth,
+pcfg->n_auth);
+sbrec_rbac_permission_set_insert_delete(rbac_perm, pcfg->insdel);
+sbrec_rbac_permission_set_update(rbac_perm,
+ pcfg->update,
+ pcfg->n_update);
+sbrec_rbac_role_update_permissions_setkey(rbac_role, pcfg->table,
+  rbac_perm);
+}
+
+static void
+check_and_update_rbac(struct northd_context *ctx)
+{
+const struct sbrec_rbac_role *rbac_role = NULL;
+const struct sbrec_rbac_permission *perm_row, *perm_next;
+const struct sbrec_rbac_role *role_row, *role_row_next;
+struct rbac_perm_cfg *pcfg;
+
+for (pcfg = rbac_perm_cfg; pcfg->table; pcfg++) {
+pcfg->row = NULL;
+}
+
+

[ovs-dev] [RFC 2/5] ovsdb: refactor utility functions into separate file

[Lance Richardson]

Move local db access functions to a new file and make give them
global scope so they can be included in the ovsdb library and used
by other ovsdb library functions.

Signed-off-by: Lance Richardson 
---
 ovsdb/automake.mk|   4 +-
 ovsdb/ovsdb-server.c | 169 +
 ovsdb/ovsdb-util.c   | 190 +++
 ovsdb/ovsdb-util.h   |  41 +++
 4 files changed, 235 insertions(+), 169 deletions(-)
 create mode 100644 ovsdb/ovsdb-util.c
 create mode 100644 ovsdb/ovsdb-util.h

diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index 33d04f8..c218bf5 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -35,7 +35,9 @@ ovsdb_libovsdb_la_SOURCES = \
ovsdb/trigger.c \
ovsdb/trigger.h \
ovsdb/transaction.c \
-   ovsdb/transaction.h
+   ovsdb/transaction.h \
+   ovsdb/ovsdb-util.c \
+   ovsdb/ovsdb-util.h
 ovsdb_libovsdb_la_CFLAGS = $(AM_CFLAGS)
 ovsdb_libovsdb_la_CPPFLAGS = $(AM_CPPFLAGS)
 
diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index 52af4d3..f1e8fbf 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -56,6 +56,7 @@
 #include "util.h"
 #include "unixctl.h"
 #include "perf-counter.h"
+#include "ovsdb-util.h"
 #include "openvswitch/vlog.h"
 
 VLOG_DEFINE_THIS_MODULE(ovsdb_server);
@@ -688,174 +689,6 @@ add_remote(struct shash *remotes, const char *target)
 return options;
 }
 
-static struct ovsdb_datum *
-get_datum(struct ovsdb_row *row, const char *column_name,
-  const enum ovsdb_atomic_type key_type,
-  const enum ovsdb_atomic_type value_type,
-  const size_t n_max)
-{
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
-const struct ovsdb_table_schema *schema = row->table->schema;
-const struct ovsdb_column *column;
-
-column = ovsdb_table_schema_get_column(schema, column_name);
-if (!column) {
-VLOG_DBG_RL(, "Table `%s' has no `%s' column",
-schema->name, column_name);
-return NULL;
-}
-
-if (column->type.key.type != key_type
-|| column->type.value.type != value_type
-|| column->type.n_max != n_max) {
-if (!VLOG_DROP_DBG()) {
-char *type_name = ovsdb_type_to_english(>type);
-VLOG_DBG("Table `%s' column `%s' has type %s, not expected "
- "key type %s, value type %s, max elements %"PRIuSIZE".",
- schema->name, column_name, type_name,
- ovsdb_atomic_type_to_string(key_type),
- ovsdb_atomic_type_to_string(value_type),
- n_max);
-free(type_name);
-}
-return NULL;
-}
-
-return >fields[column->index];
-}
-
-/* Read string-string key-values from a map.  Returns the value associated with
- * 'key', if found, or NULL */
-static const char *
-read_map_string_column(const struct ovsdb_row *row, const char *column_name,
-   const char *key)
-{
-const struct ovsdb_datum *datum;
-union ovsdb_atom *atom_key = NULL, *atom_value = NULL;
-size_t i;
-
-datum = get_datum(CONST_CAST(struct ovsdb_row *, row), column_name,
-  OVSDB_TYPE_STRING, OVSDB_TYPE_STRING, UINT_MAX);
-
-if (!datum) {
-return NULL;
-}
-
-for (i = 0; i < datum->n; i++) {
-atom_key = >keys[i];
-if (!strcmp(atom_key->string, key)){
-atom_value = >values[i];
-break;
-}
-}
-
-return atom_value ? atom_value->string : NULL;
-}
-
-static const union ovsdb_atom *
-read_column(const struct ovsdb_row *row, const char *column_name,
-enum ovsdb_atomic_type type)
-{
-const struct ovsdb_datum *datum;
-
-datum = get_datum(CONST_CAST(struct ovsdb_row *, row), column_name, type,
-  OVSDB_TYPE_VOID, 1);
-return datum && datum->n ? datum->keys : NULL;
-}
-
-static bool
-read_integer_column(const struct ovsdb_row *row, const char *column_name,
-long long int *integerp)
-{
-const union ovsdb_atom *atom;
-
-atom = read_column(row, column_name, OVSDB_TYPE_INTEGER);
-*integerp = atom ? atom->integer : 0;
-return atom != NULL;
-}
-
-static bool
-read_string_column(const struct ovsdb_row *row, const char *column_name,
-   const char **stringp)
-{
-const union ovsdb_atom *atom;
-
-atom = read_column(row, column_name, OVSDB_TYPE_STRING);
-*stringp = atom ? atom->string : NULL;
-return atom != NULL;
-}
-
-static bool
-read_bool_column(const struct ovsdb_row *row, const char *column_name,
-   bool *boolp)
-{
-const union ovsdb_atom *atom;
-
-atom = read_column(row, column_name, OVSDB_TYPE_BOOLEAN);
-*boolp = atom ? atom->boolean : false;
-return atom != NULL;
-}
-
-static void
-write_bool_column(struct ovsdb_row *row, const char *column_name, bool value)
-{
-

[ovs-dev] [RFC 1/5] stream: store stream peer id with stream state

[Lance Richardson]

Keep track of authenticated ID for stream peer. For SSL connections,
the authenticated ID is the CN (Common Name) field from the peer's
SSL certificate.

Signed-off-by: Lance Richardson 
---
 lib/stream-provider.h |  1 +
 lib/stream-ssl.c  | 44 
 lib/stream.c  | 14 ++
 lib/stream.h  |  3 +++
 4 files changed, 62 insertions(+)

diff --git a/lib/stream-provider.h b/lib/stream-provider.h
index 2226a80..ce88785 100644
--- a/lib/stream-provider.h
+++ b/lib/stream-provider.h
@@ -30,6 +30,7 @@ struct stream {
 int state;
 int error;
 char *name;
+char *peer_id;
 };
 
 void stream_init(struct stream *, const struct stream_class *,
diff --git a/lib/stream-ssl.c b/lib/stream-ssl.c
index 5d88b52..0f60e03 100644
--- a/lib/stream-ssl.c
+++ b/lib/stream-ssl.c
@@ -420,6 +420,39 @@ do_ca_cert_bootstrap(struct stream *stream)
 return EPROTO;
 }
 
+static char *
+get_peer_common_name(const struct ssl_stream *sslv)
+{
+X509_NAME_ENTRY *cn_entry;
+ASN1_STRING *cn_data;
+X509 *peer_cert;
+int cn_index;
+const char *cn;
+
+peer_cert = SSL_get_peer_certificate(sslv->ssl);
+if (!peer_cert) {
+return NULL;
+}
+cn_index = X509_NAME_get_index_by_NID(X509_get_subject_name(peer_cert),
+  NID_commonName, -1);
+if (cn_index < 0) {
+return NULL;
+}
+
+cn_entry = X509_NAME_get_entry(X509_get_subject_name(peer_cert), cn_index);
+if (!cn_entry) {
+return NULL;
+}
+
+cn_data = X509_NAME_ENTRY_get_data(cn_entry);
+if (!cn_data) {
+return NULL;
+}
+
+cn = (const char *)ASN1_STRING_data(cn_data);
+return xstrdup(cn);
+}
+
 static int
 ssl_connect(struct stream *stream)
 {
@@ -477,6 +510,17 @@ ssl_connect(struct stream *stream)
 VLOG_INFO("rejecting SSL connection during bootstrap race window");
 return EPROTO;
 } else {
+char *cn = get_peer_common_name(sslv);
+
+if (cn) {
+char *ptr = strstr(cn, " id:");
+
+if (ptr) {
+*ptr = '\0';
+}
+stream_set_peer_id(stream, cn);
+free(cn);
+}
 return 0;
 }
 }
diff --git a/lib/stream.c b/lib/stream.c
index f6ea849..cb4320c 100644
--- a/lib/stream.c
+++ b/lib/stream.c
@@ -278,8 +278,10 @@ stream_close(struct stream *stream)
 {
 if (stream != NULL) {
 char *name = stream->name;
+char *peer_id = stream->peer_id;
 (stream->class->close)(stream);
 free(name);
+free(peer_id);
 }
 }
 
@@ -430,6 +432,18 @@ stream_send_wait(struct stream *stream)
 stream_wait(stream, STREAM_SEND);
 }
 
+void stream_set_peer_id(struct stream *stream, const char *peer_id)
+{
+free(stream->peer_id);
+stream->peer_id = xstrdup(peer_id);
+}
+
+const char *stream_get_peer_id(const struct stream *stream)
+{
+return stream->peer_id;
+}
+
+
 /* Given 'name', a pstream name in the form "TYPE:ARGS", stores the class
  * named "TYPE" into '*classp' and returns 0.  Returns EAFNOSUPPORT and stores
  * a null pointer into '*classp' if 'name' is in the wrong form or if no such
diff --git a/lib/stream.h b/lib/stream.h
index f8e1891..f9bfdc8 100644
--- a/lib/stream.h
+++ b/lib/stream.h
@@ -53,6 +53,9 @@ void stream_wait(struct stream *, enum stream_wait_type);
 void stream_connect_wait(struct stream *);
 void stream_recv_wait(struct stream *);
 void stream_send_wait(struct stream *);
+void stream_set_peer_id(struct stream *, const char *);
+const char *stream_get_peer_id(const struct stream *);
+
 
 /* Passive streams: listeners for incoming stream connections. */
 int pstream_verify_name(const char *name);
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC 0/5] role-based access controls for ovsdb-server, ovn-sb

[Lance Richardson]

This series implements role-based access control infrastructure for
ovsdb-server, and uses that infrastructure to apply role-based access
controls to the OVN_Southbound database. This implementation follows
the outline discussed at:

 https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329801.html

With this series applied, enabling role-based ACLs is a matter of:

- Configuring southbound ovsdb-server and ovn-controller to use SSL,
  configuring an ovn-controller "role" for SSL connections via e.g.:
 ovn-sbctl set-connection role=ovn-controller pssl:6642
- Using unique certificates for each ovn-controller with a unique
  CN for each chassis, generated e.g. via:
 ovs-pki -B 1024 req+sign chassis1 switch
 ovs-pki -B 1024 req+sign chassis2 switch
 ovs-pki -B 1024 req+sign chassis3 switch
- Starting the southbound ovsdb-server with the "--rbac" command-line
  option:
 --rbac=db:OVN_Southbound,RBAC_Role

This series is posted as RFC mainly to solicit high-level feedback about
the approach, although feedback about implementation details would also
be welcome. Known deficiencies:

- No unit tests.
- Sketchy documentation.

Regards,

Lance


Lance Richardson (5):
  stream: store stream peer id with stream state
  ovsdb: refactor utility functions into separate file
  ovsdb: add support for role-based access controls
  ovn: add rbac tables to ovn southbound schema
  ovn-sbctl: support setting rbac role for remote connections

 lib/jsonrpc.c |  10 ++
 lib/jsonrpc.h |   2 +
 lib/stream-provider.h |   1 +
 lib/stream-ssl.c  |  44 
 lib/stream.c  |  14 +++
 lib/stream.h  |   3 +
 ovn/northd/ovn-northd.c   | 190 +++
 ovn/ovn-sb.ovsschema  |  26 -
 ovn/ovn-sb.xml|  39 +++
 ovn/utilities/ovn-sbctl.c |  12 +-
 ovsdb/automake.mk |   6 +-
 ovsdb/execution.c |  38 ++-
 ovsdb/jsonrpc-server.c|   6 +-
 ovsdb/jsonrpc-server.h|   1 +
 ovsdb/mutation.c  |  11 +-
 ovsdb/mutation.h  |   6 +-
 ovsdb/ovsdb-server.c  | 229 +++--
 ovsdb/ovsdb-tool.c|   2 +-
 ovsdb/ovsdb-util.c| 230 ++
 ovsdb/ovsdb-util.h|  44 
 ovsdb/ovsdb.h |   1 +
 ovsdb/rbac.c  | 279 ++
 ovsdb/rbac.h  |  26 +
 ovsdb/trigger.c   |   8 +-
 ovsdb/trigger.h   |   5 +-
 tests/test-ovsdb.c|   7 +-
 26 files changed, 1058 insertions(+), 182 deletions(-)
 create mode 100644 ovsdb/ovsdb-util.c
 create mode 100644 ovsdb/ovsdb-util.h
 create mode 100644 ovsdb/rbac.c
 create mode 100644 ovsdb/rbac.h

-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] stp: Fix stp tests and make them more stable.

[Joe Stringer]

On 27 March 2017 at 09:43, Alin Serdean  wrote:
>> -Original Message-
>> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
>> boun...@openvswitch.org] On Behalf Of nickcooper-zhangtonghao
>> Sent: Thursday, March 23, 2017 8:36 AM
>> To: d...@openvswitch.org
>> Subject: [ovs-dev] [PATCH v2] stp: Fix stp tests and make them more stable.
>>
>> The difference between machines may cause the test to fail.
>> More importantly, when topology is changed or the root brdige receives the
>> TCN BPDU, the root bridge will start the topology change timer. We should
>> wait the topology change timer to stop after 35s (max age 20 + forward delay
>> 15). After 35s, the root bridge will stop send CONF BPDU with
>> STP_CONFIG_TOPOLOGY_CHANGE flag and the topology will be stable.
>> During this time, we should make time warp (in a second) because the hold
>> timer of stp ports will stop after 1s. Then the root bridge can send quickly
>> topology change ack (other bridges may send TCN BPDU to root bridge) for
>> avoiding root brdige to flush fdb and mdb frequently.

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Numan Siddique]

On Mon, Mar 27, 2017 at 9:45 PM, Guru Shetty  wrote:

>
>
> On 27 March 2017 at 07:13,  wrote:
>
>> From: Numan Siddique 
>>
>> OVN implements native DNS resolution which can be used to resolve the
>> internal DNS names belonging to a logical datapath.
>>
>> To support this, a new table 'DNS' is added in the NB DB. A new column
>> 'dns_lookups' is added in 'Logical_Switch' table which references to the
>> 'DNS' table.
>>
>> Following flows are added for each logical switch which has atleast one
>> DNS entry in the 'dns_lookups' column
>>  - A logical flow in DNS_LOOKUP stage which uses the action 'dns_lookup'
>>to transform the DNS query to DNS reply packet and advances
>>to the next stage - DNS_RESPONSE.
>>
>>  - A logical flow in DNS_RESPONSE stage which implements the DNS responder
>>by sending the DNS reply from previous stage back to the inport.
>>
>> Signed-off-by: Numan Siddique 
>> ---
>>  ovn/northd/ovn-northd.8.xml |  88 ++-
>>  ovn/northd/ovn-northd.c | 150 ++-
>>  ovn/ovn-nb.ovsschema|  16 +-
>>  ovn/ovn-nb.xml  |  20 ++-
>>  ovn/utilities/ovn-nbctl.c   |   3 +
>>  tests/ovn.at| 353 ++
>> ++
>>  6 files changed, 618 insertions(+), 12 deletions(-)
>>
>> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
>> index ab8fd88..a3fe2a8 100644
>> --- a/ovn/northd/ovn-northd.8.xml
>> +++ b/ovn/northd/ovn-northd.8.xml
>> @@ -724,7 +724,73 @@ output;
>>
>>  
>>
>> -Ingress Table 13 Destination Lookup
>> +Ingress Table 13 DNS Lookup
>> +
>> +
>> +  This table looks up and resolves the DNS names of the logical ports
>> +  if configured with the host names.
>> +
>> +
>> +
>> +  
>> +
>> +  A priority-100 logical flow for each logical switch data path
>> +  if at least one of its logical port is configured with
>> +  hostname  which matches the IPv4 and IPv6 packets
>> with
>> +  udp.src = 53 and applies the action
>> +  dns_lkup and advances the packet to the next
>> table.
>> +
>> +
>> +
>> +reg0[4] = dns_lkup(); next;
>> +
>> +
>> +
>> +  For valid DNS packets, this transforms the packet into a DNS
>> +  reply if the DNS name can be resolved, and stores 1 into
>> reg0[4].
>> +  For failed DNS resolution or other kinds of packets, it just
>> stores
>> +  0 into reg0[4]. Either way, it continues to the next table.
>> +
>> +  
>> +
>> +
>> +Ingress Table 14 DNS Responses
>> +
>> +
>> +  This table implements DNS responder for the DNS replies generated
>> by
>> +  the previous table.
>> +
>> +
>> +
>> +  
>> +
>> +  A priority-100 logical flow for each logical switch data path
>> +  if at least one of its logical port is configured with
>> +  hostname which matches IPv4 and IPv6 packets with
>> +  udp.src == 53  reg0[4] == 1 and responds
>> +  back to the inport after applying these
>> +  actions.  If reg0[4] is set to 1, it means that
>> the
>> +  action dns_lkup was successful.
>> +
>> +
>> +
>> +eth.dst  eth.src;
>> +ip4.src  ip4.dst;
>> +udp.dst = udp.src;
>> +udp.src = 53;
>> +outport = P;
>> +flags.loopback = 1;
>> +output;
>> +
>> +
>> +
>> +  (This terminates ingress packet processing; the packet does
>> not go
>> +   to the next ingress table.)
>> +
>> +  
>> +
>> +
>> +Ingress Table 15 Destination Lookup
>>
>>  
>>This table implements switching behavior.  It contains these
>> logical
>> @@ -834,11 +900,23 @@ output;
>>  
>>
>>  
>> -  Also a priority 34000 logical flow is added for each logical port
>> which
>> -  has DHCPv4 options defined to allow the DHCPv4 reply packet and
>> which has
>> -  DHCPv6 options defined to allow the DHCPv6 reply packet from the
>> -  Ingress Table 12: DHCP responses.
>> +  Also the following flows are added.
>>  
>> +
>> +  
>> +A Priority 34000 logical flow is added for each logical port
>> which
>> +has DHCPv4 options defined to allow the DHCPv4 reply packet and
>> which has
>> +DHCPv6 options defined to allow the DHCPv6 reply packet from the
>> +Ingress Table 12: DHCP responses.
>> +  
>> +
>> +  
>> +A Priority 34000 logical flow for each logical switch data path
>> if at
>> +least one of its logical port is configured with hostname
>> +which allows the DNS reply packet from the
>> +Ingress Table 14:DNS responses.
>> +  
>> +
>>
>>  Egress Table 7: Egress Port Security - IP
>>
>> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
>> index 8c8f16b..d125651 100644
>> --- 

Re: [ovs-dev] How does ovs userpsace+dpdk handle the original data packet when it needs ARP request and waits for ARP reply?

[Darrell Ball]

On 3/22/17, 3:42 AM, "ovs-dev-boun...@openvswitch.org on behalf of Joo Kim" 
 wrote:

Hello,

In OVS2.6 userspace datapath code,  when there is no ARP cache, looks like
it sends ARP request on the fly (via tnl_send_arp_request() ).
Then, until ARP reply is received later,   what happens to the original
data packet?  Is it queued and sent later  once ARP resolution is made ?
Or just dropped?

The original packet is dropped.


BTW, I see  following stack trace for the original packet, where
build_tunnel_send() can send ARP request...

#0  build_tunnel_send (xport=0xdbab10, tunnel_odp_port=3,
flow=0x7fffb778, ctx=0x7fff9ac0)
 at ofproto/ofproto-dpif-xlate.c:2946

 #1  compose_output_action__ (ctx=ctx@entry=0x7fffa160, ofp_port=2,
xr=xr@entry=0x0,
 check_stp=check_stp@entry=true) at
ofproto/ofproto-dpif-xlate.c:3243
 #2  0x005d7bb2 in compose_output_action (xr=0x0,
ofp_port=,
 ctx=0x7fffa160) at ofproto/ofproto-dpif-xlate.c:3308
 #3  output_normal (ctx=ctx@entry=0x7fffa160,
out_xbundle=out_xbundle@entry=0xd96200,
 vlan=vlan@entry=0) at ofproto/ofproto-dpif-xlate.c:1958
 #4  0x005d81f6 in xlate_normal_flood (ctx=ctx@entry
=0x7fffa160,
 in_xbundle=in_xbundle@entry=0xd9b3e0, vlan=vlan@entry=0) at
ofproto/ofproto-dpif-xlate.c:2401
 #5  0x005d89ad in xlate_normal (ctx=0x7fffa160) at
ofproto/ofproto-dpif-xlate.c:2604
 #6  xlate_output_action (ctx=ctx@entry=0x7fffa160, port=,
 max_len=, may_packet_in=may_packet_in@entry=true)
 at ofproto/ofproto-dpif-xlate.c:3981
 #7  0x005d51ee in do_xlate_actions (ofpacts=ofpacts@entry
=0xd99ae8,
 ofpacts_len=ofpacts_len@entry=16, ctx=ctx@entry=0x7fffa160)
 at ofproto/ofproto-dpif-xlate.c:4781
 #8  0x005da384 in xlate_actions (xin=xin@entry=0x7fffb770,
 xout=xout@entry=0x7fffbb00) at
ofproto/ofproto-dpif-xlate.c:5618
 #9  0x005cec3c in upcall_xlate (wc=0x7fffce58,
odp_actions=0x7fffc680,
 upcall=0x7fffbaa0, udpif=0xd479b0) at
ofproto/ofproto-dpif-upcall.c:1102
 #10 process_upcall (udpif=udpif@entry=0xd479b0, upcall=upcall@entry
=0x7fffbaa0,
 odp_actions=odp_actions@entry=0x7fffc680, wc=wc@entry
=0x7fffce58)
 at ofproto/ofproto-dpif-upcall.c:1239
 #11 0x005cf3ad in upcall_cb (packet=,
flow=0x7fffcc10,
 ufid=, pmd_id=, type=,
userdata=,
 actions=0x7fffc680, wc=0x7fffce58, put_actions=0x7fffc6c0,
aux=0xd479b0)
 at ofproto/ofproto-dpif-upcall.c:1198
 #12 0x005f42f2 in dp_netdev_upcall (packet_=packet_@entry
=0xdb8660,
 flow=flow@entry=0x7fffcc10, wc=wc@entry=0x7fffce58,
ufid=ufid@entry=0x7fffc650,
 type=type@entry=DPIF_UC_MISS, userdata=userdata@entry=0x0,
___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=dAp7C8khtZWfPGsspcroEJHGwaZFPmRopj68jLq0-Q4=u9BsulnRRZYP-diPy7cKhrzCLMBtlTtfk4QS-qj3cO4=
 


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/3 v2] datapath-windows: Add support for NAT in conntrack

[Alin Serdean]

Thanks a lot for the patches!

This is not the full review yet. I will try to give it a go today.

At first glance it needs a rebase to be applied on master.

Thanks,
Alin.

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Yin Lin
> Sent: Thursday, March 23, 2017 12:12 AM
> To: d...@openvswitch.org
> Subject: [ovs-dev] [PATCH 1/3 v2] datapath-windows: Add support for NAT
> in conntrack
> 
> Add support for parsing netlink attributes related to NAT in conntrack.
> 
> Co-Authored-by: Anand Kumar 
> Co-Authored-by: Darrell Ball 
> Signed-off-by: Yin Lin 
> ---
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] stp: Fix stp tests and make them more stable.

[Alin Serdean]

This patch will fix the failing test on the windows unit test CI.

Acked-by: Alin Gabriel Serdean 


> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of nickcooper-zhangtonghao
> Sent: Thursday, March 23, 2017 8:36 AM
> To: d...@openvswitch.org
> Subject: [ovs-dev] [PATCH v2] stp: Fix stp tests and make them more stable.
> 
> The difference between machines may cause the test to fail.
> More importantly, when topology is changed or the root brdige receives the
> TCN BPDU, the root bridge will start the topology change timer. We should
> wait the topology change timer to stop after 35s (max age 20 + forward delay
> 15). After 35s, the root bridge will stop send CONF BPDU with
> STP_CONFIG_TOPOLOGY_CHANGE flag and the topology will be stable.
> During this time, we should make time warp (in a second) because the hold
> timer of stp ports will stop after 1s. Then the root bridge can send quickly
> topology change ack (other bridges may send TCN BPDU to root bridge) for
> avoiding root brdige to flush fdb and mdb frequently.
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Guru Shetty]

On 27 March 2017 at 07:13,  wrote:

> From: Numan Siddique 
>
> OVN implements native DNS resolution which can be used to resolve the
> internal DNS names belonging to a logical datapath.
>
> To support this, a new table 'DNS' is added in the NB DB. A new column
> 'dns_lookups' is added in 'Logical_Switch' table which references to the
> 'DNS' table.
>
> Following flows are added for each logical switch which has atleast one
> DNS entry in the 'dns_lookups' column
>  - A logical flow in DNS_LOOKUP stage which uses the action 'dns_lookup'
>to transform the DNS query to DNS reply packet and advances
>to the next stage - DNS_RESPONSE.
>
>  - A logical flow in DNS_RESPONSE stage which implements the DNS responder
>by sending the DNS reply from previous stage back to the inport.
>
> Signed-off-by: Numan Siddique 
> ---
>  ovn/northd/ovn-northd.8.xml |  88 ++-
>  ovn/northd/ovn-northd.c | 150 ++-
>  ovn/ovn-nb.ovsschema|  16 +-
>  ovn/ovn-nb.xml  |  20 ++-
>  ovn/utilities/ovn-nbctl.c   |   3 +
>  tests/ovn.at| 353 ++
> ++
>  6 files changed, 618 insertions(+), 12 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index ab8fd88..a3fe2a8 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -724,7 +724,73 @@ output;
>
>  
>
> -Ingress Table 13 Destination Lookup
> +Ingress Table 13 DNS Lookup
> +
> +
> +  This table looks up and resolves the DNS names of the logical ports
> +  if configured with the host names.
> +
> +
> +
> +  
> +
> +  A priority-100 logical flow for each logical switch data path
> +  if at least one of its logical port is configured with
> +  hostname  which matches the IPv4 and IPv6 packets
> with
> +  udp.src = 53 and applies the action
> +  dns_lkup and advances the packet to the next table.
> +
> +
> +
> +reg0[4] = dns_lkup(); next;
> +
> +
> +
> +  For valid DNS packets, this transforms the packet into a DNS
> +  reply if the DNS name can be resolved, and stores 1 into
> reg0[4].
> +  For failed DNS resolution or other kinds of packets, it just
> stores
> +  0 into reg0[4]. Either way, it continues to the next table.
> +
> +  
> +
> +
> +Ingress Table 14 DNS Responses
> +
> +
> +  This table implements DNS responder for the DNS replies generated by
> +  the previous table.
> +
> +
> +
> +  
> +
> +  A priority-100 logical flow for each logical switch data path
> +  if at least one of its logical port is configured with
> +  hostname which matches IPv4 and IPv6 packets with
> +  udp.src == 53  reg0[4] == 1 and responds
> +  back to the inport after applying these
> +  actions.  If reg0[4] is set to 1, it means that the
> +  action dns_lkup was successful.
> +
> +
> +
> +eth.dst  eth.src;
> +ip4.src  ip4.dst;
> +udp.dst = udp.src;
> +udp.src = 53;
> +outport = P;
> +flags.loopback = 1;
> +output;
> +
> +
> +
> +  (This terminates ingress packet processing; the packet does not
> go
> +   to the next ingress table.)
> +
> +  
> +
> +
> +Ingress Table 15 Destination Lookup
>
>  
>This table implements switching behavior.  It contains these logical
> @@ -834,11 +900,23 @@ output;
>  
>
>  
> -  Also a priority 34000 logical flow is added for each logical port
> which
> -  has DHCPv4 options defined to allow the DHCPv4 reply packet and
> which has
> -  DHCPv6 options defined to allow the DHCPv6 reply packet from the
> -  Ingress Table 12: DHCP responses.
> +  Also the following flows are added.
>  
> +
> +  
> +A Priority 34000 logical flow is added for each logical port which
> +has DHCPv4 options defined to allow the DHCPv4 reply packet and
> which has
> +DHCPv6 options defined to allow the DHCPv6 reply packet from the
> +Ingress Table 12: DHCP responses.
> +  
> +
> +  
> +A Priority 34000 logical flow for each logical switch data path
> if at
> +least one of its logical port is configured with hostname
> +which allows the DNS reply packet from the
> +Ingress Table 14:DNS responses.
> +  
> +
>
>  Egress Table 7: Egress Port Security - IP
>
> diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> index 8c8f16b..d125651 100644
> --- a/ovn/northd/ovn-northd.c
> +++ b/ovn/northd/ovn-northd.c
> @@ -112,7 +112,9 @@ enum ovn_stage {
>  PIPELINE_STAGE(SWITCH, IN,  ARP_ND_RSP,10, "ls_in_arp_rsp")
>  \
>  PIPELINE_STAGE(SWITCH, IN,  DHCP_OPTIONS,  11, "ls_in_dhcp_options")
> \

[ovs-dev] (no subject)

[A]

-- 
Apply loan at 3% interest rate @AEM Finance___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Help to Modify OVS Source Code

[Ben Pfaff]

On Mon, Mar 27, 2017 at 11:17:12AM +0530, Attitude Killer wrote:
> I am a beginner with ovs and C as well, can anyone please help me with what
> I can do with the provided source code and how?

If you're a beginner in C, I don't think that modifying OVS is a good
project to start with.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v3 2/2] ovn-northd: Add logical flows to support native DNS

[nusiddiq]

From: Numan Siddique 

OVN implements native DNS resolution which can be used to resolve the
internal DNS names belonging to a logical datapath.

To support this, a new table 'DNS' is added in the NB DB. A new column
'dns_lookups' is added in 'Logical_Switch' table which references to the
'DNS' table.

Following flows are added for each logical switch which has atleast one
DNS entry in the 'dns_lookups' column
 - A logical flow in DNS_LOOKUP stage which uses the action 'dns_lookup'
   to transform the DNS query to DNS reply packet and advances
   to the next stage - DNS_RESPONSE.

 - A logical flow in DNS_RESPONSE stage which implements the DNS responder
   by sending the DNS reply from previous stage back to the inport.

Signed-off-by: Numan Siddique 
---
 ovn/northd/ovn-northd.8.xml |  88 ++-
 ovn/northd/ovn-northd.c | 150 ++-
 ovn/ovn-nb.ovsschema|  16 +-
 ovn/ovn-nb.xml  |  20 ++-
 ovn/utilities/ovn-nbctl.c   |   3 +
 tests/ovn.at| 353 
 6 files changed, 618 insertions(+), 12 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index ab8fd88..a3fe2a8 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -724,7 +724,73 @@ output;
   
 
 
-Ingress Table 13 Destination Lookup
+Ingress Table 13 DNS Lookup
+
+
+  This table looks up and resolves the DNS names of the logical ports
+  if configured with the host names.
+
+
+
+  
+
+  A priority-100 logical flow for each logical switch data path
+  if at least one of its logical port is configured with
+  hostname  which matches the IPv4 and IPv6 packets with
+  udp.src = 53 and applies the action
+  dns_lkup and advances the packet to the next table.
+
+
+
+reg0[4] = dns_lkup(); next;
+
+
+
+  For valid DNS packets, this transforms the packet into a DNS
+  reply if the DNS name can be resolved, and stores 1 into reg0[4].
+  For failed DNS resolution or other kinds of packets, it just stores
+  0 into reg0[4]. Either way, it continues to the next table.
+
+  
+
+
+Ingress Table 14 DNS Responses
+
+
+  This table implements DNS responder for the DNS replies generated by
+  the previous table.
+
+
+
+  
+
+  A priority-100 logical flow for each logical switch data path
+  if at least one of its logical port is configured with
+  hostname which matches IPv4 and IPv6 packets with
+  udp.src == 53  reg0[4] == 1 and responds
+  back to the inport after applying these
+  actions.  If reg0[4] is set to 1, it means that the
+  action dns_lkup was successful.
+
+
+
+eth.dst  eth.src;
+ip4.src  ip4.dst;
+udp.dst = udp.src;
+udp.src = 53;
+outport = P;
+flags.loopback = 1;
+output;
+
+
+
+  (This terminates ingress packet processing; the packet does not go
+   to the next ingress table.)
+
+  
+
+
+Ingress Table 15 Destination Lookup
 
 
   This table implements switching behavior.  It contains these logical
@@ -834,11 +900,23 @@ output;
 
 
 
-  Also a priority 34000 logical flow is added for each logical port which
-  has DHCPv4 options defined to allow the DHCPv4 reply packet and which has
-  DHCPv6 options defined to allow the DHCPv6 reply packet from the
-  Ingress Table 12: DHCP responses.
+  Also the following flows are added.
 
+
+  
+A Priority 34000 logical flow is added for each logical port which
+has DHCPv4 options defined to allow the DHCPv4 reply packet and which 
has
+DHCPv6 options defined to allow the DHCPv6 reply packet from the
+Ingress Table 12: DHCP responses.
+  
+
+  
+A Priority 34000 logical flow for each logical switch data path if at
+least one of its logical port is configured with hostname
+which allows the DNS reply packet from the
+Ingress Table 14:DNS responses.
+  
+
 
 Egress Table 7: Egress Port Security - IP
 
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 8c8f16b..d125651 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -112,7 +112,9 @@ enum ovn_stage {
 PIPELINE_STAGE(SWITCH, IN,  ARP_ND_RSP,10, "ls_in_arp_rsp")   \
 PIPELINE_STAGE(SWITCH, IN,  DHCP_OPTIONS,  11, "ls_in_dhcp_options")  \
 PIPELINE_STAGE(SWITCH, IN,  DHCP_RESPONSE, 12, "ls_in_dhcp_response") \
-PIPELINE_STAGE(SWITCH, IN,  L2_LKUP,   13, "ls_in_l2_lkup")   \
+PIPELINE_STAGE(SWITCH, IN,  DNS_LOOKUP,  13, "ls_in_dns_lookup") \
+PIPELINE_STAGE(SWITCH, IN,  DNS_RESPONSE,  14, "ls_in_dns_response") \
+PIPELINE_STAGE(SWITCH, IN,  

[ovs-dev] [PATCH v3 1/2] ovn-controller: Add 'dns_lookup' action

[nusiddiq]

From: Numan Siddique 

This patch adds a new OVN action 'dns_lookup' to support native DNS.
ovn-controller parses this action and adds a NXT_PACKET_IN2
OF flow with 'pause' flag set.

A new table 'DNS' is added in the SB DB to look up and resolve
the DNS queries. When a valid DNS packet is received by
ovn-controller, it looks up the DNS name in the 'DNS' table
and if successful, it frames a DNS reply, resumes the packet
and stores 1 in the 1-bit subfield. If the packet is invalid
or cannot be resolved, it resumes the packet without any
modifications and stores 0 in the 1-bit subfield.

reg0[4] = dns_lookup(); next;

An upcoming patch will use this action and adds logical flows.

Signed-off-by: Numan Siddique 
---
 include/ovn/actions.h |  17 +++-
 ovn/controller/pinctrl.c  | 248 +-
 ovn/lib/actions.c |  52 ++
 ovn/lib/ovn-util.h|  19 
 ovn/ovn-sb.ovsschema  |  18 +++-
 ovn/ovn-sb.xml|  68 +
 ovn/utilities/ovn-sbctl.c |   3 +
 ovn/utilities/ovn-trace.c |   5 +
 tests/ovn.at  |   7 ++
 9 files changed, 429 insertions(+), 8 deletions(-)

diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index d2510fd..0e66ee8 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -70,7 +70,8 @@ struct simap;
 OVNACT(PUT_ND,ovnact_put_mac_bind)  \
 OVNACT(PUT_DHCPV4_OPTS, ovnact_put_dhcp_opts)   \
 OVNACT(PUT_DHCPV6_OPTS, ovnact_put_dhcp_opts)   \
-OVNACT(SET_QUEUE,   ovnact_set_queue)
+OVNACT(SET_QUEUE,   ovnact_set_queue)   \
+OVNACT(DNS_LOOKUP,  ovnact_dns_lookup)
 
 /* enum ovnact_type, with a member OVNACT_ for each action. */
 enum OVS_PACKED_ENUM ovnact_type {
@@ -258,6 +259,12 @@ struct ovnact_set_queue {
 uint16_t queue_id;
 };
 
+/* OVNACT_DNS_LOOKUP. */
+struct ovnact_dns_lookup {
+struct ovnact ovnact;
+struct expr_field dst;  /* 1-bit destination field. */
+};
+
 /* Internal use by the helpers below. */
 void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
 void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
@@ -385,6 +392,14 @@ enum action_opcode {
  *   - Any number of DHCPv6 options.
  */
 ACTION_OPCODE_PUT_DHCPV6_OPTS,
+
+/* "result = dns_lookup()".
+ * Arguments follow the action_header, in this format:
+ *   - A 32-bit or 64-bit OXM header designating the result field.
+ *   - A 32-bit integer specifying a bit offset within the result field.
+ *
+ */
+ACTION_OPCODE_DNS_LOOKUP,
 };
 
 /* Header. */
diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index b342189..ec7fbd5 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -661,7 +661,242 @@ exit:
 }
 
 static void
-process_packet_in(const struct ofp_header *msg)
+pinctrl_handle_dns_lookup(
+struct dp_packet *pkt_in, struct ofputil_packet_in *pin,
+struct ofpbuf *userdata, struct ofpbuf *continuation,
+struct controller_ctx *ctx)
+{
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+enum ofp_version version = rconn_get_version(swconn);
+enum ofputil_protocol proto = ofputil_protocol_from_ofp_version(version);
+struct dp_packet *pkt_out_ptr = NULL;
+uint32_t success = 0;
+
+/* Parse result field. */
+const struct mf_field *f;
+enum ofperr ofperr = nx_pull_header(userdata, NULL, , NULL);
+if (ofperr) {
+   VLOG_WARN_RL(, "bad result OXM (%s)", ofperr_to_string(ofperr));
+   goto exit;
+}
+
+/* Parse result offset. */
+ovs_be32 *ofsp = ofpbuf_try_pull(userdata, sizeof *ofsp);
+if (!ofsp) {
+VLOG_WARN_RL(, "offset not present in the userdata");
+goto exit;
+}
+
+/* Check that the result is valid and writable. */
+struct mf_subfield dst = { .field = f, .ofs = ntohl(*ofsp), .n_bits = 1 };
+ofperr = mf_check_dst(, NULL);
+if (ofperr) {
+VLOG_WARN_RL(, "bad result bit (%s)", ofperr_to_string(ofperr));
+goto exit;
+}
+
+/* Extract the DNS header */
+struct dns_header const *in_dns_header = dp_packet_get_udp_payload(pkt_in);
+
+/* Check if it is DNS request or not */
+if (in_dns_header->lo_flag & 0x80) {
+/* It's a DNS response packet which we are not interested in */
+goto exit;
+}
+
+/* Check if at least one query request is present */
+if (!in_dns_header->qdcount) {
+goto exit;
+}
+
+struct udp_header *in_udp = dp_packet_l4(pkt_in);
+size_t udp_len = ntohs(in_udp->udp_len);
+size_t l4_len = dp_packet_l4_size(pkt_in);
+uint8_t *end = (uint8_t *)in_udp + MIN(udp_len, l4_len);
+uint8_t *in_dns_data = (uint8_t *)(in_dns_header + 1);
+uint8_t *in_hostname = in_dns_data;
+uint8_t idx = 0;
+struct ds hostname;
+ds_init();
+/* Extract the hostname. If the hostname is - 'www.ovn.org' it would be
+ * 

[ovs-dev] [PATCH v3 0/2] ovn: Native DNS support

[nusiddiq]

From: Numan Siddique 


v2 -> v3

 PS1 - No changes
 PS2 (ovn-northd: Add logical flows to support native DNS)
   - Added the DNS table in NB DB and a reference to it in
 'Logical_Switch' table as suggested by Guru
   - Added as a weak reference in the Logical_Switch table, so that
 one DNS record can be referenced by multiple logical switches - all
 connected to a logical router.


Numan Siddique (2):
  ovn-controller: Add 'dns_lookup' action
  ovn-northd: Add logical flows to support native DNS

 include/ovn/actions.h   |  17 ++-
 ovn/controller/pinctrl.c| 248 +-
 ovn/lib/actions.c   |  52 +++
 ovn/lib/ovn-util.h  |  19 +++
 ovn/northd/ovn-northd.8.xml |  88 ++-
 ovn/northd/ovn-northd.c | 150 +-
 ovn/ovn-nb.ovsschema|  16 +-
 ovn/ovn-nb.xml  |  20 ++-
 ovn/ovn-sb.ovsschema|  18 ++-
 ovn/ovn-sb.xml  |  68 +
 ovn/utilities/ovn-nbctl.c   |   3 +
 ovn/utilities/ovn-sbctl.c   |   3 +
 ovn/utilities/ovn-trace.c   |   5 +
 tests/ovn.at| 360 
 14 files changed, 1047 insertions(+), 20 deletions(-)

-- 
2.9.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Document: Fix default DB in ovn-nbctl/sbctl manpages.

[Russell Bryant]

On Mon, Mar 27, 2017 at 2:50 AM, Han Zhou  wrote:
> Signed-off-by: Han Zhou 
> ---
>  ovn/utilities/ovn-nbctl.8.xml | 2 +-
>  ovn/utilities/ovn-sbctl.8.in  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)


Applied to master, thanks!

-- 
Russell Bryant
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Document: Fix default DB in ovn-nbctl/sbctl manpages.

[Han Zhou]

Signed-off-by: Han Zhou 
---
 ovn/utilities/ovn-nbctl.8.xml | 2 +-
 ovn/utilities/ovn-sbctl.8.in  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 1913488..10793ce 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -839,7 +839,7 @@
 
   The OVSDB database remote to contact.  If the OVN_NB_DB
   environment variable is set, its value is used as the default.
-  Otherwise, the default is unix:@RUNDIR@/db.sock, but this
+  Otherwise, the default is unix:@RUNDIR@/ovnnb_db.sock, but 
this
   default is unlikely to be useful outside of single-machine OVN test
   environments.
 
diff --git a/ovn/utilities/ovn-sbctl.8.in b/ovn/utilities/ovn-sbctl.8.in
index a87635d..6502b81 100644
--- a/ovn/utilities/ovn-sbctl.8.in
+++ b/ovn/utilities/ovn-sbctl.8.in
@@ -54,7 +54,7 @@ the global options by \fB\-\-\fR.
 .IP "\fB\-\-db=\fIserver\fR"
 The OVSDB database remote to contact.  If the \fBOVN_SB_DB\fR
 environment variable is set, its value is used as the default.
-Otherwise, the default is \fBunix:@RUNDIR@/db.sock\fR, but this
+Otherwise, the default is \fBunix:@RUNDIR@/ovnsb_db.sock\fR, but this
 default is unlikely to be useful outside of single-machine OVN test
 environments.
 .IP
-- 
2.1.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev