Massive Geschwindigskeitsprobleme Netzübergreifend
Hallo Zusammen,
ich habe hier in meinem Netzwerk/meinen Netzwerken teilweise massive Geschwindigkeitsprobleme. Auf dem nachfolgenden Bild habe ich mal mit Paint das Intranet zusammengekritzelt (Ich hoffe man sieht das Bild). Daran könnt ihr euch orientieren.
Mein Rechner steht im 192.168.0.0'er Netz. Mein Ziel ist eine Remotedesktop Verbindung ins 192.168.98.0'er Netz und zwar auf 192.168.98.5. Zwischen den beiden Firewalls ist ein Branch Office Tunnel (VPN) eingerichtet. Netzlaufwerke, sowie RDP funktionieren vom 0.0'er ins 0.98'er Netz. Die Geschwindigkeit ist aber so langsam, dass man nicht damit arbeiten kann. Will man sich per RDP connecten dauert es mindestens 5 Minuten um zur Anmeldemaske zu kommen weil sich das Bild so langsam aufbaut. ISt man dann endlich angemeldet und will beispielsweise einen Ordner öffnen will dauert es wieder 2-3 Minuten ! Bei Netzlaufwerken das selbe Spiel..Entweder lassen sie sich gar nicht erst connecten wegen eines Timeouts oder es dauert so extrem lange Ordner zu listen, dass man dann schon freiwillig oben rechts auf das X klickt
Ist man lokal auf dem Rechner (192.168.98.5) angemeldet geht alles wunderbar schnell. Also am Rechner liegts nicht.
Von aussen ist der 192.168.98.5 auch erreichbar..Über ein NAT..Ich kann von aussen leider nicht testen da ich nur einen bestimmten Port für eine Anwendung geöffnet habe.
Wirkliche Bottlenecks kann ich bisher im Netz auch nicht erkennen. Das LAN in beiden Netzen hat jeweils eine Gbit Anbindung. In der Firewall bekomme ich auch keine Denies (Verbote) o.ä. !
Meint ihr, es könnte etwas mit dem Routing zu tun haben ?
Falls ihr Ideen habt, bitte alles hier rein.
Achja, bevor ich es vergesse..Vor einigen Tagen lief das Ganze noch bedeutend schneller. Ich habe keine Änderungen gemacht, deshalb kann ich mir nicht erklären woher diese Geschwindigkeitseinbußen herkommen !
Danke
Gruß
exellent
ich habe hier in meinem Netzwerk/meinen Netzwerken teilweise massive Geschwindigkeitsprobleme. Auf dem nachfolgenden Bild habe ich mal mit Paint das Intranet zusammengekritzelt (Ich hoffe man sieht das Bild). Daran könnt ihr euch orientieren.
Mein Rechner steht im 192.168.0.0'er Netz. Mein Ziel ist eine Remotedesktop Verbindung ins 192.168.98.0'er Netz und zwar auf 192.168.98.5. Zwischen den beiden Firewalls ist ein Branch Office Tunnel (VPN) eingerichtet. Netzlaufwerke, sowie RDP funktionieren vom 0.0'er ins 0.98'er Netz. Die Geschwindigkeit ist aber so langsam, dass man nicht damit arbeiten kann. Will man sich per RDP connecten dauert es mindestens 5 Minuten um zur Anmeldemaske zu kommen weil sich das Bild so langsam aufbaut. ISt man dann endlich angemeldet und will beispielsweise einen Ordner öffnen will dauert es wieder 2-3 Minuten ! Bei Netzlaufwerken das selbe Spiel..Entweder lassen sie sich gar nicht erst connecten wegen eines Timeouts oder es dauert so extrem lange Ordner zu listen, dass man dann schon freiwillig oben rechts auf das X klickt
Ist man lokal auf dem Rechner (192.168.98.5) angemeldet geht alles wunderbar schnell. Also am Rechner liegts nicht.
Von aussen ist der 192.168.98.5 auch erreichbar..Über ein NAT..Ich kann von aussen leider nicht testen da ich nur einen bestimmten Port für eine Anwendung geöffnet habe.
Wirkliche Bottlenecks kann ich bisher im Netz auch nicht erkennen. Das LAN in beiden Netzen hat jeweils eine Gbit Anbindung. In der Firewall bekomme ich auch keine Denies (Verbote) o.ä. !
Meint ihr, es könnte etwas mit dem Routing zu tun haben ?
Falls ihr Ideen habt, bitte alles hier rein.
Achja, bevor ich es vergesse..Vor einigen Tagen lief das Ganze noch bedeutend schneller. Ich habe keine Änderungen gemacht, deshalb kann ich mir nicht erklären woher diese Geschwindigkeitseinbußen herkommen !
Danke
Gruß
exellent
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 64839
Url: https://administrator.de/forum/massive-geschwindigskeitsprobleme-netzuebergreifend-64839.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
7 Kommentare
Neuester Kommentar
Mmmhhh das ist schwierig, denn mögliche Fehler sind sehr vielfältig. Das Argument Gestern gings noch und wir haben nichts verändert... ist klassisch und stimmt meist nie, das weisst du selber.... Es gibt immer den Kollegen der z.B. unterm Schreibtisch den geheimen NetGear oder Longshine betreibt sofern du das nicht mit Port Security unterbindest....
Dieser Branch Office Tunnel... was ist das ??? Eine VPN Verbindung der beiden FWs über das Internet ?? Oder sind beide FWs am gleichen Standort und lokal über diesen Link verbunden ??? Benutzt deser Tunnel irgendeine Art von Encapsulation ??? Arbeiten die beiden Firewalls in einem Hot Standby oder in einem Active-Active Szenario ???
Zu diesen Fragen sagst du leider nichts
Du kannst erstmal nur strategisch Step für Step vorgehen:
Wichtig ist wie gesagt erstmal zu klären, das alle lokalen Segmente in sich fehlerfrei arbeiten und dort keine Probleme wie Collisions, STP Loops, Link Negotiation Probleme, Broadcast Stürme o.ä. auftreten. Zusätzlich kann man das mit einem Sniffer wie dem www.wireshark.org oder dem Mircrosoft Net-Monitor sehen was dort generell in den Segmenten los ist.
So musst du dich dort rantasten. Einen goldenen Rat kann es wegen der vielen Fehlermöglichkeiten nicht geben...leider !
Dieser Branch Office Tunnel... was ist das ??? Eine VPN Verbindung der beiden FWs über das Internet ?? Oder sind beide FWs am gleichen Standort und lokal über diesen Link verbunden ??? Benutzt deser Tunnel irgendeine Art von Encapsulation ??? Arbeiten die beiden Firewalls in einem Hot Standby oder in einem Active-Active Szenario ???
Zu diesen Fragen sagst du leider nichts
Du kannst erstmal nur strategisch Step für Step vorgehen:
- In den jeweiligen lokalen Segmenten mit NetIO die lokale Performance testen um auszuschliessen, das hier Probleme mit Spanning Tree (zusätzlichen Workgroup Switches unterm Schreibtisch..etc.) bestehen und lokale die Segmente fehlerfrei sind.
- Hast du das verifiziert solltest du mal mit NetIO über die FW testen sofern das Porttechnisch möglich ist um die Layer 3 Performance/ Forwarding der FWs zu testen für die unterschiedlichen Packetgrößen.
Wichtig ist wie gesagt erstmal zu klären, das alle lokalen Segmente in sich fehlerfrei arbeiten und dort keine Probleme wie Collisions, STP Loops, Link Negotiation Probleme, Broadcast Stürme o.ä. auftreten. Zusätzlich kann man das mit einem Sniffer wie dem www.wireshark.org oder dem Mircrosoft Net-Monitor sehen was dort generell in den Segmenten los ist.
So musst du dich dort rantasten. Einen goldenen Rat kann es wegen der vielen Fehlermöglichkeiten nicht geben...leider !
Hast du NetIO mit der Option -t gestartet ??? Das ist wichtig denn dann nutzt er TCP Packete. Ohne die -t Option macht er nur L2 Netbui.
Was auffällt ist das die TX Rate OK ist. Ca. 80 Mbit, was ein guter Wert bei 100 Mbit Link ist. Die RX Rate ist allerdings sehr schlecht und liegt weit unter 50%. Diese Asymetrie ist nicht normal und deutet schon auf ein Problem hin.
Der test SC1 ist sehr wahrscheinlich lokal gemacht, oder ???
Das du bei SC2 wenn der über die FW geht ein Problem bekommen kannst mag sein, denn sehr wahrscheinlich ist der TCP Port den NetIO nutzt in der FW geblockt ?!
Nebenbei bemerkt: Wenn deine FW Kopplung über eine VPN Verbindung über ein öffentliches Netz geht und damit auch dein Traffic vom .0.0er Segment als auch vom .098.0er Segment dann hast du gar keine Möglichkeit die Performance sauber zu beurteilen, denn du nutzt ein öffentliches Netz das du mit Tausenden von anderen Benutzern teilen musst. Dort lassen sich überhaupt keine Aussagen zum Durchsatz treffen, da das ja Provider abhängig ist, was für Geschwindigkeiten der in seinem Backbone fährt und wieviel Benutzer sich in seinem Netz das Netz teilen. Ggf. macht der sogar ein Rate Limiting auf Peer to Peer VPN Verbindungen. Völlig utopisch also davon auszugehen Perormance auf Linkniveau Geschwindigkeit zu bekommen !!!
Was auffällt ist das die TX Rate OK ist. Ca. 80 Mbit, was ein guter Wert bei 100 Mbit Link ist. Die RX Rate ist allerdings sehr schlecht und liegt weit unter 50%. Diese Asymetrie ist nicht normal und deutet schon auf ein Problem hin.
Der test SC1 ist sehr wahrscheinlich lokal gemacht, oder ???
Das du bei SC2 wenn der über die FW geht ein Problem bekommen kannst mag sein, denn sehr wahrscheinlich ist der TCP Port den NetIO nutzt in der FW geblockt ?!
Nebenbei bemerkt: Wenn deine FW Kopplung über eine VPN Verbindung über ein öffentliches Netz geht und damit auch dein Traffic vom .0.0er Segment als auch vom .098.0er Segment dann hast du gar keine Möglichkeit die Performance sauber zu beurteilen, denn du nutzt ein öffentliches Netz das du mit Tausenden von anderen Benutzern teilen musst. Dort lassen sich überhaupt keine Aussagen zum Durchsatz treffen, da das ja Provider abhängig ist, was für Geschwindigkeiten der in seinem Backbone fährt und wieviel Benutzer sich in seinem Netz das Netz teilen. Ggf. macht der sogar ein Rate Limiting auf Peer to Peer VPN Verbindungen. Völlig utopisch also davon auszugehen Perormance auf Linkniveau Geschwindigkeit zu bekommen !!!
Ok, 44 Mbit gehen dann nicht über ein öffentliches Netz, sonst nützt dir diese Bandbreite ohne ein commitetes QoS vom Provider natürlich nichts, denn die Last kann auf dem Link so sein das nur 5 Mbit durchkommen. Das ist immer Provider abhängig. Auf einer dedizierten Leitung natürlich nicht...keine Frage !
Die Asymetrie dürfte auch bei Last nicht auftreten, denn wenn viel los ist im Netz gilt das ja logischerweise auch für deine gesendeten Packete, denn die gehen ja auf ein und dasselbe Medium. Da kann man eher vermuten das das Gegenüber TX seitig sehr schwach auf der Brust ist !!! Was ist das ein Server oder Client und was sagt dessen TX Rate ?? Die müsste ja genau so mau sein wie die korrespondirende RX Rate auf deiner Seite ???!!
Wenn segmentübergreifend der NetIO nicht klappt hast du in der Tat ein Routing Problem wenn man die FW ausschliessen kann, das solltest du sicher prüfen (FW Logs, Traceroute, Pathping etc.).
Was sagt denn ein Ping über diese Netze sofern du ICMP Echo in der FW erlaubt hast ?
Das du natürlich erstmal generell die Layer 3 (Routing) Connectivity zwischen diesen Segmenten verifizieren und testen muss sollte klar sein, sonst macht doch ein Performancetest keinen Sinn !
Die Asymetrie dürfte auch bei Last nicht auftreten, denn wenn viel los ist im Netz gilt das ja logischerweise auch für deine gesendeten Packete, denn die gehen ja auf ein und dasselbe Medium. Da kann man eher vermuten das das Gegenüber TX seitig sehr schwach auf der Brust ist !!! Was ist das ein Server oder Client und was sagt dessen TX Rate ?? Die müsste ja genau so mau sein wie die korrespondirende RX Rate auf deiner Seite ???!!
Wenn segmentübergreifend der NetIO nicht klappt hast du in der Tat ein Routing Problem wenn man die FW ausschliessen kann, das solltest du sicher prüfen (FW Logs, Traceroute, Pathping etc.).
Was sagt denn ein Ping über diese Netze sofern du ICMP Echo in der FW erlaubt hast ?
Das du natürlich erstmal generell die Layer 3 (Routing) Connectivity zwischen diesen Segmenten verifizieren und testen muss sollte klar sein, sonst macht doch ein Performancetest keinen Sinn !
Die Layer 3 Rate testest du doch ganz automatisch, wenn du den Zielhost im anderen Netz angibst. Die NetIO Packete werden dann geroutet....
Das Anwendungen dann so langsam sind liegt dann am Rechner bzw. den Applikationen selber. NetIO nutzt keine solche Dienste sondern setzt auf die Kartentreiber direkt auf. Damt kannst du also sauber deine Netzwerkinfrastruktur testen und somit sicher sagen obs am Rechner selber oder am netzwerk liegt.
Vermutlich ist bei dir der Rechner das Problem. Wenn du einen Server hast der belastet ist wie ist dessen TCP Window Size eingestellt ??
Den Wert findest du in der Registry unter:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Tcpip/Parameters
Das Anwendungen dann so langsam sind liegt dann am Rechner bzw. den Applikationen selber. NetIO nutzt keine solche Dienste sondern setzt auf die Kartentreiber direkt auf. Damt kannst du also sauber deine Netzwerkinfrastruktur testen und somit sicher sagen obs am Rechner selber oder am netzwerk liegt.
Vermutlich ist bei dir der Rechner das Problem. Wenn du einen Server hast der belastet ist wie ist dessen TCP Window Size eingestellt ??
Den Wert findest du in der Registry unter:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Tcpip/Parameters