[ovs-dev] Test

[Corey Anderson via dev]

Corey Anderson +1(660)522-0283
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Test

[Corey Anderson via dev]

Corey Anderson +1(660)522-0283
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Test Mail

[svc . eng . git-patch]

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

[ovs-dev] test

[Moshe Levi]

Senior Manager leading OpenStack and Kubernetes
Cell Phone +972-55-66032227

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

[ovs-dev] Test email. Please, ignore.

[Ilya Maximets]

Please ignore.  Testing whether mail list alive.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] test

[home]

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

[ovs-dev] test

[Ben Pfaff]

Timothy Redaelli pointed out that ovs-dev@ might be rewriting "From"
addresses.  Let's see.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Test result. RE: [patch v1] conntrack-tcp: Handle tcp session reuse.

[Darrell Ball]

Thanks much for testtng Neo


On Sun, Mar 18, 2018 at 1:30 AM, Yangxiaoliang (Neo) <
david.yangxiaoli...@huawei.com> wrote:

> Hi  Darrell,
>
>
>
> Sorry for delay.
>
>
>
> During the last week, I have tried sveral live migration script, and found
> that
>
>
>
> 1. sctipt1: Tcp stream will stop only 2 seconds, then the stream is ok. (
> 8Gbps… 0Gbps .<- 0Gbps for 2 seconds ->….0Gbps … 8Gbps)
>
>   #Migrate VM to the destination
>
>   #Then flush all conntrack on the destination: ovs-appctl
> dpctl/flush-conntrack netdev@ovs-netdev
>
>
>
> 2. Use the original script (listed as below) to test. The TCP stream will
> stop for more 100 secons.
>
>
>
> Reply to your questions: ==
>
> 1/ How you carry out the migration ?
>
> I have two servers (9.16.1.111 and 9.16.1.114) with centos 7.3 installed.
> Two VMs were running on 9.16.1.111 at the beginning.
>
> Migrate VM1( iperf3 client) between 9.16.1.111 and 9.16.1.114.
>
>
>
> Live migration script(This is the original script):
>
>   // 9.16.1.111 -> 9.16.1.114
>
>   #virsh migrate vm1 qemu+tcp://9.16.1.114/system
>
>   // Clear conntrack entry on 111 host to prepare for next migration
>
>   #ovs-appctl dpctl/flush-conntrack netdev@ovs-netdev zone=11 (zone 11 is
> configured on 9.16.1.111 for vm1: table=14,priority=6,ip
> actions=ct(table=16,zone=11))
>
>
>
>   //9.16.1.114 -> 9.16.1.111
>
>   #virsh migrate vm1 qemu+tcp://9.16.1.111/system
>
>   #ovs-appctl dpctl/flush-conntrack netdev@ovs-netdev zone=21(zone 21 is
> configured on 9.16.1.114 for vm1: table=14,priority=6,ip
> actions=ct(table=16,zone=21))
>


If I understand correctly, the VM is migrated away and then back to the
same HV, so in the case, it does not move zone in the final state
w.r.t the start state and you are essentially simulating dropping a bunch of
packets between being on "HV X" and then back to the same "HV X".

I see you did a flush on the zone (somehow I missed that b4), so we have a
new connection being setup in conntrack in this case as well.
I did not see any resets but it looks like the connection gets re-setup
anyways after a period of 100 seconds.
I will do another parse of the packet traces to be sure.

However, with the zone flush, I would expect to hit the new connection case
when back to same HV and zone. This means the increased
skew allowed with the patch should apply here as well.  In the previous
test, you had the full context including the code traces you saw,
but those are missing in the second test. Could you provide those so we can
confirm which case we are hitting in this second test ?

Thanks Darrell




>
>
> 2/ The packets and their timing seen coming the endpoints; the rst packets
> are of particular interest.
>
> The packets and more information are list as below:
>
>
>
>  software version 
>
> ovs_version: "2.7.3"
>
> libvirt 3.2.0
>
> QEMU emulator version 2.8.1.1(25.124)
>
> dpdk 16.11
>
>
>
>  ovs-ofctl show br-tap0 (9.16.1.111 has the same br-tap0 with
> 9.16.1.114) 
>
> OFPT_FEATURES_REPLY (xid=0x2): dpid:90e2ba69cd11
>
> n_tables:254, n_buffers:0
>
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>
> 1(hnic0): addr:e6:8d:45:ae:05:ce // connected to linux bridge(in)
>
>  config: 0
>
>  state:  0
>
>  current:10MB-FD COPPER
>
>  speed: 10 Mbps now, 0 Mbps max
>
> 2(hnic1): addr:b6:d1:cd:16:ad:51 // connected to linux bridge(out)
>
>  config: 0
>
>  state:  0
>
>  current:10MB-FD COPPER
>
>  speed: 10 Mbps now, 0 Mbps max
>
> 3(tap0): addr:a6:f7:0b:73:1a:7a
>
>  config: 0
>
>  state:  0
>
>  speed: 0 Mbps now, 0 Mbps max
>
> 4(p-tap0-int): addr:5a:26:31:7b:24:1d
>
>  config: 0
>
>  state:  0
>
>  speed: 0 Mbps now, 0 Mbps max
>
> LOCAL(br-tap0): addr:90:e2:ba:69:cd:11
>
>  config: 0
>
>  state:  0
>
>  current:10MB-FD COPPER
>
>  speed: 10 Mbps now, 0 Mbps max
>
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>
>
>
>  Linux bridge 
>
> bridge name bridge id   STP enabled interfaces
>
> br-linux1   8000.b6d1cd16ad51   no  hnic0
>
> hnic1
>
>
>
>  ovs-ofctl dump-flows br-tap0 (on host 9.16.1.111) 
>
> table=0,priority=2,in_port=1 actions=resubmit(,2)
>
> table=0,priority=2,in_port=4 actions=resubmit(,2)
>
> table=0,priority=0 actions=drop
>
> table=0,priority=1 actions=resubmit(,10)
>
> table=1,priority=0 actions=resubmit(,14)
>
> table=2,priority=0 actions=resubmit(,4)
>
> table=4,priority=0 actions=resubmit(,14)
>
> table=10,priority=2,arp actions=resubmit(,12)
>
> table=10,priority=1,dl_src=90:E2:BA:69:CD:11 actions=resubmit(,1)
>
> table=10,priority=0 actions=drop
>
> 

Re: [ovs-dev] Test result. RE: [patch v1] conntrack-tcp: Handle tcp session reuse.

[Yangxiaoliang (Neo)]

Hi  Darrell,

Sorry for delay.

During the last week, I have tried sveral live migration script, and found that

1. sctipt1: Tcp stream will stop only 2 seconds, then the stream is ok. ( 
8Gbps… 0Gbps .<- 0Gbps for 2 seconds ->….0Gbps … 8Gbps)
  #Migrate VM to the destination
  #Then flush all conntrack on the destination: ovs-appctl 
dpctl/flush-conntrack netdev@ovs-netdev

2. Use the original script (listed as below) to test. The TCP stream will stop 
for more 100 secons.

Reply to your questions: ==
1/ How you carry out the migration ?
I have two servers (9.16.1.111 and 9.16.1.114) with centos 7.3 installed. Two 
VMs were running on 9.16.1.111 at the beginning.
Migrate VM1( iperf3 client) between 9.16.1.111 and 9.16.1.114.

Live migration script(This is the original script):
  // 9.16.1.111 -> 9.16.1.114
  #virsh migrate vm1 qemu+tcp://9.16.1.114/system
  // Clear conntrack entry on 111 host to prepare for next migration
  #ovs-appctl dpctl/flush-conntrack netdev@ovs-netdev zone=11 (zone 11 is 
configured on 9.16.1.111 for vm1: table=14,priority=6,ip 
actions=ct(table=16,zone=11))

  //9.16.1.114 -> 9.16.1.111
  #virsh migrate vm1 qemu+tcp://9.16.1.111/system
  #ovs-appctl dpctl/flush-conntrack netdev@ovs-netdev zone=21(zone 21 is 
configured on 9.16.1.114 for vm1: table=14,priority=6,ip 
actions=ct(table=16,zone=21))

2/ The packets and their timing seen coming the endpoints; the rst packets are 
of particular interest.
The packets and more information are list as below:

 software version 
ovs_version: "2.7.3"
libvirt 3.2.0
QEMU emulator version 2.8.1.1(25.124)
dpdk 16.11

 ovs-ofctl show br-tap0 (9.16.1.111 has the same br-tap0 with 9.16.1.114) 

OFPT_FEATURES_REPLY (xid=0x2): dpid:90e2ba69cd11
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(hnic0): addr:e6:8d:45:ae:05:ce // connected to linux bridge(in)
 config: 0
 state:  0
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
2(hnic1): addr:b6:d1:cd:16:ad:51 // connected to linux bridge(out)
 config: 0
 state:  0
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
3(tap0): addr:a6:f7:0b:73:1a:7a
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
4(p-tap0-int): addr:5a:26:31:7b:24:1d
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
LOCAL(br-tap0): addr:90:e2:ba:69:cd:11
 config: 0
 state:  0
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

 Linux bridge 
bridge name bridge id   STP enabled interfaces
br-linux1   8000.b6d1cd16ad51   no  hnic0
hnic1

 ovs-ofctl dump-flows br-tap0 (on host 9.16.1.111) 
table=0,priority=2,in_port=1 actions=resubmit(,2)
table=0,priority=2,in_port=4 actions=resubmit(,2)
table=0,priority=0 actions=drop
table=0,priority=1 actions=resubmit(,10)
table=1,priority=0 actions=resubmit(,14)
table=2,priority=0 actions=resubmit(,4)
table=4,priority=0 actions=resubmit(,14)
table=10,priority=2,arp actions=resubmit(,12)
table=10,priority=1,dl_src=90:E2:BA:69:CD:11 actions=resubmit(,1)
table=10,priority=0 actions=drop
table=12,priority=3,arp,dl_src=90:E2:BA:69:CD:11,arp_spa=194.168.100.11,arp_sha=90:E2:BA:69:CD:11
 actions=resubmit(,1)
table=12,priority=2,arp actions=drop
table=14,priority=10,icmp actions=resubmit(,18)
table=14,priority=6,ip actions=ct(table=16,zone=11)
table=14,priority=0 actions=resubmit(,20)
table=14,priority=20,ip,ip_frag=yes,actions=resubmit(,18)
table=16,priority=20,ct_state=+est+trk,ip actions=resubmit(,20)
table=16,priority=15,ct_state=+rel+trk,ip actions=resubmit(,20)
table=16,priority=10,ct_mark=0x8000/0x8000,udp actions=resubmit(,20)
table=16,priority=5,ct_state=+new+trk,ip,in_port=3 actions=resubmit(,18)
table=16,priority=5,ct_state=+new+trk,ip,in_port=4 actions=resubmit(,18)
table=16,priority=5,ct_state=+new+trk,ip,in_port=2 
actions=ct(commit,zone=11,exec(load:0x1->NXM_NX_CT_MARK[31])),output:4
table=16,priority=5,ct_state=+new+trk,ip,in_port=1 
actions=ct(commit,zone=11,exec(load:0x1->NXM_NX_CT_MARK[31])),output:3
table=18,priority=0,in_port=3 actions=output:1
table=18,priority=0,in_port=2 actions=output:4
table=18,priority=0,in_port=4 actions=output:2
table=18,priority=0,in_port=1 actions=output:3
table=20,priority=10,in_port=3 actions=output:4
table=20,priority=10,in_port=4 actions=output:3
table=20,priority=1 actions=resubmit(,18)

 ovs-ofctl dump-flows br-tap0 (on host 9.16.1.114) 
table=0,priority=2,in_port=1 actions=resubmit(,2)
table=0,priority=2,in_port=4 actions=resubmit(,2)
table=0,priority=0 actions=drop
table=0,priority=1 actions=resubmit(,10)

Re: [ovs-dev] Test result. RE: [patch v1] conntrack-tcp: Handle tcp session reuse.

[Darrell Ball]

On Tue, Mar 6, 2018 at 5:23 PM, Yangxiaoliang (Neo) <
david.yangxiaoli...@huawei.com> wrote:

> Hi Darrell,
>
> I have tested VM migration with this patch for several times. And this
> patch can avoid stopping the TCP stream,


Thanks for testing and reporting Neo



> but the issue is that the TCP stream will suspend for  a big number of
> seconds after migration ( for example, more than 100 seconds on 8Gbps). I
> think users will not be satisfied this issue.


Thanks, could you please report:
1/ How you carry out the migration ?
2/ The packets and their timing seen coming the endpoints; the rst packets
are of particular interest.



>
> Can we enlarge the range that is saved by sequence tracking to be more
> permissive to decrease the time.


The problem with enlarging the range is the common case becomes too
permissive and we loose the benefit of sequence tracking.



> Or maybe in the future we will solve this issue completely, for now it's
> not recommended to migrate VM with a big network throughput. Or any other
> idea ?


> Thanks.
>
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-bounces@
> openvswitch.org] On Behalf Of Darrell Ball
> Sent: Thursday, March 01, 2018 3:26 PM
> To: dlu...@gmail.com; d...@openvswitch.org
> Subject: [ovs-dev] [patch v1] conntrack-tcp: Handle tcp session reuse.
>
> Fix tcp sequence tracking for session reuse cases.  This can happen, for
> example by doing VM migration, where sequence tracking needs to be more
> permissive.  The solution is to be more permissive for session restart and
> session start only.  We don't differentiate session start here where we
> could be more strict, although we could, because the gain in protection is
> almost zero and the code modularity would be lessened and code complexity
> increased.
> This issue originates in release 2.7.
>
> Signed-off-by: Darrell Ball 
> ---
>  lib/conntrack-tcp.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/lib/conntrack-tcp.c b/lib/conntrack-tcp.c index
> 04460c3..a0ddd65 100644
> --- a/lib/conntrack-tcp.c
> +++ b/lib/conntrack-tcp.c
> @@ -160,7 +160,6 @@ tcp_conn_update(struct conn *conn_, struct
> conntrack_bucket *ctb,
>  uint16_t win = ntohs(tcp->tcp_winsz);
>  uint32_t ack, end, seq, orig_seq;
>  uint32_t p_len = tcp_payload_length(pkt);
> -int ackskew;
>
>  if (tcp_invalid_flags(tcp_flags)) {
>  return CT_UPDATE_INVALID;
> @@ -195,11 +194,11 @@ tcp_conn_update(struct conn *conn_, struct
> conntrack_bucket *ctb,
>   */
>
>  orig_seq = seq = ntohl(get_16aligned_be32(>tcp_seq));
> +bool check_ackskew = true;
>  if (src->state < CT_DPIF_TCPS_SYN_SENT) {
>  /* First packet from this end. Set its state */
>
>  ack = ntohl(get_16aligned_be32(>tcp_ack));
> -
>  end = seq + p_len;
>  if (tcp_flags & TCP_SYN) {
>  end++;
> @@ -232,6 +231,7 @@ tcp_conn_update(struct conn *conn_, struct
> conntrack_bucket *ctb,
>  if (src->seqhi == 1
>  || SEQ_GEQ(end + MAX(1, dst->max_win << dws),
> src->seqhi)) {
>  src->seqhi = end + MAX(1, dst->max_win << dws);
> +check_ackskew = false;
>  }
>  if (win > src->max_win) {
>  src->max_win = win;
> @@ -265,7 +265,13 @@ tcp_conn_update(struct conn *conn_, struct
> conntrack_bucket *ctb,
>  end = seq;
>  }
>
> -ackskew = dst->seqlo - ack;
> +int ackskew;
> +if (check_ackskew) {
> +ackskew = dst->seqlo - ack;
> +} else {
> +ackskew = 0;
> +}
> +
>  #define MAXACKWINDOW (0x + 1500)/* 1500 is an arbitrary fudge
> factor */
>  if (SEQ_GEQ(src->seqhi, end)
>  /* Last octet inside other's window space */
> --
> 1.9.1
>
> ___
> 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] Test result. RE: [patch v1] conntrack-tcp: Handle tcp session reuse.

[Yangxiaoliang (Neo)]

Hi Darrell,

I have tested VM migration with this patch for several times. And this patch 
can avoid stopping the TCP stream, but the issue is that the TCP stream will 
suspend for  a big number of seconds after migration ( for example, more than 
100 seconds on 8Gbps).  

I think users will not be satisfied this issue. Can we enlarge the range that 
is saved by sequence tracking to be more permissive to decrease the time. Or 
maybe in the future we will solve this issue completely, for now it's not 
recommended to migrate VM with a big network throughput. Or any other idea ?

Thanks.

-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
On Behalf Of Darrell Ball
Sent: Thursday, March 01, 2018 3:26 PM
To: dlu...@gmail.com; d...@openvswitch.org
Subject: [ovs-dev] [patch v1] conntrack-tcp: Handle tcp session reuse.

Fix tcp sequence tracking for session reuse cases.  This can happen, for 
example by doing VM migration, where sequence tracking needs to be more 
permissive.  The solution is to be more permissive for session restart and 
session start only.  We don't differentiate session start here where we could 
be more strict, although we could, because the gain in protection is almost 
zero and the code modularity would be lessened and code complexity increased.
This issue originates in release 2.7.

Signed-off-by: Darrell Ball 
---
 lib/conntrack-tcp.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/conntrack-tcp.c b/lib/conntrack-tcp.c index 04460c3..a0ddd65 
100644
--- a/lib/conntrack-tcp.c
+++ b/lib/conntrack-tcp.c
@@ -160,7 +160,6 @@ tcp_conn_update(struct conn *conn_, struct conntrack_bucket 
*ctb,
 uint16_t win = ntohs(tcp->tcp_winsz);
 uint32_t ack, end, seq, orig_seq;
 uint32_t p_len = tcp_payload_length(pkt);
-int ackskew;
 
 if (tcp_invalid_flags(tcp_flags)) {
 return CT_UPDATE_INVALID;
@@ -195,11 +194,11 @@ tcp_conn_update(struct conn *conn_, struct 
conntrack_bucket *ctb,
  */
 
 orig_seq = seq = ntohl(get_16aligned_be32(>tcp_seq));
+bool check_ackskew = true;
 if (src->state < CT_DPIF_TCPS_SYN_SENT) {
 /* First packet from this end. Set its state */
 
 ack = ntohl(get_16aligned_be32(>tcp_ack));
-
 end = seq + p_len;
 if (tcp_flags & TCP_SYN) {
 end++;
@@ -232,6 +231,7 @@ tcp_conn_update(struct conn *conn_, struct conntrack_bucket 
*ctb,
 if (src->seqhi == 1
 || SEQ_GEQ(end + MAX(1, dst->max_win << dws), src->seqhi)) {
 src->seqhi = end + MAX(1, dst->max_win << dws);
+check_ackskew = false;
 }
 if (win > src->max_win) {
 src->max_win = win;
@@ -265,7 +265,13 @@ tcp_conn_update(struct conn *conn_, struct 
conntrack_bucket *ctb,
 end = seq;
 }
 
-ackskew = dst->seqlo - ack;
+int ackskew;
+if (check_ackskew) {
+ackskew = dst->seqlo - ack;
+} else {
+ackskew = 0;
+}
+
 #define MAXACKWINDOW (0x + 1500)/* 1500 is an arbitrary fudge factor */
 if (SEQ_GEQ(src->seqhi, end)
 /* Last octet inside other's window space */
--
1.9.1

___
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] test

[Miguel Angel Ajo Pelayo]

ACK. It worked for me.

On Mon, Jan 29, 2018 at 9:55 PM Ben Pfaff  wrote:

> I've heard that there are problems with the mailing list this morning,
> so here's a test email.
> ___
> 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] test

[Ben Pfaff]

I've heard that there are problems with the mailing list this morning,
so here's a test email.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Test

[Nandan Kulkarni]

Hi there,

This email is to test OVS dev ML.

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