Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 33 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 20145 views
  • Users 0 members are here
Options
Suggested
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

XG Firewall - Wifi MTU nach Update 17.1.3

Pascal G

Hallo Zusammen,

 

wir hatten bei einem Kunden die letzte Woche auf die hälfte seiner XG Firewalls (Insgesamt 15 Stk.) das Update 17.1.3 ausgerollt da wir im Vorfeld Verbindungsabbrüche im WLAN hatten und hofften das dies mit dem Update behoben wurde.

Jetzt ist auf den WLAN Schnittstellen aufgefallen das die MTU von 1500 auf 1450 umgestellt ist und der MSS Wert mit 1460 garnicht dazu passt.

Nach ein paar Prüfungen hat man auch schnell festgestellt dass WLAN extrem langsam ist (Pingzeiten auf Clients bis 225 ms). Habe das auch sicherheitshalber auf den XGs geprüft die noch in der Grundinstallation mit Firmware 17.0.0 sind. Hier ist der Wert noch korrekt.

Habe danach auf einer XG erstmal die MTU manuel auf 1500 gesetzt. Jetzt habe ich wieder Pingzeiten von 5 ms auf die Clients jedoch ist das auf dauer leider keine Lösung da bi einem Neustart die MTU natürlich wieder auf die 1450 umgestellt wird.

 

Hat jemand noch dieses Phänomen und eventuelle Ideen?

 

Also WLAN löschen, AP löschen und alles neu anlegen bringt auch nichts. Sobald man das WLAN einem AP zuweist wird die MTU wieder runter gestellt von 1500 auf 1450. Eventuell Fehler im AP Update?

 

 

Danke schon mal im Voraus

 

Grüße



This thread was automatically locked due to age.
Parents
  • 0

    Dank  haben wir mittlerweile eine Lösung die wohl Boot- und Update-sicher ist:

    Wir haben die MTU wieder auf Standard gesetzt und dafür TCP Segmentation Offloading deaktiviert. Damit erzielen wir dieselbe Performance, wie mit angepasster MTU.

     

    Hier seine Anleitung:

    Console>  system diagnostics interface-driver-settings set <interface_name> offload tso off

    To show: Console> system diagnostics interface-driver-settings show <interface_name> offload

    • tcp-segmentation-offload: off
      tx-tcp-segmentation: off
      tx-tcp-ecn-segmentation: off
      tx-tcp6-segmentation: off

    To revert back, simply:

    Console>  system diagnostics interface-driver-settings set <interface_name> offload tso on

  • 0 in reply to dja

    Das hört sich gut an und ich werde es bei Gelegenheit auch testen.

    Frage: was passiert konkret beim Deaktivieren des Offloadings? Oder besser gesagt: wann fällt mir diese Änderung wieder auf die Füße? Es hat ja vermutlich einen Grund, dass es standardmäßig aktiviert ist?

Reply
  • 0 in reply to dja

    Das hört sich gut an und ich werde es bei Gelegenheit auch testen.

    Frage: was passiert konkret beim Deaktivieren des Offloadings? Oder besser gesagt: wann fällt mir diese Änderung wieder auf die Füße? Es hat ja vermutlich einen Grund, dass es standardmäßig aktiviert ist?

Children
  • 0 in reply to Jelle

    Jelle said:
    Frage: was passiert konkret beim Deaktivieren des Offloadings? Oder besser gesagt: wann fällt mir diese Änderung wieder auf die Füße?

    Wie ich es verstehe, kann es wohl für eine höhere Last auf der CPU sorgen. Der Wikipedia-Artikel dazu: de.wikipedia.org/.../TCP_segmentation_offload

    Jelle said:
    Es hat ja vermutlich einen Grund, dass es standardmäßig aktiviert ist?

    Das habe ich mich auch gefragt. Laut  ist diese Einstellung unkritisch und es wird gar überlegt, ob nicht sogar off die neue Standardeinstellung sein sollte in zukünftigen SFOS-Releases.

     

    Wir haben TCP Segmentation Offloading seit einigen Tagen deaktiviert und bisher keine Probleme feststellen können.

  • 0 in reply to dja

    also ich teile dazu mal den Beitrag:

    https://blog.ip-projects.de/sophos-utm-problem-intel-82579lm-chipsatz/

    Diese Funktion dient dazu in schnellen Netzwerken die CPU Last von TCP/IP Paketen zu reduzieren indem Teilsegmente auf die Netzwerkkarte ausgelagert werden.

     

    Bei uns auch keine Probleme bisher. Denke das wird eher kritisch wenn die FW schon vor der Einstellung auf 80-90% CPU Last steht

  • 0 in reply to Pascal G

    Danke für Euer Feedback dazu. Dann werde ich das wohl auch mal testen.

    Wie sieht das aus bei einem HA-Cluster (A-P)? Muss ich das auf beiden Appliances machen und zwischendurch einen Wechsel durchführen?

  • 0 in reply to Jelle

    Ist das Problem zufällig noch bei jemandem aktuell?

     

    Ich bin bei meiner Fehlersuche auf dieses Thema gestoßen, bei mir ist die Performance der Seperaten Zone seit ich die XG installiert habe ziemlich schlecht.

    Betrifft aber nur den Download, der liegt bei ca. 0,5MBit - Upload ist mit 5 MBir ok. Im zweiten WLAN (Bridge to AP) passt es aber.

    MTU ist bei mir ebenfalls 1450, MSS 1460. Das offloading hab ich bereits deaktiviert, keine Besserung. Auch ohne IPS, WebProxy usw. wird es nicht schneller.

    Ich benutze übrigens die aktuellste SFOS Version.

    Hier noch mein Thema, das hab ich auf Englisch eröffnet, bevor ich dieses hier entdeckt habe:

    community.sophos.com/.../408386

  • 0 in reply to Andreas Leopold

    Soweit ich es verfolgt habe wurde das Offloading mit 17.5.4 automatisch deaktiviert und mit 17.5.5 und ggf. auch 17.5.6 dann aber nicht mehr. Einer der Gründe warum ich aktuell weiter 17.5.4 verwende. Aber das hast Du ja bereits selber deaktiviert. Allerdings muss die MSS doch 40 Byte unter der MTU liegen wenn ich mich recht entsinne? Also MSS auf 1410 stellen?

  • 0 in reply to Jelle

    Hallo!

    Ich habe gerade getestet - die MTU in der Konsole ist anscheinend doch 1500 - nur das Webinterface zeigt 1450 an. Auch bei einem neuen WLAN - ifconfig sagt immer 1500 - ich denke, das sollte dann so passen?

  • 0 in reply to Andreas Leopold

    Hab jetzt die MTU testweise auf 1300 eingestellt - keine Ahnung, wie ich darauf gekommen bin. Die IPS hat neu gestartet und die Performance war plötzlich OK.

    Ich werde das mal ein paar Tage beobachten. Kann es wirklich sein, dass diese Einstellung was bewirkt hat?

  • 0 in reply to Andreas Leopold

    Die MTU zu ändern war soweit ich mich entsinnen kann ein Lösungsvorschlag vor dem TCP Offloading und dem Patch dazu. Auch damals wurde schon festgestellt dass MTU in der Oberfläche und in der Konsole unterschiedlich sind.

    Am besten Du eröffnest dazu ein Ticket bei Sophos, da sie das offensichtlich immer noch nicht hinbekommen haben. Sowohl das Thema TCP Offloading welches anscheinend seit 17.5.5 wieder aktuell ist sowie auch das MTU-Verhalten bzw. die unterschiedlichen Werte.

  • 0 in reply to Jelle

    Okay, verstehe.

    Ich habe jetzt nochmals etwas getestet - das Ganze ist nicht so konstant, wie ich gedacht habe.

    Nach einiger Zeit sinkt der Speed wieder auf 1-2 MBit - mit MTU 1500 sind es 0,5 Mbit.

    Direkt nach dem Ändern ist es meistens wieder auf 16-17 MBit, das sinkt dann wieder langsam ab. Dafür hab ich nach dem Ändern sehr viel Packetloss und dropped Connections.

    Ich würde ja ein Ticket aufmachen, aber für meine Home-XG wird das wohl kaum jemanden interessieren. Ich bin XG Certified Architect und kenne die Support-Abläufe schon etwas.

    Aber ist nicht das erste Mal, dass ich bei einer XG Firewall ganz komische Dinge beobachten konnte, die sich dann meistens der Support auch nicht erklären konnte.

    Tut mir wirklich Leid, aber das bestärkt meine Meinung zu diesem Produkt,ich wollte es jetzt wieder einmal zu Hause verwenden, aber niemals würde ich eine XG Firewall produktiv zu einem Kunden stellen... :(

  • 0 in reply to Andreas Leopold

    Welche Drops siehst du?

    Wir brauchen den Drppkt von der Appliance.