ZeroWindow problemen

[pkwarts]

Ons bedrijf heeft last van een redelijk vervelend probleem met een linux server (centos). Op deze server draait een webserver, SVN en samba, een allround servertje dus.

De gebruikers met Windows 7 melden dat zij vaak de server niet kunnen bereiken, welk protocol maakt niet uit (ook pingen naar de machine werkt dan niet). Na enkele minuten kunnen zij weer keurig verbinden en is het probleem weg. Ditzelfde probleem is ook 1 keer op een Mac voorgekomen. Mijn eigen workstation draait Fedora en ikzelf heb dit probleem geen 1 keer gehad (en ik zit constant op de server).

Onze netwerk-topologie is vrij simpel: een unmanaged Cisco switch met daaraan de router, alle workstations en de server. Mijn workstation (die nog nooit problemen heeft gehad) zit dus op dezelfde manier verbonden met de server als de rest van de workstations.

Op de server heb ik een aantal keer Wireshark laten draaien en zag dat elke keer als een PC niet meer verbinding kon leggen met de server, deze een window size van 0 aan de server doorgaf en vervolgens een tijdlang geen pakketjes meer stuurde naar de server. Na een tijd probeert de server weer verbinding te leggen met de client waarna alles weer vrolijk hervat wordt.

Het belangrijkste stukje log: 192.168.1.100 is de server, 192.168.1.136 de client. Bovenaan wat verkeer wat nog goed gaat, onderaan de log zit het probleem.
No. Time Source Destination Protocol Info
22367 10.154122 192.168.1.136 192.168.1.100 TCP 54871 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1464 WS=8

No. Time Source Destination Protocol Info
22368 10.154209 192.168.1.100 192.168.1.136 TCP http > 54871 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 WS=7

No. Time Source Destination Protocol Info
22369 10.154372 192.168.1.136 192.168.1.100 TCP 54871 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0

No. Time Source Destination Protocol Info
22371 10.154799 192.168.1.136 192.168.1.100 HTTP GET /recognize/favicon.ico HTTP/1.1

No. Time Source Destination Protocol Info
22372 10.154864 192.168.1.100 192.168.1.136 TCP http > 54871 [ACK] Seq=1 Ack=564 Win=15744 Len=0

No. Time Source Destination Protocol Info
22402 10.176158 192.168.1.100 192.168.1.136 HTTP HTTP/1.1 200 OK (image/vnd.microsoft.icon)

No. Time Source Destination Protocol Info
22403 10.176318 192.168.1.100 192.168.1.136 TCP http > 54871 [FIN, ACK] Seq=1164 Ack=564 Win=15744 Len=0

No. Time Source Destination Protocol Info
22405 10.176999 192.168.1.136 192.168.1.100 TCP 54871 > http [FIN, ACK] Seq=564 Ack=1164 Win=64512 Len=0

No. Time Source Destination Protocol Info
22406 10.177053 192.168.1.100 192.168.1.136 TCP http > 54871 [ACK] Seq=1165 Ack=565 Win=15744 Len=0

No. Time Source Destination Protocol Info
22689 10.378000 192.168.1.100 192.168.1.136 TCP http > 54871 [FIN, ACK] Seq=1164 Ack=565 Win=15744 Len=0

No. Time Source Destination Protocol Info
22690 10.378298 192.168.1.136 192.168.1.100 TCP [TCP ZeroWindow] 54871 > http [ACK] Seq=565 Ack=1165 Win=0 Len=0

Van wat ik lees is dit een zeer lastig probleem om te diagnosticeren. Hoe ik de situatie in de laatste vier regels zie (en verbeter me als dat fout is), is dat de client eerst aan de server doorgeeft dat hij een window van 64512 byte heeft, de server dan 2 pakketjes stuurt, en de client vervolgens laat weten dat zijn buffer vol is en de server voorlopig niks moet sturen.

Wat we tot nu toe geprobeerd hebben en niet heeft geholpen:

• Andere netwerkkabels van de server naar de switch en van de workstation naar de switch
• Een netwerkkaart van 1 van de workstations op 100mbit gezet (omdat mijn workstation het wel altijd deed en op 100mbit werkt)

Heeft iemand enig idee waar we het probleem moeten zoeken of hoe we nuttige tests kunnen uitvoeren? Anders moeten we namelijk 1 voor 1 dingen gaan vervangen omdat we geen flauw idee hebben waar het probleem ligt.

[zenith]

die zerowindow moet je er echt uitkrijgen, wat ik wel is tegenkom is dat een virusscanner zich met de content bemoeid en dat niet snel genoeg doet. Met een zerowindow komt er ook geen bit data meer van de sender naar de receiver totdat er weer een window update vanuit de receiver komt. Het feit dat icmp wegvalt op het moment dat je ook zero windows ziet van de client geeft aan dat er ook wat op je netwerk aan de hand is. is je server met dual nics aangesloten of kun je de client op de switch hangen om mogelijk dingen uit te sluiten, hoe lang duurt het voor je pingetjes naar de server weer terug zijn (ivm met spanningtree oid)

wat wel apart is aan je tracefile is dat je server eigelijk direct de haak er weer opgooit.

post anders eens een rauwe tcpdump op de server met hierin het probleem dat zich voordoet?

[ Voor 6% gewijzigd door zenith op 25-03-2012 11:50 ]

[pkwarts]

zenith schreef op zondag 25 maart 2012 @ 11:48:
die zerowindow moet je er echt uitkrijgen, wat ik wel is tegenkom is dat een virusscanner zich met de content bemoeid en dat niet snel genoeg doet. Met een zerowindow komt er ook geen bit data meer van de sender naar de receiver totdat er weer een window update vanuit de receiver komt.

Bedoel je met de sender de computer die de zerowindow aangeeft (de client)? In dat geval, dat is inderdaad wat ik steeds zie. Het is de server die de verbinding steeds weer opzet na een tijd, niet de client.

Het feit dat icmp wegvalt op het moment dat je ook zero windows ziet van de client geeft aan dat er ook wat op je netwerk aan de hand is. is je server met dual nics aangesloten of kun je de client op de switch hangen om mogelijk dingen uit te sluiten, hoe lang duurt het voor je pingetjes naar de server weer terug zijn (ivm met spanningtree oid)

Geen dual nics in de server. Overal lees ik dat het probleem zou moeten liggen bij de partij die zerowindow eruit stuurt, maar aangezien het ALLE Windows machines zijn, zou dat te toevallig zijn. Ik zal maandag alles rigoreus bij gaan houden, maar het duurt altijd 30 sec tot 3 minuten voordat de computers weer kunnen verbinden (voordat de server weer een keep-alive eruit stuurt), zeker geen timeout van een seconde oid.

De client hangt al direct aan de switch, of bedoel je wat anders?

wat wel apart is aan je tracefile is dat je server eigelijk direct de haak er weer opgooit.

Ik heb een fout gemaakt door een stuk log weg te laten, want er is wel degelijk nog wat verkeer tussen de client en server na zerowindow: de client sloot drie smb sessies af en de server bevestigde deze alle drie (alhoewel ik niet weet of dat wel aankwam bijvoorbeeld) Ik zal deze maandag posten.

post anders eens een rauwe tcpdump op de server met hierin het probleem dat zich voordoet?

Ik zal maandag nog meer loggen en dit hier posten. Gut feeling, ligt het probleem bij de server, netwerk apparatuur of de (windows)clients?

[zenith]

pkwarts schreef op zondag 25 maart 2012 @ 13:25:
[...]


Bedoel je met de sender de computer die de zerowindow aangeeft (de client)? In dat geval, dat is inderdaad wat ik steeds zie. Het is de server die de verbinding steeds weer opzet na een tijd, niet de client.


[...]

Geen dual nics in de server. Overal lees ik dat het probleem zou moeten liggen bij de partij die zerowindow eruit stuurt, maar aangezien het ALLE Windows machines zijn, zou dat te toevallig zijn. Ik zal maandag alles rigoreus bij gaan houden, maar het duurt altijd 30 sec tot 3 minuten voordat de computers weer kunnen verbinden (voordat de server weer een keep-alive eruit stuurt), zeker geen timeout van een seconde oid.

De client hangt al direct aan de switch, of bedoel je wat anders?


[...]

Ik heb een fout gemaakt door een stuk log weg te laten, want er is wel degelijk nog wat verkeer tussen de client en server na zerowindow: de client sloot drie smb sessies af en de server bevestigde deze alle drie (alhoewel ik niet weet of dat wel aankwam bijvoorbeeld) Ik zal deze maandag posten.


[...]


Ik zal maandag nog meer loggen en dit hier posten. Gut feeling, ligt het probleem bij de server, netwerk apparatuur of de (windows)clients?

De client geeft hier het zerowindow. Dus die zegt tegen je server, stop met data zenden want ik heb geen buffer meer. Dit blijft net zolang totdat de client een window update stuurt, hierna gaat de server weer zenden.

Een volledige tracefile zal zeker helpen.