Traag netwerkverkeer tussen twee specifieke hosts

[triet]

Ik heb in mijn thuissituatie een probleem waarbij ik werkelijk waar geen idee heb waar dit aan zou kunnen liggen. Zelf ben ik zeer ervaren als't gaat om netwerk- en serverbeheer en ik ga hier proberen jullie uit te leggen wat het probleem is. Ondertussen ben ik radeloos, en dat zegt wat! :-)

Thuis heb ik een server staan met daarop draaiend "Proxmox" (KVM oplossing), gebaseerd op Debian. Hierop draaien een aantal virtuele machines, gebridged naar eth0. Die zitten via een Netgear GS108T aan een Netgear WNDR3800 met daarop OpenWrt AA (12.09) via een KPN Glasvezel (100/100) verbinding. Dit is een PPPoE met MSS clamping aan vanwege de kleinere (1460) MTU door de PPPoE overhead. Mijn verbindingen vanaf het netwerk (zowel server, clients, bedraad en draadloos) zijn zowel inbound als outbound prima, ik haal de te verwachte snelheden.

Daarnaast heb ik een Synology DS209+II (laatste software) staan op een andere locatie via een Ziggo 60/6 verbinding. Ook deze haalt de te verwachten snelheden. Datzelfde geldt voor de clients op dat netwerk.

Oftewel: so far so good en nergens problemen.

Nu draai ik een rsync backup vanaf mijn server (vanuit een virtuele machine) naar de synology. Deze backup gaat met een snelheid tussen de 300-450KBps, consequent. Dit is veel trager dan ik zou mogen verwachten dus daarom ben ik op onderzoek gegaan naar hoe dit kan. De grap is namelijk dat ik vanaf een willekeurige andere client in mijn netwerk WEL de volledige snelheid naar die remote Synology haal. Dat is bizar en ik heb de logica nog niet kunnen vinden.

Server maakt gebruik van MSI B75 Pro3-M:

code:

r8169 0000:03:00.0: eth0: RTL8168evl/8111evl at 0xffffc90001850000, bc:5f:f4:81:b5:b7, XID 0c900800 IRQ 27
r8169 0000:03:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

MTU staat op 1500.

uname -a geeft:

code:

Linux vbx 2.6.32-22-pve #1 SMP Mon Jul 15 08:36:46 CEST 2013 x86_64 GNU/Linux

Wat ik heb gedaan:

Uitsluiten dat het aan de server zelf ligt:

• Transfer tussen server en lokale clients: > 12MBps
• Zelfde backup naar andere remote server (in datacentre): goede snelheid, zoals je mag verwachten
• Zowel vanaf host als virtuele machines. Hier ligt't probleem dus niet.

Uitsluiten dat het aan de Synology ligt:

• Een transfer vanaf mijn (wireless) MacBook Pro of raspberry (bedraad 100Mbps) naar de Synology, ongeacht protocol (rsync/ssh/ftp): tussen de 3-5MBps! Ongeveer 10x zo snel!
• Een andere, gelijk geconfigureerde Proxmox server (zelfde mobo) via een XMSnet verbinding met gelijke OpenWrt router en instellingen (op MSS clamping na) haalt WEL goede snelheden naar de Synology.

Protocol misschien traag? Encryptie vertraagt de boel?

• In plaats van rsync een transfer via ssh (met en zonder compressie) geprobeerd, net zo traag
• In plaats van rsync een transfer via ftp (met en zonder ssl) geprobeerd, net zo traag
• Nee dus, want vanaf mijn Macbook of raspberry gaat het, ongeacht protocol, WEL snel.

Wellicht KVM of bridging een probleem?

• Transfer niet vanaf virtuele machine maar vanaf host gedaan: net zo traag
• Server netwerkconfig kaal gemaakt (/etc/network/interfaces alleen eth0 interface up gebracht, verder geen bridges of KVM draaiend), net zo traag
• Bovendien zou je dan verwachten dat het verkeer lokaal ook problematisch is.

Specifieke TCP problemen? Window scaling?

• net.ipv4.tcp_window_scaling (default 1) ook op 0 gezet: geen verschil.
• tcpdumps gedraaid en oa. windowing tactiek, mtu discovery etc. vergeleken tussen verschillende machines: geen echte verschillen kunnen ontdekken, resultaat blijft hetzelfde

Andere zaken?

• MSS clamping uitgezet? Geen resultaat (ja, dat m'n verbinding niet goed meer werkt uiteraard)
• iptables/QoS doorgespit: niets ingesteld
• Andere switchpoorten geprobeerd, geen verschil
• Direct op router aangesloten (interne switch), geen verschil
• Boel rebooten, zowel switch, router, server en synology, geen verschil
• Andere lokale IP adressen geprobeerd (ja, logisch vind ik't toch al niet meer dus wie weet): geen verschil
• Router (Cisco wireless ziggo ding) offsite gereboot, geen verschil
• Router offsite instellingen allemaal doorgelopen, geen verschil
• Backupfiles vanaf server via NFS geshared naar raspberry en vanaf daar de rsync draaien: SNEL!

Conclusie so-far:

Uiteindelijk kom ik dus niet verder dan dat specifiek DIE fysieke server met de offsite Synology een probleem heeft. Al het andere werkt prima. Dat is toch apart? En dat'ie ook nog eens altijd dezelfde snelheden aanhoudt? Ik vermoed een complot want ik snap hier werkelijk niets meer van!

Wat ik nog niet heb gedaan:

• Server ander OS geprobeerd en kijken of het dan nog steeds is met deze server
• Server naar andere client op remote locatie connecten (staat nu verder niets waarmee ik dat kan testen)

Meer weet ik even niet te proberen... Mijn hoop ligt bij de collectieve kennis van jullie want ik sta op het punt het op te geven. Help?

21:06u: toegevoegd dat ik ook naar een remote server de backup heb gedraaid en dat wel goed gaat.

[CaptJackSparrow]

Flink verhaal maar ik geloof dat deze test er niet tussen stond. Die specifieke back-up vanuit die virtuele machine al naar een andere opslaglocatie geprobeerd?

[triet]

CaptJackSparrow schreef op woensdag 24 juli 2013 @ 20:51:
Flink verhaal maar ik geloof dat deze test er niet tussen stond. Die specifieke back-up vanuit die virtuele machine al naar een andere opslaglocatie geprobeerd?

Ja, die heb ik ook al geprobeerd. Alles vanaf de virtuele machine naar andere (remote) locaties gaan wel goed. Ik heb o.a. naar servers (van werk) in datacentres geprobeerd en dat gaat dus wel goed...

[CaptJackSparrow]

Lastig. Hier zijn dan ook redelijk wilde speculaties niet misplaatst.

Het lijkt dus om de combinatie van de server (onafhankelijk van virtueel of fysiek) en bestemmingslocatie of, vanuit de bestemmingslocatie gezien, om de combinatie met de bronlocatie te gaan. Klopt dat?

Ik denk aan: 'ergens' speed/duplex settings (gecombineerd met?) hardwaregerelateerde (MAC?) setting? Een (managed?) switch of router setting gekoppeld aan de bron of doellocatie(IP?) (van beide kanten gezien). Je hebt al tussenliggende apparatuur in de netwerken (aan beide kanten?) deels omzeild. Wat heb je er minimaal tussen gehad?

Had die andere server die wel goede snelheid haalde hetzelfde IP adres?

Heb je evt. een losse/andere NIC geprobeerd?

[Fish]

Doe de test eens met iperf ipv bestanden schuiven (als de synologie dat kan)

het eerste waar ik dan aan denk is dat de snelheid met opzet ergens is begrensd
Of dat deze anders wordt gerouteerd over een drukkere machine

[Verwijderd]

Ik ben (helaas) geen Linux expert maar bij cisco-switches heb je een aparte setting voor MTU en Jumbo frames (Jumbo voor 1/10gbit links)

Ik zie bij jouw staan : "eth0: jumbo features [frames: 9200 bytes]" Indien de server met 9200byte frames verstuurt zal de wndr3800 een hoge load krijgen omdat hij het zal moeten fragmenteren, hierdoor zal je performance inzakken. Kan je Jumbo frames niet uitzetten? Indien dat nog niet het gewenste resultaat oplevert probeer de mtu eens op de server op 1460 te zetten (matchen met max mtu router)

[triet]

N.a.v. de opmerking over iperf heb ik uitgebreid tests zitten draaien en daar kwam toch wel een interessant iets naar boven: de transfersnelheid is niet alleen naar deze host traag maar naar het gehele "internet". Oftewel: lokaal gaat goed (~ 300Mbps iperf tussen router en machine), maar remote gaat traag.

Host -> router: ~ 300Mbps
Host -> raspberry: ~ 97Mbps
Host -> remote server (60/6 ziggo): ~ 5Mbps
Host -> remote server (100Mbps): ~ 20Mbps

Raspberry -> router: ~ 97Mbps
Raspberry -> host: ~97Mbps
Raspberry -> remote server (60/6 ziggo): ~ 30Mbps
Rasyberry -> remote server (100Mbps): ~75Mbps

De host draait Proxmox 3.0, draaiend op een RedHat 2.6.32 kernel. Exact dezelfde config staat ook op een andere locatie achter XMSnet glas: geen problemen.

Mijn glas (KPN) heeft echter een PPPoE verbinding waardoor de MTU over deze link 1492 is.

Uiteindelijk ben ik zover dat als ik de MTU op de host op 1200 zet ik ongeveer gelijkende snelheden haal als de raspberry ook haalt.

Wat ik niet kan verklaren:
- waarom heeft de raspberry (en mijn mac etc.) geen last van deze problemen?
- waarom helpt een MTU van 1200 wel, maar hoger (vrijwel) geen verschil?

Ik vermoed nu dat aan de linux kernelversie ligt en dat in nieuwe kernels er dus wijzigingen gedaan zijn. Uiteraard kan het ook nog hardware zijn, die heb ik nl. ook nog niet uitgesloten.

Hebben jullie nog tips m.b.t. MTU?

Update 17.52u: kernelupgrade (handmatig) gedaan naar 3.0.nogwat. Zelfde probleem..

[Wim-Bart]

Lijkt wel of je een MTU probleem hebt waarbij je server niet terug schakelt op een kleinere MTU. Ik heb sinds enige tijd zelf problemen met Jumbo Frames naar externe systemen. Op 1 of andere wijze lijkt het wel of de netwerk stack niet in staat is om te detecteren dat de gehele link geen Jumbo frames aan kan met als gevolg traagheid. Met name richting Linux systemen. Bij inspectie blijkt op netwerk niveau dat mijn systeem stug Jumbo frames blijft gebruiken en mijn router daarvan over zijn nek gaat. Terwijl intern alles goed werkt, Na uitschakelen Jumbo frames was alles opgelost

[triet]

Jumbo frames staan uit, zowel op de onderliggende switch en router. Overigens kan de Netgear WNDR3800 (router) met OpenWrt inderdaad zelf geen MTU > 1500 aan dus die snapt sowieso geen jumbo frames.

Ook heb ik de realtek driver (r8168/8111) gedownload van hun site en gecompiled - geen verschil met de stock linux driver (r8169).

Tot op heden nog geen enkel resultaat. Ik ben erachter gekomen dat ik met een iperf met --mss 536 nog een normale snelheid haal. Het lijkt dus iets met die MSS clamping te maken te hebben maar dan begrijp ik nog niet waarom alleen die specifieke server er last van heeft en bijv. mijn raspberry niet.

Om de on-board netwerkkaart uit te sluiten heb ik nu een Intel CT gigabit pci-e kaartje besteld om te kijken of daarmee de problemen wel verholpen zijn... Wordt vervolgd.

[johnkeates]

En als je alle netwerk onderdelen op een lagere MTU zet dan je PPPoE link?

Ik weet niet welke switch methode je gebruikt (vde? gewoon een bridge met forwarding?) maar je kan soms ook op je switch/bridge zelf problemen hebben, die je dan niet in de OSsen kan oplossen.

Wat iperf betreft, heb je het 'de andere kant op' al geprobeerd? Waarschijnlijk heb je nu je VM steeds als iperf client gedraaid, of juist alleen maar als server, en dan kan het de moeite waard zijn om het dus omgekeerd ook te testen. Als dat verschil maakt is het een probleem met een filter ergens, als het geen verschil maakt heeft het dus met de gehele link te maken.

[Kabouterplop01]

Je MTU is 1492 vanwege pppoe; dan is je mss 1452 (altijd 40 bytes lager dan je MTU; 20 bytes IP overhead en 20 bytes TCP overhead)

[triet]

Intel kaartje (e1000) aangesloten, getest, zelfde probleem... Zucht.

code:

e1000e: Intel(R) PRO/1000 Network Driver - 2.4.14-NAPI
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
e1000e 0000:01:00.0: Disabling ASPM L0s L1
e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
e1000e 0000:01:00.0: setting latency timer to 64
e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:01:00.0: irq 29 for MSI/MSI-X
e1000e 0000:01:00.0: irq 30 for MSI/MSI-X
e1000e 0000:01:00.0: irq 31 for MSI/MSI-X
e1000e 0000:01:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 68:05:ca:19:f6:8d
e1000e 0000:01:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:01:00.0: eth1: MAC: 3, PHY: 8, PBA No: E46981-008
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Let op dat ik 'm rename van eth1 -> eth0 via udev, vandaar dat in de laatste regel plots eth0 staat.

Hardware lijkt het dus niet aan te liggen. Ik kan er nog steeds niet bij waarom mijn raspberry op 100Mbps goede snelheden haalt en deze bak met Gbit consequent kut draait zodra'ie door de PPPoE tunnel moet. Dat terwijl alle andere devices op het netwerk er dus geen last van hebben en'ie lokaal gewoon goed performt.

De tests draai ik trouwens vanaf de host (dus niet vanuit de virtuele machines, al maakt dat niet uit voor de resultaten). Daarbij heb ik ook de host kaal opgestart, zonder vlans, zonder virtuele machines, geen bridging etc., gewoon 'eth0' kaal met een IP adresje erop en dan de tests draaien.

Interessant aan de iperf output is trouwens de aparte Transfer sizes (256, 512 etc.):

code:

------------------------------------------------------------
Client connecting to XXXXXX, TCP port 5001
TCP window size: 97.0 KByte (default)
------------------------------------------------------------
[  3] local 10.0.100.6 port 40480 connected with xxxxxxxx port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec  1.12 MBytes  9.44 Mbits/sec
[  3]  1.0- 2.0 sec   384 KBytes  3.15 Mbits/sec
[  3]  2.0- 3.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  3.0- 4.0 sec   256 KBytes  2.10 Mbits/sec
[  3]  4.0- 5.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  5.0- 6.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  6.0- 7.0 sec   256 KBytes  2.10 Mbits/sec
[  3]  7.0- 8.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  8.0- 9.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  9.0-10.0 sec   512 KBytes  4.19 Mbits/sec
[  3]  0.0-10.5 sec  5.12 MBytes  4.08 Mbits/sec

Switch kan ik niet op lager dan 1518 zetten dus dat kan ik niet testen. De router op lager zetten maakte geen verschil.

Vanaf remote naar server heb ik nog niet getest, ga ik ook nog even doen maar ik verwacht weinig verschil.

Het enige wat ik nog niet gedaan heb is een clean OS (debian oid) erop zetten of even via debian live dingetje booten en dan maar tests draaien...

[johnkeates]

Heb je ook al packets ge-inspect met iets als Wireshark?

[Fish]

ff een brainfart hoor. maar stel je aan 1 kant de mtu in of aan 2 kanten?

[webfreakz.nl]

Ik weet niet welke kant(en) op je welke snelheid haalt maar je kan met IPTables de TCP MSS setten voor een specifieke destination:

http://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html

Dan kan je lokaal wel een hoge MTU gebruiken.

[ Voor 17% gewijzigd door webfreakz.nl op 30-07-2013 19:15 ]

[triet]

webfreakz.nl schreef op dinsdag 30 juli 2013 @ 19:05:
Ik weet niet welke kant(en) op je welke snelheid haalt maar je kan met IPTables de TCP MSS setten voor een specifieke destination:

http://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html

Dan kan je lokaal wel een hoge MTU gebruiken.

Nu gebruik ik OpenWrt met de --clamp-mss-to-pmtu optie op m'n outgoing (WAN) interface. Dat helpt dus blijkbaar voor alle machines, behalve de server waar het nu over gaat. Dit aanpassen naar --set-mss met verschillende waarden (1452, 1400, 536, ...) heeft allemaal geen effect. Dus helaas geen verbetering! Ik snap er nog steeds niets van.

[johnkeates]

Al ge-wiresharked? Kan met een goedkoop ethernet hubje.

En ik kan het zo 1-2-3 niet vinden, maar heb je ook al geprobeerd op 100mbit te draaien, of met half-duplex? (wat in dit geval vast niet helpt, maar alles wat je kan veranderen is de moeite waard in zo'n geval)

Eigelijk zou het het prettigst zijn als je layers kan elimineren. Als je link-layer 100% goed moet zijn, dan kan je in elk geval concenteren op de internet layer...

[triet]

johnkeates schreef op donderdag 01 augustus 2013 @ 19:00:
Al ge-wiresharked? Kan met een goedkoop ethernet hubje.

Ik ben met tcpdump aan de gang gegaan om iperf transfers te vergelijken tussen m'n server en een raspberry. Daar zag ik weinig verschil in maar dat ga ik nog'ns wat uitgebreider doen.

En ik kan het zo 1-2-3 niet vinden, maar heb je ook al geprobeerd op 100mbit te draaien, of met half-duplex? (wat in dit geval vast niet helpt, maar alles wat je kan veranderen is de moeite waard in zo'n geval)
[/quote]

Dat heb ik inderdaad gedaan waarmee het beter leek (100Mbps fdx). De snelheid was iig een stuk hoger maar vreselijk instabiel.

Eigelijk zou het het prettigst zijn als je layers kan elimineren. Als je link-layer 100% goed moet zijn, dan kan je in elk geval concenteren op de internet layer...

Ik heb:
- kabels vervangen
- server dichtbij switch geplaatst (1,5m)
- netwerkkaart aangepast (zie eerdere post van rtl8188 -> e1000)
- switchport aangepast, zelfs direct aan router gehangen
- kernel geupgraded (2.6.32 -> 3.2.x)
- mtu verlaagd
- sysctl values getuned
- ... en nog veel meer

Wat ik nu in ieder geval nog ga doen:
- verder tcpdumpen/wiresharken en analyseren (mijn switch ondersteunt port mirroring)
- kale linux install (live cd oid) op server opstarten en iperf tests draaien om toch b0rked OS uit te sluiten

Uiteindelijk heb ik dus wel een narrow-down gedaan dat het alleen bij DIE machine gebeurt en alleen naar BUITEN mijn lokale netwerk. Lokaal performt goed.

[johnkeates]

Hmm, dan kan het nog steeds op alle layers zitten. Interessant probleem. (minder leuk dat het nog niet opgelost is )

Een wireshark met port mirroring moet ook genoeg zijn. Een iperf die goed gaat met een iperf die niet goed gaat vergelijken zou genoeg opheldering moeten geven.

[webfreakz.nl]

Graag zie ik een packet capture op je remote destination, waarbij je de TCP-MSS geforceert hebt met IPTables op je server.

[Wim-Bart]

Te weinig buffers in je netwerk stack?

[webfreakz.nl]

Heb je al wat kunnen capturen? Of die IPTables settings kunnen proberen? Ik vond trouwens een andere optie, je kan in plaats van IPTables ook een static route setten met een fixed TCP-MSS, zie

man route

en zoek op MSS.

[triet]

Ik kom hier nog op terug, nu even vakantie! Maar nog steeds geen succes...

[triet]

Goed, daar ben ik weer. Uiteindelijk leek het toch sterk op een MTU probleem. Ik heb de router (NetGear WNDR3800 met OpenWrt trunk) vervangen door een MikroTik 951G-2HnD. Nu werkt de boel wel goed. Ook met gebruik van een pfSense doos is het probleem NIET aanwezig.

Oftewel: voor mij is het probleem opgelost d.m.v. niet meer gebruiken van OpenWrt. Hoera! Dank voor alle reacties.

[Will_M]

Misschien te laat met een reactie/vraag maar hoe stonden de duplex instellingen op de switches én nic's? Al vaker door anderen gevragen in dit topic maar ik zie er nergens een antwoord op óf ik lees er over heen.

Duplex modus van de ene switch is niet de te vergelijken met de settings op een ander merk switch.

auto/auto op een Cisco-Intel combi geeft andere resultaten dan een auto/auto op een Nortel/Intel combi, bijvoorbeeld.

Server - Switch vandaar altijd "Fixed" qua speed/negotiatie zetten is mijn advies!!

[ Voor 10% gewijzigd door Will_M op 28-09-2013 18:12 ]