traag netwerk

[Verwijderd]

Situatie schets:



Probleem: Ons netwerk is af en toe erg traag. Het duurt b.v 30 seconden voordat er een map geopend kan worden. Email verzenden(smtp) gaat zo traag dat de clients nog al eens een time-out krijgen.

hardware/software:
Servers PII 450 mhz,(raid5) NT4server (PDC)
PII 500 mhz, NT4server (Mail, MDaemon)
PIV 1,4 GHZ(Raid 5) Win2kserver (domaincontroller voor win2k domein)
PIII 1 GHZ, Win2kserver (Exchange 2000)

We zitten hier in een overgangsfase, vandaar de 2 domeinen. De windows2000 DC draait DNS,DHCP,WINS.

Zoals in de afbeelding weergegeven is zitten alle servers samen op een 3com 3300 switch. Deze loopt via een utp5 kabeltje naar een andere 3com 3300 switch. Vanaf deze switch lopen er weer een aantal kabels naar een aantal andere switches. Hier zitten de clients dus op.

Het bladeren/zoeken van mappen bestanden en emailen lukt tussen de servers zelf wel heel goed. Alles is dan bloedje snel. Echter vanaf de clients is het niet voorruit te branden.

Ook van WS01 is het erg traag. De vertragende factor zit hem dus niet in de utp kabel tussen de 2 switches.

Een wins probleem? Nee want zodra ik een server benader via \\ip.naam.hier.zo dan is het net zo traag. Daarnaast gaat het emailen direct via ip (Ik heb dus nergens hostnamen ingevuld).


Wat hebben we zelf al bedacht/getest:
1. Alle kabels vanaf, patchkast tot werkplek zijn doorgemeten door HVL
2. De firmwares van de switches geupgrade/gedowngrade.
3. Ik heb met mrtg grafieken gemaakt van de nt4 server en van de koppeling tussen de 2 3com switches. Dataverkeer van de nt4server is gemiddeld 130 kb/s en tussen de koppeling loopt gemiddeld 200 kb/s. Aangezien we een 100Mbit netwerk hebben zou dit geen probleem moeten zijn.
4. Sniffen (1 Poort van de switch krijgt alle data ook toe gezonden) We zien niks raars voorbij vliegen als het netwerk traag is. Dus geen overvloed aan broadcast pakketjes e.d)

Probleem doet zich voor tussen alle verschillende OSsen. (win9x/2000/xp)

Alles is dus met vlagen, dan is het weer snel, dan weer langzaam. Er is gewoon geen pijl op te trekken

[Tylen]

Wegens het niet werken van je plaatje Deze vraag: Zijn de domein namen wel verschillend?

[Verwijderd]

Jeroen_Tielen schreef op 25 oktober 2002 @ 11:03:
Wegens het niet werken van je plaatje Deze vraag: Zijn de domein namen wel verschillend?

Sorry, firewall stond iets te scherp afgesteld

Ja, de 2 domeinen zijn verschillend. Ze hebben trouwens geen Trust met elkaar.
Maar zoals in mijn verhaal staat wekrt het geheel op IP nivo ook traag.

[Verwijderd]

Heb je niet 1 switch meer tussen de tweede 3com en de werkstations ??

[Massiefje]

en als je nou naar alle machine's pingt, stuk voor stuk. Is het dan ook langzaam ?
Zo ja, check je netwerk-/ip-settings. Gateway zou weleens fout kunnen zijn.

[Arno]

* Arno is ook wel eens traag

Maar ff ontopic: Staan je servers/switchpoorten wel op fullduplex

[Verwijderd]

Waar draaien de clients op? XP soms?

[Verwijderd]

Lezen is ook een vak.
Al geprobeerd om die XP-machines uit te laten tijdens een test?

[Verwijderd]

Massiefje schreef op 25 oktober 2002 @ 11:18:
en als je nou naar alle machine's pingt, stuk voor stuk. Is het dan ook langzaam ?
Zo ja, check je netwerk-/ip-settings. Gateway zou weleens fout kunnen zijn.

Als ik naar de machines ping dan heb ik gewoon een normale ping van 4 a 500 usec.

Traag schreef op 25 oktober 2002 @ 11:19:
/me is ook wel eens traag

Maar ff ontopic: Staan je servers/switchpoorten wel op fullduplex

Ja alles full-duplex. Maar zou er hier iets verkeerd gaan dan zou de communicatie tussen de servers onderling ook traag moeten zijn. En dat is dus niet het geval.

Verwijderd schreef op 25 oktober 2002 @ 11:27:
Lezen is ook een vak.
Al geprobeerd om die XP-machines uit te laten tijdens een test?

Wij van systeembeheer draaien XP. Behalve ik Die systemen hebben we ook al eens uit gezet. Ook een test-linux server die samba draait heeft al aan het "shutdown -h" commando moeten geloven

[Verwijderd]

Verwijderd schreef op 25 oktober 2002 @ 11:30:
[...]


Als ik naar de machines ping dan heb ik gewoon een normale ping van 4 a 500 usec.

Moet de round trip delay time bij 100Mb ethernet niet kleiner zijn dan 5,12 usec ???
Of vergis ik me daar zo hard in ??

[Arno]

Verwijderd schreef op 25 oktober 2002 @ 11:38:
Moet de round trip delay time bij 100Mb ethernet niet kleiner zijn dan 5,12 usec ???
Of vergis ik me daar zo hard in ??

Dat weet ik zo niet, maar 500 is best wel veel

[_Arthur]

Verwijderd schreef op 25 oktober 2002 @ 11:30:

Ja alles full-duplex. Maar zou er hier iets verkeerd gaan dan zou de communicatie tussen de servers onderling ook traag moeten zijn. En dat is dus niet het geval.

Ik ben van mening dat hier wel eens het probleem kan zitten. FullDuplex wil nog wel eens meer problemen vooroorzaken dan halfduplex. Zeker met autosensing clients/netwerk kaarten.

Je belasting op je netwerk is in het algemeen genomen minimaal, dus zou het netwerk ook op half-duplex meer dan een perfecte performance moeten leveren.

Probeer eens op een paar clients hun netwerk verbinding op halfduplex (fixed) te zetten en niet op autosensing (of fullduplex). Stel dit aan beide kanten in, dus op zowel de switch als op de client, niet 1 kant op autosensing laten staan. En test nog eens.

[Verwijderd]

Bij Ethernet 10BaseT is die round trip delay time max. 51,2. Bij 100BASET moet dit dus 10X sneller, wat logisch is. Anders detecteert je netwerk geen collisions. Dan krijgt je netwerk last van "late collision". Deze late collision vetragen je netwerk ongelooflijk omdat vele pakketten verloren gaan. Het beste is een keer de standaarden van IEEE 802.3u ter hand te nemen. En een keertje nakijken dat je nergens in het netwerk te veel switchen passeert naar de servers en dat nergens kabels zijn die te lang zijn of segmenten die te groot zijn.
Netwerkproblemen die enkel af en toe de kop opsteken zijn het lastigst om te zoeken he !!!
Daar heb je het meeste plezier aan

[bibroni]

Een paar vraagjes:
-Sinds wanneer doen de problemen zich voor? Altijd al of sinds een wijziging.
-Staan alle machines in hetzelfde V-lan?
-Zijn er bij een lange ping-test drops te zien?
-Is er gecontroleerd of mac-adressen uniek zijn?
-staan er nog meer machines op de switches?
-Is al geprobeerd om één voor één de servers uit te zetten?

Het klinkt alsof er ergens collisions op het netwerk zitten oid (ik neem trouwens aan dat de verbinding tussen de twee switches op trunking staat???)

[ Voor 0% gewijzigd door bibroni op 25-10-2002 12:18 . Reden: typ-o ]

[Verwijderd]

kalyndra schreef op 25 oktober 2002 @ 11:59:
Een paar vraagjes:
-Is er gecontroleerd of mac-adressen uniek zijn?

Het klinkt alsof er ergens collisions op het netwerk zitten oid (ik neem trouwens aan dat de verbinding tussen de twee switches op trunking staat???)

Elke NIC heeft een uniek MAC-Adres dus... als men daar niet manueel gaat emuleren is een mac-adres ALTIJD uniek.

Over de collision ben ik het met je eens. Volgens mij is er ergens een kabel die te lang is, of een segment te groot waar hij late collision gaat aanmaken.

[Tylen]

geef eens een pathping van een client naar de server en kijk hoe de verbinding is.

[bibroni]

ja in theorie is elk mac adress uniek, ik heb zelf al meegemaakt dat dit niet het geval was (ik weet het de kans is erg klein maar toch....) het kan nooit kwaad om dit te checken. Het geeft erg leuke effecten in je netwerk........

[djack]

Nu wil ik niet strange overkomen maar ge moet eens proberen met uw poorten op half duplex te zetten.
Een vriend van mij had het zelfde probleem, een netwerk da mega slow was toch was het niet de pc's nog de kabels, dus de switch was het probleem, met het testen van netwerk met cisco werkte alles naar behoren.
Door een klein toeval had hij de poorten nor half duplex gezet en ineens hup de performatie van zijn netwerk was zoals het moest zijn.

Bugje in de soft ? tja wie zal het zeggen ma als dit uw probleem oplost ....

[Predator]

4. Sniffen (1 Poort van de switch krijgt alle data ook toe gezonden) We zien niks raars voorbij vliegen als het netwerk traag is. Dus geen overvloed aan broadcast pakketjes e.d)

Zag je ook geen overdadige hoeveelheden errors ? (runts/giants/CRC-errors/...)

Hoe staan de poorten op je switch zelf ?

[Verwijderd]

Flow control ?

[Verwijderd]

mischien een hele stomme vraag hoor (ben zelf puur *nix admin): Staat je resolving wel goed? Ondanks het feit dat je ip addressen gebruikt, kan de applicatie mischien nog steeds een gethostbyname() call uitvoeren, wat evt de boel kan vertragen op het moment dat je resolving niet goed is ingesteld.

[Verwijderd]

Alvast bedankt voor het meedenken. We gaan morgen alle servers een keer plat leggen en dan knippen we kabel tussen de 2 3com's eruit. Dan kunnen we tenminste het een en ander uitsluiten. Ik houd jullie op de hoogte!

[snakeye]

Verwijderd schreef op 25 oktober 2002 @ 11:54:
Bij Ethernet 10BaseT is die round trip delay time max. 51,2. Bij 100BASET moet dit dus 10X sneller, wat logisch is. Anders detecteert je netwerk geen collisions. Dan krijgt je netwerk last van "late collision". Deze late collision vetragen je netwerk ongelooflijk omdat vele pakketten verloren gaan. Het beste is een keer de standaarden van IEEE 802.3u ter hand te nemen. En een keertje nakijken dat je nergens in het netwerk te veel switchen passeert naar de servers en dat nergens kabels zijn die te lang zijn of segmenten die te groot zijn.
Netwerkproblemen die enkel af en toe de kop opsteken zijn het lastigst om te zoeken he !!!
Daar heb je het meeste plezier aan

bij Full-duplex ethernet heb je helemaal geen collisions. En dan nog bij (echte) switches is elke poort een apart ethernet segment en collisions blijven dan beperkt tot die ene poort de rest op die switch heeft daar geen last van. Jouw verhaaltje gaat dus niet op voor zijn situatie.


Waar het inderdaad het meeste op lijkt is duplex mismatch. Als de ene kant half duplex praat en de andere kant full duplex krijg je de raarste dingen. Dus check op server zelf dat die ook op 100 Mbit full duplex staan en stel het keihard in ook op de switch. En check ook eens de duplex settings van de poorten die met de andere switches verbonden zitten. Set deze aan beide zijde vast op 100 Mbit full duplex. suc6

[sko]

Wat ik meegemaakt heb bij 3com switches, als je NICs handmatig op full-duplex zet gaat het fout, de snelheid zakt naar 1MByte/sec , alles automatisch werkt wel goed

[Verwijderd]

Laat eens wat 'net statistics workstation' zien. Dit om te zien of het aantal errors erg hoog tov het aantal packets. (Ik weet niet of er een 'mooier' WIN-prog. is om tx/rx errors te kunnen zien. Zoiets als 'entstat' op AIX)

[Kabouterplop01]

Als je eens probeerde de servers en de switch waarop de servers gepatched zitten, alsmede de kabel tussen de 2 switches(en de poorten) op 100 full te laten en de pc's aan de andere kant 10 half; moet je opletten.

100mBit full werkt leuk als er 1 pc aan de switch zit. Je maakt een collission/broadcast domain door de switch met een andere switch met een kabel te verbinden, waarop meerdere pc's zitten. Alle MAC adressen gaan over dat zelfde kabeltje.

good fun!

[Kabouterplop01]

Ik bedoel dus de poorten en netwerkkaarten van de pc's op 10 half
De verbinding tussen de 2 switches 100 full.
En de servers en poorten ook 100 full.

[The Eagle]

sko schreef op 26 oktober 2002 @ 22:14:
Wat ik meegemaakt heb bij 3com switches, als je NICs handmatig op full-duplex zet gaat het fout, de snelheid zakt naar 1MByte/sec , alles automatisch werkt wel goed

Kan ik beamen. Uit eigen ervaring weet ik dat het autosensing bij 3Com's af en toe vreemde quirks kan hebben...zou me niks verbazen als het daarin zat.

[Fish]

je zegt .. bij vlagen

kan het zijn dat er meerdere users zwaar aan comuniceren (printjobs?) zijn waardoor de switch "overbelast" word ... hoe noem je dat backplane o.i.d.?

[FatalError]

Een switch, ook hele goedkope, overbelast je niet zomaar.

[Coen Rosdorff]

Telnet eens naar die switches, en bekijk de traffic en error counters van de betrokken poorten eens.

[Fish]

FatalError schreef op 28 oktober 2002 @ 20:57:
Een switch, ook hele goedkope, overbelast je niet zomaar.

Nou ja dat maak ik maar op omdat het "met vlagen" voorkomt

[TrailBlazer]

heb je een probleem met het opzetten van sessies of is de feitelijke dataoverdracht ook traag zet eens een FTP server op en haal dan een bestand binnen van een gieg ofzo hoe gaat dat