CoolBlue

Hallo, ich hab bei einem kleinen Kunden (4x Win7 PC + 1x SBS2008) ein merkwürdiges Netzwerkproblem, das ich trotz Wochenlanger Suche einfach nicht finde. Zwischendurch bei der Arbeit stürzen alle netzwerkbasierenden Anwendungen einfach ab. Das heißt, welche die auf eine CIFS gesharete Datenbank zugreifen aber auch welche die auf eine Datebank mittels TCP Port zugreifen. Im Ereignislog steht einfach nur noch "Application Hang" und die Anwendung reagiert auch nicht mehr und es wird nur noch von Windows angeboten diese hart zu schließen. Ebenfalls macht der Explorer die gleichen Probleme, da die Ordnerumleitung für Desktop und Eigene Dateien aktiv ist. Es sind unterschiedliche Endgeräte. Zwei von DELL (recht neu) und ein selbst zusammen gebauter. Verwendet wird Intel und Broadcom Netzwerkinterfaces und ein HP 1800-24 Webmanged Switch. Folgendes hab ich schon gemacht: - HP Switch Firmeware Update - HP Switch gegen einen D-Link Home-Switch ersetzt - DELL Service angerufen, Board eines der Rechner getauscht - Netzwerktreiber und andere Systemtreiber und BIOS an einem der DELL PCs aktualisiert. - BIOS und Netzwerktreiber und andere Systemtreiber am Server erneuert. - TCP Offloading am Server deaktiviert. - IPv6 am Client deaktiviert (häkchen entfernt) - Netzwerkkabel der Clients getauscht. So wie ich das sehe muss es was mit einer zentralen Komponente zu tun haben, da die Anwendungen auf allen Clients recht zeitnah zeitgleich stehen bleiben. Da bleibt eigentlich nur der Server. Dieser loggt jedoch nichts im Ereignislog diesbezüglich. Die Anwendungen selbst laufen lokal soweit stabil. Der Server ist ein DELL T110 Server (halbes Jahr alt) mit Quad XEON und 8GB RAM. Derzeit ist auf keinem der Systeme ein Virenscanner installiert und auch keine Drittanbieter Firewall. Die Probleme existieren schon sehr lange und waren schon da als Windows auf den Geräten frisch installiert wurden. Weiß jemand Rat? Ist das vielleicht ein bekanntes Small Bussiness Server Problem?

@olc Die Idee hatte ich direkt nach meinem Post.. vor deiner Antwort.. hatte einfach nur keine Zeit gehabt hier zurück zu schreiben @TroRon Ja korrekt Norman Endpoint Protection (*zungebrecher sabbel*) ist das, auf dem Server läuft auch die Management Console fürs Netzwerk. Hab mit dem Dingen aber keine Erfahrung bissher, ist ein Neukunde von mir, der das schon dort laufen hatte. Verrate mir dein Wissen :-)

Hallo OLC, danke für die Tips. Manchmal hilft es einfach nur mal die Probleme wegzuschreiben oder jemanden zu erzählen und dann kommt man prompt auf eine neue Idee. Habe den Virenscanner deaktiviert und siehe da, es gibt keine Probleme mehr. Jetzt muss ich nur noch schauen ob es vill eine neue Version gibt (ich vermute mal das die aktuelle Version sich mit einem der neueren Windows Patches beißt) oder ich muss den Support kontaktieren. Gruße coolblue

Hallo haben hier einen Fileserver der das Problem hat, dass zwischendurch von ihm keine Daten geliefert werden. Jemand transferiert eine oder mehrere Dateien, der Transfer beginnt und dann plötzlich bleibt der bis zu einer Minute stehen und macht danach in voller Geschwindigkeit weiter. HP ML350 G5 Windows 2003 Server R2 SP2 + alle Patches 32bit 4 GB RAM NC373i Netzwerkkarte Gigabit HP 4204vl Switch AD und Fileserver mit DNS und DHCP NORMAN Anti-Virus sonst läuft dort eigentlich nichts. Ich hab mit Perfmon/Taskmanager den Netzwerktraffik beobachtet und man sieht am Server das die Übertragung auf 0 zusammen bricht und nach einer Minute geht es weiter. Hin und wieder bricht der Client sogar ab. Hab verschiedene Clients ausprobiert mit verschiedenen OS.. geht nicht Haben die Daten auf einen exakt identisch ausgestatteten W2k3 Server kopiert und von dort mit den Clients gesaugt, kein Problem.. geht. Problem liegt also nur an diesem einem Server. Auch wenn man mit mehreren Clients gleichzeitig Daten transferriert, bleiben alle Clients gleichzeitig stehen und warten auf Antwort. Das BIOS und die Treiber der NIC und des gesamten Server habe ich schon geupdatet. Half leider nichts. Hat es scheinbar sogar noch schlimmer gemacht. Netzwerkkabel getauscht. Brachte auch nix. Was mir auffällt.. es scheint nur SMB zu sein. Die RDP Sitzung funktioniert weiterhin einwandfrei während der Störung. Auch Internetrequests (Browser) gehen währenddessen. Was könnte das noch sein? Hab schon überlegt eine weitere Netzwerkkarte zu bestellen und einzusetzen, aber soll es wirklich daran liegen, wenn jegliche andere Kommunikation funktioniert? Gruß CoolBlue

Ja ist er. Glaube aber das Problem gefunden zu haben, es könnte am IKE Phase2 Keyexhange der Checkpoint liegen, Checkpoint analyisert das gerade.

Hi, es sind keine Energieeinstellungen aktiv. Ebenfalls sind auch keien DFÜ Verbindungen eingerichtet die ablaufen könnten. Die Verbindung wird über ein Site-to-Site Tunnel mit zwei Checkpoint Firewalls aufrecht erhalten. In Zusammenarbeit mit Checkpoint habe ich noch folgendes ausprobiert: - Update des RDP Clients auf Version 6.1 - In der Registry KeepAliveEnable (HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server) aktiviert. Jetzt heißt es wieder warten ob das was geholfen hat. Sonst noch jemand Ideen?

Hi, wir haben hier eine Site-To-Site Verbindung mit 2 Checkpoint Safe@Office 500 Boxen. Hauptsitz: -SDSL 2mbit Leitung -Terminal Server Win2003 für den Zugriff durch 2-3 Benutzer per VPN -AD Server und 2-3 andere Server Außenstelle: - T-DSL Business mit Feste-IP - 2 XP SP2 Arbeitsplätze die RDP auf den TS über VPN nutzen. RDP läuft soweit auch einwanwandfrei. DNS auflösung geht, Ping geht wunderbar, ebenfalls auch ein Dauer Ping. Nach 30 Minuten (man kann die Uhr nach stellen) friert RDP ein.. es dauert knapp 3 bis 5 Minuten dann wacht die Sitzung wieder auf. Alternativ kann man msterm.exe auch killen und einfach eine neue Sitzung starten. Man kann dann direkt weiter arbeiten. Habe mal eine RDP Sitzung zum TS aufgebaut und zeitgleich eine RDP Sitzung zum AD Server... die AD Sitzung ist nicht eingefroren. Lokal im Hauptsitz hab ich mal mit RDP auf dem TS gearbeitet.. Keine Probleme gehabt. Liegt es nun am VPN oder am TS? Kann mir das nicht erklären. Grüße Jan

Ne den beiden Servern gehts soweit prächtig. Ping geht. DNS lookup geht. DNS Einträge gibt es auch keine. Es gibt auch keine LDAP oder Kerberos fehlermeldungen, oder ein bestimmtes Ereigniss. Mal läuft er auch mal 2 Woche ohne Probleme. netdiag und dcdiag hatte ich in dem moment nicht ausprobiert.. muss ich mal dran denken. Hab da schon echt Stunden mit verbracht und Protokolle gelesen aber alle Ereignis IDs (wenn man im Inet danach sucht) weisen auf Anmeldeprobleme hin bzw einem fehlenden AD Controller.

Hi, wir haben hier einen Server, der AD, DNS, DHCP, MS SQL, WSUS 3 und Printerservices anbietet. Nach knapp einer Woche geht das Drucken nicht mehr. Die Druckerwarteschlange füllt sich mit Aufträgen, jedoch werden diese nicht zum Drucker weitergereicht. Neustart des Spoolers hilft nicht. Wenn man dann ins Systemlog schaut, sieht man hunderte von roten Fehlermeldungen verschiedener Dienste. Alle Dienste haben in etwa die gleiche Fehlermeldung, nämlich das eine Authentifizierung am Active Directory nicht möglich ist. (darunter auch der Spooler Dienst) Hab schon nach einander alle Windows Dienste neu gestartet, bringt gar nichts. Erst nach einem Server Neustart läuft alles wieder einwandfrei. Es gibt auch keine Log einträge von abgewaffelten Diensten oder Fehlermeldungen vor den "anmeldeproblemen". Es sieht so aus als wäre der AD Dienst (welcher ist das eigentlich im Dienstemanager?) wie vom Erdboden verschluckt. Interessanterweise nutzen die Dienste zur Anmeldung auch nicht den Backup AD Server. Jemand ne Idee?

Das Routing macht die Firewall von GateProtect (X1.1) und die baut ein PPPOE Tunnel über ein DLINK DSL Modem auf, welches im Bridge Mode läuft. Gruß Jan

Ne wirrkürlich.. manchmal sagt der sender "DATA" der exchange antwortet mit "jo kanns loslegen" und dann kommt nix mehr. oder exchange sagt "kannst loslegen" dann kommen daten.. mal 2-3 zeilen.. mal n ganzer block mit anhang und dann bleibt er hängen .... hab mir verschiedene wireshark traces angeguckt und alle enden sie an unterschiedlichen punkten... dennoch liegt die statistische häufigkeit bei dem punkt direkt nach "DATA > ja kanns loslegen" Gruß Jan

Soooo :-)) also an der MTU kann es denke ich nicht liegen. Ich bekomme laut Wireshark Pakete mit bis zu 1500 bytes herein die erfolgreich angenommen und verarbeitet wurden. Kann es vielleicht an einem Anti-Spam System liegen was ich testweise mal installiert hatte und evtl nen event-sink hinterlassen haben könnte? Trotzdem wundert es mich, dass 80% der Mails erfolgreich rein kommen (pie mal daumen). Hat hier niemand mal ein paar Tipps? Muss ja keine Lösung sein, aber vielleicht ne Idee die mir die Anregung gibt bestimmte dinge zu testen oder zu analysieren. Gruß Jan

Hi, ich verzweifel :-( Hab am DSL mal die MTU auf 1300 gesetzt... testhalber.. kann ja sein das da was nicht durchgeht. Brachte nix.. Google Groups bringt mich auch nicht weiter. Die Leute Posten ihre Fehlemeldung, so wie ich auch und als Antwort gibs meist nur die Erklärung dieser. Könnt mir ja vorstellen das das Kabel kaputt ist, aber auf dem Server laufen noch andere VM's die keine derartigen Probleme haben. Nen Filetransfer via SMB auf dem Server klappte ebenfalls ohen retransmittet packets laut wireshark. Es muss doch irgendwas mit dem Exchange.. dem SMTP vom IIS oder evtl. was mit VMware zu tun haben. Denn das Problem trat exakt nach dem Umzug auf. Vorher wars nen realer Domain Controller Server mit Exchange 2003 SP2 und nun ist es nen virtualisierter dedicated Exchange 2003 SP2 Server. Gruß Jan

Hi... bin noch am üben mit Wireshark... aber hab die tolle funktion "Follow TCP Stream" gefunden... und finde das Ergebnis einer Beispielverbindung recht interessant: 220 mx3.artada.de Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Mon, 14 May 2007 16:54:25 +0200 EHLO www.bizzeweb.de 250-mx3.artada.de Hello [193.110.43.78] 250-TURN 250-SIZE 250-ETRN 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-8bitmime 250-BINARYMIME 250-CHUNKING 250-VRFY 250-X-EXPS GSSAPI NTLM LOGIN 250-X-EXPS=LOGIN 250-AUTH GSSAPI NTLM LOGIN 250-AUTH=LOGIN 250-X-LINK2STATE 250-XEXCH50 250 OK MAIL FROM:<info@actebispeacock.de> 250 2.1.0 info@actebispeacock.de....Sender OK RCPT TO:<marcel.esken@artada.de> 250 2.1.5 marcel.esken@artada.de DATA 354 Start mail input; end with <CRLF>.<CRLF> Received: (qmail 20719 invoked from network); 14 May 2007 13:21:54 +0200 Received: from localhost (HELO may.intersolute.de) (127.0.0.1) by localhost with SMTP; 14 May 2007 13:21:54 +0200 Date: Mon, 14 May 2007 13:21:54 +0200 Return-Path: info@actebispeacock.de To: marcel.esken@artada.de From: Actebis Peacock <info@actebispeacock.de> Reply-to: Actebis Peacock <info@actebispeacock.de> Subject: ?iso-8859-1?Q?Palm_Endkundenaktion:_Kostenloses_Navigationspaket_TomTom?= =?iso-8859-1?Q?=AE_beim_Kauf_eines_Palm=AE_Treo=99_Smartphones?= Message-ID: <e60c003fd6a8fffbd7a619d4c327f23c@may.intersolute.de> X-Priority: 3 X-Mailer: PHPMailer [version 1.72] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>Palm-News</title> <!-- base --> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="pragma" content="no-cache"> <meta name="cache-co451 Timeout waiting for client input ich finde es äußerst interessant, das er einfach so mittendrin urplötzlich die Übertragung einstellt. Grüße Jan Lange

Tarpitting abschalten hat schonmal nix gebracht. Exchange meldet laut Wireshark des öfteren: Response: 451 Timeout waiting for client input Und die gegenseite macht dann natürlich diesen obligatorischen I/O Error. Was mir auffiel ist das ich des öfteren Rote Einträge bekomme mit "TCP previous segment lost" "Dup ACK" "TCP Retransmission" "TCP Window Update" "TCP Fast Retransmission" Weißn icht ob ich das als Hinweiß oder als Normal werten soll. Denn laut TCP Richtlinien (google) heißt es, das es ein normales Verhalten ist, wenn Pakete z.b. durch QoS oder andere Situationen gedropped werden. Dafür wurde ja die Technik für Fast Retrasmission und Dup ACK eingeführt um das fix zu kompensieren. Aber selbst wenn es ein "Hinweiß" darstellt. Macht es auhc keinen Sinn, weil es sich hierbei ja um TCP handelt und Pakete so oft wiederholt werden, bis sie vollständig angekommen sind. Was mach ja auch an den Retransmissions erkennt. Bis auf die Möglichkeit mal den IMF abzuschalten, fällt mir sonst echt nix mehr dazu ein :-( Grüße Jan

Hi, danke für deine Antwort. Aber nur noch mal als Info. Ich habe extra darauf geachtet das nur eins der beiden System Filter an hat. Früher hatte wird Exchange "nackt" (nur AD-User prüfung aktiviert) und die Firewall mit anti-spam. Leider ist das Anti-Spam Modul in der Firewall für die Katz. Also habe ich alle "Sachen" in der Firewall deaktiviert und ebenso auch den Proxy, damit die original Source-IP am Exchange landet und eben dort mal IMF aktiviert. IMF hab ich aber noch nich so lange aktiv auf dem neuen Server und die Empfangsprobleme waren schon vorher da. Direkt nachdem der Exchange auf den neuen Server gemoved wurde. Einzige was ich mir vorstellen kann ist das Tarpitting, das von Anfang an aktiv war. Das könnte ich mal deaktivieren.

Ups vergessen: per SNAT sind keine Anti-Spam oder Anti-Viren Dienste in der Kette. per Proxy ist nen SpamAssassin und nen Kaspersky aktiv auf der Firewall. Im Exchange hab ich Tarpitting an und den IMF Filter mit der Rule das er E-Mails ab dem Punktelevel 7 ablehnen soll. Im Wireshark Log sieht man auch, dass Exchange Mails mit ner Fehlermeldung ablehnt wenn diese auf IMF zutrifft.

DSL 16.000 (Helinet, Fest IP) > DLINK DSL MODEM > GateProtect Firewall (100mbit 3Com Karte) GateProtect Firewall (Gigabit Dual INTEL Nic) > HP Gigabit Switch 1400 > C2D Server mit GB Nic (Windows 2003 Server) > VMware Server 1.0.1 > Windows 2003 Server (Guest) > Exchange 2003 Standard Server Firewall macht nen SNAT auf die IP des Exchange für Port 25. Ich kann in der Firewall einen Proxy einschalten für SMTP. Habe mit Proxy und mit SNAT probiert, verhält sich beides gleich, nur das die Verbindung dann eben von der Firewall kommt (IP) statt ausm Internet. Auf dem VMWare Server läuft ebenfalls noch nen Fileserver, nen AD Server mit DNS usw. Jede VM ist einzeln gefirewalled über Subnetze. Grüße Jan

Nachtrag: Wenn ich mit Wireshark mitverfolge bekomme ich hinundwieder auf SMTP Ebene die Meldung "Response: 451 Timeout waiting for client input" Ich vermute mal das das gleich kommt mit dem SMTP Exchange Log und der Meldung "TIMEOUT"

Hi, sooo nach durchforsten der mitgeschriebenen Logs ist mir aufgefallen das dort des öfteren TIMEOUTS drin stehen. Manchmal auf nur ein EHLO, MAIL, RCPT.. aber kein DATA _und_ kein QUIT. Mails von Domains wo wir wissen, dass dort keine E-Mail reinkommt, stehen bei uns im Log fast immer mit TIMEOUT drin. Wodran kann das denn so urplötzlich liegen? Grüße Jan Lange

Also SMTPDiag sagt ist alles in Ordnung. Die DNS Eintrage mit dem MX Record habe ich ebenfalls schon überprüft gehabt. Das läuft auch alles soweit ganz gut. Mit der Testmail muss ich schauen wann Zeit ist und der E-Mail Partner ebenfalls Zeit hat.

ähm ups! Streich das "immer" aus meinem ersten Post. Bisher ist uns das erst bei zwei Firmen bewusst aufgefallen. Aber es ist definitiv seit dem der Exchange Server umgezogen ist auf dem neuen Server. Windows 2003 R2, Domänen Mitglied, nur Exchange (dediziert)

Hi Günther mir kam der NDR auch schon merkwürdig vor. Wir haben das mit zwei Firmen (wortmann.de und lge.de) ich nenn sie einfach mal hier, ist ja nix unbekanntes. Laut Google ist das ein Fehler wenn die Kommunikation beim übertragen zusammen bricht, von daher wäre es schon mal logisch das nicht unser Exchange das generiert sondern der Mail Server auf der anderen Seite. Laut Auskunft andere Mitarbeiter heißt es, das seit dem Exchange Server move auf einen anderen Host angeblich "weniger" Mails ankommen. Genau spezifizieren konnten sie das nicht, weil es in der regel Newsletter wohl sind wo man (ich ja meist auch nicht) nicht weiß welche das sind die nun fehlen. Wir setzen Exchange 2003 SP2 ein auf einem Single Host. Kein Proxy, kein Anti-Spam Plugin. Nur rein Exchange. Feste-IP, Reverse-NAT Port 25 im Exchange sind die Optionen aktiviert für Tarpitting und die Überprüfung ob es die Empfänger Adresse gibt. Alles andere ist aus. Exchange Best Practise hab ich mal laufen lassen, der sagt aber bis auf ein paar gelbe Ausrufezeichen (die aber normal sind) das alles ok ist, an. Gruß Jan

Hi, wenn andere Leute unserem Exchange etwas senden wollen, bekomme diese Leute immer folgende nichts aussagene Fehlermeldung: ============================================================== FIRST : Wed, 28 Feb 2007 22:52:39 KST +0900 LAST : Wed, 28 Feb 2007 22:52:39 KST +0900 RETRY COUNT : 1 LOOP COUNT : 0 REMOTE SERVER RESPONSE : 451 4.4.2 Bad connection (io timeout) ============================================================== Ich hab jetzt schon so oft zu unterschiedlichen Zeiten nen manuellen Telnet SMTP-Sessio Test gemacht und jedesmal reagierte der Server normal. Ebenso hab ich Traceroutes zur Verbindungskontrolle gemacht in die betroffenen Netze. Geht auch alles sauber. Ein Telnet SMTP Connect auf den gegenüberliegenden SMTP Server geht ebenfalls wunderbar. Kennt jemand das Problem? Gruß Jan

Hab dasselbe Problem mit qMail. Nur noch keine Zeit zur Analyse gehabt. Weiterhin ist das ne Linux Büchse beim Provider mit Öffentlicher IP und Reverse DNS Eintrag. Von daher sollte das ja eigentlich gehen. Jan