Re: [ovs-dev] [PATCH] extract-ofp-fields: Define .TQ directive in nroff output.

[Ben Pfaff]

On Wed, Jan 25, 2017 at 11:10:19PM -0800, Daniele Di Proietto wrote:
> 2017-01-25 20:31 GMT-08:00 Ben Pfaff :
> > This missing directive caused groff warnings and probably some erroneous
> > output too.
> >
> > Fixes: 96fee5e0a2a0 ("ovs-fields: New manpage to document Open vSwitch and 
> > OpenFlow fields.")
> > Reported-by: Daniele Di Proietto 
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Daniele Di Proietto 

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

Re: [ovs-dev] [PATCH] extract-ofp-fields: Define .TQ directive in nroff output.

[Daniele Di Proietto]

2017-01-25 20:31 GMT-08:00 Ben Pfaff :
> This missing directive caused groff warnings and probably some erroneous
> output too.
>
> Fixes: 96fee5e0a2a0 ("ovs-fields: New manpage to document Open vSwitch and 
> OpenFlow fields.")
> Reported-by: Daniele Di Proietto 
> Signed-off-by: Ben Pfaff 

Acked-by: Daniele Di Proietto 

> ---
>  build-aux/extract-ofp-fields | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
> index 4c92246..333d90e 100755
> --- a/build-aux/extract-ofp-fields
> +++ b/build-aux/extract-ofp-fields
> @@ -714,6 +714,12 @@ def make_ovs_fields(meta_flow_h, meta_flow_xml):
>  .  ns
>  .  IP "$1"
>  ..
> +
> +.de TQ
> +.  br
> +.  ns
> +.  TP "$1"
> +..
>  .de URL
>  $2 \\(laURL: $1 \\(ra$3
>  ..
> --
> 2.10.2
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] extract-ofp-fields: Define .TQ directive in nroff output.

[Ben Pfaff]

This missing directive caused groff warnings and probably some erroneous
output too.

Fixes: 96fee5e0a2a0 ("ovs-fields: New manpage to document Open vSwitch and 
OpenFlow fields.")
Reported-by: Daniele Di Proietto 
Signed-off-by: Ben Pfaff 
---
 build-aux/extract-ofp-fields | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index 4c92246..333d90e 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -714,6 +714,12 @@ def make_ovs_fields(meta_flow_h, meta_flow_xml):
 .  ns
 .  IP "$1"
 ..
+
+.de TQ
+.  br
+.  ns
+.  TP "$1"
+..
 .de URL
 $2 \\(laURL: $1 \\(ra$3
 ..
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] selinux: Allow creating tap devices.

[Daniele Di Proietto]

On 25/01/2017 00:01, "Ansis Atteka"  wrote:

>
>
>On Jan 25, 2017 4:22 AM, "Daniele Di Proietto"  wrote:
>
>Current SELinux policy in RHEL and Fedora doesn't allow the creation of
>TAP devices.
>
>A tap device is used by dpif-netdev to create internal devices.
>
>Without this patch, adding any bridge backed by the userspace datapath
>would fail.
>
>This doesn't mean that we can run Open vSwitch with DPDK under SELinux
>yet, but at least we can use the userspace datapath.
>
>Signed-off-by: Daniele Di Proietto 
>
>
>
>
>Acked-by: Ansis Atteka 
>
>
>I saw that other open source projects like OpenVPN use rw_file_perms shortcut 
>macro. Not sure how relevant that is for OVS but that macro expands to a 
>little more function calls than what you have below. Maybe we don't need it, 
>if what you have
> just worked.

Thanks a lot for the review.

I cooked this up using audit2allow and I tested it on fedora 25.  I'm now able 
to create and delete userspace bridges, without any further complaints from 
selinux

I'm definitely not an expert in SELinux, so I'm not sure if it's better to use 
the macro and ask for extra permission, or to hardcode the list.

What do you think?

>
>---
> selinux/openvswitch-custom.te | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/selinux/openvswitch-custom.te b/selinux/openvswitch-custom.te
>index 47ddb562c..98de89c98 100644
>--- a/selinux/openvswitch-custom.te
>+++ b/selinux/openvswitch-custom.te
>@@ -5,8 +5,11 @@ require {
> type openvswitch_tmp_t;
> type ifconfig_exec_t;
> type hostname_exec_t;
>+type tun_tap_device_t;
> class netlink_socket { setopt getopt create connect getattr write 
> read };
> class file { write getattr read open execute execute_no_trans };
>+class chr_file { ioctl open read write };
>
>
>
>
>+class tun_socket { create };
> }
>
> #= openvswitch_t ==
>@@ -14,3 +17,5 @@ allow openvswitch_t self:netlink_socket { setopt getopt 
>create connect getattr w
> allow openvswitch_t hostname_exec_t:file { read getattr open execute 
> execute_no_trans };
> allow openvswitch_t ifconfig_exec_t:file { read getattr open execute 
> execute_no_trans };
> allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };
>+allow openvswitch_t self:tun_socket { create };
>+allow openvswitch_t tun_tap_device_t:chr_file { ioctl open read write };
>--
>2.11.0
>
>___
>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

[ovs-dev] [PATCH] ovs-fields: Eliminate non-ASCII characters from groff input.

[Ben Pfaff]

It's difficult to make groff portably accept non-ASCII characters.  It's
easier to replace them by groff escapes for the same characters, which
this commit does.

Fixes: 96fee5e0a2a0 ("ovs-fields: New manpage to document Open vSwitch and 
OpenFlow fields.")
Signed-off-by: Ben Pfaff 
---
 build-aux/extract-ofp-fields | 2 ++
 lib/meta-flow.xml| 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index bc15a8b..4c92246 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -752,6 +752,8 @@ ovs\-fields \- protocol header fields in OpenFlow and Open 
vSwitch
 oline = oline.replace(u'\u2208', r'\[mo]')
 oline = oline.replace(u'\u2260', r'\[!=]')
 oline = oline.replace(u'\u2264', r'\[<=]')
+oline = oline.replace(u'\u2265', r'\[>=]')
+oline = oline.replace(u'\u00d7', r'\[mu]')
 if len(oline):
 output += [oline]
 
diff --git a/lib/meta-flow.xml b/lib/meta-flow.xml
index 186a8db..3db0f82 100644
--- a/lib/meta-flow.xml
+++ b/lib/meta-flow.xml
@@ -3102,8 +3102,7 @@ actions=clone(load:0->NXM_OF_IN_PORT[],output:123)
 
 vlan_tci=0x5000/0xe000
 
-  Match packets with no 802.1Q header or tagged with prior‐
-  ity 2 (in any VLAN).
+  Match packets with no 802.1Q header or tagged with priority 2 (in 
any VLAN).
 
 
 vlan_tci=0/0xefff
-- 
2.10.2

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

Re: [ovs-dev] [PATCH v2 3/3] ovs-router: introduce pkt-mark.

[Jarno Rajahalme]

Also, IMO this series is good to go to the branch-2.7 as well.

  Jarno

> On Jan 25, 2017, at 2:54 PM, Jarno Rajahalme  wrote:
> 
> With a few remarks below,
> 
> Acked-by: Jarno Rajahalme >
> 
>> On Jan 24, 2017, at 9:57 PM, Pravin B Shelar  wrote:
>> 
>> OVS router is basically partial copy of linux kernel FIB.
>> kernel routing table uses skb-mark along with usual routing
>> parameters. Following patch brings in support for skb-mark
>> to ovs-router so that we can lookup route for given skb-mark.
>> 
>> Signed-off-by: Pravin B Shelar 
>> ---
>> v1-v2:
>> Removed ovs/route2/add command
>> reverted change to plen variable type.
>> ---
>> lib/netdev-vport.c   |   4 +-
>> lib/ovs-router.c | 125 
>> ++-
>> lib/ovs-router.h |   6 ++-
>> lib/route-table.c|   2 +-
>> ofproto/ofproto-dpif-sflow.c |   5 +-
>> ofproto/ofproto-dpif-xlate.c |   2 +-
>> tests/ovs-router.at  |  42 +++
>> tests/tunnel-push-pop.at |   3 ++
>> 8 files changed, 147 insertions(+), 42 deletions(-)
>> 
>> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
>> index 88b0bcf..2d0aa43 100644
>> --- a/lib/netdev-vport.c
>> +++ b/lib/netdev-vport.c
>> @@ -260,10 +260,12 @@ tunnel_check_status_change__(struct netdev_vport 
>> *netdev)
>>bool status = false;
>>struct in6_addr *route;
>>struct in6_addr gw;
>> +uint32_t mark;
>> 
>>iface[0] = '\0';
>>route = >tnl_cfg.ipv6_dst;
>> -if (ovs_router_lookup(route, iface, NULL, )) {
>> +mark = netdev->tnl_cfg.egress_pkt_mark;
>> +if (ovs_router_lookup(mark, route, iface, NULL, )) {
>>struct netdev *egress_netdev;
>> 
>>if (!netdev_open(iface, NULL, _netdev)) {
>> diff --git a/lib/ovs-router.c b/lib/ovs-router.c
>> index 935b60a..d30eb3c 100644
>> --- a/lib/ovs-router.c
>> +++ b/lib/ovs-router.c
>> @@ -45,6 +45,11 @@
>> #include "unaligned.h"
>> #include "unixctl.h"
>> #include "util.h"
>> +#include "openvswitch/vlog.h"
>> +
>> +VLOG_DEFINE_THIS_MODULE(ovs_router);
>> +
>> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
>> 
>> static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER;
>> static struct classifier cls;
>> @@ -57,6 +62,7 @@ struct ovs_router_entry {
>>struct in6_addr src_addr;
>>uint8_t plen;
>>uint8_t priority;
>> +uint32_t mark;
>> };
>> 
>> static struct ovs_router_entry *
>> @@ -88,11 +94,12 @@ ovs_router_lookup_fallback(const struct in6_addr 
>> *ip6_dst, char output_bridge[],
>> }
>> 
>> bool
>> -ovs_router_lookup(const struct in6_addr *ip6_dst, char output_bridge[],
>> +ovs_router_lookup(uint32_t mark, const struct in6_addr *ip6_dst,
>> +  char output_bridge[],
>>  struct in6_addr *src, struct in6_addr *gw)
>> {
>>const struct cls_rule *cr;
>> -struct flow flow = {.ipv6_dst = *ip6_dst};
>> +struct flow flow = {.ipv6_dst = *ip6_dst, .pkt_mark = mark};
>> 
>>cr = classifier_lookup(, OVS_VERSION_MAX, , NULL);
>>if (cr) {
>> @@ -115,7 +122,8 @@ rt_entry_free(struct ovs_router_entry *p)
>>free(p);
>> }
>> 
>> -static void rt_init_match(struct match *match, const struct in6_addr 
>> *ip6_dst,
>> +static void rt_init_match(struct match *match, uint32_t mark,
>> +  const struct in6_addr *ip6_dst,
>>  uint8_t plen)
>> {
>>struct in6_addr dst;
>> @@ -127,6 +135,8 @@ static void rt_init_match(struct match *match, const 
>> struct in6_addr *ip6_dst,
>>memset(match, 0, sizeof *match);
>>match->flow.ipv6_dst = dst;
>>match->wc.masks.ipv6_dst = mask;
>> +match->wc.masks.pkt_mark = UINT32_MAX;
>> +match->flow.pkt_mark = mark;
>> }
>> 
>> static int
>> @@ -178,7 +188,8 @@ out:
>> }
>> 
>> static int
>> -ovs_router_insert__(uint8_t priority, const struct in6_addr *ip6_dst,
>> +ovs_router_insert__(uint32_t mark, uint8_t priority,
>> +const struct in6_addr *ip6_dst,
>>uint8_t plen, const char output_bridge[],
>>const struct in6_addr *gw)
>> {
>> @@ -187,13 +198,14 @@ ovs_router_insert__(uint8_t priority, const struct 
>> in6_addr *ip6_dst,
>>struct match match;
>>int err;
>> 
>> -rt_init_match(, ip6_dst, plen);
>> +rt_init_match(, mark, ip6_dst, plen);
>> 
>>p = xzalloc(sizeof *p);
>>ovs_strlcpy(p->output_bridge, output_bridge, sizeof p->output_bridge);
>>if (ipv6_addr_is_set(gw)) {
>>p->gw = *gw;
>>}
>> +p->mark = mark;
>>p->nw_addr = match.flow.ipv6_dst;
>>p->plen = plen;
>>p->priority = priority;
>> @@ -202,7 +214,12 @@ ovs_router_insert__(uint8_t priority, const struct 
>> in6_addr *ip6_dst,
>>err = get_src_addr(gw, output_bridge, >src_addr);
>>}
>>if (err) {
>> +struct ds ds = DS_EMPTY_INITIALIZER;
>> +
>> +ipv6_format_mapped(ip6_dst, );
>> +

Re: [ovs-dev] [PATCH v2 3/3] ovs-router: introduce pkt-mark.

[Jarno Rajahalme]

With a few remarks below,

Acked-by: Jarno Rajahalme 

> On Jan 24, 2017, at 9:57 PM, Pravin B Shelar  wrote:
> 
> OVS router is basically partial copy of linux kernel FIB.
> kernel routing table uses skb-mark along with usual routing
> parameters. Following patch brings in support for skb-mark
> to ovs-router so that we can lookup route for given skb-mark.
> 
> Signed-off-by: Pravin B Shelar 
> ---
> v1-v2:
> Removed ovs/route2/add command
> reverted change to plen variable type.
> ---
> lib/netdev-vport.c   |   4 +-
> lib/ovs-router.c | 125 ++-
> lib/ovs-router.h |   6 ++-
> lib/route-table.c|   2 +-
> ofproto/ofproto-dpif-sflow.c |   5 +-
> ofproto/ofproto-dpif-xlate.c |   2 +-
> tests/ovs-router.at  |  42 +++
> tests/tunnel-push-pop.at |   3 ++
> 8 files changed, 147 insertions(+), 42 deletions(-)
> 
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index 88b0bcf..2d0aa43 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -260,10 +260,12 @@ tunnel_check_status_change__(struct netdev_vport 
> *netdev)
> bool status = false;
> struct in6_addr *route;
> struct in6_addr gw;
> +uint32_t mark;
> 
> iface[0] = '\0';
> route = >tnl_cfg.ipv6_dst;
> -if (ovs_router_lookup(route, iface, NULL, )) {
> +mark = netdev->tnl_cfg.egress_pkt_mark;
> +if (ovs_router_lookup(mark, route, iface, NULL, )) {
> struct netdev *egress_netdev;
> 
> if (!netdev_open(iface, NULL, _netdev)) {
> diff --git a/lib/ovs-router.c b/lib/ovs-router.c
> index 935b60a..d30eb3c 100644
> --- a/lib/ovs-router.c
> +++ b/lib/ovs-router.c
> @@ -45,6 +45,11 @@
> #include "unaligned.h"
> #include "unixctl.h"
> #include "util.h"
> +#include "openvswitch/vlog.h"
> +
> +VLOG_DEFINE_THIS_MODULE(ovs_router);
> +
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
> 
> static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER;
> static struct classifier cls;
> @@ -57,6 +62,7 @@ struct ovs_router_entry {
> struct in6_addr src_addr;
> uint8_t plen;
> uint8_t priority;
> +uint32_t mark;
> };
> 
> static struct ovs_router_entry *
> @@ -88,11 +94,12 @@ ovs_router_lookup_fallback(const struct in6_addr 
> *ip6_dst, char output_bridge[],
> }
> 
> bool
> -ovs_router_lookup(const struct in6_addr *ip6_dst, char output_bridge[],
> +ovs_router_lookup(uint32_t mark, const struct in6_addr *ip6_dst,
> +  char output_bridge[],
>   struct in6_addr *src, struct in6_addr *gw)
> {
> const struct cls_rule *cr;
> -struct flow flow = {.ipv6_dst = *ip6_dst};
> +struct flow flow = {.ipv6_dst = *ip6_dst, .pkt_mark = mark};
> 
> cr = classifier_lookup(, OVS_VERSION_MAX, , NULL);
> if (cr) {
> @@ -115,7 +122,8 @@ rt_entry_free(struct ovs_router_entry *p)
> free(p);
> }
> 
> -static void rt_init_match(struct match *match, const struct in6_addr 
> *ip6_dst,
> +static void rt_init_match(struct match *match, uint32_t mark,
> +  const struct in6_addr *ip6_dst,
>   uint8_t plen)
> {
> struct in6_addr dst;
> @@ -127,6 +135,8 @@ static void rt_init_match(struct match *match, const 
> struct in6_addr *ip6_dst,
> memset(match, 0, sizeof *match);
> match->flow.ipv6_dst = dst;
> match->wc.masks.ipv6_dst = mask;
> +match->wc.masks.pkt_mark = UINT32_MAX;
> +match->flow.pkt_mark = mark;
> }
> 
> static int
> @@ -178,7 +188,8 @@ out:
> }
> 
> static int
> -ovs_router_insert__(uint8_t priority, const struct in6_addr *ip6_dst,
> +ovs_router_insert__(uint32_t mark, uint8_t priority,
> +const struct in6_addr *ip6_dst,
> uint8_t plen, const char output_bridge[],
> const struct in6_addr *gw)
> {
> @@ -187,13 +198,14 @@ ovs_router_insert__(uint8_t priority, const struct 
> in6_addr *ip6_dst,
> struct match match;
> int err;
> 
> -rt_init_match(, ip6_dst, plen);
> +rt_init_match(, mark, ip6_dst, plen);
> 
> p = xzalloc(sizeof *p);
> ovs_strlcpy(p->output_bridge, output_bridge, sizeof p->output_bridge);
> if (ipv6_addr_is_set(gw)) {
> p->gw = *gw;
> }
> +p->mark = mark;
> p->nw_addr = match.flow.ipv6_dst;
> p->plen = plen;
> p->priority = priority;
> @@ -202,7 +214,12 @@ ovs_router_insert__(uint8_t priority, const struct 
> in6_addr *ip6_dst,
> err = get_src_addr(gw, output_bridge, >src_addr);
> }
> if (err) {
> +struct ds ds = DS_EMPTY_INITIALIZER;
> +
> +ipv6_format_mapped(ip6_dst, );
> +VLOG_DBG_RL(, "src addr not available for route %s", 
> ds_cstr());
> free(p);
> +ds_destroy();
> return err;
> }
> /* Longest prefix matches first. */
> @@ -222,13 +239,12 @@ ovs_router_insert__(uint8_t priority, const struct 
> in6_addr *ip6_dst,
> }
> 
> void

Re: [ovs-dev] [PATCH v2 1/3] tunnel: Add support to configure ptk_mark

[Jarno Rajahalme]

With one correction below,

Acked-by: Jarno Rajahalme 

> On Jan 24, 2017, at 9:57 PM, Pravin B Shelar  wrote:
> 
> Today packet mark action is broken for Tunnel ports with
> tunnel monitoring. User can write a flow to set pkt-mark for
> any tunnel traffic, but there is no way to set the packet
> mark for corresponding BFD trffic.
> 

“trffic” -> “traffic”

> Following patch introduces new option in OVSDB tunnel
> configuration so that user can set skb-mark for given
> tunnel endpoint. OVS would set the mark according to the
> skb-mark option for all tunnel traffic including packets
> generated by vSwitchd like tunnel monitoring BFD packet.
> 
> Signed-off-by: Pravin B Shelar 
> ---
> v1-v2:
> Handle zero egress_pkt_mark
> Added more documentation.
> ---
> NEWS |  2 ++
> lib/netdev-vport.c   |  7 +++
> lib/netdev.h |  2 ++
> ofproto/tunnel.c |  5 +
> tests/tunnel-push-pop.at | 16 
> vswitchd/vswitch.xml |  6 ++
> 6 files changed, 38 insertions(+)
> 
> diff --git a/NEWS b/NEWS
> index 0a9551c..6838649 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -51,6 +51,8 @@ Post-v2.6.0
>a per-OpenFlow bridge basis rather than globally. (The interface
>has not changed.)
>  * Removed support for IPsec tunnels.
> + * Added support to set packet mark for tunnel endpoint using
> +   `egress_pkt_mark` OVSDB option.
>- DPDK:
>  * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
>which set the number of rx and tx descriptors to use for the given 
> port.
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index 4c2ced5..88b0bcf 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -509,6 +509,9 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
> *args, char **errp)
> }
> 
> free(str);
> +} else if (!strcmp(node->key, "egress_pkt_mark")) {
> +tnl_cfg.egress_pkt_mark = strtoul(node->value, NULL, 10);
> +tnl_cfg.set_egress_pkt_mark = true;
> } else {
> ds_put_format(, "%s: unknown %s argument '%s'\n",
>   name, type, node->key);
> @@ -649,6 +652,10 @@ get_tunnel_config(const struct netdev *dev, struct smap 
> *args)
> smap_add(args, "df_default", "false");
> }
> 
> +if (tnl_cfg.set_egress_pkt_mark) {
> +smap_add_format(args, "egress_pkt_mark",
> +"%"PRIu32, tnl_cfg.egress_pkt_mark);
> +}
> return 0;
> }
> 
> diff --git a/lib/netdev.h b/lib/netdev.h
> index bef9cdd..d6c07c1 100644
> --- a/lib/netdev.h
> +++ b/lib/netdev.h
> @@ -89,6 +89,8 @@ struct netdev_tunnel_config {
> struct in6_addr ipv6_dst;
> 
> uint32_t exts;
> +bool set_egress_pkt_mark;
> +uint32_t egress_pkt_mark;
> 
> uint8_t ttl;
> bool ttl_inherit;
> diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c
> index ce727f4..e285d54 100644
> --- a/ofproto/tunnel.c
> +++ b/ofproto/tunnel.c
> @@ -461,6 +461,11 @@ tnl_port_send(const struct ofport_dpif *ofport, struct 
> flow *flow,
> | (cfg->csum ? FLOW_TNL_F_CSUM : 0)
> | (cfg->out_key_present ? FLOW_TNL_F_KEY : 0);
> 
> +if (cfg->set_egress_pkt_mark) {
> +flow->pkt_mark = cfg->egress_pkt_mark;
> +wc->masks.pkt_mark = UINT32_MAX;
> +}
> +
> if (pre_flow_str) {
> char *post_flow_str = flow_to_string(flow);
> char *tnl_str = tnl_port_fmt(tnl_port);
> diff --git a/tests/tunnel-push-pop.at b/tests/tunnel-push-pop.at
> index 700ef55..4aaa669 100644
> --- a/tests/tunnel-push-pop.at
> +++ b/tests/tunnel-push-pop.at
> @@ -12,6 +12,8 @@ AT_CHECK([ovs-vsctl add-port int-br t2 -- set Interface t2 
> type=vxlan \
>options:remote_ip=1.1.2.93 options:out_key=flow 
> options:csum=true ofport_request=4\
> -- add-port int-br t4 -- set Interface t4 type=geneve \
>options:remote_ip=flow options:key=123 
> ofport_request=5\
> +-- add-port int-br t5 -- set Interface t5 type=geneve \
> +   options:remote_ip=1.1.2.93 options:out_key=flow 
> options:egress_pkt_mark=1234 ofport_request=6\
>], [0])
> 
> AT_CHECK([ovs-appctl dpif/show], [0], [dnl
> @@ -25,6 +27,7 @@ dummy@ovs-dummy: hit:0 missed:0
>   t2 2/4789: (vxlan: key=123, remote_ip=1.1.2.92)
>   t3 4/4789: (vxlan: csum=true, out_key=flow, remote_ip=1.1.2.93)
>   t4 5/6081: (geneve: key=123, remote_ip=flow)
> + t5 6/6081: (geneve: egress_pkt_mark=1234, out_key=flow, 
> remote_ip=1.1.2.93)
> ])
> 
> dnl First setup dummy interface IP address, then add the route
> @@ -91,6 +94,12 @@ AT_CHECK([tail -1 stdout], [0],
>   [Datapath actions: tnl_pop(6081)
> ])
> 
> +dnl Check Geneve tunnel (t6) pop
> +AT_CHECK([ovs-appctl ofproto/trace ovs-dummy 
> 

Re: [ovs-dev] [PATCH 2/2] ovs-fields: New manpage to document Open vSwitch and OpenFlow fields.

[Ben Pfaff]

On Tue, Jan 24, 2017 at 05:13:15PM -0800, Justin Pettit wrote:
> 
> > On Jan 24, 2017, at 5:11 PM, Justin Pettit  wrote:
> > 
> > This was a lot of work.  Thanks for doing it!
> > 
> > --Justin
> 
> Whoops!
> 
> Acked-by: Justin Pettit 

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

[ovs-dev] Meat / Poultry

[Bonesca - Jona - Afrigo]

    [ View in browser ]( http://r.newsletter.bonescamail.nl/nru6r04eoatrf.html 
)   
 [   ]( http://r.newsletter.bonescamail.nl/2n3cr00h9aoatrd.html )
 
 
Special offers meat and poultry :
 
Turkeytails / Putenschwanz / Kalkoenstaart / Croupions de Dinde 10 kilo - 10 
box € 0,65 per kilo!!
 
Chickenleg Quarters / Hähnchenschenkel / Kuikenpoten / Cuisse de Poulet AAA 
grade 5 kilo 20 box € 5,25 per box!!
 
Souphen / Suppenhühn / Soepkip / Poule in parts
10 x 1 kilo 10 box € 1,65 per kilo!!
 
Cow Skin cutted / Kühehaut geschnitten / Koeienhuid / Peau de Boeuf 8 x 1 kilo 
8 x 1 kilo 10 box € 2,39 per kilo!!
 
etc etc etc     

 
This email was sent to d...@openvswitch.org
You received this email because you are registered with Bonesca Import en 
Export BV
 
[ Unsubscribe here ]( http://r.newsletter.bonescamail.nl/nru6r04eoatrg.html )  

Sent by
[  ]( http://r.newsletter.bonescamail.nl/2n3cr00i1qoatrd.html )     
© 2017 Bonesca Import en Export BV  

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

[ovs-dev] Updated Sugar CRM Users

[Susan Zook]

Hi,



Would you be interested in Targeted “*Sugar CRM”* leads? We are happy to
provide the database across globe, specifically *North America, EMEA, APAC*
 and *Latin America*.



We also have other users like *Salesforce CRM, Nimble, PipelineDeals,
Pipedrive, Hubspot CRM, Workbooks, Zoho CRM, Microsoft Dynamics, Prosper
works, Nutshell, Prophet CRM, Goldmine, Insightly, Salesnet, Vtiger CRM*
many more.



Please review and let me know your thoughts, I will get back to you counts,
pricing and more information in my next email.



Await your response!



Best Regards,
*Susan Zook* | Mktg Manager

  If you do not wish to receive further emails, please respond with
"Leave Out" or "Unsubscribe" in subject line.
[image: beacon]
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

[Jozef Bacigál]

Before the meeting will start.


Have made some [1] documentation for ODL and [2] few patch sets with rpc 
implementation of openflow bundles extension.


[1] 
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Bundles_extension_support

[2] https://git.opendaylight.org/gerrit/#/c/50957/


Jozef


Od: Jan Scheurich 
Odoslané: 25. januára 2017 8:48
Komu: Abhijit Kumbhare; Zoltán Balogh; László Sürü; Miklós Pelyva; Jozef 
Bacigál; Tomáš Slušný; Prasanna Huddar; Shuva Jyoti Kar; Sharath Kumar V; 
Kanagasundaram K; Sunil Kumar G; D Arunprakash; Muthukumaran K; Jarno Rajahalme 
(ja...@ovn.org); d...@openvswitch.org
Predmet: OVS - ODL Sync on OF Bundle in 1.3
Kedy: 25. januára 2017 17:00-18:00.
Kde: Skype Meeting

We'll use below webex instead of Lync/SkypeFB:
https://meetings.webex.com/collabs/#/meetings/detail?uuid=MBFUHFYE8TRG3NPX76F4PLRS2N-3OWH=231184.55753
Rescheduled to Wednesday due to unavailability of key participants.
@Jarno: As you are the OVS brain behind bundles. Do you have the chance to join 
for a short time to discuss some details regarding OF 1.3 bundle implementation?
Hi Jarno,
OpenDaylight folks are finally starting to implement support of OpenFlow 
bundles as a basis for the bundle-based hitless recync procedure we discussed 
earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 or 
1.5, they intend to implement the bundle extension to OF 1.3 as specified in 
EXT-230 in
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip
Would you have time for a short meeting on early Monday to discuss and confirm 
whether the OVS implementation of bundles in OF 1.3 is compliant with EXT-230 
and has everything they need?
Thanks, Jan


JozefBacigál
Software Engineer

Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
R centrum / Janka Kráľa 9 /  974 01 Banská Bystrica / Slovakia
+421 908 766 972 / jozef.baci...@pantheon.tech
reception: +421 2 206 65 114 / www.pantheon.tech

[logo]


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

Re: [ovs-dev] [ovn] What's the manner of sending GARP for distributed dnat_and_snat?

[Dong Jun]

Thanks, get it.


On 2017/1/25 16:30, Mickey Spiegel wrote:


On Wed, Jan 25, 2017 at 12:26 AM, Dong Jun > wrote:


Hi

I learned about the distributed dnat_and_snat. Now I don't see
what's the manner of sending GARP for distributed dnat_and_snat
IP. In the past, we set nat_addresses column in lsp that connected
to gateway lrp. Now the type of lrp was changed from l3gateway to
patch, does this affect GARP for distributed dnat_and_snat IP?


GARP is not supported in the current patch set for distributed NAT. I 
have started working on a couple of patches for GARP with distributed 
NAT. The first patch is allowing options nat-addresses to be set to 
the string "router", in which case northd will collect all the NAT 
external IP addresses and load balancer IP addresses from VIPs and set 
the port_binding nat-addresses correspondingly. The second patch will 
extend GARP functionality for distributed NAT, by replacing options 
nat-addresses with a column nat_addresses that with max:unlimited, and 
the optional addition of a port name to the end of the string. When 
the port name is present, GARP will only be issued for the addresses 
in that column on the chassis where the specified port is resident.


Mickey



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

Re: [ovs-dev] Invitation: OVS-DPDK bi-weekly meeting...

[Kevin Traynor]

Cancelling for 26th Jan. Next meeting 9th Feb.

thanks,
Kevin.

On 12/13/2016 05:47 PM, ktray...@redhat.com wrote:
> You have been invited to the following event.
> 
> Title: OVS-DPDK bi-weekly meeting
> Hi All,
> 
> At the OVS-DPDK Meetup after the OVS conference, it was suggested to
> have a regular sync up call between people working on OVS-DPDK. Let's
> keep it to status/plans and keep the technical discussion for the
> mailing list.
> 
> I'd suggest for a first meeting, we collect status for the items
> identified at the meetup
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325217.html
> and discuss any new plans or opens anyone wants to talk about.
> 
> You can connect to Bluejeans on a computer or through phone dial in, all
> welcome.
> https://bluejeans.com/393834449
> 
> US: +1.408.740.7256
> UK: +44.203.608.5256
> Germany: +49.32.221.091256
> Ireland: +353.1.697.1256
> Other numbers at https://www.bluejeans.com/numbers
> Meeting ID: 393834449
> 
> thanks
> Kevin.
> When: Every 2 weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu
> Jun 29, 2017 Dublin
> Where: https://bluejeans.com/393834449
> Calendar: d...@openvswitch.org
> Who:
> * ktray...@redhat.com - organizer
> * d...@openvswitch.org
> 
> Event details:
> https://www.google.com/calendar/event?action=VIEW=cmRzbXJxdnZqNmF0cDg5MThyc2NncW5vcWcgZGV2QG9wZW52c3dpdGNoLm9yZw=MTkja3RyYXlub3JAcmVkaGF0LmNvbTVjNzQ5OGViNzY1MGEyM2JlMDE2ZDI4ZDkwNWVjM2E3OWE3N2VjZjU=Europe/Dublin=en
> 
> 
> Invitation from Google Calendar: https://www.google.com/calendar/
> 
> You are receiving this courtesy email at the account d...@openvswitch.org
> because you are an attendee of this event.
> 
> To stop receiving future updates for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification settings
> for your entire calendar.
> 
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn more at
> https://support.google.com/calendar/answer/37135#forwarding
> 
> 
> ___
> 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] [ovn] What's the manner of sending GARP for distributed dnat_and_snat?

[Mickey Spiegel]

On Wed, Jan 25, 2017 at 12:26 AM, Dong Jun  wrote:

> Hi
>
> I learned about the distributed dnat_and_snat. Now I don't see what's
> the manner of sending GARP for distributed dnat_and_snat IP. In the past,
> we set nat_addresses column in lsp that connected to gateway lrp. Now the
> type of lrp was changed from l3gateway to patch, does this affect GARP for
> distributed dnat_and_snat IP?
>

GARP is not supported in the current patch set for distributed NAT. I have
started working on a couple of patches for GARP with distributed NAT. The
first patch is allowing options nat-addresses to be set to the string
"router", in which case northd will collect all the NAT external IP
addresses and load balancer IP addresses from VIPs and set the port_binding
nat-addresses correspondingly. The second patch will extend GARP
functionality for distributed NAT, by replacing options nat-addresses with
a column nat_addresses that with max:unlimited, and the optional addition
of a port name to the end of the string. When the port name is present,
GARP will only be issued for the addresses in that column on the chassis
where the specified port is resident.

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

[ovs-dev] [ovn] What's the manner of sending GARP for distributed dnat_and_snat?

[Dong Jun]

Hi

I learned about the distributed dnat_and_snat. Now I don't see 
what's the manner of sending GARP for distributed dnat_and_snat IP. In 
the past, we set nat_addresses column in lsp that connected to gateway 
lrp. Now the type of lrp was changed from l3gateway to patch, does this 
affect GARP for distributed dnat_and_snat IP?



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

Re: [ovs-dev] [PATCH] selinux: Allow creating tap devices.

[Ansis Atteka]

On Jan 25, 2017 4:22 AM, "Daniele Di Proietto" 
wrote:

Current SELinux policy in RHEL and Fedora doesn't allow the creation of
TAP devices.

A tap device is used by dpif-netdev to create internal devices.

Without this patch, adding any bridge backed by the userspace datapath
would fail.

This doesn't mean that we can run Open vSwitch with DPDK under SELinux
yet, but at least we can use the userspace datapath.

Signed-off-by: Daniele Di Proietto 

Acked-by: Ansis Atteka 

I saw that other open source projects like OpenVPN use rw_file_perms
shortcut macro. Not sure how relevant that is for OVS but that macro
expands to a little more function calls than what you have below. Maybe we
don't need it, if what you have just worked.

---
 selinux/openvswitch-custom.te | 5 +
 1 file changed, 5 insertions(+)

diff --git a/selinux/openvswitch-custom.te b/selinux/openvswitch-custom.te
index 47ddb562c..98de89c98 100644
--- a/selinux/openvswitch-custom.te
+++ b/selinux/openvswitch-custom.te
@@ -5,8 +5,11 @@ require {
 type openvswitch_tmp_t;
 type ifconfig_exec_t;
 type hostname_exec_t;
+type tun_tap_device_t;
 class netlink_socket { setopt getopt create connect getattr write
read };
 class file { write getattr read open execute execute_no_trans };
+class chr_file { ioctl open read write };

+class tun_socket { create };
 }

 #= openvswitch_t ==
@@ -14,3 +17,5 @@ allow openvswitch_t self:netlink_socket { setopt getopt
create connect getattr w
 allow openvswitch_t hostname_exec_t:file { read getattr open execute
execute_no_trans };
 allow openvswitch_t ifconfig_exec_t:file { read getattr open execute
execute_no_trans };
 allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };
+allow openvswitch_t self:tun_socket { create };
+allow openvswitch_t tun_tap_device_t:chr_file { ioctl open read write };
--
2.11.0

___
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