Re: [ovs-dev] [PATCH 3/3] tunnel: Add ofproto/list-tunnels command for troubleshooting.
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(&once)) { fat_rwlock_init(&rwlock); +unixctl_command_register("ofproto/list-tunnels", "", 0, 0, + tnl_unixctl_list, NULL); ovsthread_once_done(&once); } } @@ -318,7 +326,7 @@ tnl_port_receive(const struct flow *flow) OVS_EXCLUDED(rwlock) if (!VLOG_DROP_DBG(&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(&ds, "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(&tnl_port->match, &ds); +tnl_match_fmt(&tnl_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(&ds, ", out_key="); +ds_put_cstr(ds, ", out_key="); if (!cfg->out_key_present) { -ds_put_cstr(&ds, "none"); +ds_put_cstr(ds, "none"); } else if (cfg->out_key_flow) { -ds_put_cstr(&ds, "flow"); +ds_put_cstr(ds, "flow"); } else { -ds_put_format(&ds, "%#"PRIx64, ntohll(cfg->out_key)); +ds_put_format(ds, "%#"PRIx64, ntohll(cfg->out_key)); } } if (cfg->ttl_inherit) { -ds_put_cstr(&ds, ", ttl=inherit"); +ds_put_cstr(ds, ", ttl=inherit"); } else { -ds_put_format(&ds, ", ttl=%"PRIu8, cfg->ttl); +ds_put_format(ds, ", ttl=%"PRIu8, cfg->ttl); } if (cfg->tos_inherit) { -ds_put_cstr(&ds, ", tos=inherit"); +ds_put_cstr(ds, ", tos=inherit"); } else if (cfg->tos) { -
Re: [ovs-dev] [PATCH v2] openvswitch: Trim off padding before L3+ netfilter processing
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, >> /* The conntrack module expects to be working at L3. */ >>
Re: [ovs-dev] [no-slow 6/6] ofproto-dpif: Don't slow-path controller actions with pause.
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.
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.
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.
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.
> 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.
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(&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.
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 = &dupcall->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.
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(&all_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(&all_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(&all_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
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.
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
> > > > > > 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, n_
Re: [ovs-dev] Donation!!!
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!!!
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
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
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