Fragensteller
sporadische http Verzögerungen im LAN bei TMG 2010 (NLB)?

Allgemeine Diskussion
-
Hallo,
Wir haben ein Problem dass wir im internen Netzwerk bei beliebigen sites im Internet (nur bei Aufrufen von HTTP in Browsern) manchmal Timeouts erhalten. Das passiert vereinzelt bei den Mitarbeitern und auch mehr oder weniger zufällig (z.B gmx.de, maps.google.de). Man ruft die site auf und es passiert ca 25 sek. nichts. Entweder baut siche die Seite auf oder es kommt ein Timeout. Einmal F5 gedrückt, und die Seite ist wieder da. Falls ein Download auf der Website nebenbei auf ist, gibt es keine Probleme (dieser läuft durch). Die TMG Ereignisse zeigen mir nichts passendes an.
Wir nutzen seit 6 Monaten TMG 2010 Enterprise im NLB Betrieb mit IGMP (vorher nur Multicast) unter Windows Server 2008R2 mit 4 Netzwerken. Zur aktuellen Konfig: Wir nutzen keine WPAD, deaktivierten cache/ kein CARP. Vorher waren diese Optionen an, aber das Problem hat sich dadruch nicht geändert. Folgende Optionen sind aktiviert: Der "Forefront TMG Clientsupport mit und webproxyserver (8080) ist aktiviert, sowie , http-compression.
Clientseitig können wir im IE 8/9, Firefox, Chrome die Proxyeinstellungen auf "automatisch suchen" ein/aus stellen, aber der Fehler bleibt bestehen.
Das BPA Tool auf beiden Nodes sagt auch das alles in Ordnung ist
Als Lösungstipps habe ich von Microsoft schon diverse Links zum troubleshooting und interrupt issue- Lösungen erhalten, die auch nichts gebracht haben.
Ich war mir zu 99% sicher dass es daran lag, dass auf dem "Internet"- Interface die externen DNS Server zusätzlich eingetragen waren. Laut best practice sollte man am besten nur die internen DNS Server auf den "Internen" Interface eintragen (wie bei uns). Auf unserem DC/DNS Server sind Weiterleitungen auf die ProviderDNS Server. Nach der Umstellung, war die Auflösung sogar einen Ticken schneller geworden, aber das Problem bleibt leider weiterhin bestehen.
Langsam gehen mir die Ideen aus. Irgendeine Idee wie man am besten vorgehen kann um den Fehler zu finden ? z.B. durch die TMG tools oder einen Sniffer?
- Typ geändert Alex Pitulice Montag, 25. März 2013 11:53 Warten auf Testen
Donnerstag, 21. März 2013 15:18
Alle Antworten
-
Hi,
ich tippe auf 1) DNS Probleme, oder vermutlich eher 2) NLB Probleme.
Wenn Du die DNS Einstellungen (1) nach Best Practices konfiguriert hast:
http://social.technet.microsoft.com/wiki/contents/articles/recommended-network-adapter-configuration-for-forefront-tmg-enterprise-edition-servers.aspxDann vermute ich (2). Zum Testen kannst Du mal auf einen TMG Node ein NLB Drain Stopp machen und dann ein NLB Stopp und dann die DNS Namensaufloesung nochmal neu probieren. Fuer (2) hilft auch ein Netzwerksniffer wie den MMA (http://www.it-training-grote.de/download/MMA-40.pdf).
Dann kannst Du einen Trace an betroffenen Clients starten und schauen was Du in den Trace Logs siehst
regards Marc Grote aka Jens Baier - www.it-training-grote.de - www.forefront-tmg.de - www.nt-faq.de
Donnerstag, 21. März 2013 18:14 -
Hallo supporter,
Bist Du weitergekommen?
Gruss,
AlexAlex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.Montag, 25. März 2013 11:53 -
Hi.
Ich bin jetzt erst aus dem Urlaub zurückgekommen.
Habe eben gerade einen Node ausgeglichen und beendet/ drainstopp
ausgeführt und werde mal das ganze die nächsten Tage beobachten.Allerdings habe ich mal von meinem Win7 Client einfach mal Wireshark laufen lassen.
Man sieht bei mir dass mit dem NLB, unser Netzwerk mit Anfragen
zwischen den Clients von und aus dem Internet voll gemüllt wird .
Beispiel: "Ethernet II, Src: Dell_bb:15:8d (00:1a:a0:bb:15:8d), Dst:
MS-NLB-VirtServer-Multicast_c0:a8:01:01
(03:bf:c0:a8:01:01)"Besonders ärgerlich ist das auch jeglicher HTTP im Klartext im
Netzwerk rausgerufen wird. Aber das ganze ist wohl normal da wir vor
einem Monat den Clusterausführungsmodus von Multicast with IGMP auf
reines MULTICAST umgestellt haben und unsere Switche (HP2824)
nicht richtig mit dem IGMP Snooping zu konfigurieren sind.Nachtrag:
Um die Switche wissen zu lassen welche MAC Adresse wohin gehört und den
Broadcast zu vermeiden, muss man einen statischen ARP Eintrag der
Multicast Adresse machen. Problem ist bei uns: Wir haben keine Switche
die statische Multicastadressen unterstüzten. Höchstens UNIcast MACs.
Darum muss ich mir nun überlegen ob ich entweder neue Switche (oder
Layer3 Switche) besorge oder das komplette NLB auf UNIcast umstelle (was
in der Vergangenheit Probleme bereitet hat).
- Bearbeitet KMSupport Mittwoch, 17. April 2013 09:22
Montag, 15. April 2013 13:30