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í.
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:
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.
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 rozchodit. Kdyžtak bych se ještě obrátil pro radu 😁
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)