Hi, I have a stretch box configured as VLAN router (Cubox -i2ex). There is a drastic difference between the bandwidth of the uplink (VLAN1) and the downlinks (VLAN 2 to 7):
On 192.168.7.1 (VLAN 7: eth0.7) I see arround 9 MB/s in a simple test: rd@home:~$ wget -O /dev/null http://fs/debian-9.3.0-amd64-netinst.iso [...] (9.08 MB/s) rd@home:~$ On 192.168.0.30 (VLAN 1: eth0.1) is see less than 10%: rd@home:~$ wget -O /dev/null https://git.kernel.org/torvalds/t/linux-5.3-rc1.tar.gz --2019-07-27 14:46:38-- https://git.kernel.org/torvalds/t/linux-5.3-rc1.tar.gz [...] (339KB/s) To prove that it has nothing to do with the uplink (there is a Fritzbox 6430) itself, I connected another machine on same VLAN 1 (192.168.0.203). So overall, the network looks like this Internet | | Fritz-Box | | 192.168.0.203 |--------------------------------------- x86 | | 192.168.0.30 | Cubox i | | 192.168.7.* | Note, the Cubox-i has only 1 physical interface, drawn are the virtual interface. The x86 machine reaches also a much higher network bandwidth: rd@h370:~/tmp.nobackup$ wget -O /dev/null https://git.kernel.org/torvalds/t/ linux-5.3-rc1.tar.gz [...] (5,49 MB/s) rd@h370:~/tmp.nobackup$ I did run ifstat to confirm that there is no other traffic which consumes all the bandwidth: rd@home:/etc/shorewall$ ifstat -i eth0.1 1 eth0.1 KB/s in KB/s out 495.00 16.34 417.14 16.03 484.33 16.53 384.80 11.96 393.33 12.67 632.59 17.68 607.90 17.91 354.39 12.00 678.58 20.97 1119.24 26.88 1185.20 27.27 925.91 21.84 1245.82 27.88 940.69 26.06 1023.72 26.89 1114.13 26.33 997.74 24.56 876.72 19.49 1167.56 27.73 906.41 24.30 1127.62 27.36 919.79 20.01 915.31 20.95 990.86 23.97 1119.22 26.94 905.54 26.40 1143.21 28.44 1096.15 26.98 924.62 24.89 1076.53 24.87 1004.04 23.99 811.11 23.13 983.71 24.46 885.05 23.19 1052.26 43.33 1230.55 37.11 1517.61 33.67 818.60 24.37 1057.24 26.63 1131.38 26.47 1278.43 30.12 1123.24 24.31 788.14 21.74 757.56 23.86 1135.29 27.91 1161.76 25.15 1465.32 32.04 1175.41 26.16 1371.36 31.56 811.73 21.70 540.97 16.91 381.78 20.95 306.44 13.07 378.02 12.93 603.65 16.67 418.31 16.35 393.71 16.46 479.89 15.05 436.74 13.85 395.96 12.05 476.41 14.51 470.09 18.23 322.02 12.20 427.35 14.33 464.25 14.39 404.19 11.09 999.41 24.39 931.23 24.89 Also top does not show any obvious overload: rd@home:~$ top top - 14:51:53 up 34 days, 1:18, 3 users, load average: 1.10, 1.11, 1.24 Tasks: 177 total, 2 running, 125 sleeping, 0 stopped, 0 zombie %Cpu(s): 5.2 us, 5.2 sy, 0.0 ni, 87.9 id, 0.2 wa, 0.0 hi, 1.5 si, 0.0 st KiB Mem : 2062764 total, 89308 free, 239480 used, 1733976 buff/cache KiB Swap: 4726172 total, 4726172 free, 0 used. 1740396 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13341 rd 20 0 12072 7196 3716 S 3.6 0.3 0:01.33 wget 7221 root 20 0 62236 3508 2468 S 2.9 0.2 394:36.44 owserver 1257 rd 20 0 4036 2304 2052 S 2.0 0.1 945:39.61 reed- contact-mo 7687 rd 20 0 4712 2508 1596 S 2.0 0.1 571:54.03 monitor.sh 13597 rd 20 0 7212 2900 2276 R 1.6 0.1 0:00.53 top 1040 asterisk 20 0 221968 58292 30316 S 1.3 2.8 565:37.76 asterisk 17 root 20 0 0 0 0 S 0.7 0.0 434:16.89 ksoftirqd/1 10 root 20 0 0 0 0 R 0.3 0.0 94:31.09 rcu_sched 202 root 20 0 27144 6192 5760 S 0.3 0.3 89:57.07 systemd- journal 8678 root 0 -20 0 0 0 I 0.3 0.0 0:22.47 kworker/ 2:2H-kb 21622 root 20 0 0 0 0 I 0.3 0.0 0:01.57 kworker/ u8:3-ev 32581 root 0 -20 0 0 0 I 0.3 0.0 0:18.03 kworker/ 0:1H-kb 1 root 20 0 26672 5236 3852 S 0.0 0.3 2:42.16 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:07.14 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0.0 0.0 4:43.82 ksoftirqd/0 11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0.0 0.0 2:43.11 migration/0 So in summary: -> The uplink of the cubox to the internet is slow (<10% of available bandwidth) -> The cubox can run on the physical interface (the0) much higher traffic (as shown on VLAN 7) -> Another x86 host can run much higher traffic into the Internet Any idea on what could restrict the bandwidth on the Cubox uplink is very welcome. Also any ideas to diagnose the issue further would be useful for me. Many thanks Rainer -- Rainer Dorsch http://bokomoko.de/
