[ovs-discuss] Pointers requested for OVS configuration with OpenWRT - Out of order packets issue

Mon Mar 20 17:02:20 UTC 2017

Hello and Greetings.

We are setting up a SDN/Openflow enabled test bed involved with LTE
functionality.

TP-Link 1043ND (V3) with OpenWRT (Chaos Calmer, r49389), OpenVSwitch (
(Open vSwitch) 2.3.90 , with DB Schema 7.11.2) is being used as
SDN/openflow enabled device in the test bed.

We observe out of order packets, (may be packet corruption), duplication of
packets, because of which the application fails. (When we searched the
archives, we found the link
https://mail.openvswitch.org/pipermail/ovs-discuss/2012-April/026929.html,
where a use case or application scenario was requested and ours is an
example application scenario)

An LTE eNB is split into two parts (Part 1 - RRH and Part 2- RCC) are
connected via the SDN Switch. RRH <-> SDN-SW <-> RCC. The RRH and RCC needs
to be synchronized and this is achieved by frames/packets generated every 1
milli second. The frames generated is bursty (i.e. 14 pkts of 772 bytes
generated within 30 to 50 micro seconds) at each side is sent across the
SDN-SW. Every 20 milli seconds, a Jumbo frame (6K+ packet) fragmented to
due to MTU size limitation (MTU size is 4070 in TP-Link 1043ND), is
generated. The data rate when considered per second is very less, i.e.
84Mbps, (when jumbo frame is sent every 20ms) it is 141 Mbps.

The frames received are out of order, duplicated, (corrupted?) (Reference
attached
RCC_SDN_Cap_PktSize722.pcapng
RRH_SDN_Cap_PktSize722.pcapng)

In a second configuration, when the size of 14pkts (generated per milli
second) increases - the behavior is same.
(Reference attached RCC_SDN_Cap_PktSize1322.pcapng
RRH_SDN_Cap_PktSize1322.pcapng)

IF the TP-Link 1043ND is used a L2 Switch, all packets sent are received at
the other end in order. The data flow to the OVS/Linux kernel, Linux kernel
based forwarding currently brings the limitation.

Can some one point out what configurations (Traffic Control, or any other
mechanisms, or fix in OVS)  so that the data flow via the SDN switch can be
stablized? I am blocked currently.

=================
OVS related info at the switch
=================
root at OpenWrt:~# ovs-vsctl show
5714d570-6295-43cb-93dd-476e599c1604
    Bridge br-lan
        Controller "tcp:192.168.1.10:6633"
            is_connected: true
        Port "eth1.4"
            Interface "eth1.4"
        Port "eth1.6"
            Interface "eth1.6"
        Port "eth1.5"
            Interface "eth1.5"
        Port "eth1.3"
            Interface "eth1.3"
        Port br-lan
            Interface br-lan
                type: internal
root at OpenWrt:~# ovs-ofctl dump-flows br-lan
NXST_FLOW reply (xid=0x4):
 cookie=0x20000000000000, duration=4174.490s, table=0, n_packets=6699,
n_bytes=8391882, idle_age=2446,
priority=1,udp,in_port=1,dl_src=18:66:da:2a:4c:48,dl_dst=98:90:96:9e:0c:1e,nw_src=172.22.0.21,nw_dst=172.22.0.16,tp_src=50000,tp_dst=50000
actions=output:3
 cookie=0x20000000000000, duration=4174.045s, table=0, n_packets=2342,
n_bytes=2680972, idle_age=2446,
priority=1,udp,in_port=3,dl_src=98:90:96:9e:0c:1e,dl_dst=18:66:da:2a:4c:48,nw_src=172.22.0.16,nw_dst=172.22.0.21,tp_src=50000,tp_dst=50000
actions=output:1
 cookie=0x20000000000000, duration=4169.869s, table=0, n_packets=4,
n_bytes=240, idle_age=2441,
priority=1,arp,in_port=3,dl_src=98:90:96:9e:0c:1e,dl_dst=18:66:da:2a:4c:48
actions=output:1
 cookie=0x20000000000000, duration=4169.861s, table=0, n_packets=4,
n_bytes=240, idle_age=2441,
priority=1,arp,in_port=1,dl_src=18:66:da:2a:4c:48,dl_dst=98:90:96:9e:0c:1e
actions=output:3
 cookie=0x20000000000000, duration=4102.384s, table=0, n_packets=39,
n_bytes=74202, idle_age=2446,
priority=1,ip,in_port=1,dl_src=18:66:da:2a:4c:48,dl_dst=98:90:96:9e:0c:1e,nw_src=172.22.0.21,nw_dst=172.22.0.16
actions=output:3
 cookie=0x0, duration=4225.241s, table=0, n_packets=103, n_bytes=197466,
idle_age=2409, priority=0 actions=CONTROLLER:65535
root at OpenWrt:~#
=================

IF OVS is disabled and TP-Link 1043ND is used as a normal L2 Switch,
packets are received in order and there is no corruption.

RCC_No_SDN_Cap_PktSize1322.pcapng
RRH_No_SDN_Cap_PktSize1322.pcapng

RCC_No_SDN_Cap_PktSize722.pcapng
RRH_No_SDN_Cap_PktSize722.pcapng

==========

RRH generates the first packet to RCC to initiate communication, (since RCC
comes up first and waits for data at the UDP port 50000). RRH IP is
172.22.0.21 and RCC IP is 172.22.0.16.

Out of order is clearly visible with the late reception of Jumbo frames at
RRH sent from RCC.
In the SDN enabled captures, (12th pkt in RRH and 10th pkt at RCC are
different. is the 10th pkt corrupted? Similarly the following packets.

Help with pointers to get over this blocking condition is sincerely
appreciated.

Best regards
Manikantan

----------------------------------------------------------------------------
Manikantan (Mani) Srinivasan
Research Scholar (PhD),
High Performance Computing and Networking (HPCN) Lab,
BSB #358, Department of Computer Science and Engineering,
Indian Institute of Technology - Madras,
Chennai, PIN Code (ZIP) 600036, INDIA.
Phone: +91-44-22575369
----------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170320/8fbf29d4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ovs_OpenWrt_logs.tgz
Type: application/x-gzip
Size: 4287997 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170320/8fbf29d4/attachment-0001.tgz>