Win2k server heeft na een tijdje verhoogde ping

[Antyrael]

Ik zoek al twee weken naar een oorzaak/oplossing hiervoor, ik word er aardig gaar van. Hopelijk heb ik hier meer kans dan op Google enzo.

Het probleem: Windows 2000 server zit via Essentkabel online sinds 2 weken nu, na enkele uren probleemloos online te zijn verandert plotseling de gemiddelde ping van <50ms naar >900ms met enorm veel timeouts.
Een reboot is het enige dat (tijdelijk) helpt, NIC disablen -> enablen verandert niets. Vandaag was het zelfs al na ongeveer een uur dat de verbinding verslechterde.
De melding die op de kabelmodem voorkomt tijdens deze hoge pings is "IP filter fout", volgens Essentkabel zou dit een fout in de configuratie van het netwerk moeten zijn.
Op de Win2k server is ook RRAS ingesteld als NAT server, IP adressen zijn handmatig op alle werkstations ingesteld met correcte subnet masks en Default Gateways.
De 5 IP adressen (dus exclusief het netwerk- en broadcastadres) zijn allemaal op de NIC naar het kabelmodem ingevoerd met subnet masks 255.255.255.248.

Met alléén het eerst te gebruiken IP adres komt dit probleem ook voor; ook terwijl RRAS nog niet in gebruik was kwam het probleem voor (er is nooit gebruik gemaakt van een andere vorm van ICS op de server).
Ik kan het helaas niet testen door een ander apparaat, zoals een laptop, op de kabelmodem aan te sluiten en kijken of het dan goed gaat, want het gebeurt te willekeurig lijkt wel.

Als ik alles bij elkaar neem lijkt het erop alsof een apparaat in het netwerk de oorzaak is, door een foutieve configuratie. Maar als ik dan bedenk dat het probleem zich ook al voordeed vóórdat er gebruik gemaakt werd van enige vorm van internet delen, weet ik het niet meer te zoeken
De server is een dual Xeon op een Intel moederbord, deze heeft 2 onboard Intel NICs. We hebben er een extra netwerkkaart (3Com) ingezet en de bewuste onboard NIC disabled in het BIOS, helaas blijft ook hiermee het probleem bestaan.

Omdat ik er al een hele tijd mee bezig ben denk ik dat ik het overzicht kwijt ben en daardoor dingen over het hoofd zie, als iemand een (of meer) tip(s) heeft zijn die meer dan welkom!!!

Groeten,
Bob

[ajhaverkamp]

Is het de ping van werkstation naar server?
Of de ping van werkstation naar internetlocatie?

Wat zegt "tracert" als het om de tweede situatie gaat? Waar zit dan de traagheid?

[Jazzy]

Vergeet niet om uiterst zwijgzaam te zijn over je server, specificaties van de server, nics en inrichting zijn alleen maar overbodige ruis.

[Jazzy]

Oeps...

[ Voor 97% gewijzigd door Jazzy op 30-06-2003 12:58 ]

[Antyrael]

Die hoge pings zijn van en naar die server toe over het internet, op de LAN kant is er niets aan de hand.
Geen enkel werkstation kan nog internetten als dit probleem zich voordoet (of een website wordt hééééél langzaam opgebouwd).
Een pathping naar de server geeft hoge packetloss weer bij het IP adres van de server.
Na een reboot is het weer normaal, voorlopig.

[Antyrael]

Jazzy schreef op 30 June 2003 @ 12:58:
Vergeet niet om uiterst zwijgzaam te zijn over je server, specificaties van de server, nics en inrichting zijn alleen maar overbodige ruis.

Bedankt voor de tip, maar meer gedetaileerde gegevens dan ik nu heb gegeven was ik ook niet van plan om vrij te geven (die zijn ook niet noodzakelijk om dit op te kunnen lossen;))

[nielsj]

dat vraag ik me toch wel een beetje af, je weet pas waar het aan ligt als je het opgelost hebt...

maar draai je misschien een firewall oid op die machine, en zou deze het kunnen veroorzaken?

[Antyrael]

NielsJ schreef op 30 June 2003 @ 13:05:
dat vraag ik me toch wel een beetje af, je weet pas waar het aan ligt als je het opgelost hebt...

Dat is wel zo, maar ik ben van mening dat wanneer ik IP adressen enzo ga weggeven dit niet echt helpt het probleem op te lossen, wat voor type mobo het is kan natuurlijk geen kwaad

NielsJ schreef op 30 June 2003 @ 13:05:maar draai je misschien een firewall oid op die machine, en zou deze het kunnen veroorzaken?

De firewall is op dit moment uitgeschakeld ivm het probleem oplossen.

[ Voor 12% gewijzigd door Antyrael op 30-06-2003 14:48 ]

[Reptile209]

Op mijn werk @ helpdesk wel eens een ping van 900 zien terugvallen naar 30 toe KaZaa uitgezet werd... er hoeft maar 1 PC in het netwerk KaZaa te draaien, en bent zuur... hint?

[Antyrael]

Reptile209 schreef op 30 June 2003 @ 13:11:
Op mijn werk @ helpdesk wel eens een ping van 900 zien terugvallen naar 30 toe KaZaa uitgezet werd... er hoeft maar 1 PC in het netwerk KaZaa te draaien, en bent zuur... hint?

Goeie hint, maar dit is hier niet het geval, niemand draait P2P (peer-to-peer, niet pay-to-play ) software en er is ook geen "verstopte" FTP of andere server aanwezig.
toch bedankt

[vyruz]

ik heb ook zoiets gehad met mijn windows 2000 server....
heb er toen service pack 3 opgezet en had op een of andere manier geen problemen meer.
weet niet of je die er al op heb gezet
het zat bij mij namelijk ook niet in de RAS server en had ook geen FTP ofzoiets draaien...

[Verwijderd]

idd met een tracert kijken waar de problemen zitten... als dat idd bij je server zit ff de sniffer van win2k installen (add/remove software) en kijken waardoor het komt...

[Brahiewahiewa]

Hmmz, zou 't niet zo kunnen zijndat je server geowned is en dattie wordt gebruikt voor het relayen van SPAM of als temp FTP?

[Verwijderd]

Idd, wat Brahiewawhatever al zei. doe es een search naar 'lpt*;com*;nul*' voor de zekerheid. en een netstat -a -n als je ping 14,000 krijgt

[Verwijderd]

mwa... het zou kunnen, maar het disablen van de netwerkkaart zou het probleem dan ook moeten verhelpen

edit: verkeerd gelezen... als het probleem nog eens voordoet en je disabled en vervolgens enabled je netwerkkaart weer hou je dan hetzelfde probleem?

[ Voor 43% gewijzigd door Verwijderd op 30-06-2003 17:10 ]

[DynaMikeY]

Misschien een (AD-)DNS replicatie naar de buitenwereld die congestie op de lijn veroorzaakt?

Heb je misschien IIS draaien? Keer IIS Lockdown Tool erover heen knallen. En uiteraard sowieso ding patchen totdat je erbij neervalt

[ Voor 45% gewijzigd door DynaMikeY op 30-06-2003 17:38 ]

[Verwijderd]

nee hoor... sp4 en klaar

zowieso, waar dat oneindig patchen vandaan komt... 2 patches na sp3!!! waarvan je slechts de laatste patch hoeft te installen bij een nieuwe server (sp3 + 1 patch; nu dus sp4)

http://www.microsoft.com/...kid=3&submit1=go&isie=yes

[ Voor 102% gewijzigd door Verwijderd op 30-06-2003 17:47 ]

[Predator]

PNS -> NT

[Antyrael]

Thx voor alle reacties! ik heb echter al gecontroleerd op *.diz en *.nfo bestanden (en bestanden >5 MB), ook heb ik zelf gekeken in de dirs die gebruikt worden voor dit soort sh*t.
Maar die SP4, is die al veilig genoeg bevonden om op een productie server te installeren? ik ben meestal niet zo happig om heel snel na het uitkomen van een SP om die zsm te installeren.
En AD wordt niet naar buiten gerepliceerd, het is een eenzame server die verder geen contact met andere servers heeft.
Inderdaad, disablen en enablen van de NIC helpt niet, helaas

Vandaag is het allemaal nog erger zelfs, vanochtend vroeg werd het probleem verholpen door een reboot, minder dan een uur later was het alweer raak. Weer een reboot en nu, een half uur later: alwéér mis!!
Ik ga er nu naartoe en hoop met de network monitor het een en ander te kunnen opvangen wat wellicht de oorzaak is.
Ik laat het nog wel weten!

[Verwijderd]

kijk als je direct openstaat naar inet zou ik toch zo snel mogelijk sp4 installeren (wel even testen natuurlijk). als je netjes achter een firewall zit heeft het allemaal niet zo'n haast.

overigens als dit een productie server is en je hangt hem direct aan internet, ben je volgens mij niet goed snik

[ Voor 29% gewijzigd door Verwijderd op 01-07-2003 11:44 ]

[Verwijderd]

Kijk eens naar task manager of er ergens een service veel resources vreet, misschien dat die dan ook veel netwerkverkeer veroorzaakt,
En het is idd goed om even een netwerk-scan tooltje te draaien, je zoekt het probleem nu bij de server maar misschien dat een werkstation veel broadcast aan het genereren is via de server naar buiten toe.
Doet het probleem zich ook voor als alle werkstations uit staan?

[Jimbolino]

- ontkoppel je server van je LAN en kijk of het probleem aanhoudt

- instal een du-meter op al je pc's en kijk wie er traffic genereerd

- virusscan je hele netwerk

[pierre-oord]

Misschien, nog makkelijker, is het om een firewall als zonealarm erop te zetten, zie je zo welke programma's er naar buiten willen gaan en wat er in wil. En idd, sluit hem van het LAN af.

[Antyrael]

Wederom bedankt voor de reacties!!

Ik heb (voor de derde maal) contact gehad met de kabelprovider en wat blijkt, er blijkt dus tóch iets niet helemaal 100% te zijn in het netwerk van ze.

Installeren van SP4 heeft helaas niet geholpen, ik heb de server al alleen aan de kabel gehad en toen was het probleem ook aan de orde. Een virusscanner staat er ook op en ik heb daar wel iets aangepast, nl het realtime scannen heb ik uitgezet (zou niet de eerste keer zijn dat dit problemen veroorzaakt).
Er draaide ook geen service die veel resources gebruikte op het moment van de slechte verbinding.
Ik wacht nu nog de bevindingen van de kabelprovider af, want ik vermoed dat het toch daar ligt.
Nogmaals bedankt en ik laat nog weten hoe het afloopt

[Antyrael]

Net gebeld door de kabelprovider, er was inderdaad een probleem in de centrale die ze gerepareerd hebben. Nu zou de verbinding goed moeten zijn en blijven!
We zullen het wel zien

In ieder geval bedankt voor de hulp en ideeën iedereen!

[Antyrael]

Het probleem is nog steeds niet opgelost

Ik begin het echt zat te worden, ik weet het niet meer te vinden......
Ik kan er geen logica meer in vinden.

[Brahiewahiewa]

Dan moet je de network monitor (agent) installeren op die machine en kijken wat er allemaal over de lijn gaat en hoe.

[Antyrael]

Brahiewahiewa schreef op 03 July 2003 @ 16:26:
Dan moet je de network monitor (agent) installeren op die machine en kijken wat er allemaal over de lijn gaat en hoe.

Die heb ik al draaiende gehad op het moment van die hoge pings, het enige wat ik daarbij zag was veel uitgaande Kerberos traffic naar een hele zooi voor mij onbekende IP adressen.

Hier één van die vele packets, misschien dat iemand het bekend voorkomt?

10 235.671875 LOCAL USC IN431B73 SSP Unknown Security Support Provider SERVERNAAM 238.67.27.115 IP
Frame: Base frame properties
Frame: Time of capture = 7/1/2003 11:23:32.389
Frame: Time delta from previous physical frame: 0 microseconds
Frame: Frame number: 10
Frame: Total frame length: 418 bytes
Frame: Capture frame length: 418 bytes
Frame: Frame data: Number of data bytes remaining = 418 (0x01A2)
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
ETHERNET: Destination address : 000000000000
ETHERNET: .......1 = Group address
ETHERNET: ......0. = Universally administered address
ETHERNET: Source address : 000000000000
ETHERNET: .......0 = No routing information present
ETHERNET: ......0. = Universally administered address
ETHERNET: Frame Length : 418 (0x01A2)
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 404 (0x0194)
IP: ID = 0xC205; Proto = UDP; Len: 404
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Precedence = Routine
IP: Type of Service = Normal Service
IP: Total Length = 404 (0x194)
IP: Identification = 49669 (0xC205)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 1 (0x1)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x2BF4
IP: Source Address = 192.168.0.1
IP: Destination Address = 238.67.27.115
IP: Data: Number of data bytes remaining = 384 (0x0180)
UDP: IP Multicast: Src Port: Unknown, (3078); Dst Port: Unknown (1434); Length = 384 (0x180)
UDP: Source Port = 0x0C06
UDP: Destination Port = 0x059A
UDP: Total length = 384 (0x180) bytes
UDP: UDP Checksum = 0x5EE5
UDP: Data: Number of data bytes remaining = 376 (0x0178)
MSRPC: dg RPC Ping: seq 0x1010101 opnum 0x101 frag 0x101 serial 0x101 act id 0x01010101010101010101010101010101
MSRPC: Version = 4 (0x4)
MSRPC: Packet Type = Ping
MSRPC: Flags 1 = 1 (0x1)
MSRPC: .......1 = Reserved -or- First fragment (AES/DC)
MSRPC: ......0. = Not a last fragment -or- No cancel pending
MSRPC: .....0.. = Not a fragment -or- No cancel pending (AES/DC)
MSRPC: ....0... = Receiver to repond with a fack PDU -or- Reserved (AES/DC)
MSRPC: ...0.... = Not used -or- Does not support concurrent multiplexing (AES/DC)
MSRPC: ..0..... = Not for an idempotent request -or- Did not execute guaranteed call (Fault PDU only) (AES/DC)
MSRPC: .0...... = Not for a broadcast request -or- 'Maybe' call semantics not requested (AES/DC)
MSRPC: 0....... = Reserved -or- No object UUID specified in the optional object field (AES/DC)
MSRPC: Flags 2 (dg header prop) = 1 (0x1)
MSRPC: .......1 = Reserved
MSRPC: ......0. = No cancel pending
MSRPC: .....0.. = Reserved
MSRPC: ....0... = Reserved
MSRPC: ...0.... = Reserved
MSRPC: ..0..... = Reserved
MSRPC: .0...... = Reserved
MSRPC: 0....... = Reserved
MSRPC: Packed Data Representation
MSRPC: Serial Number High Byte = 1 (0x1)
MSRPC: Object Identifier = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
MSRPC: Interface Identifier = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
MSRPC: Activity Identifier = 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
MSRPC: Server Boot Time = 16843009 (0x1010101)
MSRPC: Interface Version (dg header prop) = 16843009 (0x1010101)
MSRPC: Sequence Number (dg header prop) = 16843009 (0x1010101)
MSRPC: Operation Number (c/o Request prop. dg header prop) = 257 (0x101)
MSRPC: Interface Hint = 257 (0x101)
MSRPC: Activity Hint = 257 (0x101)
MSRPC: Packet Body Length = 257 (0x101)
MSRPC: Fragment Number = 257 (0x101)
MSRPC: Authentication Protocol Identifier = 1 (0x1)
MSRPC: Serial Number Low Byte = 1 (0x1)
SSP: Unknown Security Support Provider
SSP: Authentication Level = 226 (0xE2)
SSP: Key Sequence Number = 8 (0x8)
SSP: Pad = 49705 (0xC229)
SSP: SSP Data

[Brahiewahiewa]

Antyrael schreef op 03 July 2003 @ 16:39:
[...]het enige wat ik daarbij zag was veel uitgaande Kerberos traffic naar een hele zooi voor mij onbekende IP adressen.[...]

Waren dat allemaal adressen in een reserved broadcast range, zoals 238.67.27.115 ?

[Antyrael]

Brahiewahiewa schreef op 03 July 2003 @ 18:05:
[...]

Waren dat allemaal adressen in een reserved broadcast range, zoals 238.67.27.115 ?

Lijkt er niet op, ze eindigen oa op 1, 0, 14, 16, 18, 19, 20, 21, 22, 24, 25, 26, etc.
Dacht je aan een smurf (of andere DDoS) aanval?

[Brahiewahiewa]

Antyrael schreef op 04 July 2003 @ 09:20:
[...]Lijkt er niet op, ze eindigen oa op 1, 0, 14, 16, 18, 19, 20, 21, 22, 24, 25, 26, etc.

Uhm, het gaat met name om de getallen waar de ip-adressen mee beginnen

Dacht je aan een smurf (of andere DDoS) aanval?

Nope, ik denk dat je server aan het broadcasten is over je public nic. Doe's de output van ROUTE PRINT posten

[Antyrael]

Ok, zodra ik weer op de server kan zal ik dat ff posten

[axis]

Misschien ook een leuke tip: Eeye Iris.. Is een 'mooie' sniffer, die het allemaal wat leesbaarder maakt.. laatst ook op een productieserver geinstalleerd gehad, omdat je bij het sniffen met de network monitor door de bomen het bos niet meer zag. Tekent ook grafiekjes met traffic.

[Antyrael]

Hier is de route print output:

===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 195.aa.bbb.97 195.aa.bbb.100 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 1
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 1
195.aa.bbb.97 255.255.255.248 195.aa.bbb.100 195.aa.bbb.100 1
195.aa.bbb.100 255.255.255.255 127.0.0.1 127.0.0.1 1
195.aa.bbb.255 255.255.255.255 195.aa.bbb.100 195.aa.bbb.100 1
224.0.0.0 224.0.0.0 192.168.0.1 192.168.0.1 1
224.0.0.0 224.0.0.0 195.aa.bbb.100 195.aa.bbb.100 1
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
Default Gateway: 195.aa.bbb.97
===========================================================================

[Brahiewahiewa]

Je kunt de metric van je Internet adres verlagen vwb de broadcast range:

code:

route change 224.0.0.0 mask 224.0.0.0 195.aa.bbb.100 metric 20

dan zou dat verkeer "binnen" moeten blijven

[Antyrael]

Dat ga ik zeker doen, wie weet is dit het antwoord wat ik zocht, thx

[Antyrael]

Het werkt niet, ik krijg de melding "The route specified was not found.".
toch staat deze er wel in, ik heb het ook geprobeerd met IF 195.aa.bbb.100 erachter maar dat hielp ook niet.

Ik kan ook nog toevoegen dat op het moment dat de pings weer rond de 1000msec zaten, ik Iris (of zelfs Network Monitor) de melding gaf dat de NIC ongeldig was en dat ik een andere interface moest kiezen. (NIC disablen/enablen hielp dit niet oplossen)
..... het wordt steeds gekker lijkt wel

[Antyrael]

Sorry dat ik zo achter elkaar zit te posten, maar ik heb nog iets nieuws.

Op het netwerk zit ook een Netpilot met een dedicated ISDN verbinding.
Tussen de Win2k server (192.168.0.1) en de Netpilot (192.168.0.254) is totaal geen traffic mogelijk, ieder IP adres die ik op de server zet is onbereikbaar vanaf de Netpilot.
De server kan verder alles op het netwerk bereiken en het complete netwerk kan de Netpilot én de server gewoon bereiken.

Ik kom er nu weer achter dat 192.168.0.10 op de server wél bereikbaar is voor de Netpilot en dat wanneer ik dit IP adres als hoofd IP adres instel ik de Netpilot ook kan bereiken.

Op de Netpilot zie ik helemaal geen enkele instelling waar de IP adressen 192.168.0.1 en 192.168.0.2 in voorkomen, geen route of firewall regel, niets.

[Antyrael]

Ok, probleem gevonden, Veritas Backup Exec versie 9.0 gebruikt SQLserver 2000 en die zat zo vreselijk te broadcasten.
Ik kan me niet voorstellen dat dit normaal is, dus ik ben even wezen zoeken en denk dat ik hier de oorzaak heb:
http://www.symantec.com/a...data/w32.sqlexp.worm.html

Bedankt voor de hulp allemaal! ik ga eens kijken waarom Veritas een insecure SQL server meeïnstalleert .....

[Jimbolino]

Jimbolino schreef op 01 July 2003 @ 22:05:
- virusscan je hele netwerk

al die moeite... en bleek het gewoon een sql wormpje te zijn

[Antyrael]

inderdaad
Maar er staat Norton Antivirus CE 7.62 op, met de laatste virusdefinitions, je zou toch verwachten dat die zo'n oud wormpje wel zou herkennen.
Het was uiteindelijk de slammer-remover (ook van Symantec) die de besmette dll herkende.