Re: [ovs-dev] [PATCH 3/3] tunnel: Add ofproto/list-tunnels command for troubleshooting.

[Vishal Deep Ajmera]

Thanks Ben. This indeed is a very useful command to have. Would it also make 
sense
to print the Source IP and Destination IP fields as part of list command ? This 
might help 
in identifying the tunnel quickly.

Warm Regards,
Vishal Ajmera

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Ben Pfaff
Sent: Friday, December 29, 2017 2:05 AM
To: d...@openvswitch.org
Cc: Ben Pfaff 
Subject: [ovs-dev] [PATCH 3/3] tunnel: Add ofproto/list-tunnels command for 
troubleshooting.

I've recently had to debug some issues related to tunnel implementation.
This command would make it easier to have some confidence in how tunnels are 
actually set up inside OVS.

Signed-off-by: Ben Pfaff 
---
 ofproto/tunnel.c | 74 +---
 tests/cfm.at |  3 +++
 2 files changed, 58 insertions(+), 19 deletions(-)

diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c index 
f6d266a00607..770e0103476a 100644
--- a/ofproto/tunnel.c
+++ b/ofproto/tunnel.c
@@ -37,6 +37,7 @@
 #include "tunnel.h"
 #include "openvswitch/vlog.h"
 #include "unaligned.h"
+#include "unixctl.h"
 #include "ofproto-dpif.h"
 #include "netdev-vport.h"
 
@@ -121,7 +122,10 @@ static struct tnl_port *tnl_find_ofport(const struct 
ofport_dpif *)
 
 static uint32_t tnl_hash(struct tnl_match *);  static void tnl_match_fmt(const 
struct tnl_match *, struct ds *); -static char *tnl_port_fmt(const struct 
tnl_port *) OVS_REQ_RDLOCK(rwlock);
+static char *tnl_port_to_string(const struct tnl_port *)
+OVS_REQ_RDLOCK(rwlock);
+static void tnl_port_format(const struct tnl_port *, struct ds *)
+OVS_REQ_RDLOCK(rwlock);
 static void tnl_port_mod_log(const struct tnl_port *, const char *action)
 OVS_REQ_RDLOCK(rwlock);
 static const char *tnl_port_get_name(const struct tnl_port *) @@ -129,6 +133,8 
@@ static const char *tnl_port_get_name(const struct tnl_port *)  static void 
tnl_port_del__(const struct ofport_dpif *, odp_port_t)
 OVS_REQ_WRLOCK(rwlock);
 
+static unixctl_cb_func tnl_unixctl_list;
+
 void
 ofproto_tunnel_init(void)
 {
@@ -136,6 +142,8 @@ ofproto_tunnel_init(void)
 
 if (ovsthread_once_start()) {
 fat_rwlock_init();
+unixctl_command_register("ofproto/list-tunnels", "", 0, 0,
+ tnl_unixctl_list, NULL);
 ovsthread_once_done();
 }
 }
@@ -318,7 +326,7 @@ tnl_port_receive(const struct flow *flow) 
OVS_EXCLUDED(rwlock)
 
 if (!VLOG_DROP_DBG(_rl)) {
 char *flow_str = flow_to_string(flow, NULL);
-char *tnl_str = tnl_port_fmt(tnl_port);
+char *tnl_str = tnl_port_to_string(tnl_port);
 VLOG_DBG("tunnel port %s receive from flow %s", tnl_str, flow_str);
 free(tnl_str);
 free(flow_str);
@@ -467,7 +475,7 @@ tnl_port_send(const struct ofport_dpif *ofport, struct flow 
*flow,
 
 if (pre_flow_str) {
 char *post_flow_str = flow_to_string(flow, NULL);
-char *tnl_str = tnl_port_fmt(tnl_port);
+char *tnl_str = tnl_port_to_string(tnl_port);
 VLOG_DBG("flow sent\n"
  "%s"
  " pre: %s\n"
@@ -642,53 +650,58 @@ tnl_port_mod_log(const struct tnl_port *tnl_port, const 
char *action)
 }
 }
 
-static char *
-tnl_port_fmt(const struct tnl_port *tnl_port) OVS_REQ_RDLOCK(rwlock)
+static void OVS_REQ_RDLOCK(rwlock)
+tnl_port_format(const struct tnl_port *tnl_port, struct ds *ds)
 {
 const struct netdev_tunnel_config *cfg =
 netdev_get_tunnel_config(tnl_port->netdev);
-struct ds ds = DS_EMPTY_INITIALIZER;
 
-ds_put_format(, "port %"PRIu32": %s (%s: ", tnl_port->match.odp_port,
+ds_put_format(ds, "port %"PRIu32": %s (%s: ", 
+ tnl_port->match.odp_port,
   tnl_port_get_name(tnl_port),
   netdev_get_type(tnl_port->netdev));
-tnl_match_fmt(_port->match, );
+tnl_match_fmt(_port->match, ds);
 
 if (cfg->out_key != cfg->in_key ||
 cfg->out_key_present != cfg->in_key_present ||
 cfg->out_key_flow != cfg->in_key_flow) {
-ds_put_cstr(, ", out_key=");
+ds_put_cstr(ds, ", out_key=");
 if (!cfg->out_key_present) {
-ds_put_cstr(, "none");
+ds_put_cstr(ds, "none");
 } else if (cfg->out_key_flow) {
-ds_put_cstr(, "flow");
+ds_put_cstr(ds, "flow");
 } else {
-ds_put_format(, "%#"PRIx64, ntohll(cfg->out_key));
+ds_put_format(ds, "%#"PRIx64, ntohll(cfg->out_key));
 }
 }
 
 if (cfg->ttl_inherit) {
-ds_put_cstr(, ", ttl=inherit");
+ds_put_cstr(ds, ", ttl=inherit");
 } else {
-ds_put_format(, ", ttl=%"PRIu8, cfg->ttl);
+ds_put_format(ds, ", ttl=%"PRIu8, cfg->ttl);
 }
 
 if (cfg->tos_inherit) {
-ds_put_cstr(, ", tos=inherit");
+ds_put_cstr(ds, ", tos=inherit");
 } else if (cfg->tos) {
-ds_put_format(, ", 

Re: [ovs-dev] [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing

[Ed Swierk via dev]

On Fri, Dec 22, 2017 at 3:31 PM, Pravin Shelar  wrote:
> On Thu, Dec 21, 2017 at 7:17 AM, Ed Swierk  wrote:
>> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
>> included in the L3 length. For example, a short IPv4 packet may have
>> up to 6 bytes of padding following the IP payload when received on an
>> Ethernet device. In the normal IPv4 receive path, ip_rcv() trims the
>> packet to ip_hdr->tot_len before invoking netfilter hooks (including
>> conntrack and nat).
>>
>> In the IPv6 receive path, ip6_rcv() does the same using
>> ipv6_hdr->payload_len. Similarly in the br_netfilter receive path,
>> br_validate_ipv4() and br_validate_ipv6() trim the packet to the L3
>> length before invoking NF_INET_PRE_ROUTING hooks.
>>
>> In the OVS conntrack receive path, ovs_ct_execute() pulls the skb to
>> the L3 header but does not trim it to the L3 length before calling
>> nf_conntrack_in(NF_INET_PRE_ROUTING). When nf_conntrack_proto_tcp
>> encounters a packet with lower-layer padding, nf_checksum() fails and
>> logs "nf_ct_tcp: bad TCP checksum". While extra zero bytes don't
>> affect the checksum, the length in the IP pseudoheader does. That
>> length is based on skb->len, and without trimming, it doesn't match
>> the length the sender used when computing the checksum.
>>
>> The assumption throughout nf_conntrack and nf_nat is that skb->len
>> reflects the length of the L3 header and payload, so there is no need
>> to refer back to ip_hdr->tot_len or ipv6_hdr->payload_len.
>>
>> This change brings OVS into line with other netfilter users, trimming
>> IPv4 and IPv6 packets prior to L3+ netfilter processing.
>>
>> Signed-off-by: Ed Swierk 
>> ---
>> v2:
>> - Trim packet in nat receive path as well as conntrack
>> - Free skb on error
>> ---
>>  net/openvswitch/conntrack.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>> index b27c5c6..1bdc78f 100644
>> --- a/net/openvswitch/conntrack.c
>> +++ b/net/openvswitch/conntrack.c
>> @@ -703,6 +703,33 @@ static bool skb_nfct_cached(struct net *net,
>> return ct_executed;
>>  }
>>
>> +/* Trim the skb to the L3 length. Assumes the skb is already pulled to
>> + * the L3 header. The skb is freed on error.
>> + */
>> +static int skb_trim_l3(struct sk_buff *skb)
>> +{
>> +   unsigned int nh_len;
>> +   int err;
>> +
>> +   switch (skb->protocol) {
>> +   case htons(ETH_P_IP):
>> +   nh_len = ntohs(ip_hdr(skb)->tot_len);
>> +   break;
>> +   case htons(ETH_P_IPV6):
>> +   nh_len = ntohs(ipv6_hdr(skb)->payload_len)
>> +   + sizeof(struct ipv6hdr);
>> +   break;
>> +   default:
>> +   nh_len = skb->len;
>> +   }
>> +
>> +   err = pskb_trim_rcsum(skb, nh_len);
>> +   if (err)
> This should is unlikely.
>> +   kfree_skb(skb);
>> +
>> +   return err;
>> +}
>> +
> This looks like a generic function, it probably does not belong to OVS
> code base.

It occurs to me that skb_trim_l3() can't just reach into ip_hdr(skb)
before calling pskb_may_pull(skb, sizeof(struct iphdr)) to make sure
the IP header is actually there; and for IPv4 it should validate the
IP header checksum, including options. Once we add all these steps,
skb_trim_l3() starts to look an awful lot like br_validate_ipv4() and
br_validate_ipv6(). And those in turn are eerily similar to ip_rcv()
and ip6_rcv(). It would be nice to avoid duplicating this logic yet
again.

What if we turn br_validate_ipv4() and br_validate_ipv6() into generic
functions and call them from both br_netfilter and ovs_ct--should
there be any fundamental difference between these two receive paths,
at least for L3+ conntrack processing?

For example, currently br_netfilter updates the
IPSTATS_MIB_INTRUNCATEDPKTS and IPSTATS_MIB_INDISCARDS counters. It
would be easy to make this conditional in a generic function, if we
still don't want ovs_ct to update those counters.

>>  #ifdef CONFIG_NF_NAT_NEEDED
>>  /* Modelled after nf_nat_ipv[46]_fn().
>>   * range is only used for new, uninitialized NAT state.
>> @@ -715,8 +742,12 @@ static int ovs_ct_nat_execute(struct sk_buff *skb, 
>> struct nf_conn *ct,
>>  {
>> int hooknum, nh_off, err = NF_ACCEPT;
>>
>> +   /* The nat module expects to be working at L3. */
>> nh_off = skb_network_offset(skb);
>> skb_pull_rcsum(skb, nh_off);
>> +   err = skb_trim_l3(skb);
>> +   if (err)
>> +   return err;
>>
> ct-nat is executed within ct action, so I do not see why you you call
> skb-trim again from ovs_ct_nat_execute().
> ovs_ct_execute() trim should take care of the skb.
>
>> /* See HOOK2MANIP(). */
>> if (maniptype == NF_NAT_MANIP_SRC)
>> @@ -,6 +1142,9 @@ int ovs_ct_execute(struct net *net, struct sk_buff 
>> *skb,
>>   

Re: [ovs-dev] [no-slow 6/6] ofproto-dpif: Don't slow-path controller actions with pause.

[Ben Pfaff]

On Thu, Dec 21, 2017 at 02:25:15PM -0800, Justin Pettit wrote:
> A previous patch removed slow-pathing for controller actions with the
> exception of ones that specified "pause".  This commit removes that
> restriction so that no controller actions are slow-pathed.
> 
> Signed-off-by: Justin Pettit 

On second look, I don't have anything more to add.  I guess you could
delete the extra blank line here:

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 1558dd970cdc..98e3d832eb7d 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4494,7 +4494,6 @@ finish_freezing__(struct xlate_ctx *ctx, uint8_t table)
ctx->pause->userdata,
ctx->pause->userdata_len);
 } else {
-
 if (ctx->recirc_update_dp_hash) {
 struct ovs_action_hash *act_hash;
 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [no-slow 5/6] ofproto-dpif: Don't slow-path controller actions.

[Ben Pfaff]

On Thu, Dec 21, 2017 at 02:25:14PM -0800, Justin Pettit wrote:
> Controller actions have become more commonly used for purposes other
> than just making forwarding decisions (e.g., packet logging).  A packet
> that needs to be copied to the controller and forwarded would always be
> sent to ovs-vswitchd to be handled, which could negatively affect
> performance and cause heavier CPU utilization in ovs-vswitchd.
> 
> This commit changes the behavior so that OpenFlow controller actions
> become userspace datapath actions while continuing to let packet
> forwarding and manipulation continue to be handled by the datapath
> directly.
> 
> This patch still slow-paths controller actions with the "pause" flag
> set.  A future patch will stop slow-pathing these pause actions as
> well.
> 
> Signed-off-by: Justin Pettit 

I took a second look at this patch, by request.

The NEWS item doesn't explain what this feature means to users.

It wasn't clear to me whether UACF_DONT_SEND re-implements existing
behavior or introduces a behavioral change.  If it introduces a change,
maybe one of the tutorials (like the Faucet tutorial?) relies on it, so
we might need to change them.

I don't know how many flags you expect.  If it's only one or two, maybe
they should just be "bool"s.  (There's no ABI to freeze here, so they
could be converted to a flag word if they got bigger.)

In xlate_controller_action(), a comment refers to the slowpath meter,
but I think that it should refer to the controller meter.

I wonder whether some of the data in the user_action_cookie for
controller actions should actually be put into the frozen_state.  I
think that all of it other than the recirc_id could actually go in the
frozen_state, but the userdata in particular can have an arbitrary size,
which in extremis might make the datapath action too large and which we
don't really need to copy between the kernel and userspace repeatedly.

The comment on struct user_action_cookie here seems inappropriate, since
I believe that recirc_id will always be nonzero:
uint32_t recirc_id; /* Non-zero if recirc id allocated. */

Thanks,

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

Re: [ovs-dev] [no-slow 4/6] ofproto: Add 'ofproto_uuid' and 'ofp_in_port' to user action cookie.

[Ben Pfaff]

On Thu, Dec 21, 2017 at 02:25:13PM -0800, Justin Pettit wrote:
> Previously, the ofproto instance and OpenFlow port have been derived
> based on the datapath port number.  This change explicitly declares them
> both, which will be helpful in future commits that no longer can depend
> on having a unique datapath port (e.g., a source port that represents
> the controller).
> 
> Signed-off-by: Justin Pettit 

When I applied more scrutiny to this patch, I noticed that the changes
to ofproto-dpif.c and .h aren't needed.

Thanks,

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

Re: [ovs-dev] [PATCH] ofp-actions: Log version, vendor, and type of unknown actions being parsed.

[Ben Pfaff]

On Wed, Jan 03, 2018 at 04:19:17PM -0800, Justin Pettit wrote:
> 
> > On Jan 3, 2018, at 4:11 PM, Ben Pfaff  wrote:
> > 
> > This may help debugging difficult controller problems.
> > 
> > Reported-by: Su Wang 
> > Signed-off-by: Ben Pfaff 
> 
> Acked-by: Justin Pettit 

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

Re: [ovs-dev] [PATCH] ofp-actions: Log version, vendor, and type of unknown actions being parsed.

[Justin Pettit]

> On Jan 3, 2018, at 4:11 PM, Ben Pfaff  wrote:
> 
> This may help debugging difficult controller problems.
> 
> Reported-by: Su Wang 
> Signed-off-by: Ben Pfaff 

Acked-by: Justin Pettit 

--Justin


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

[ovs-dev] [PATCH] ofp-actions: Log version, vendor, and type of unknown actions being parsed.

[Ben Pfaff]

This may help debugging difficult controller problems.

Reported-by: Su Wang 
Signed-off-by: Ben Pfaff 
---
 lib/ofp-actions.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 49e086eee6f3..1d364f98bbd1 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -9221,6 +9221,9 @@ ofpact_decode_raw(enum ofp_version ofp_version,
 }
 }
 
+VLOG_WARN_RL(, "unknown %s action for vendor %#"PRIx32" and "
+ "type %"PRIu16, ofputil_version_to_string(ofp_version),
+ hdrs.vendor, hdrs.type);
 return (hdrs.vendor
 ? OFPERR_OFPBAC_BAD_VENDOR_TYPE
 : OFPERR_OFPBAC_BAD_TYPE);
-- 
2.10.2

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

Re: [ovs-dev] [no-slow 2/6] ofproto-dpif: Reorganize upcall handling.

[Ben Pfaff]

On Thu, Dec 21, 2017 at 02:25:11PM -0800, Justin Pettit wrote:
> - This reduces the number of times upcall cookies are processed.
> - It separate true miss calls from slow-path actions.
> 
> The reorganization will also be useful for a future commit.
> 
> Signed-off-by: Justin Pettit 

I took a second look at this patch, giving it more scrutiny.  I can't
yet explain why this line is deleted.  It seems like ->ufid is still
used in the same way as it was before:

> @@ -813,7 +816,6 @@ recv_upcalls(struct handler *handler)
>  
>  upcall->key = dupcall->key;
>  upcall->key_len = dupcall->key_len;
> -upcall->ufid = >ufid;
>  
>  upcall->out_tun_key = dupcall->out_tun_key;
>  upcall->actions = dupcall->actions;
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [no-slow 1/6] ofproto-dpif: Add ability to look up an ofproto by UUID.

[Ben Pfaff]

On Tue, Jan 02, 2018 at 10:24:21AM -0800, Justin Pettit wrote:
> 
> 
> > On Jan 2, 2018, at 8:40 AM, Ben Pfaff  wrote:
> > 
> > On Thu, Dec 21, 2017 at 02:25:10PM -0800, Justin Pettit wrote:
> >> This will have callers in the future.
> >> 
> >> Signed-off-by: Justin Pettit 
> > 
> > The new comment in struct ofproto_dpif only refers to one of the
> > hmap_nodes.
> > 
> > Acked-by: Ben Pfaff 
> 
> Thanks.  I added a comment.

I took a second look and noticed that all_ofproto_dpifs_by_* could be
static:

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index ab70244396bf..561430c51141 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -186,11 +186,11 @@ COVERAGE_DEFINE(rev_mcast_snooping);
 struct shash all_dpif_backers = SHASH_INITIALIZER(_dpif_backers);
 
 /* All existing ofproto_dpif instances, indexed by ->up.name. */
-struct hmap all_ofproto_dpifs_by_name =
+static struct hmap all_ofproto_dpifs_by_name =
   HMAP_INITIALIZER(_ofproto_dpifs_by_name);
 
 /* All existing ofproto_dpif instances, indexed by ->uuid. */
-struct hmap all_ofproto_dpifs_by_uuid =
+static struct hmap all_ofproto_dpifs_by_uuid =
   HMAP_INITIALIZER(_ofproto_dpifs_by_uuid);
 
 static bool ofproto_use_tnl_push_pop = true;
diff --git a/ofproto/ofproto-dpif.h b/ofproto/ofproto-dpif.h
index 0f7086824f3d..ca7b38b10d19 100644
--- a/ofproto/ofproto-dpif.h
+++ b/ofproto/ofproto-dpif.h
@@ -310,12 +310,7 @@ struct ofproto_dpif {
 uint64_t ams_seqno;
 };
 
-/* All existing ofproto_dpif instances, indexed by ->up.name. */
-extern struct hmap all_ofproto_dpifs_by_name;
 struct ofproto_dpif *ofproto_dpif_lookup_by_name(const char *name);
-
-/* All existing ofproto_dpif instances, indexed by ->uuid. */
-extern struct hmap all_ofproto_dpifs_by_uuid;
 struct ofproto_dpif *ofproto_dpif_lookup_by_uuid(const struct uuid *uuid);
 
 ovs_version_t ofproto_dpif_get_tables_version(struct ofproto_dpif *);

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

[ovs-dev] Habilidades contables para no contadores

[Contabilidad financiera al alcance de todos]

Cifras confiables para una adecuada toma de decisiones 

Habilidades contables para no contadores
24 de enero- CP. Hugo Coca Chávez - 9am-8pm

Toda persona que acuda a este seminario conocerá las principales herramientas 
contables que permitirán entender cómo funciona la contabilidad y cada una de 
sus cuentas principales. Aprenderá a elaborar a partir de la emisión de 
registros contables los principales estados financieros usados en las empresas, 
para a partir de ahí generar la información necesaria y suficiente para tomar 
decisiones de inversión, análisis o financiamiento, entre otras.

BENEFICIOS DE ASISTIR: 

- Obtendrá las bases de contabilidad y conocerá sus alcances.
- Conocerá los sistemas y métodos de registros.
- Entenderá la importancia de la información financiera para generar estados 
financieros que le permitirán tomar decisiones operativas, de inversión y de 
financiamiento.
- Aprenderá a analizar el balance general y el estado de resultados. 

¿Requiere la información a la Brevedad? responda este email con la palabra: 
Contadores + nombre - teléfono - correo.


centro telefónico:018002120744


 


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

Re: [ovs-dev] [no-slow 2/6] ofproto-dpif: Reorganize upcall handling.

[Gregory Rose]

On 1/2/2018 11:42 AM, Justin Pettit wrote:

On Dec 28, 2017, at 3:22 PM, Gregory Rose  wrote:

SFAICT it emulates exactly what the system-traffic.at test 001 does.  And it 
works fine... /shrug.

What distribution, kernel, etc are you using for your check-kmod testing?  I'll 
try to emulate that
exactly and then see if I can get similar results.

I'm using Ubuntu 16.04 with kernel 4.4.0-104-generic.  I sent you a link on our 
Slack channel to the internal tester that runs different OSs.  It fails a few 
of tests, but they're the same ones that fail on master.  (We need to address 
those, but they shouldn't be related to my patches.)

--Justin




Justin,

I have done more testing last night and this morning and have a couple 
of findings.


First, the tests themselves *all* succeed.  However, they are marked as 
failed because of warnings that
occur during OVS_TRAFFIC_VSWITCHD_STOP in system-traffic.at.  If I 
comment out

OVS_TRAFFIC_VSWITCHD_STOP then the test runs successfully.

AT_SETUP([datapath - ping between two ports])
OVS_TRAFFIC_VSWITCHD_START()

AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])

ADD_NAMESPACES(at_ns0, at_ns1)

ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")

NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.2 | 
FORMAT_PING], [0], [dnl

3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
NS_CHECK_EXEC([at_ns0], [ping -s 1600 -q -c 3 -i 0.3 -w 2 10.1.1.2 | 
FORMAT_PING], [0], [dnl

3 packets transmitted, 3 received, 0% packet loss, time 0ms
])
NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.1.1.2 | 
FORMAT_PING], [0], [dnl

3 packets transmitted, 3 received, 0% packet loss, time 0ms
])

dnl OVS_TRAFFIC_VSWITCHD_STOP
AT_CLEANUP

## -- ##
## openvswitch 2.8.90 test suite. ##
## -- ##
  1: datapath - ping between two ports   ok

## - ##
## Test results. ##
## - ##

1 test was successful.

I'm now debugging the OVS_TRAFFIC_VSWITCHD_STOP macro and trying to 
determine what

is causing the problem.  Here are the log messages:

2018-01-03T17:30:52.340Z|00039|netdev_linux|WARN|ovs-p1: removing 
policing failed: No such device
2018-01-03T17:30:52.341Z|00040|ofproto|WARN|br0: cannot get STP status 
on nonexistent port 2
2018-01-03T17:30:52.341Z|00041|ofproto|WARN|br0: cannot get RSTP status 
on nonexistent port 2
2018-01-03T17:30:52.343Z|00042|bridge|INFO|bridge br0: deleted interface 
ovs-p1 on port 2
2018-01-03T17:30:52.346Z|00043|bridge|WARN|could not open network device 
ovs-p1 (No such device)
2018-01-03T17:30:52.360Z|00044|bridge|INFO|bridge br0: deleted interface 
ovs-p0 on port 1
2018-01-03T17:30:52.364Z|00045|bridge|WARN|could not open network device 
ovs-p0 (No such device)
2018-01-03T17:30:52.367Z|00046|bridge|WARN|could not open network device 
ovs-p1 (No such device)


It is the WARNS from the OVS_TRAFFIC_VSWITCHD_STOP part of the test that 
are causing all tests to fail.


Again, I see this on multiple systems.  They are all VMs though so I'm 
wondering if the internal test that

you are referring to was run on bare metal?

Thanks,

- Greg

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

Re: [ovs-dev] [PATCH V2] OF1.5/EXT-334 OXS/Extensible Flow Entry Statistics Support

[Jan Scheurich]

> > >
> > > This Patch provides implementation Existing flow entry statistics are
> > > redefined as standard OXS(OpenFlow Extensible Statistics) fields for
> > > displaying the arbitrary flow stats.The existing Flow Stats were renamed
> > > as Flow Description.
> > >
> > > To support this implementation below messages are newly added
> > >
> > > OFPRAW_OFPT15_FLOW_REMOVED,
> > > OFPRAW_OFPST15_FLOW_REQUEST,
> > > OFPRAW_OFPST15_FLOW_DESC_REQUEST,
> > > OFPRAW_OFPST15_AGGREGATE_REQUEST,
> > > OFPRAW_OFPST15_FLOW_REPLY,
> > > OFPRAW_OFPST15_FLOW_DESC_REPLY,
> > > OFPRAW_OFPST15_AGGREGATE_REPLY,
> > >
> > > The current commit adds support for the new feature in flow statistics
> > > multipart messages,aggregate multipart messages and OXS support for flow
> > > removal message, individual flow description messages.
> > >
> > > "ovs-ofctl dump-flows" needs to be provided with the arbitrary OXS fields
> > > for displaying the desired flow stats.
> > >
> > > Below are Commands to display OXS stats field wise
> > >
> > > Flow Statistics Multipart
> > > ovs-ofctl dump-flows -O OpenFlow15  idle_time
> > > ovs-ofctl dump-flows -O OpenFlow15  packet_count
> > > ovs-ofctl dump-flows -O OpenFlow15  byte_count
> >
> > This would break backward compatibility for one of the most frequently used 
> > OVS CLI commands. Why don't you introduce a new
> command such as "ovs-ofctl dump-flow-stats" for the new OXS stats?
> 
> I think you might be misinterpreting the meaning here.  It doesn't
> appear to break compatibility, at least not in a major way, since it
> doesn't do a lot of updates to the tests that would otherwise be
> required.

Perhaps I am missing the point of some of these changes. I understand that OVS 
needs to support the new extensible OXS flow stats syntax in OpenFlow 1.5 and 
the differentiated MP request/reply pairs OFPMP_FLOW_DESC (replacing the former 
OFPMP_FLOW) and OFPMP_FLOW_STATS (just fetching flow stats per flow w/o the 
rest of the flow data).

But I don't understand why this should have any impact on the existing CLI 
command "ovs-ofctl dump-flows" and its output. This tool expressly fetches and 
displays the complete flow dump from OVS, including match, instructions/actions 
and statistics. When using OF 1.5 it should transparently apply OFPMP_FLOW_DESC 
MP request/reply to fetch the data, up to OF 1.4 it should use the original 
OFPMP_FLOW.

I can't see any ovs-ofctl use case that would justify the use of the new 
OFPMP_FLOW_STATS request/reply. The removed data in the reply compared to the 
full flow description are mainly the instructions, the full match is still 
there to identify each flow. So cutting down the transferred data volume can 
hardly be the reason (Note, this may still be different for real OF 1.5 
controllers).

If you believe we should have an ovs-ofctl command anyhow, e.g. for testing 
purposes, I suggest to introduce a new command or add an option to dump-flows 
to force use of this particular MP message. The output would be limited to flow 
match and stats in that case.

The new command to dump aggregate flow stats is of course a welcome addition. 
It should work irrespectively of the used OpenFlow version with the 
OFPMP_AGGREGATE_STATS primitive using classic flow stats prior to OF 1.5 and 
OXS flow stats in OF 1.5.

All in all I am NACK-ing this patch as it stands.

Regards, Jan

BTW: I have played a bit with the patch. The existing ovs-ofctl test cases 
appear to not break because the changes described in the commit message and the 
documentation are not effective. The legacy command format "ovs-ofctl 
dump-flows -O OpenFlow15  []" still produces the complete flow 
dump including instructions/actions:

# ovs-ofctl -Oopenflow15 dump-flow-desc br0
OFPST_FLOW_DESC reply (OF1.5) (xid=0x2):
 cookie=0x0, duration=90.515s, table=0, n_packets=0, n_bytes=0, reset_counts 
idle_age=840, hard_age=32766, in_port="br0-ns1" actions=output:"br0-ns2"
 cookie=0x0, duration=90.507s, table=0, n_packets=0, n_bytes=0, reset_counts 
idle_age=840, hard_age=32766, in_port="br0-ns2" actions=output:"br0-ns1"
 cookie=0x0, duration=850.125s, table=0, n_packets=2, n_bytes=180, 
idle_age=849, hard_age=32766, priority=0 actions=NORMAL

# ovs-ofctl -Oopenflow15 dump-flows br0
 cookie=0x0, duration=94.634s, table=0, n_packets=0, n_bytes=0, idle_age=844, 
hard_age=0, in_port="br0-ns1" actions=output:"br0-ns2"
 cookie=0x0, duration=94.626s, table=0, n_packets=0, n_bytes=0, idle_age=844, 
hard_age=0, in_port="br0-ns2" actions=output:"br0-ns1"
 cookie=0x0, duration=854.244s, table=0, n_packets=2, n_bytes=180, 
idle_age=853, hard_age=0, priority=0 actions=NORMAL

The only difference appears to be that the flow property reset_counts is 
missing and that hard_age seems corrupt in the new ovs-ofctl dump-flow-desc.

Furthermore, specifying any OXS field at the end of ovs-ofctl dump-flows 
 is without effect:

# ovs-ofctl -Oopenflow15 dump-flows br0 duration
 cookie=0x0, duration=173.536s, table=0, n_packets=0, 

Re: [ovs-dev] Donation!!!

[Maria-Elisabeth]

I am Maria-Elisabeth Schaeffler, a German citizen, wife of late Georg W. 
Schaeffler, 75 years old. You can see here: 
en.wikipedia.org/wiki/Maria-Elisabeth_Schaeffler I intend to give to you a 
portion of my Wealth as a free-will financial donation to you. Respond now to 
partake.

Regards,
Maria-Elisabeth Schaeffler.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Donation!!!

[Maria-Elisabeth]

I am Maria-Elisabeth Schaeffler, a German citizen, wife of late Georg W. 
Schaeffler, 75 years old. You can see here: 
en.wikipedia.org/wiki/Maria-Elisabeth_Schaeffler I intend to give to you a 
portion of my Wealth as a free-will financial donation to you. Respond now to 
partake.

Regards,
Maria-Elisabeth Schaeffler.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [OVSDB-TLS] Ssl handshake fail

[A Vamsikrishna]

Hi All ,


I am following below wiki for OVSDB-TLS communication:

https://wiki.opendaylight.org/view/OVSDB_Integration:TLS_Communication

Steps followed:

I have copied ctl.jks and truststore.jks from my ubuntu to config/ssl folder

made true in aaa-cert-config.xml

made use-ssl = true in  org.opendaylight.ovsdb.library.cfg

sudo ovs-vsctl --bootstrap set-ssl /etc/openvswitch/sc-privkey.pem  
/etc/openvswitch/sc-cert.pem /var/lib/openvswitch/pki/controllerca/cacert.pem

sudo ovs-vsctl set-manager ssl:192.168.56.1:6640


I am seeing below error in ODL logs:

D: [id: 0x78b62606, L:/192.168.56.1:6640 - R:/192.168.56.102:41618]
-01-03 14:31:42,261 | ERROR | assiveConnServ-3 | OvsdbConnectionService 
  | 380 - org.opendaylight.ovsdb.library - 1.6.0.SNAPSHOT | Ssl handshake fail. 
channel [id: 0x78b62606, L:/192.168.56.1:6640 ! R:/192.168.56.102:41618]


And I am not seeing the SSL connection on OVS :

stack@ubuntu:/etc/openvswitch$ sudo ovs-vsctl show
3dfb73ad-1ea2-46ed-b749-ba55a1ee912f
Manager "ssl:192.168.56.1:6640"
Bridge br-ex
Controller "ssl:192.168.56.1:6653"
   Port br-ex
Interface br-ex
type: internal
ovs_version: "2.6.1"
stack@ubuntu:/etc/openvswitch$
stack@ubuntu:/etc/openvswitch$

stack@ubuntu:/var/log/openvswitch$
stack@ubuntu:/var/log/openvswitch$ tail -5 ovsdb-server.log
2018-01-02T18:20:05.920Z|07252|reconnect|INFO|ssl:192.168.56.1:6640: waiting 8 
seconds before reconnect
2018-01-02T18:20:13.921Z|07253|reconnect|INFO|ssl:192.168.56.1:6640: 
connecting...
2018-01-02T18:20:13.928Z|07254|stream_ssl|WARN|SSL_connect: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
2018-01-02T18:20:13.928Z|07255|reconnect|INFO|ssl:192.168.56.1:6640: connection 
attempt failed (Protocol error)
2018-01-02T18:20:13.928Z|07256|reconnect|INFO|ssl:192.168.56.1:6640: waiting 8 
seconds before reconnect
stack@ubuntu:/var/log/openvswitch$
stack@ubuntu:/var/log/openvswitch$

Can you please help me out in fixing this issue ?

Attaching the config files changed & Please let me know if you need any info to 
help on this issue.

Thanks,
Vamsi
#
#   Boot Time Configuration 
*
#   Config knob changes will require controller restart 
*
#

#Ovsdb plugin's (OVS, HwVtep) support both active and passive connections. 
OVSDB library by
#default listens on port 6640 for switch initiated connection. Please use 
following config
#knob for changing this default port.
ovsdb-listener-port = 6640

#This flag will be enforced across all the connection's (passive and active) if 
set to true
use-ssl = true

#Set Json Rpc decoder max frame length value. If the OVSDB node contains large 
configurations
#that can cause connection related issue while reading the configuration from 
the OVSDB node
#database. Increasing the max frame lenge helps resolve the issue. Please see 
following bug
#report for more details ( https://bugs.opendaylight.org/show_bug.cgi?id=2732 &
#https://bugs.opendaylight.org/show_bug.cgi?id=2487). Default value set to 
10.
json-rpc-decoder-max-frame-length = 10


#
#   Run Time Configuration  
*
#   Config knob changes doesn't require controller resart   
*
#
#Timeout value (in millisecond) after which OVSDB rpc task will be 
cancelled.Default value is
#set to 1000ms, please uncomment and override the value if requires.Changing 
the value don't
#require controller restart.
ovsdb-rpc-task-timeout = 1000

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

Re: [ovs-dev] [PATCH] dpif-netdev: Refactor datapath flow cache

[Fischetti, Antonio]

Thanks William for your comments.
Some replies inline.

-Antonio

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of William Tu
> Sent: Wednesday, January 3, 2018 1:32 AM
> To: Wang, Yipeng1 
> Cc: d...@openvswitch.org; Tai, Charlie 
> Subject: Re: [ovs-dev] [PATCH] dpif-netdev: Refactor datapath flow cache
> 
> Hi Yipeng,
> 
> Thanks for the reply.
> 
> On Tue, Jan 2, 2018 at 10:45 AM, Wang, Yipeng1 
> wrote:
> > Hi, William,
> >
> > Thanks for the comment. You are right. If the RSS hash does not
> consider the fields that matter, the situation you mentioned could
> happen.
> >
> > There are two design options for CD as you may find, when the
> signatures collide, we could either replace the existing entry (the
> current design), or still insert the entry into the cache. If we chose
> the second design, I think the situation you mentioned could be
> alleviated. We chose the first one mostly because of its simplicity and
> speed for the hit case. For example, if we allow multiple entries with
> the same signature stay in one bucket, then the lookup function needs to
> iterate all the entries in a bucket to find all the matches (for scalar
> version). And additional loops and variables are required to iterate all
> the matches. We expected to see some percentage of throughput influence
> for cache hit cases.
> 
> I think the cost of having multiple entries with the same signature is
> too high, basically the CD lookup time increase from O(1) to O(n),
> where n is the bucket size.
> 
> >
> > But as you suggested, if the situation you mentioned is very common in
> real use cases, and RSS does not consider the vlan id, we could choose
> to not overwrite. Another option is to reduce the insertion rate (or
> turn off CD) as CD's miss ratio is high (this is similar to the EMC
> conditional insertion). Then the 100% miss ratio case can be alleviated.
> This is an easy change for CD. Or we could use software hash together
> with RSS to consider vlan tag, this could benefit EMC too I guess.

[Antonio] Hmm, I expect that adding some software hash computation would
kill the performance.


> >
> > There are many design options and trade-offs but we eventually want to
> have a design that work for most use cases.
> 
> I don't have any traffic dataset, but I would assume it's pretty
> common that multiple tunneling protocols are deployed. That said, the
> RSS hash, which is based on outer-header 5-tuple, might have little
> difference and cause high collision when flows try to match fields
> such as vxlan vni, or geneve metadata field. Matching the inner
> packets requires recirculation, so the rss of inner 5-tuple come from
> cpu, and I guess the CD's hit rate is higher for inner packets.
> 
> The DFC (datapath flow cache) patch seems to have similar drawbacks?

[Antonio] This is a general issue due to the fact that RSS hash is 
computed on a pre-defined 5-tuple of the outer header. So it's not
specific to the CD or the DFC implementations. For sure it affects
the EMC.


> The fundamental issue seems to be the choice of hash function (RSS),
> which only covers 5-tuple. Can we configure the rss hash to hash on
> more fields when subtables uses more than 5-tuple?

[Antonio] 
> 
> Regards,
> William
> ___
> 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