[ovs-discuss] 答复: [ovs-dev] Why are iperf3 udp packets out of order in OVS DPDK case?

[杨�D]

Ian, here is my configuration, sorry I can't show flow details because it is
confidential. By the way, iperf3 tcp is ok and performance is good enough,
I'm really confused, udp was ok but tcp were not ok in my VM environment
before, it broke my sense :-), I can avoid out of order issue if I control
udp bandwidth to 1G by -b 1G.

The traffic doesn't reach vlan ports, this ovs node acts as a NAT gateway,
it steers the traffic back and forth between iperf3 client and server,
iperf3 client and server are other physical machines which are IP reachable
for this ovs node.

$ sudo ovs-vsctl show
4135a1ed-2bcb-449a-bb07-ed907d6c265f
Bridge br-int
Port br-int
Interface br-int
type: internal
Port "vlan151"
tag: 151
Interface "vlan151"
type: internal
Port "vlan12"
tag: 12
Interface "vlan12"
type: internal
Port "dpdk0"
Interface "dpdk0"
type: dpdk
options: {dpdk-devargs=":07:00.1", n_rxq="7"}
Port "vlan11"
tag: 11
Interface "vlan11"
type: internal
Port "vlan153"
tag: 153
Interface "vlan153"
type: internal
ovs_version: "2.11.1"
$ sudo ovs-vsctl list Open_vSwitch
_uuid   : 4135a1ed-2bcb-449a-bb07-ed907d6c265f
bridges : [778ea619-496c-417c-ac08-92d7784f1660]
cur_cfg : 46
datapath_types  : [netdev, system]
db_version  : "7.16.1"
dpdk_initialized: true
dpdk_version: "DPDK 18.11.1"
external_ids: {hostname="eip01", rundir="/var/run/openvswitch",
system-id="f331dcc0-8ae7-4f2b-aa30-10ae4c8a7b11"}
iface_types : [dpdk, dpdkr, dpdkvhostuser, dpdkvhostuserclient,
erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt,
system, tap, vxlan]
manager_options : []
next_cfg: 46
other_config: {dpdk-init="true", dpdk-socket-mem="4096",
pmd-cpu-mask="0xfe"}
ovs_version : "2.11.1"
ssl : []
statistics  : {}
system_type : ubuntu
system_version  : "16.04"
inspur@eip01:~$ sudo ovs-vsctl -- get Interface dpdk0 mtu_request
9000

-邮件原件-
发件人: Stokes, Ian [mailto:ian.sto...@intel.com] 
发送时间: 2019年8月27日 18:02
收件人: Yi Yang (杨�D)-云服务集团 ;
ovs-discuss@openvswitch.org
抄送: ovs-...@openvswitch.org
主题: Re: [ovs-dev] Why are iperf3 udp packets out of order in OVS DPDK
case?



On 8/27/2019 9:35 AM, Yi Yang (杨�D)-云服务集团 wrote:
> Hi, all
> 
>   
> 
> I’m doing experiments with OVS and OVS DPDK, only one bridge is there, 
> ports and flows are same for OVS and OVS DPDK, in OVS case, everything 
> works well, but in OVS DPDK case, iperf udp performance data are very 
> poor, udp packets are out of order, I have limited MTU and send buffer 
> by �Cl1410 �C M1410, anybody knows why and how to fix it? Thank you in
advance.
> 

Hi,

can you provide more detail of you deployment? OVS version, DPDK version,
configuration commands for ports/flows etc.

Thanks
Ian

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


smime.p7s
Description: S/MIME cryptographic signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] SSL errors with OVS on Alpine Linux

[Shivaram Mysore]

Hi,

I am running OVS on Alpine Linux
 (
ovs-vswitchd
(Open vSwitch) 2.10.1) and getting SSL errors.  I have a similar setup on
Ubuntu and other COTS switches with same/similar certs and I don't have any
issues.

I am getting errors like below

2019-08-28T00:55:38.905Z|01201|rconn|INFO|ovs-br0<->ssl:10.22.23.97:6653:
connecting...
2019-08-28T00:55:38.905Z|01202|stream_ssl|ERR|Certificate must be
configured to use SSL
2019-08-28T00:55:38.905Z|01203|rconn|WARN|ovs-br0<->ssl:10.22.23.97:6653:
connection failed (Protocol not available)
2019-08-28T00:55:38.905Z|01204|rconn|INFO|ovs-br0<->ssl:10.22.23.97:6653:
continuing to retry connections in the background but suppressing further
logging
2019-08-28T00:55:46.903Z|01205|stream_ssl|ERR|Certificate must be
configured to use SSL
2019-08-28T00:55:46.903Z|01206|rconn|WARN|ovs-br0<->ssl:10.22.23.97:6654:
connection failed (Protocol not available)
2019-08-28T00:55:46.904Z|01207|stream_ssl|ERR|Certificate must be
configured to use SSL
2019-08-28T00:55:46.904Z|01208|rconn|WARN|ovs-br0<->ssl:10.22.23.97:6653:
connection failed (Protocol not available)
2019-08-28T00:55:46.904Z|01209|fail_open|WARN|Could not connect to
controller (or switch failed controller's post-connection admission control
policy) for 15 seconds, failing open
2019-08-28T00:55:54.903Z|01210|stream_ssl|ERR|Certificate must be
configured to use SSL
2019-08-28T00:55:54.904Z|01211|rconn|WARN|ovs-br0<->ssl:10.22.23.97:6654:
connection failed (Protocol not available)
2019-08-28T00:55:54.904Z|01212|stream_ssl|ERR|Certificate must be
configured to use SSL
2019-08-28T00:55:5


$ *ovs-vsctl list ssl*
_uuid   : c1fec598-13b9-40a3-bf50-dfe54529505c
bootstrap_ca_cert   : false
ca_cert :
"/var/lib/openvswitch/pki/my_godaddy-ca-cert-chain.pem"
certificate : "/var/lib/openvswitch/pki/client.cert.pem"
external_ids: {}
private_key : "/var/lib/openvswitch/pki/client.key.pem"

What could be wrong?  Has anyone used OVS on Alpine Linux?

Thanks

/Shivaram
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] MTU / Fragmentation / VXLAN

[Justin Pettit]

> On Aug 25, 2019, at 9:38 PM, Heim, Dennis  wrote:
> 
> I have an issue with SIP phones registered to a Cisco Call Manager Express 
> (CME).
>  
> Network Layout:
> Phone->Physical Switch->OvS(A)VXLAN Overlay-OvS(B)—CME.
>  
> When the packet reaches  OvS(A) the sip (invite) packet for the phone call is 
> in tact (packet 51).
>  
> 
>  
> However, when I look at traces on OvS(B), I do not see that SIP invite. 
> Interesting enough, the SIP registration message arrives as the phone is 
> registered with the CME.

Are you sure that Packet 51 is the one that requires fragmentation?  According 
to your screenshot, it looks like the packet is 114 bytes.  1500 bytes is the 
most common MTU and a VXLAN encapsulation overhead is probably around 40 bytes, 
so there should be plenty of room for it.

The ICMP "fragmentation needed" error message would normally contain the first 
64 bytes or so of the packet that needs fragmenting.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovsdb_idl - received unexpected reply message

[Shivaram Mysore]

Thanks Ben for more insight.

Regards

On Tue, Aug 27, 2019 at 4:20 PM Ben Pfaff  wrote:

> On Mon, Aug 26, 2019 at 09:53:17PM -0700, Shivaram Mysore wrote:
> > Hi,
> >
> > System info:
> > # *ovs-vswitchd --version*
> > ovs-vswitchd (Open vSwitch) 2.10.1
> >
> > # *lsmod | grep openvswitch*
> > openvswitch   155648  3
> > nsh16384  1 openvswitch
> > nf_conncount   24576  1 openvswitch
> > nf_nat 49152  3 openvswitch,ipt_MASQUERADE,iptable_nat
> > nf_conntrack  151552  6
> >
> openvswitch,nf_conncount,ipt_MASQUERADE,nf_conntrack_netlink,xt_conntrack,nf_nat
> > nf_defrag_ipv6 24576  2 openvswitch,nf_conntrack
> > libcrc32c  16384  4 openvswitch,nf_nat,nf_conntrack,xfs
> >
> > On OVS startup, I am seeing this error and am unable to understand the
> > reason or where I should look for more debugging:
> >
> >
> 2019-08-27T04:40:50Z|00027|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> > SERVER_MONITOR_COND_REQUESTED -> DATA_MONITOR_COND_REQUESTED at
> > lib/ovsdb-idl.
> > c:1817
> > 2019-08-27T04:40:50Z|00028|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> > send request, method="set_db_change_aware", params=[true], id=5
> > 2019-08-27T04:40:50Z|00029|poll_loop|DBG|wakeup due to [POLLIN] on fd 11
> > (<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:157
> > 2019-08-27T04:40:50Z|00030|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> > received reply, result={}, id=4
> >
> 2019-08-27T04:40:50Z|00031|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> > DATA_MONITOR_COND_REQUESTED -> MONITORING at lib/ovsdb-idl.c:694
> > 2019-08-27T04:40:50Z|00032|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> > received reply, result={}, id=5
> >
> 2019-08-27T04:40:50Z|00033|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> > received unexpected reply message: {"error":null,"id":5,"result":{}}
>
> This particular message is DBG level because it isn't significant.
> There's a comment in the code that has a little more information:
>
> /* Unknown message.  Log at a low level because this can happen if
>  * ovsdb_idl_txn_destroy() is called to destroy a transaction
>  * before we receive the reply.
>  *
>  * (We could sort those out from other kinds of unknown messages by
>  * using distinctive IDs for transactions, if it seems valuable to
>  * do so, and then it would be possible to use different log
>  * levels. XXX?) */
> char *s = jsonrpc_msg_to_string(msg);
> VLOG_DBG("%s: received unexpected %s message: %s",
>  jsonrpc_session_get_name(idl->session),
>  jsonrpc_msg_type_to_string(msg->type), s);
> free(s);
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Flow comparison with OFPFlowMod message

[Ben Pfaff]

On Tue, Aug 27, 2019 at 12:08:08PM -0700, Nick Yurchenko wrote:
> Hi,
> 
> In my project I need to compare an active flow in the table(obtained from
> `EventOFPFlowStatsReply`) with a OFPFlowMod message that is sent to the
> controller.
> 
> I've thrown together a method to compare the two but it doesn't look good.
> Is there a better way to do this?

It's pretty risky to try to compare matches and actions directly,
because there is more than one way to represent many of them.  It might
be better to simply rely on flow cookies.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovsdb_idl - received unexpected reply message

[Ben Pfaff]

On Mon, Aug 26, 2019 at 09:53:17PM -0700, Shivaram Mysore wrote:
> Hi,
> 
> System info:
> # *ovs-vswitchd --version*
> ovs-vswitchd (Open vSwitch) 2.10.1
> 
> # *lsmod | grep openvswitch*
> openvswitch   155648  3
> nsh16384  1 openvswitch
> nf_conncount   24576  1 openvswitch
> nf_nat 49152  3 openvswitch,ipt_MASQUERADE,iptable_nat
> nf_conntrack  151552  6
> openvswitch,nf_conncount,ipt_MASQUERADE,nf_conntrack_netlink,xt_conntrack,nf_nat
> nf_defrag_ipv6 24576  2 openvswitch,nf_conntrack
> libcrc32c  16384  4 openvswitch,nf_nat,nf_conntrack,xfs
> 
> On OVS startup, I am seeing this error and am unable to understand the
> reason or where I should look for more debugging:
> 
> 2019-08-27T04:40:50Z|00027|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> SERVER_MONITOR_COND_REQUESTED -> DATA_MONITOR_COND_REQUESTED at
> lib/ovsdb-idl.
> c:1817
> 2019-08-27T04:40:50Z|00028|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> send request, method="set_db_change_aware", params=[true], id=5
> 2019-08-27T04:40:50Z|00029|poll_loop|DBG|wakeup due to [POLLIN] on fd 11
> (<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:157
> 2019-08-27T04:40:50Z|00030|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> received reply, result={}, id=4
> 2019-08-27T04:40:50Z|00031|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> DATA_MONITOR_COND_REQUESTED -> MONITORING at lib/ovsdb-idl.c:694
> 2019-08-27T04:40:50Z|00032|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> received reply, result={}, id=5
> 2019-08-27T04:40:50Z|00033|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> received unexpected reply message: {"error":null,"id":5,"result":{}}

This particular message is DBG level because it isn't significant.
There's a comment in the code that has a little more information:

/* Unknown message.  Log at a low level because this can happen if
 * ovsdb_idl_txn_destroy() is called to destroy a transaction
 * before we receive the reply.
 *
 * (We could sort those out from other kinds of unknown messages by
 * using distinctive IDs for transactions, if it seems valuable to
 * do so, and then it would be possible to use different log
 * levels. XXX?) */
char *s = jsonrpc_msg_to_string(msg);
VLOG_DBG("%s: received unexpected %s message: %s",
 jsonrpc_session_get_name(idl->session),
 jsonrpc_msg_type_to_string(msg->type), s);
free(s);
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Flow comparison with OFPFlowMod message

[Nick Yurchenko]

Hi,

In my project I need to compare an active flow in the table(obtained from
`EventOFPFlowStatsReply`) with a OFPFlowMod message that is sent to the
controller.

I've thrown together a method to compare the two but it doesn't look good.
Is there a better way to do this?
```
def compare_flow_and_flowmsg(flow, msg):
# TODO: this is v hacky, there must be a better way to compare this
return sorted(flow.match.items()) == sorted(msg.match.items()) and\
flow.cookie == msg.cookie and \
all(action1.serialize_body() == action2.serialize_body() for
action1, action2 in
zip(flow.instructions[0].actions, msg.instructions[0].actions))
```
Thank you.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovsdb_idl - received unexpected reply message

[Shivaram Mysore]

Ignore this request for help.  There was some mistakes in my setup.

Thanks

On Mon, Aug 26, 2019 at 9:53 PM Shivaram Mysore 
wrote:

> Hi,
>
> System info:
> # *ovs-vswitchd --version*
> ovs-vswitchd (Open vSwitch) 2.10.1
>
> # *lsmod | grep openvswitch*
> openvswitch   155648  3
> nsh16384  1 openvswitch
> nf_conncount   24576  1 openvswitch
> nf_nat 49152  3 openvswitch,ipt_MASQUERADE,iptable_nat
> nf_conntrack  151552  6
> openvswitch,nf_conncount,ipt_MASQUERADE,nf_conntrack_netlink,xt_conntrack,nf_nat
> nf_defrag_ipv6 24576  2 openvswitch,nf_conntrack
> libcrc32c  16384  4 openvswitch,nf_nat,nf_conntrack,xfs
>
> On OVS startup, I am seeing this error and am unable to understand the
> reason or where I should look for more debugging:
>
> 2019-08-27T04:40:50Z|00027|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> SERVER_MONITOR_COND_REQUESTED -> DATA_MONITOR_COND_REQUESTED at
> lib/ovsdb-idl.
> c:1817
> 2019-08-27T04:40:50Z|00028|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> send request, method="set_db_change_aware", params=[true], id=5
> 2019-08-27T04:40:50Z|00029|poll_loop|DBG|wakeup due to [POLLIN] on fd 11
> (<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:157
> 2019-08-27T04:40:50Z|00030|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> received reply, result={}, id=4
> 2019-08-27T04:40:50Z|00031|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> DATA_MONITOR_COND_REQUESTED -> MONITORING at lib/ovsdb-idl.c:694
> 2019-08-27T04:40:50Z|00032|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
> received reply, result={}, id=5
> 2019-08-27T04:40:50Z|00033|ovsdb_idl|DBG|unix:/var/run/openvswitch/db.sock:
> received unexpected reply message: {"error":null,"id":5,"result":{}}
> 2019-08-27T04:40:50Z|00034|netlink_socket|DBG|nl_sock_send__ (Success):
> nl(len:17, type=26(family-defined), flags=305[REQUEST][ACK][DUMP], seq=1,
> pid=3163
> 940381
> 
> ...
> 2019-08-27T04:40:50Z|00049|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:172, type=16(control), flags=0, seq=1, pid=13,genl(cmd=1,version=2)
> 2019-08-27T04:40:50Z|00050|netlink_socket|DBG|nl_sock_transact_multiple__
> (Success): nl(len:52, type=18(family-defined), flags=1[REQUEST], seq=1,
> pid=3283
> 033594
> 2019-08-27T04:40:50Z|00051|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:72, type=2(error), flags=0, seq=1, pid=3283033594 error(-19(No such
> device)
> , in-reply-to(nl(len:52, type=18(family-defined), flags=1[REQUEST], seq=1,
> pid=3283033594))
> 2019-08-27T04:40:50Z|00052|netlink_socket|DBG|received NAK error=0 (No
> such device)
> 2019-08-27T04:40:50Z|00053|netlink_socket|DBG|nl_sock_transact_multiple__
> (Success): nl(len:104, type=16(family-defined),
> flags=405[REQUEST][ACK][ATOMIC],
>  seq=2, pid=3283033594
> 2019-08-27T04:40:50Z|00054|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:124, type=2(error), flags=0, seq=2, pid=3283033594 error(-95(Not
> supported)
> , in-reply-to(nl(len:104, type=16(family-defined),
> flags=405[REQUEST][ACK][ATOMIC], seq=2, pid=3283033594))
> 2019-08-27T04:40:50Z|00055|netlink_socket|DBG|received NAK error=0 (Not
> supported)
> 2019-08-27T04:40:50Z|00056|netlink_socket|DBG|nl_sock_transact_multiple__
> (Success): nl(len:36, type=31(ovs_vport), flags=9[REQUEST][ECHO], seq=1,
> pid=13,
> genl(cmd=3,version=1)
> 2019-08-27T04:40:50Z|00057|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:56, type=2(error), flags=0, seq=1, pid=13 error(-19(No such device),
> in-rep
> ly-to(nl(len:36, type=31(ovs_vport), flags=9[REQUEST][ECHO], seq=1,
> pid=13))
> 2019-08-27T04:40:50Z|00058|netlink_socket|DBG|received NAK error=0 (No
> such device)
> 
> ...
> 2019-08-27T04:40:50Z|00154|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:56, type=2(error), flags=0, seq=1d, pid=13 error(-19(No such
> device), in-re
> ply-to(nl(len:36, type=31(ovs_vport), flags=9[REQUEST][ECHO], seq=1d,
> pid=13))
> 2019-08-27T04:40:50Z|00155|netlink_socket|DBG|received NAK error=0 (No
> such device)
> 2019-08-27T04:40:50Z|00156|ovs_router|DBG|src addr not available for route
> ff00::
> 2019-08-27T04:40:50Z|00157|netlink_socket|DBG|nl_sock_recv__ (Success):
> nl(len:20, type=3(done), flags=2[MULTI], seq=1, pid=3163940381 done(0)
> ovs-vswitchd: /var/run/openvswitch/ovs-vswitchd.pid: already running as
> pid 13, aborting
> ovs-vswitchd: /var/run/openvswitch/ovs-vswitchd.pid: already running as
> pid 13, aborting
> ovs-vswitchd: /var/run/openvswitch/ovs-vswitchd.pid: already running as
> pid 13, aborting
>
> Thanks
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] GRE with link-local remote_ip: "not a valid IPv6 address"

[Gregory Rose]

On 8/27/2019 9:40 AM, Sven Gebauer wrote:

Am 27.08.19 um 17:12 schrieb Gregory Rose:

2019-08-22T07:22:09.545Z|00050|socket_util|ERR|"fe80::1%ens9" is not a valid 
IPv6 address

Remove the '%ens9' from your IPv6 address, that's not valid.


Then how do i specify the scope (i.e. interface) of a link-local address?
The `ip` command has the `dev` option for this, but i couldn't find
anything like that in the OVS docs. The changelog [0] says that the
%-Notation is supported since v2.8.


That's a good question - I've never used that notation and was not aware 
of it.


Maybe someone else can help with that part but I'm curious why you feel 
the need to specify the link-local address.


- Greg



Regards,
Sven

[0] 
https://github.com/openvswitch/ovs/blob/5c7ba90d8189ee7b35a1723d5a76dc205720af50/NEWS#L353


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] GRE with link-local remote_ip: "not a valid IPv6 address"

[Sven Gebauer]

Am 27.08.19 um 17:12 schrieb Gregory Rose:
>> 2019-08-22T07:22:09.545Z|00050|socket_util|ERR|"fe80::1%ens9" is not a valid 
>> IPv6 address
> 
> Remove the '%ens9' from your IPv6 address, that's not valid.
>

Then how do i specify the scope (i.e. interface) of a link-local address?
The `ip` command has the `dev` option for this, but i couldn't find
anything like that in the OVS docs. The changelog [0] says that the
%-Notation is supported since v2.8.

Regards,
Sven

[0] 
https://github.com/openvswitch/ovs/blob/5c7ba90d8189ee7b35a1723d5a76dc205720af50/NEWS#L353
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Query on DEC_ttl action implementation in datapath

[Justin Pettit]

I think it was considered cleaner from an ABI perspective, since it doesn't 
require another action, since "set" was already supported.  In practice, I 
don't think it's a problem, since usually a TTL decrement is associated with a 
routing decision, and TTLs tend to be fairly static between two hosts.

--Justin


> On Aug 27, 2019, at 1:11 AM, bindiya Kurle  wrote:
> 
> hi ,
> I have a question related to dec_ttl action implemented in datapath.
> when  dec_ttl action is configured in OVS following action get added in 
> datapath.
> 
> recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no), 
> packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3,
> 
> if packet comes with different TTL on same port then one more action get 
> added in datapath.
> for ex:
> recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no), 
> packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3,  
> 
> Could someone please explain why dec_ttl is implemeted as a set action  
> rather than dec_ttl action.
> 
> 
> I mean , why for different ttl one more rule get added rather than  just 
> adding it as  following as done in userspace
> 
> recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3, 
> bytes:294, used:0.737s, actions:dec_ttl,2 
> 
> Regards,
> Bindiya
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] GRE with link-local remote_ip: "not a valid IPv6 address"

[Gregory Rose]

On 8/27/2019 3:09 AM, Sven Gebauer wrote:

Hi all,

I'm trying to create a GRE tunnel with an IPv6 link-local address as the
remote_ip. According to the changelog, this should be supported since
v2.8.0. However...

root@vpntest4:~# ovs-vsctl add-br ovsbr0
root@vpntest4:~# ovs-vsctl add-port ovsbr0 ovsbr0-gre -- set interface 
ovsbr0-gre type=ip6gre options:remote_ip='fe80::1%ens9'
ovs-vsctl: Error detected while setting up 'ovsbr0-gre': ovsbr0-gre: bad ip6gre 
'remote_ip'
ovsbr0-gre: ip6gre type requires valid 'remote_ip' argument.  See ovs-vswitchd 
log for details.
ovs-vsctl: The default log directory is "/var/log/openvswitch".

root@vpntest4:~# tail /var/log/openvswitch/ovs-vswitchd.log
2019-08-22T07:22:09.545Z|00050|socket_util|ERR|"fe80::1%ens9" is not a valid 
IPv6 address


Remove the '%ens9' from your IPv6 address, that's not valid.

- Greg



2019-08-22T07:22:09.545Z|00051|netdev_vport|WARN|ovsbr0-gre: bad ip6gre 
'remote_ip'
ovsbr0-gre: ip6gre type requires valid 'remote_ip' argument
2019-08-22T07:22:09.545Z|00052|netdev|WARN|ovsbr0-gre: could not set 
configuration (Invalid argument)


Regular (non-link-local) IPv6 addresses work fine.
Setting up a tunnel with the `ip` command like this also works:
# ip link add test-gre type ip6gretap remote fe80::1 dev ens9

Any idea what I'm doing wrong here? Or is this a bug?
I'm using Open vSwitch 2.11.0 on Ubuntu 19.04, kernel version 5.0.0.

Thanks
Sven
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] GRE with link-local remote_ip: "not a valid IPv6 address"

[Sven Gebauer]

Hi all,

I'm trying to create a GRE tunnel with an IPv6 link-local address as the
remote_ip. According to the changelog, this should be supported since
v2.8.0. However...

root@vpntest4:~# ovs-vsctl add-br ovsbr0
root@vpntest4:~# ovs-vsctl add-port ovsbr0 ovsbr0-gre -- set interface 
ovsbr0-gre type=ip6gre options:remote_ip='fe80::1%ens9'
ovs-vsctl: Error detected while setting up 'ovsbr0-gre': ovsbr0-gre: bad ip6gre 
'remote_ip'
ovsbr0-gre: ip6gre type requires valid 'remote_ip' argument.  See ovs-vswitchd 
log for details.
ovs-vsctl: The default log directory is "/var/log/openvswitch".

root@vpntest4:~# tail /var/log/openvswitch/ovs-vswitchd.log
2019-08-22T07:22:09.545Z|00050|socket_util|ERR|"fe80::1%ens9" is not a valid 
IPv6 address
2019-08-22T07:22:09.545Z|00051|netdev_vport|WARN|ovsbr0-gre: bad ip6gre 
'remote_ip'
ovsbr0-gre: ip6gre type requires valid 'remote_ip' argument
2019-08-22T07:22:09.545Z|00052|netdev|WARN|ovsbr0-gre: could not set 
configuration (Invalid argument)


Regular (non-link-local) IPv6 addresses work fine.
Setting up a tunnel with the `ip` command like this also works:
# ip link add test-gre type ip6gretap remote fe80::1 dev ens9

Any idea what I'm doing wrong here? Or is this a bug?
I'm using Open vSwitch 2.11.0 on Ubuntu 19.04, kernel version 5.0.0.

Thanks
Sven
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Why are iperf3 udp packets out of order in OVS DPDK case?

[Stokes, Ian]

On 8/27/2019 9:35 AM, Yi Yang (杨燚)-云服务集团 wrote:

Hi, all

  


I’m doing experiments with OVS and OVS DPDK, only one bridge is there,
ports and flows are same for OVS and OVS DPDK, in OVS case, everything works
well, but in OVS DPDK case, iperf udp performance data are very poor, udp
packets are out of order, I have limited MTU and send buffer by –l1410 –
M1410, anybody knows why and how to fix it? Thank you in advance.



Hi,

can you provide more detail of you deployment? OVS version, DPDK 
version, configuration commands for ports/flows etc.


Thanks
Ian



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


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Why are iperf3 udp packets out of order in OVS DPDK case?

[杨�D]

Hi, all

 

I’m doing experiments with OVS and OVS DPDK, only one bridge is there,
ports and flows are same for OVS and OVS DPDK, in OVS case, everything works
well, but in OVS DPDK case, iperf udp performance data are very poor, udp
packets are out of order, I have limited MTU and send buffer by �Cl1410 �C
M1410, anybody knows why and how to fix it? Thank you in advance.

 

iperf3: OUT OF ORDER - incoming packet = 65 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 66 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 67 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 68 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 69 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 70 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 71 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 72 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 73 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 74 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 75 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 76 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 77 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 78 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 79 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 80 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 81 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 82 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 83 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 84 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 85 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 86 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 87 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 88 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 89 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 90 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 91 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 92 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 93 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 94 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 95 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 96 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 97 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 98 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 99 and received packet = 352 AND SP
= 5

iperf3: OUT OF ORDER - incoming packet = 100 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 101 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 102 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 103 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 104 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 105 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 106 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 107 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 108 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 109 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 110 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 111 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 112 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 113 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 114 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 115 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 116 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 117 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 118 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 119 and received packet = 352 AND
SP = 5

iperf3: OUT OF ORDER - incoming packet = 120 and received packet = 352 AND
SP = 5

[ovs-discuss] Query on DEC_ttl action implementation in datapath

[bindiya Kurle]

hi ,
I have a question related to dec_ttl action implemented in datapath.
when  dec_ttl action is configured in OVS following action get added in
datapath.

recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=64,frag=no),
packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=63)),3,

if packet comes with different TTL on same port then one more action get
added in datapath.
for ex:
recirc_id(0),in_port(2),eth(),eth_type(0x0800),ipv4(ttl=9,frag=no),
packets:3, bytes:294, used:0.068s, actions:set(ipv4(ttl=8)),3,

Could someone please explain why dec_ttl is implemeted as a set action
rather than dec_ttl action.


I mean , why for different ttl one more rule get added rather than  just
adding it as  following as done in userspace

recirc_id(0),in_port(3),eth(),eth_type(0x0800),ipv4(frag=no), packets:3,
bytes:294, used:0.737s, actions:dec_ttl,2

Regards,
Bindiya
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss