Linux router met twee OpenVPN connectie's traagheid

[Streutjes]

Ik wil Linux gebruiken als router, dit doe ik nu met een Raspberry Pi met een extra ethernet interface (USB-->ethernet). DHCP server en VLAN's etc. zijn ook geconfigureerd, dus een volwaardige router.

Deze router maakt verbinding met twee VPN's, beide via OpenVPN. Maar de VPN verbindingen zijn mega traag en ik kom er niet achter waarom, heeft iemand een idee?

De configuratie:
Eth0: intern, VLAN 10 t/m 80 (eth0.10, t/m eth0.80)
Eth1: extern (rechtstreeks aan ISP)
Tun0: VPN 1 naar ander lokaal netwerk
Tun1: VPN 2 naar betaalde VPN-dienst voor internet

Op de PI draait de laatste versie van Buster Lite (gebaseerd op Debian).

Beide VPN's gebruiken een andere poort en andere encryptie settings.

Client's maken gebruik van een aparte routing tabel (via policy based routing), zodat ik internet over 'n VPN kan routen. De PI zelf gebruikt gewoon eth1 als default gateway en dus de main routing tabel.

Als ik een van de twee VPN's uit zet, dan blijft de overgebleven VPN traag.

De load van de PI is prima, komt zelfs met de speedtest niet boven de 0,70. Bij 4.00 zijn alle 4 de core's pas 100% in gebruik.

Als ik een speedtest doe vanuit een client en dit routeer over eth1 dan haal ik 60/10, dat is ook exact mijn internet snelheid.
Als ik een speedtest doe over tun0 of tun1, dan schommelt download tussen de 15 en 45mbit, upload tussen de 0,5 en 5mbit.

Het vreemde is, als ik deze set-up gebruik achter een bestaande router, dus zodat eth1 van de PI niet rechtstreeks een extern IP krijgt, werkt alles snel, haal ik op beide VPN's 58/9mbit (dus bijna mijn internet snelheid). Wat gaat er mis?



Mijn settings:
Main routinetabel:

code:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 217.121.136.1 0.0.0.0 UG 203 0 0 eth1
10.0.10.0 0.0.0.0 255.255.255.0 U 205 0 0 eth0.20
10.0.30.0 0.0.0.0 255.255.255.0 U 208 0 0 eth0.80
10.0.200.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
10.45.112.0 0.0.0.0 255.255.255.0 U 0 0 0 tun1
192.168.5.0 0.0.0.0 255.255.255.0 U 204 0 0 eth0.10
192.168.10.0 0.0.0.0 255.255.255.0 U 206 0 0 eth0.40
192.168.20.0 0.0.0.0 255.255.255.0 U 207 0 0 eth0.60
217.121.136.0 0.0.0.0 255.255.254.0 U 203 0 0 eth1

Ifconfig:

code:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.200.254 netmask 255.255.255.0 broadcast 10.0.200.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 187 bytes 17278 (16.8 KiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 115 bytes 12961 (12.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 217.121.137.XXX netmask 255.255.254.0 broadcast 255.255.255.255
ether d0:37:45:d1:da:57 txqueuelen 1000 (Ethernet)
RX packets 27 bytes 9846 (9.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 45 bytes 7224 (7.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.5.254 netmask 255.255.255.0 broadcast 192.168.5.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 179 bytes 13998 (13.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 47 bytes 6865 (6.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.20: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.10.254 netmask 255.255.255.0 broadcast 10.0.10.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 1146 (1.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.40: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.254 netmask 255.255.255.0 broadcast 192.168.10.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 1164 (1.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.60: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.20.254 netmask 255.255.255.0 broadcast 192.168.20.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14 bytes 1164 (1.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0.80: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.30.254 netmask 255.255.255.0 broadcast 10.0.30.255
ether b8:27:eb:cb:72:82 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13 bytes 1104 (1.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 97 bytes 7917 (7.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 97 bytes 7917 (7.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.3 netmask 255.255.255.0 destination 10.8.0.3
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 2 bytes 398 (398.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2 bytes 160 (160.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.45.112.132 netmask 255.255.255.0 destination 10.45.112.132
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Routing tabel voor de clients:

code:

default dev tun1 scope link 
10.0.10.0/24 via 10.0.10.254 dev eth0.20 
10.0.30.0/24 via 10.0.30.254 dev eth0.80 
10.8.0.0/24 via 10.8.0.1 dev tun0 
192.168.5.0/24 via 192.168.5.254 dev eth0.10 
192.168.10.0/24 via 192.168.10.254 dev eth0.40 
192.168.20.0/24 via 192.168.20.254 dev eth0.60

Iptables NAT:

code:

11 759 MASQUERADE all -- * eth1 0.0.0.0/0 0.0.0.0/0 
43 2704 MASQUERADE all -- * tun1 0.0.0.0/0 0.0.0.0/0 
79 5669 MASQUERADE all -- * tun0 0.0.0.0/0 0.0.0.0/0

Iptables:

code:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -i eth0.10 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0.10 -o tun1 -j ACCEPT
-A FORWARD -i eth0.20 -o tun1 -j ACCEPT
-A FORWARD -i eth0.40 -o tun1 -j ACCEPT
-A FORWARD -i eth0.60 -o tun1 -j ACCEPT
-A FORWARD -i eth0.80 -o tun1 -j ACCEPT

[ Voor 46% gewijzigd door Streutjes op 15-03-2021 14:27 ]

[plizz]

Welke Raspberry Pi gaat het om? 1ste versie?

[laurens0619]

Werkt de vpn nog wel als die direct aan internet hamgt? Heb je dat gecontroleerd met watismijnip?

En mbt je cpu load

Openvpn has always been I/O-bound on Pi, never CPU-bound (excluding tinfoil-hat-sized cypher blocks perhaps)

[ Voor 43% gewijzigd door laurens0619 op 09-02-2021 22:29 ]

[Thralas]

laurens0619 schreef op dinsdag 9 februari 2021 @ 22:10:
En mbt je cpu load

[...]

Dubieuze quote. Natuurlijk is OpenVPN niet I/O bound - packets naar buiten duwen is véél minder complex dan crypto. Dat heet niets met 'tinfoil hats' te maken, met AES hebben embedded devices zonder hardware acceleration al snel genoeg moeite. Maar ik geloof niet dat het hier relevant is - het ding lijkt me snel genoeg.

plizz schreef op dinsdag 9 februari 2021 @ 21:53:
Welke Raspberry Pi gaat het om? 1ste versie?

Als ik de case Google dan lijkt het een 4. Die moet inderdaad toch wel rap genoeg zijn voor 60/10.

Streutjes schreef op dinsdag 9 februari 2021 @ 20:13:
De configuratie:

Voeg eens wat [code]-tags in, dan is het nog leesbaar ook..

Beide VPN's gebruiken een andere poort en andere encryptie settings.

Kun je daar wat meer van laten zien? Client configs, bijvoorbeeld.

Het vreemde is, als ik deze set-up gebruik achter een bestaande router, dus zodat eth1 van de PI niet rechtstreeks een extern IP krijgt, werkt alles snel, haal ik op beide VPN's 58/9mbit (dus bijna mijn internet snelheid). Wat gaat er mis?

Het enige dat je daar verandert is dat je een kabel omprikt, verder niets, en dan wordt het traag?

Weet je zeker dat het verkeer via dezelfde interface naar buiten gaat als je achter de router zit (omdat je dan naar ik aanneem wel eens twee IPs in hetzelfde subnet kunt hebben)?

Wat voor uplink is het? Glas, DSL? PPPoE? Weet je zeker dat de MTU juist is? Gaan de VPNs over UDP of TCP? Heb je gecontroleerd of het verkeer in de 'snelle' situatie daadwerkelijk via de VPN interface loopt?

[Streutjes]

plizz schreef op dinsdag 9 februari 2021 @ 21:53:
Welke Raspberry Pi gaat het om? 1ste versie?

Het is een 3B+

[Streutjes]

laurens0619 schreef op dinsdag 9 februari 2021 @ 22:10:
Werkt de vpn nog wel als die direct aan internet hamgt? Heb je dat gecontroleerd met watismijnip?

En mbt je cpu load

[...]

Jep, als ik direct aan het internet hang werken beide VPN’s, dit heb ik idd getest met watismijnip

[Streutjes]

Thralas schreef op dinsdag 9 februari 2021 @ 23:17:
[...]


Dubieuze quote. Natuurlijk is OpenVPN niet I/O bound - packets naar buiten duwen is véél minder complex dan crypto. Dat heet niets met 'tinfoil hats' te maken, met AES hebben embedded devices zonder hardware acceleration al snel genoeg moeite. Maar ik geloof niet dat het hier relevant is - het ding lijkt me snel genoeg.


[...]


Als ik de case Google dan lijkt het een 4. Die moet inderdaad toch wel rap genoeg zijn voor 60/10.


[...]


Voeg eens wat [code]-tags in, dan is het nog leesbaar ook..


[...]


Kun je daar wat meer van laten zien? Client configs, bijvoorbeeld.


[...]


Het enige dat je daar verandert is dat je een kabel omprikt, verder niets, en dan wordt het traag?

Weet je zeker dat het verkeer via dezelfde interface naar buiten gaat als je achter de router zit (omdat je dan naar ik aanneem wel eens twee IPs in hetzelfde subnet kunt hebben)?

Wat voor uplink is het? Glas, DSL? PPPoE? Weet je zeker dat de MTU juist is? Gaan de VPNs over UDP of TCP? Heb je gecontroleerd of het verkeer in de 'snelle' situatie daadwerkelijk via de VPN interface loopt?

Ik heb kabel internet (Ziggo).

VPN’s zijn beide UDP

Het enige wat ik inderdaad verander is de kabel omprikken.
Dus in de trage situatie hangt de PI met eth1 rechtstreeks aan internet (Ziggo modem staat in bridge mode).
Bij de snelle situatie hangt m’n router rechtstreeks aan het internet en krijgt de PI op eth1 een IP van de router, dit is uiteraard een ander subnet als ik gebruik voor eth0 in de PI.
En ook dit loopt zeker via de VPN, gecheckt via watismijnip

Cliënt configs kan ik vanavond pas sturen, ben niet thuis nu

[Streutjes]

laurens0619 schreef op dinsdag 9 februari 2021 @ 22:10:
Werkt de vpn nog wel als die direct aan internet hamgt? Heb je dat gecontroleerd met watismijnip?

En mbt je cpu load

[...]

Alleen t vreemde is, achter ‘n router werkt t wel, dus t is geen performance probleem lijkt me

[brambo123]

Voor zover ik weet is OpenVPN geen multi-threaded applicatie.
Dus een load van 0,7 is dan in toch wel 70% belasting.
Meerdere VPN verbindingen zijn wel meerdere threads, dus daardoor maakt het geen verschil als er eentje uitgezet wordt.
Juiste cipher kiezen is dan toch wel erg belangrijk.
Als ik de snelheid test op een Pi 4 (overclocked) haal ik met AES-128-GCM max 40Mbps.
Met AES-128-CBC gaat die naar rond de 90Mbps.
Zonder hardware matige encryptie kun je beter kijken of chacha20-poly1305 mogelijk is, doet 150Mbps op een Pi4.
En wel handig met Ziggo modems: keepalive ingeschakelen, omdat Ziggo modems nogal de neiging hebben om verbindingen te verbreken.

[Streutjes]

brambo123 schreef op woensdag 10 februari 2021 @ 09:06:
Voor zover ik weet is OpenVPN geen multi-threaded applicatie.
Dus een load van 0,7 is dan in toch wel 70% belasting.
Meerdere VPN verbindingen zijn wel meerdere threads, dus daardoor maakt het geen verschil als er eentje uitgezet wordt.
Juiste cipher kiezen is dan toch wel erg belangrijk.
Als ik de snelheid test op een Pi 4 (overclocked) haal ik met AES-128-GCM max 40Mbps.
Met AES-128-CBC gaat die naar rond de 90Mbps.
Zonder hardware matige encryptie kun je beter kijken of chacha20-poly1305 mogelijk is, doet 150Mbps op een Pi4.
En wel handig met Ziggo modems: keepalive ingeschakelen, omdat Ziggo modems nogal de neiging hebben om verbindingen te verbreken.

Ik snap wat je bedoeld. Maar waarom werkt t dan achter n router wel goed? Zelfde settings in OpenVPN/Encryptie.

En ik kan niks meer instellen in het Ziggo modem, want deze staat in bridge modes (is vanuit Ziggo gebeurd)

[Streutjes]

Misschien belangrijke toevoeging: Als de PI rechtstreeks aan internet hangt is eth1 steady 60/10, maar de VPN’s zijn instabiel mbt snelheid.
Terwijl als ik de PI achter n router hang alles stabiel is...

Ik heb t gevoel dat ik iets aan eth1 moet doen om t stabiel te krijgen, maar weet niet wat...
Is ‘n MTU van 1500 goed voor internet/Ziggo? (connectie van PI met Ziggo cable modem)

[ Voor 12% gewijzigd door Streutjes op 10-02-2021 09:48 ]

[Ben(V)]

Volgens mij zit je gewoon aan de rand van je hardware capaciteit.
Even opsommen:

• Geen hardware encryptie ondersteuning,
• OpenVpn is single threaded, dus maar een core wordt gebruikt.
• Netwerk interfacing op een pi 3 wordt via een USB channel gedaan (dus zeer instabiel)

Als je hem dan rechtstreeks aan het internet hangt dan krijgt hij meer te doen wat anders het Ziggo modem voor je doet en dat pushed hem waarschijnlijk net over de rand.

Dat ziggo modem doet dingen als collisions afhandelen, retries opvragen voor missing tcp packages en fragmented packages weer samenvoegen.
Het internet is een veel minder schonen omgeving dan het lan.

En mtu size is eigenlijk alleen van belang voor het versturen van data, maar als je de optimale setting wilt weten dan kun je dat simpel met een ping command uitzoeken door te kijken bij welke mtu size het DF bit gezet wordt.
zo iets dus:

ping 8.8.8.8 -l 1500 -f

Pinging 8.8.8.8 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

En als je de juiste mtu size gevonden hebt dan krijg je dit

ping 8.8.8.8 -l 1472 -f

Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1472) time=15ms TTL=117
Reply from 8.8.8.8: bytes=68 (sent 1472) time=15ms TTL=117
Reply from 8.8.8.8: bytes=68 (sent 1472) time=11ms TTL=117
Reply from 8.8.8.8: bytes=68 (sent 1472) time=11ms TTL=117

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 15ms, Average = 13ms

EDIT:
Was even vergeten dat die box op linux draai dan moet je dus dit commando geven:

ping 8.8.8.8 -s 1400 -c4

[ Voor 3% gewijzigd door Ben(V) op 10-02-2021 10:34 ]

[Streutjes]

Ben(V) schreef op woensdag 10 februari 2021 @ 10:10:
Volgens mij zit je gewoon aan de rand van je hardware capaciteit.
Even opsommen:

• Geen hardware encryptie ondersteuning,
• OpenVpn is single threaded, dus maar een core wordt gebruikt.
• Netwerk interfacing op een pi 3 wordt via een USB channel gedaan (dus zeer instabiel)

Als je hem dan rechtstreeks aan het internet hangt dan krijgt hij meer te doen wat anders het Ziggo modem voor je doet en dat pushed hem waarschijnlijk net over de rand.

Dat ziggo modem doet dingen als collisions afhandelen, retries opvragen voor missing tcp packages en fragmented packages weer samenvoegen.
Het internet is een veel minder schonen omgeving dan het lan.

En mtu size is eigenlijk alleen van belang voor het versturen van data, maar als je de optimale setting wilt weten dan kun je dat simpel met een ping command uitzoeken door te kijken bij welke mtu size het DF bit gezet wordt.
zo iets dus:

[...]


En als je de juiste mtu size gevonden hebt dan krijg je dit

[...]


EDIT:
Was even vergeten dat die box op linux draai dan moet je dus dit commando geven:

[...]

Kortom volgens jouw gaat dit m niet worden met ‘n PI3? Zou dit met ‘n 4 wel kunnen?

Maar, zonder de VPN werkt t prima en stabiel, dat is ‘t vreemde...

[ Voor 4% gewijzigd door Streutjes op 10-02-2021 10:54 ]

[Ben(V)]

Uiteraard, OpenVpn is de echte belasting.
Alle encryptie moet zonder hardware ondersteuning door de cpu afgehandeld worden.

Geen idee of een pi4 het wel trekt.
Kwam laatst dit tegen, ziet er wel aardig uit.
https://www.friendlyarm.c...ct/product&product_id=284
En hier wat test rapportage erover.
https://www.stupid-projects.com/benchmarking-the-nanopi-r4s

Maar uiteraard weet ik niet of het voor jou voldoende performance bied.

[Streutjes]

Ben(V) schreef op woensdag 10 februari 2021 @ 11:17:
Uiteraard, OpenVpn is de echte belasting.
Alle encryptie moet zonder hardware ondersteuning door de cpu afgehandeld worden.

Geen idee of een pi4 het wel trekt.
Kwam laatst dit tegen, ziet er wel aardig uit.
https://www.friendlyarm.c...ct/product&product_id=284
En hier wat test rapportage erover.
https://www.stupid-projects.com/benchmarking-the-nanopi-r4s

Maar uiteraard weet ik niet of het voor jou voldoende performance bied.

Ik snap ‘t. Maar t vreemde is dat de PI er achter n router geen problemen mee heeft... Zelfde encryptie...

Interessant product die NanoPI

[Ben(V)]

Dat had ik toch uitgelegd.

Even in lekentaal dan:
Als je hem achter een router plaats doet die router een hoop werk dat die pi niet meer hoeft te doen.
Als die pi dan op het randje staat gaat het net nog goed.
Als hij zelf het internet verkeer moet afhandelen dan red hij het niet meer.

[Streutjes]

Ben(V) schreef op woensdag 10 februari 2021 @ 11:26:
Dat had ik toch uitgelegd.

Even in lekentaal dan:
Als je hem achter een router plaats doet die router een hoop werk dat die pi niet meer hoeft te doen.
Als die pi dan op het randje staat gaat het net nog goed.
Als hij zelf het internet verkeer moet afhandelen dan red hij het niet meer.

Ik snap wel wat je bedoeld, maar dit zie ik verder nergens terug aan processor of geheugen gebruik.

Internet is gewoon snel, 60/10. Ik maak een VPN, software matig, niks aan de hand met processor/geheugen.

Eerlijk gezegd zie ik nergens terug dat t gaat om performance issues, geen enkel bewijs voor. Is ‘n aanname.

Als ik de PI achter de router plaats veranderd er niks aan het processor en geheugen gebruik.

[ Voor 30% gewijzigd door Streutjes op 10-02-2021 12:17 ]

[Ben(V)]

Tja de rapportage van het cpu en geheugen gebruik zijn gemiddelden en daar kun je zoiets echt niet op aflezen.
En veel van dit soort zaken worden door de netwerkkaart afgehandeld, dus daar kan ook de bottleneck zitten en dat zie je helemaal nooit in de cpu belasting.

Maar als je mijn "aanname" niet plausible vind staat niets je in de weg het te negeren, ik probeer enkel te helpen.

[Streutjes]

Ben(V) schreef op woensdag 10 februari 2021 @ 12:22:
Tja de rapportage van het cpu en geheugen gebruik zijn gemiddelden en daar kun je zoiets echt niet op aflezen.
En veel van dit soort zaken worden door de netwerkkaart afgehandeld, dus daar kan ook de bottleneck zitten en dat zie je helemaal nooit in de cpu belasting.

Maar als je mijn "aanname" niet plausible vind staat niets je in de weg het te negeren, ik probeer enkel te helpen.

Zo bedoelde ik ‘t niet. Maar ik ben opzoek naar ‘hard bewijs’ zodat ik verder kan en eventueel op zoek naar ‘n ander stuk hardware.

Want ik heb dit ook geprobeerd met ‘n EdgeRouter 12P, zwaarste model mbt hardware. Hierop werkt t wel stabiel, maar schiet de CPU load omhoog waardoor ik lage snelheid haal...

Dus ik hoopte met de PI ‘n oplossing te hebben

[ Voor 22% gewijzigd door Streutjes op 10-02-2021 13:40 ]

[laurens0619]

Ik zou kijken wat de io doet
Om eerlijk gezegd ik vind deze resultaten al zeer goed. De pi is netwerk technisch nu eenmaal geen top apparaat (iets met usb bus) en icm openvpn niet.

Als je cheap hardware zoekt om vpn te routeren zou ik een ASUS RT-AC86U. Dat is de goedkoopste hardware die ik ken die hard openvpn kan routeren, 260mbit is haalbaar

https://www.skadligkod.se...rt-ac86u-merlin-firmware/

[ Voor 13% gewijzigd door laurens0619 op 10-02-2021 17:38 ]

[Streutjes]

laurens0619 schreef op woensdag 10 februari 2021 @ 17:23:
Ik zou kijken wat de io doet
Om eerlijk gezegd ik vind deze resultaten al zeer goed. De pi is netwerk technisch nu eenmaal geen top apparaat (iets met usb bus) en icm openvpn niet.

Als je cheap hardware zoekt om vpn te routeren zou ik een ASUS RT-AC86U. Dat is de goedkoopste hardware die ik ken die hard openvpn kan routeren

Duidelijk. Maar wel vreemd dat eth1 zelf gewoon 60/10 stabiel haalt, alleen OpenVPN niet. Maar achter ‘n router weer wel...

[laurens0619]

Streutjes schreef op woensdag 10 februari 2021 @ 17:39:
[...]

Duidelijk. Maar wel vreemd dat eth1 zelf gewoon 60/10 stabiel haalt, alleen OpenVPN niet. Maar achter ‘n router weer wel...

Tja, ik sluit mij bij @Ben(V) je loopt tegen de limieten van de pi aan. Grote kans dat de internet traffic de pi het sowieso zwaarder maakt maar het kan ook gewoon toeval zijn. Ik snap dat je het wilt verklaren (goede eigenschap) maar het gaat verder dan CPU. Check de io (wait is dat toch?), nadeel is namelijk ook dat de ethernet bus de snelheid deelt met de usb bus.

Ik zou een pi (3b+) nooit als internet router inzetten en helemaal niet icm vpn. Daarvoor is de hardware gewoon absoluut niet gemaakt en te zwak.

Wellicht gaat de pi 4 het wel trekken? misschien even deze auteur een berichtje sturen welke snelheden die haalt
https://www.zahradnik.io/raspberry-pi-as-a-home-router

[ Voor 24% gewijzigd door laurens0619 op 10-02-2021 17:49 ]

[Streutjes]

laurens0619 schreef op woensdag 10 februari 2021 @ 17:44:
[...]

Tja, ik sluit mij bij @Ben(V) je loopt tegen de limieten van de pi aan. Grote kans dat de internet traffic de pi het sowieso zwaarder maakt maar het kan ook gewoon toeval zijn. Ik snap dat je het wilt verklaren (goede eigenschap) maar het gaat verder dan CPU. Check de io (wait is dat toch?), nadeel is namelijk ook dat de ethernet bus de snelheid deelt met de usb bus.

Ik zou een pi (3b+) nooit als internet router inzetten en helemaal niet icm vpn. Daarvoor is de hardware gewoon absoluut niet gemaakt en te zwak.

Wellicht gaat de pi 4 het wel trekken? misschien even deze auteur een berichtje sturen welke snelheden die haalt
https://www.zahradnik.io/raspberry-pi-as-a-home-router

Bedankt.

De PI4 is al onderweg (vorige week besteld), ik ga het daar nogmaals mee proberen. Deze heeft ook USB3.0, dus de USB-ethernet interface zal hier ook een betere performance hebben.

[Ben(V)]

De pi 4 heeft gewoon een nette lan interface en geen usb bridge zoals de pi 3

[laurens0619]

Ben(V) schreef op woensdag 10 februari 2021 @ 19:46:
De pi 4 heeft gewoon een nette lan interface en geen usb bridge zoals de pi 3

Klopt!
Alleen jammer dat als je een 2e ethernet poort wilt je die via usb moet aansluiten (of gpio?)

[Mijzelf]

Ben(V) schreef op woensdag 10 februari 2021 @ 11:26:
Dat had ik toch uitgelegd.

Even in lekentaal dan:
Als je hem achter een router plaats doet die router een hoop werk dat die pi niet meer hoeft te doen.
Als die pi dan op het randje staat gaat het net nog goed.
Als hij zelf het internet verkeer moet afhandelen dan red hij het niet meer.

Welk werk hoeft de pi dan niet meer te doen? Als ik het zo lees is het een kwestie van omprikken, dus met de pi erbij is er dubbel NAT. Zou het het droppen van IPTV op een andere VLAN zijn? Gaat dat bij Ziggo niet van de 60Mbit af?

[Thralas]

Ben(V) schreef op woensdag 10 februari 2021 @ 10:10:
Als je hem dan rechtstreeks aan het internet hangt dan krijgt hij meer te doen wat anders het Ziggo modem voor je doet en dat pushed hem waarschijnlijk net over de rand.

Wat bedoel je met 'meer te doen'?

Dat ziggo modem doet dingen als collisions afhandelen, retries opvragen voor missing tcp packages en fragmented packages weer samenvoegen.

Die claims kloppen allemaal van geen kant.

Mijzelf schreef op woensdag 10 februari 2021 @ 20:06:
Welk werk hoeft de pi dan niet meer te doen? Als ik het zo lees is het een kwestie van omprikken, dus met de pi erbij is er dubbel NAT.

@Streutjes wordt hierboven met een kluitje het riet in gestuurd. Er is tot dusver geen verklaring waarom het trager zou zijn enkel door het omprikken. Hij krijgt een ander IP en that's it. Misschien blijkt er uiteindelijk een logische verklaring voor te zijn, maar dan mist er een stukje cruciale informatie.

Is ‘n MTU van 1500 goed voor internet/Ziggo? (connectie van PI met Ziggo cable modem)

Ja, dat werkt gewoon met MTU 1500 en is het probleem dus niet.

Bovendien kun je het performance-aspect gewoon testen: stel een null cipher in op de VPN die je in eigen beheer hebt. En ook handig: even met iperf testen. Link speed correct?

Zou het het droppen van IPTV op een andere VLAN zijn? Gaat dat bij Ziggo niet van de 60Mbit af?

Dat is niet aan de orde bij Ziggo lijkt me? Die leveren TV over coax..

Ik lees nu pas dat de snelheid variëert en niet perse altijd traag is. Dat geeft wmb. aanleiding om ook even naar buffers e.d. te kijken, naast de overige suggesties:

OpenVPN really slow with udp (tcp is ok)

Daar suggereert iemand dat z'n UDP performance op een Raspberry Pi verbetert na het zetten van buffer sizes (merk op dat OpenVPN volgens de laatste post de OS defaults gebruikt).

If all else fails: een pcap maken zowel op de raspberry pi als een OpenVPN server aan de andere kant, daarover IPerf en dan vergelijken met/zonder router. Dan moet je een verschil kunnen zien. Of simpelweg al kijken naar het OpenVPN-verkeer: misschien kun je retransmits ontdekken?

[Streutjes]

Thralas schreef op woensdag 10 februari 2021 @ 20:52:
[...]


Wat bedoel je met 'meer te doen'?


[...]


Die claims kloppen allemaal van geen kant.


[...]


@Streutjes wordt hierboven met een kluitje het riet in gestuurd. Er is tot dusver geen verklaring waarom het trager zou zijn enkel door het omprikken. Hij krijgt een ander IP en that's it. Misschien blijkt er uiteindelijk een logische verklaring voor te zijn, maar dan mist er een stukje cruciale informatie.


[...]


Ja, dat werkt gewoon met MTU 1500 en is het probleem dus niet.

Bovendien kun je het performance-aspect gewoon testen: stel een null cipher in op de VPN die je in eigen beheer hebt. En ook handig: even met iperf testen. Link speed correct?


[...]


Dat is niet aan de orde bij Ziggo lijkt me? Die leveren TV over coax..

Ik lees nu pas dat de snelheid variëert en niet perse altijd traag is. Dat geeft wmb. aanleiding om ook even naar buffers e.d. te kijken, naast de overige suggesties:

OpenVPN really slow with udp (tcp is ok)

Daar suggereert iemand dat z'n UDP performance op een Raspberry Pi verbetert na het zetten van buffer sizes (merk op dat OpenVPN volgens de laatste post de OS defaults gebruikt).

If all else fails: een pcap maken zowel op de raspberry pi als een OpenVPN server aan de andere kant, daarover IPerf en dan vergelijken met/zonder router. Dan moet je een verschil kunnen zien. Of simpelweg al kijken naar het OpenVPN-verkeer: misschien kun je retransmits ontdekken?

Bedankt voor deze verhelderende info, super!
Hier kan ik iets mee.

Hij krijgt een ander IP en that's it

Precies dat dus :-)

TV loopt inderdaad via coax, niet over internet/VLAN oid.

Ik zou OpenVPN op TCP kunnen testen, zou dat iets kunnen oplossen?

[Luxicon]

Streutjes schreef op woensdag 10 februari 2021 @ 17:39:
[...]

Duidelijk. Maar wel vreemd dat eth1 zelf gewoon 60/10 stabiel haalt, alleen OpenVPN niet. Maar achter ‘n router weer wel...

Hoe bedoel je dit precies? Als de router zelf OpenVPN toepast is dat een relatief zware belasting.

[Thralas]

Streutjes schreef op woensdag 10 februari 2021 @ 21:48:
Ik zou OpenVPN op TCP kunnen testen, zou dat iets kunnen oplossen?

Zeker het proberen waard, maar ik zou beginnen met iperf over udp en tcp om te bevestigen of uit te sluiten dat het probleem daarmee ook speelt.

Bovendien is dat ook meteen de handigste manier om de tunnel zelf mee te testen.

[Streutjes]

Luxicon schreef op woensdag 10 februari 2021 @ 22:30:
[...]


Hoe bedoel je dit precies? Als de router zelf OpenVPN toepast is dat een relatief zware belasting.

Snap ik. Maar de PI maakt de VPN. Rechtstreeks aan de WAN of achter ‘n router, dan blijft de belasting gelijk mbt OpenVPN, dus dat lijkt me niet het probleem.
Want achter ‘n router werkt ‘t stabiel en snel. Alleen rechtstreeks aan de WAN niet.

[ Voor 10% gewijzigd door Streutjes op 11-02-2021 06:33 ]

[Streutjes]

Thralas schreef op woensdag 10 februari 2021 @ 22:49:
[...]


Zeker het proberen waard, maar ik zou beginnen met iperf over udp en tcp om te bevestigen of uit te sluiten dat het probleem daarmee ook speelt.

Bovendien is dat ook meteen de handigste manier om de tunnel zelf mee te testen.

Ik ga dit weekend eens testen. Met ‘n beetje geluk is dan ook de PI 4 binnen...

[Ben(V)]

Thralas schreef op woensdag 10 februari 2021 @ 20:52:
[...]


Wat bedoel je met 'meer te doen'?


[...]


Die claims kloppen allemaal van geen kant.


[...]


@Streutjes wordt hierboven met een kluitje het riet in gestuurd. Er is tot dusver geen verklaring waarom het trager zou zijn enkel door het omprikken. Hij krijgt een ander IP en that's it. Misschien blijkt er uiteindelijk een logische verklaring voor te zijn, maar dan mist er een stukje cruciale informatie.


[...]


Ja, dat werkt gewoon met MTU 1500 en is het probleem dus niet.

Bovendien kun je het performance-aspect gewoon testen: stel een null cipher in op de VPN die je in eigen beheer hebt. En ook handig: even met iperf testen. Link speed correct?


[...]


Dat is niet aan de orde bij Ziggo lijkt me? Die leveren TV over coax..

Ik lees nu pas dat de snelheid variëert en niet perse altijd traag is. Dat geeft wmb. aanleiding om ook even naar buffers e.d. te kijken, naast de overige suggesties:

OpenVPN really slow with udp (tcp is ok)

Daar suggereert iemand dat z'n UDP performance op een Raspberry Pi verbetert na het zetten van buffer sizes (merk op dat OpenVPN volgens de laatste post de OS defaults gebruikt).

If all else fails: een pcap maken zowel op de raspberry pi als een OpenVPN server aan de andere kant, daarover IPerf en dan vergelijken met/zonder router. Dan moet je een verschil kunnen zien. Of simpelweg al kijken naar het OpenVPN-verkeer: misschien kun je retransmits ontdekken?

Ik geloof dat jouw claims van geen kanten deugen.
Als hij er een router tussen zet dan haalt hij de performance wel, conclusie de router die hij ertussen zet handelt dingen af die de pi daarna niet meer hoeft te doen, waardoor hij net binnen de mogelijkheden van zijn beperkte capaciteit blijft.
En dat is ook logisch want die router zal out of sync packages afhandelen, retries voor corrupte packages en collisions en dat hoef de netwerkkaart van die pi niet meer te doen wat toch al een zwak punt is.

En tcp gebruiken in plaats van udp is enkel een zwaardere belasting en dus een zinloze suggestie.
Ook volkomen onzinnig, want die tcp of udp zit encapsulated binnen het VPN protocol dus udp is meer dan voldoende en tcp geeft enkel meer overhead.
Dngen als andere ip's hebben er natuurlijk niets ook niets mee te maken.

[Luxicon]

Streutjes schreef op donderdag 11 februari 2021 @ 06:32:
[...]

Snap ik. Maar de PI maakt de VPN. Rechtstreeks aan de WAN of achter ‘n router, dan blijft de belasting gelijk mbt OpenVPN, dus dat lijkt me niet het probleem.
Want achter ‘n router werkt ‘t stabiel en snel. Alleen rechtstreeks aan de WAN niet.

Dan zou ik denken aan NAT en de firewall, of iets wat met routeren te maken heeft. De PI zal het verkeer toch af moeten handelen?

[Streutjes]

Ik ga dit weekend aan de slag met de PI4.
Dan zal ik ook meteen met ‘n andere OS testen (Ubuntu).

Ik zal de uitslag hier plaatsen

[Thralas]

Ben(V) schreef op donderdag 11 februari 2021 @ 09:21:
En dat is ook logisch want die router zal out of sync packages afhandelen

Als je bedoelt out of sequence: daar doet die router niets mee. Reordering gebeurt bij tcp aan de client- en serverkant. Nimmer ergens daartussen.

Hier gebruikt TS OpenVPN in udp modes: daar is de reliability layer door OpenVPN zelf toegevoegd bovenop udp. Daar heeft je router al helemaal geen kennis van.

, retries voor corrupte packages en collisions

Retries worden hier door OpenVPN afgehandeld (zie boven). Packets raken niet zomaar corrupt. Collissions bestaan niet op de transportlaag; wel op de linklaag: daarvan kun je in de ifconfig output van TS zien dat er nul collissions zijn opgetreden

en dat hoef de netwerkkaart van die pi niet meer te doen wat toch al een zwak punt is.

Ook dat komt hier niet voor: de dropped frame counters staan ook op nul.

En tcp gebruiken in plaats van udp is enkel een zwaardere belasting en dus een zinloze suggestie.
Ook volkomen onzinnig, want die tcp of udp zit encapsulated binnen het VPN protocol dus udp is meer dan

Het gaat hier over OpenVPN in udp/tcp mode. Dat is buiten de tunnel.

Dngen als andere ip's hebben er natuurlijk niets ook niets mee te maken.

Mooi. Dan is dat het enige waar we het wel over eens zijn.

Je geeft hier vaak goedbedoeld advies, maar het valt me op dat je 'feiten' daarbij altijd erg stellig presenteert terwijl het regelmatig voorkomt dat het niet helemaal klopt of zelfs helemaal geen hout snijdt (zoals hier). Ik ben tevens niet de eerste die je daarop wijst.

---

Voor de goede orde: ik heb OpenVPN ook zelf nog even gebenchmarkt op een Raspberry Pi 3.

code:

# iperf3 -c 10.1.0.1 -t 3
Connecting to host 10.1.0.1, port 5201
[  5] local 10.1.0.2 port 50504 connected to 10.1.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.11 MBytes  68.0 Mbits/sec   10   91.5 KBytes       
[  5]   1.00-2.00   sec  7.96 MBytes  66.8 Mbits/sec    3   92.8 KBytes       
[  5]   2.00-3.00   sec  8.02 MBytes  67.3 Mbits/sec    3   95.4 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.00   sec  24.1 MBytes  67.4 Mbits/sec   16             sender
[  5]   0.00-3.06   sec  23.9 MBytes  65.7 Mbits/sec                  receiver

iperf Done.
root@rpi3:~# iperf3 -c 10.1.0.1 -t 3 -R
Connecting to host 10.1.0.1, port 5201
Reverse mode, remote host 10.1.0.1 is sending
[  5] local 10.1.0.2 port 50510 connected to 10.1.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  9.78 MBytes  82.0 Mbits/sec                  
[  5]   1.00-2.00   sec  10.3 MBytes  86.2 Mbits/sec                  
[  5]   2.00-3.00   sec  9.33 MBytes  78.2 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.08   sec  31.2 MBytes  85.0 Mbits/sec  136             sender
[  5]   0.00-3.00   sec  29.4 MBytes  82.2 Mbits/sec                  receiver

iperf Done.

En dat is met OpenVPN met aes-256 als cipher. Zónder haalt hij 95 Mbit/s beide kanten op, dat is volgens mij de limiet van de usb ethernet controller van de RPi.

code:

openvpn --genkey --secret key # key overzetten
openvpn --secret key --dev tun --ifconfig 10.1.0.1 10.1.0.2 --cipher aes-256-cbc
openvpn --secret key --dev tun --remote 192.168.0.33 --ifconfig 10.1.0.2 10.1.0.1 --cipher aes-256-cbc

[Streutjes]

Thralas schreef op donderdag 11 februari 2021 @ 21:46:
[...]


Als je bedoelt out of sequence: daar doet die router niets mee. Reordering gebeurt bij tcp aan de client- en serverkant. Nimmer ergens daartussen.

Hier gebruikt TS OpenVPN in udp modes: daar is de reliability layer door OpenVPN zelf toegevoegd bovenop udp. Daar heeft je router al helemaal geen kennis van.


[...]


Retries worden hier door OpenVPN afgehandeld (zie boven). Packets raken niet zomaar corrupt. Collissions bestaan niet op de transportlaag; wel op de linklaag: daarvan kun je in de ifconfig output van TS zien dat er nul collissions zijn opgetreden


[...]


Ook dat komt hier niet voor: de dropped frame counters staan ook op nul.

[quote]
En tcp gebruiken in plaats van udp is enkel een zwaardere belasting en dus een zinloze suggestie.
Ook volkomen onzinnig, want die tcp of udp zit encapsulated binnen het VPN protocol dus udp is meer dan
[/qupte]

Het gaat hier over OpenVPN in udp/tcp mode. Dat is buiten de tunnel.


[...]


Mooi. Dan is dat het enige waar we het wel over eens zijn.

Je geeft hier vaak goedbedoeld advies, maar het valt me op dat je 'feiten' daarbij altijd erg stellig presenteert terwijl het regelmatig voorkomt dat het niet helemaal klopt of zelfs helemaal geen hout snijdt (zoals hier). Ik ben tevens niet de eerste die je daarop wijst.

---

Voor de goede orde: ik heb OpenVPN ook zelf nog even gebenchmarkt op een Raspberry Pi 3.

code:

# iperf3 -c 10.1.0.1 -t 3
Connecting to host 10.1.0.1, port 5201
[  5] local 10.1.0.2 port 50504 connected to 10.1.0.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.11 MBytes  68.0 Mbits/sec   10   91.5 KBytes       
[  5]   1.00-2.00   sec  7.96 MBytes  66.8 Mbits/sec    3   92.8 KBytes       
[  5]   2.00-3.00   sec  8.02 MBytes  67.3 Mbits/sec    3   95.4 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.00   sec  24.1 MBytes  67.4 Mbits/sec   16             sender
[  5]   0.00-3.06   sec  23.9 MBytes  65.7 Mbits/sec                  receiver

iperf Done.
root@rpi3:~# iperf3 -c 10.1.0.1 -t 3 -R
Connecting to host 10.1.0.1, port 5201
Reverse mode, remote host 10.1.0.1 is sending
[  5] local 10.1.0.2 port 50510 connected to 10.1.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  9.78 MBytes  82.0 Mbits/sec                  
[  5]   1.00-2.00   sec  10.3 MBytes  86.2 Mbits/sec                  
[  5]   2.00-3.00   sec  9.33 MBytes  78.2 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-3.08   sec  31.2 MBytes  85.0 Mbits/sec  136             sender
[  5]   0.00-3.00   sec  29.4 MBytes  82.2 Mbits/sec                  receiver

iperf Done.

En dat is met OpenVPN met aes-256 als cipher. Zónder haalt hij 95 Mbit/s beide kanten op, dat is volgens mij de limiet van de usb ethernet controller van de RPi.

code:

openvpn --genkey --secret key # key overzetten
openvpn --secret key --dev tun --ifconfig 10.1.0.1 10.1.0.2 --cipher aes-256-cbc
openvpn --secret key --dev tun --remote 192.168.0.33 --ifconfig 10.1.0.2 10.1.0.1 --cipher aes-256-cbc

Jouw benchmark ziet er goed uit!

Welke OS gebruik jij? Was dat rechtstreeks aan internet of achter ‘n router?

[Streutjes]

Update: Zojuist de PI4 binnen gekregen en geïnstalleerd/confonfigureerd. Zelfde probleem.

Over eth1 snel (60/10) en over tun0 en tun1 traag en onstabiel.

Dit viel me wel op:

code:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.3  netmask 255.255.255.0  destination 10.8.0.3
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 61087  bytes 80330325 (76.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35937  bytes 8241107 (7.8 MiB)
        TX errors 0  dropped 108 overruns 0  carrier 0  collisions 0

TX drops. Maar dat zie ik ook gebeuren als de PI achter de router zit en dan is de snelheid wel goed.

Ik heb geen enkel idee waar ik het nog moet zoeken... Iemand suggesties?

[Mijzelf]

Zou het iets elektrisch kunnen zijn? Wat als je een switch tussen de modem en de PI zet?

[DataGhost]

Ben(V) schreef op woensdag 10 februari 2021 @ 10:10:
Volgens mij zit je gewoon aan de rand van je hardware capaciteit.
Even opsommen:

• Geen hardware encryptie ondersteuning,
• OpenVpn is single threaded, dus maar een core wordt gebruikt.
• Netwerk interfacing op een pi 3 wordt via een USB channel gedaan (dus zeer instabiel)

Als je hem dan rechtstreeks aan het internet hangt dan krijgt hij meer te doen wat anders het Ziggo modem voor je doet en dat pushed hem waarschijnlijk net over de rand.

Dit is allemaal geen probleem als 'ie achter een router hangt dus dan is het dat ook niet als 'ie direct online hangt en hij verder hetzelfde doet. Er moet dus een externe factor zijn die ervoor zorgt dat de performance omlaag (en/of belasting omhoog) gaat, a.k.a. hij doet waarschijnlijk onbedoeld extra dingen die niet zijn opgemerkt.

Dat ziggo modem doet dingen als collisions afhandelen, retries opvragen voor missing tcp packages en fragmented packages weer samenvoegen.

Mja. Lees je alsjeblieft eens in in de verschillende lagen uit een van de netwerk-modellen en kijk wat waar precies gebeurt. Van de zaken die je noemt gebeuren ze allemaal of in beide situaties in de Pi, of in geen van beide situaties in de Pi, of gewoon helemaal niet). Ze verschuiven niet tussen Pi en modem. Anders is de Pi namelijk opeens een modem geworden (collisions) of het modem/router een endpoint (fragmented packets samenvoegen). "Retries" worden niet "opgevraagd", de verzender krijgt gewoon geen bevestiging dat een packet is aangekomen en stuurt het opnieuw. Je kan als ontvanger namelijk niet weten dat iets niet is aangekomen als je niet eens weet of het überhaupt verstuurd is.

En mtu size is eigenlijk alleen van belang voor het versturen van data, maar als je de optimale setting wilt weten dan kun je dat simpel met een ping command uitzoeken door te kijken bij welke mtu size het DF bit gezet wordt.

Als je met jargon strooit, zorg dan alsjeblieft dat je klepel op de juiste plek hangt anders klinkt het zo raar. De DF-bit is "Don't Fragment" en die zet je zelf door -f aan (de Windows-versie van) ping te geven. Hierdoor zal je packet gedropt worden en hopelijk krijg je een ICMP-packet terug die dat vertelt, anders een timeout. Als je DF niet zelf zet zal je ping ongeacht packetsize goed kunnen gaan, waardoor je ten onrechte denkt de MTU te hebben gevonden.

EDIT:
Was even vergeten dat die box op linux draai dan moet je dus dit commando geven:

[...]

Hier zie je waarom het belangrijk is om te weten wat je doet in plaats van iets wat je ergens gelezen hebt gewoon na te papegaaien, het commando wat je noemt stuurt pings zonder DF-bit dus die gaan lekker door ongeacht MTU. Je moet -Mdo toevoegen dus ping 8.8.8.8 -s1500 -Mdo.

Ben(V) schreef op woensdag 10 februari 2021 @ 11:26:
Dat had ik toch uitgelegd.

Even in lekentaal dan:
Als je hem achter een router plaats doet die router een hoop werk dat die pi niet meer hoeft te doen.
Als die pi dan op het randje staat gaat het net nog goed.
Als hij zelf het internet verkeer moet afhandelen dan red hij het niet meer.

Dus ten overvloede: dit klopt niet zonder meer met de context van je eerdere post in het achterhoofd. Het kan natuurlijk wel zo zijn dat er bijv. veel traffic naar het IP van TS toe gaat wat normaal niet bij de Pi aan zou komen, maar als er verder geen devices op het netwerk zijn die (via de Pi) allerlei netwerkverkeer aanvragen is dat niet heel logisch. Gelukkig is het wel meetbaar.

Ben(V) schreef op donderdag 11 februari 2021 @ 09:21:
[...]


Ik geloof dat jouw claims van geen kanten deugen.

Het zou je sieren om je eigen claims eens van tevoren te verifiëren. Het is niet de eerste keer dat ik jou hierop betrap.

Als hij er een router tussen zet dan haalt hij de performance wel, conclusie de router die hij ertussen zet handelt dingen af die de pi daarna niet meer hoeft te doen, waardoor hij net binnen de mogelijkheden van zijn beperkte capaciteit blijft.

Dat is een conclusie, niet per se de conclusie. Een waarschijnlijke eerste verdachte is wel overmatig extra netwerkverkeer wat anders niet op de Pi binnenkomt of uitgaat, maar

En dat is ook logisch want die router zal out of sync packages afhandelen, retries voor corrupte packages en collisions en dat hoef de netwerkkaart van die pi niet meer te doen wat toch al een zwak punt is.

zoals eerder gezegd, dit is onzin. Alles wat in het modem-gedeelte gebeurde zal daar blijven, alles wat in de Pi gebeurde zal in de Pi blijven. Dat het modem een router-gedeelte heeft ingebouwd betekent niet dat de zaken die je noemt daar plaatsvinden en dan "uitgeschakeld" worden bij het uitschakelen van het router-gedeelte.

[Thralas]

Streutjes schreef op vrijdag 12 februari 2021 @ 22:28:
Welke OS gebruik jij? Was dat rechtstreeks aan internet of achter ‘n router?

Raspbian 10 (Buster) binnen m'n eigen LAN (dus alleen een switch ertussen).

Streutjes schreef op zaterdag 13 februari 2021 @ 12:43:
Over eth1 snel (60/10) en over tun0 en tun1 traag en onstabiel.

Ter bevestiging: het is dus zonder tunnel altijd stabiel (met en zonder router), maar de probleemsituatie treedt alleen op met OpenVPN?

TX drops. Maar dat zie ik ook gebeuren als de PI achter de router zit en dan is de snelheid wel goed.

Ik heb geen enkel idee waar ik het nog moet zoeken... Iemand suggesties?

Je hebt nog wat zaken niet geprobeerd (of het niet verteld); tcp mode OpenVPN en de suggesties uit de laatste 2 alineas van mijn eerdere post:

Thralas in "Linux router met twee OpenVPN connectie's traagheid"

Begin ook vooral met iperf (udp/tcp) zonder OpenVPN, want het opmerkelijkste verschil tussen je stabiele/niet-stabiele situatie lijkt vooralsnog udp vs. tcp.

[Streutjes]

Update:

Zojuist weer wat tests gedaan.

Interfaces gewisseld (configuratie). Dus de USB-ethernet en de onboard card. Dat haalde niks uit.

De OpenVPN op TCP gedraaid. Yep. Stukken beter. Veel stabieler en ik haal nu 53/8,5. Dit is al zeer bruikbaar.
Zitten er nadelen aan het op TCP te draaien?

Echter, toch vreemd dat achter 'n router ik op UDP een hogere snelheid haal.

Kleine toevoeging: Beide OpenVPN's heb ik niet zelf in beheer, dus mbt configuratie kan ik weinig. Echter diegene welke ik voor internet gebruik (betaalde VPN) heb ik zowel een UDP als TCP config van.

[ Voor 29% gewijzigd door Streutjes op 13-02-2021 23:07 ]

[Thralas]

Streutjes schreef op zaterdag 13 februari 2021 @ 21:43:
De OpenVPN op TCP gedraaid. Yep. Stukken beter. Veel stabieler en ik haal nu 53/8,5. Dit is al zeer bruikbaar.
Zitten er nadelen aan het op TCP te draaien?

Niet echt. Het is theoretisch niet handig, maar daar zijn meer spookverhalen over geschreven (zoek maar eens op tcp meltdown) dan dat het nu werkelijk een probleem is. Meestal werkt het prima.

Ik zou altijd udp gebruiken waar het kan, maar hier heb je een uitstekende reden om daar vanaf te wijken.

Echter, toch vreemd dat achter 'n router ik op UDP een hogere snelheid haal.

Hier iemand met vergelijkbare problemen. Ik denk dat er (weer) iets loos is met de Connectbox (heb je die ook?) en udp.

Thralas in "Rest van het netwerk traag door bittorrent verkeer"

[Streutjes]

Thralas schreef op zondag 14 februari 2021 @ 12:43:
[...]


Niet echt. Het is theoretisch niet handig, maar daar zijn meer spookverhalen over geschreven (zoek maar eens op tcp meltdown) dan dat het nu werkelijk een probleem is. Meestal werkt het prima.

Ik zou altijd udp gebruiken waar het kan, maar hier heb je een uitstekende reden om daar vanaf te wijken.


[...]


Hier iemand met vergelijkbare problemen. Ik denk dat er (weer) iets loos is met de Connectbox (heb je die ook?) en udp.

Thralas in "Rest van het netwerk traag door bittorrent verkeer"

Duidelijk.

Jep, ik heb de Ziggo Connectbox, maar dan dus wel in bridge mode.

De overstap naar fiber van T-Mobile loopt. Dan kan ik de PI rechtstreeks aansluiten (met de fiber-ethernet converter welke ze meeleveren, enkel VLAN300 aansturen en verbinding)

[Plopeye]

Streutjes schreef op woensdag 10 februari 2021 @ 21:48:
[...]


Bedankt voor deze verhelderende info, super!
Hier kan ik iets mee.


[...]

Precies dat dus :-)

TV loopt inderdaad via coax, niet over internet/VLAN oid.

Ik zou OpenVPN op TCP kunnen testen, zou dat iets kunnen oplossen?

TCP over TCP tunneling is heel dom om te doen...

Je krijgt dan last van TCP meltdown:
https://openvpn.net/faq/what-is-tcp-meltdown/

[Streutjes]

Even voor diegene wie geen vertrouwen had/heeft in de performance van de PI voor router/netwerk doeleinden:
Met de PI4 haal ik 565Mbps als ik van VLAN1 naar VLAN2 iets kopieer (beide via eth0 van de PI). De routering/processing loopt via de PI. Uiteraard zie ik het CPU gebruik en load omhoog schieten, maar dit lijkt me een prima score. Ik ken routers welke deze snelheid niet halen...

[ Voor 18% gewijzigd door Streutjes op 09-03-2021 21:25 ]

[Streutjes]

Update:

Inmiddels heb ik glasvezel van T-Mobile. De PI zit rechtstreeks op de glas-ethernet convertor.

Zonder OpenVPN haal ik 47/47Mbit en een ping van 6ms.
Met OpenVPN (UDP) haal ik 45,5/45,5 met een ping van 7ms.

Dus nu werkt alles zoals het hoort en ook gewoon op UDP.

Kortom, Ziggo/Connectbox was het probleem!

Mbt performance: Als ik de internet verbinding vol balast over de VPN, dus 45mbit, dan is de load +/- 0,43 en het CPU gebruik van OpenVPN +/- 43% (1 van de 4 core's dus), aangezien OpenVPN "single threaded" is, prima score, headroom genoeg!

[ Voor 28% gewijzigd door Streutjes op 15-03-2021 18:36 ]