Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem Jak najít bottleneck v síti

Zdravím,
hledám způsob, jak najít bottleneck v síti. Přemýšlím, zda neexistuje nějaký lepší způsob než odpojovat jednotlivá zařízení...

Mám SMB server, kde mám připojení 1000/500Mbit a přistupuji k tomu z počítače, kde mám 1000/1000Mbit (reálně 600/800Mbit.)
Jako tunel používám Wireguard. Očekával bych, že při přenášení souborů (např. pomocí Windows Explorer,) bych měl dosahovat alespoň 50MB/s. Reálně však mám pouze 22MB/s pro download, resp. 17MB/s pro upload.

Otestoval jsem připojení přes iperf3 a bohužel mi opravdu vychází 123Mbit/s, resp. 190Mbit/s. Během testování byla rychlost na serveru 900/500Mbit a na počítači 600/800Mbit.

V čem může být háček? Wireguard by rychlost limitovat neměl a HW na kterém běží také ne. Zkoušel jsem přesunout Wireguard z BPI R2 na server s Ryzen 5 5600G a výsledek je stejný, takže HW bottleneck by být neměl. Zkoušel jsem také různé tooly pro otestování rychlosti a vychází mi to stejně.

Díky za objasnění.

Předmět Autor Datum
smb server běží na jakém hw přesně - banana pí? ryzen 5? cokoliv jiného tajného? wireguard má s tvou…
lední brtník 27.09.2022 01:09
lední brtník
Omlouvám se, pořádně jsem to nesepsal. Připojuji se přes internet, tzn. že přes Wireguard připojuji…
wg 27.09.2022 01:36
wg
Otestoval jsem připojení bez Wireguardu. Při 10 paralelních spojeních pomocí iperf dostávám při down…
wg 27.09.2022 09:32
wg
Mám teorii, proč se to takto může chovat. Internetové připojení na server je přes PPPOE a maximální…
wg 27.09.2022 12:45
wg
Pokial mas podozrenie na PPPoe tak ho zmen na iny protokol.
fleg 27.09.2022 20:22
fleg
Mám optiku od T-Mobile a PPPoE je vyžadováno pro autorizaci(?.) Místo pronájmu jejich modemu jsem vy…
wg 28.09.2022 18:02
wg
Takze to nie je pripojenie na server, ale len sposob autentifikacie u ISP. Cize PPPOE nemusis vobec…
fleg 28.09.2022 18:14
fleg
Hezký!!! Dobře jsi to debugoval. :-) Nastavení MTU na routeru nestačí. To ti jen zaručí fragmentaci…
touchwood 27.09.2022 20:41
touchwood
Moc děkuji 😊 MSS se pokusím spíše vyhnout kvůli možnému vytížení CPU. Zkusím si s tím nějak pohrát a…
wg 28.09.2022 18:16
wg
CPU nic vytěžovat nebude, naopak, je to velmi elegantní řešení (které se aplikuje jen na SYN pakety,… poslední
touchwood 28.09.2022 19:46
touchwood

smb server běží na jakém hw přesně - banana pí? ryzen 5? cokoliv jiného tajného?
wireguard má s tvou lan sítí společného co, nebo čemu stojí v cestě? nemáš snad doma svůj hw se sambou, z toho krámu vpn tunel na jiný hw jako brána do zbytku lan sítě? pokud to tak není, proč ho zmiňuješ?
nebo ta samba běží fyzicky jinde / v jiné síti?

Omlouvám se, pořádně jsem to nesepsal.

Připojuji se přes internet, tzn. že přes Wireguard připojuji dvě naprosto rozdílné síťe.
Samba běží na Ryzen 5, VPN server běží na BPI R2 a slouží jako brána k serveru.

Zkoušel jsem rychlost internetu z obou sítí.
Ze sítě, kde je server, mám na speedtest.net, provider ISP Alliance, rychlost 900/500Mbit.
Ze sítě, kde je klientský počítač, mam na speedtest.net, provider ISP Alliance, rychlost 600/800Mbit.

Vyzkoušel jsem si ověřit připojení napřímo bez Wireguardu a ukazuje se, že se nedostanu přes 250Mbit. Průměr za 60s jsem měl 244Mbit/s, resp 230Mbit/s na druhou stranu. Testoval jsem to pomocí iperf3, takže vliv HW nebo čehokoliv dalšího na straně serveru/klienta, je možné vyloučit.
Vůbec nevím, čím by to mohlo být. Předpokládám nějaký bottleneck na straně ISP? Proč by byla rychlost tolik rozdílná, když na ISP Alliance mám rychlost připojení minimálně dvojnásobnou?
Zkráceně: problém zřejmě není s VPN, ale někde "po cestě".
Fyzicky jsou od sebe obě zařízení vzdálené asi 12km.

EDIT: vyzkoušel jsem v iperf vytvořit více paralelních spojení - nastavil jsem na 4 - a rázem dosahuji bez Wireguardu rychlost 800Mbit/s. Možná bude problémem opravdu HW. Zkusím s tím ještě něco udělat.

Otestoval jsem připojení bez Wireguardu. Při 10 paralelních spojeních pomocí iperf dostávám při downloadu 500Mbit/s (očekávaná plná rychlost) a upload na server 800Mbit/s (taktéž očekávaná plná rychlost.) Obojí otestováno pouze pomocí iperf.
Pokud zapnu Wireguard, tak po nastavení MTU ze 1420 na 1400, dostávám upload pouze 400Mbit/s, což je poloviční rychlost než očekávaná, ale download mám 500Mbit/s, což je plná rychlost.
Při MTU z klienta nastavených na 1420, byla rychlost uploadu okolo 190Mbit/s. Po nastavení na zmíňených MTU 1400, se dostanu na těch 400Mbit/s. Nastavení jiné hodnoty MTU na serveru, nemá vliv na výkon.

Mám dvě otázky - proč má MTU vliv pouze na jedné straně - tzn. nastavení jiného MTU na serveru neovlivní download na klienta, ale nastavení MTU1400 na klientovi upload na server zdvojnásobí? Proč je rozdíl pouze u uploadu a download jede plnou rychlostí?

iperf server a WG server běží pro testovací účely na stejné mašině a vytížení CPU nepřesáhlo 12% a peak na jednom jádru byl max. 60%.
Normálně bych to neřešil, ale zrovna upload mi je potřeba, jelikož většinou právě nahrávám data na NASku z PC.

Moc děkuji za případné odpovědi.

Mám teorii, proč se to takto může chovat.
Internetové připojení na server je přes PPPOE a maximální MTU je nastavené na 1492. V případě stahování ze serveru se používá ono maximální MTU 1492 a nedochází k roztříštění na více fragmentů.
Jakmile však nahrávám něco na server, tak se někde po cestě fragment "obalí" a přesáhne 1492 bytů, což způsobí roztříštění na více fragmentů.

Mohl bych poprosit někoho o validaci? Je to vůbec možné? Moc o tomto nevím, pouze bych to rád vyřešil a optimalizoval.
Jsem schopný nasimulovat podobné tříštění pokud nastavím MTU na IFace klienta na hodnotu < 1470. Následně se rychlost uploadu sníží ze 400Mbit/s na 190Mbit/s.
Ve Wireguardu mám nastavené MTU1380. Zkoušel jsem s tím hýbat, ale nemá to žádný výsledek.

Hezký!!! Dobře jsi to debugoval. :-)

Nastavení MTU na routeru nestačí. To ti jen zaručí fragmentaci paketů. Musel bys totožné MTU nastavit už na serveru se sambou a opačně na klientovi za tunelem (což je kontraproduktivní v LAN), nebo a to je druhá možnost, nastavit MSS-clamping na routeru s Wireguardem. Hezky popsané a vysvětlené to je zde:

https://blog.ipspace.net/2013/01/tcp-mss-clamping-what-is-it-and-why-do.html

v iptables nějak takto:

iptables -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380

Hýbat s MTU na WG iface nedává smysl, ten se musí vejít do 1500B klasického IP nebo dokonce PPP paketu - proto má "jen" 1380B. Nezapomeň nastavit clamping na obou stranách wg tunelu.

CPU nic vytěžovat nebude, naopak, je to velmi elegantní řešení (které se aplikuje jen na SYN pakety, tedy první paket spojení, pak to už jede samospádem)

edit: jinak technicky:
MTU na ethernetu: 1500
MTU na PPPoE: 1492 (PPP zapouzdření si bere 8B)
MTU na WG přes PPPoE: 1492 - 60 = 1432B max. (za předpokladu, že je použito pouze IPv4, jinak je to minus 80B)

Zpět do poradny Odpovědět na původní otázku Nahoru