This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM 9.3 Downloads sehr laaaangsam

Hallo Zusammen,

ich habe aktuell das Problem, das Downloads über unsere UTM sehr, sehr langsam sind. Leider finde ich keinen Weg das ganz zu beschleunigen. Gehen die Downloads über HTTPS, wird es richtig schlimm, dann sind Download Raten von 5 KB/S möglich. Der gleiche Download, der über die UTM dann 4 Stunden dauern sollte, geht direkt über die 50 MBit Leitung, ohne UTM dazwischen, in 30 Sekunden.
Mir ist klar, das die UTM Scannt und Filtert, aber das die Downloads dann so langsam werden, kann ich nicht wirklich verstehen.
Wir haben extra gerade die Hardware aufgerüstet und die UTM dümpelt bei der Auslastung immer nur noch bei ca. 2% rum, RAM liegt bei unter 20%, das sieht eigentlich alles sehr gut aus.

Kann mir jemand einen Tipp geben, in welche Richtung ich hier suchen kann?

Vielen Dank im vorraus!


This thread was automatically locked due to age.
Parents
  • Intrusion Protection an? QOS/TrafficShaper Regel angelegt mit Download Limitierer?
  • Da die Hardware aufgerüstet wurde, schliesse ich Problem aufgrund unterdimensionierter Hardware (CPU vom unteren Ende der Leistungsmässigen Nahrungskette wie ein Atom N270 o.ä. etc) mal aus.

    Bei 50MBit in 30s...da sprechen wir also von einem Download in der Grössenordnung 150-200MByte

    Falls im Web Proxy die max AV Scan Size mehr oder weniger noch Default ist (20 MByte oder so), sollte der Proxy das direkt und ungescannt durchreichen. Falls Scansize grösser wie der erwähnte Download von eben 150-200 Mbyte (und ggf. sogar DUal AV aktiv), kann man die UTM je nach Downloadtyp (z.Bsp. .iso oder Archiv mit Tonnen von Archiven und Executables drin) u.U. arg beschäftigen...

    Falls obiges nicht zutrifft, würde ich am ehesten mal von folgenden Problemen ausgehen:

    - Interface Duplex Probleme (Cisco Router oder Kabelmodem an der UTM dran ?). Einfach mal das WAN Interface (oder ggf. auch interne LAN Interface) fix auf GBit FDX setzen

    - An den UTM Flooding Protection Einstellungen rumgespielt ? Falls aktiv, mal alle (insbes. TCP flooding protection) deaktivieren

    - Die erwähnten (falschen) QoS Einstellungen sind eher unwahrscheinlich, ausser man hat testweise mal was eingerichtet, und die Bandbreitenpools massiv unglücklich tief gesetzt...Die Drosselung mit dem Download Throttling funktioniert gegen das Internet erfahrungsgemäss eh nur bedingt oder gar nicht...die meisten CDN´s und ISP Router ignorieren die ICMP Source Quench und delayed ACKs weitestgehend, und senden dennoch immer "volle Pulle" [8-)]
Reply
  • Da die Hardware aufgerüstet wurde, schliesse ich Problem aufgrund unterdimensionierter Hardware (CPU vom unteren Ende der Leistungsmässigen Nahrungskette wie ein Atom N270 o.ä. etc) mal aus.

    Bei 50MBit in 30s...da sprechen wir also von einem Download in der Grössenordnung 150-200MByte

    Falls im Web Proxy die max AV Scan Size mehr oder weniger noch Default ist (20 MByte oder so), sollte der Proxy das direkt und ungescannt durchreichen. Falls Scansize grösser wie der erwähnte Download von eben 150-200 Mbyte (und ggf. sogar DUal AV aktiv), kann man die UTM je nach Downloadtyp (z.Bsp. .iso oder Archiv mit Tonnen von Archiven und Executables drin) u.U. arg beschäftigen...

    Falls obiges nicht zutrifft, würde ich am ehesten mal von folgenden Problemen ausgehen:

    - Interface Duplex Probleme (Cisco Router oder Kabelmodem an der UTM dran ?). Einfach mal das WAN Interface (oder ggf. auch interne LAN Interface) fix auf GBit FDX setzen

    - An den UTM Flooding Protection Einstellungen rumgespielt ? Falls aktiv, mal alle (insbes. TCP flooding protection) deaktivieren

    - Die erwähnten (falschen) QoS Einstellungen sind eher unwahrscheinlich, ausser man hat testweise mal was eingerichtet, und die Bandbreitenpools massiv unglücklich tief gesetzt...Die Drosselung mit dem Download Throttling funktioniert gegen das Internet erfahrungsgemäss eh nur bedingt oder gar nicht...die meisten CDN´s und ISP Router ignorieren die ICMP Source Quench und delayed ACKs weitestgehend, und senden dennoch immer "volle Pulle" [8-)]
Children
No Data