Hallo Leute, kennt ihr das Problem ihr wählt euch mittels PPOE bei eurer Firewall am Provider ein und macht einen SpeedTest, leider ist die Geschwindigkeit des Speedtest nicht der selbe wie wenn ihr die Breitbandverbindung direkt mit einen Notebook oder einer Fritzbox aufbaut. Hatte das Problem mit Barracuda FW, Fortinet und auch Mikrotik Router. Habe bei meiner Konverto Linie nun den MSS auf 1452 und den MTU auf 1492 (std.) eingestellt. Kennt jemand das Problem? Danke für die Tips VG

Bei IPv4 und "normalem" PPPoE, ist die MTU 1492 (1500 Byte Standard MTU - 8 IP PPPoE overhead), d.h. MSS ist bei 1452 (immer 40 Byte unter der MTU, aufgrund IP und TCP header). Mikrotik nutzt standardmäßig eine niedrigere MTU als notwendig, diese ist 1480 Byte, d.h. die MSS ist dann 1440 Byte. Kein MTU Wert ist grundsätzlich ein Problem, die Konfiguration darf nur nicht falsch sein. Oft wird nämlich MSS, MTU und die ping size unter windows und linux (ICMP payload lenght) miteinander verwechselt, das sind alle 3 komplett unterschiedliche Werte und wenn man diese miteinander verwechselt dann riskiert man falsche Einstellungen zu machen. RFC4638 erlaubt die PPPoE "IP" MTU auf 1500 Byte aufzudrehen - vorausgesetzt dass L2 dazwischen erlaubt 8 Byte mehr - das macht zb Brennercom. Dadurch wird hinter dem PPPoE Router eine Standard MTU von 1500 Byte IP geliefert und allen Problemen grundsätzlich ausgestellt. parkesel Habe bei meiner Konverto Linie nun den MSS auf 1452 und den MTU auf 1492 (std.) eingestellt. Sollte richtig sein, die manuell einzustellen sollte aber nicht notwendig sein; die MTU wird per PPP LCP ausgehandelöt, und die MSS kann sich dein Firewall basierend auf der ausgehandelten MTU selber ausrechnen (- 40 byte). parkesel leider ist die Geschwindigkeit des Speedtest nicht der selbe Üblicherweise laden bei MTU Problemen bestimmte Webseiten nicht komplett (Seite bleibt unvollständig geladen). Barracuda scheint mit PPPoE Sessions grundsätzlich ein Problem zu haben; aber MTU Probleme manifestieren sich normalerweise anders. Hängende Webseite und SSH session, File Transfers die nach 2 KB abbrechen, das sind normalerweise die Symptome eines MTU Problemes. parkesel Habe bei meiner Konverto Linie nun den MSS auf 1452 und den MTU auf 1492 (std.) eingestellt. Kennt jemand das Problem? Danke für die Tips Hat dass das Problem gelöst? Oder hast du die Einstellung gemacht und hast jetzt das genau gleiche Problem wie vorher auch?

EDIT: @[gelöscht] hat im selben Moment geantwortet, meine Antwort erübrigt sich somit 😁

Hallo, Danke für deine schnelle professionelle Antwort, eigentlich läuft die Linie über meine Barracuda recht Gut, nur ärgert es mich wenn ich von der FW CLI einen ./speedtest absetze bekomme ich Server: KONVERTO AG - Bozen (id = 25254) ISP: Konverto SpA Latency: 1.59 ms (0.12 ms jitter) Download: 97 Mbps (data used: 194.1 MB) Upload: 60.40 Mbps (data used: 27.2 MB) Packet Loss: 0.0% und mit meinen Windows Rechner direkt angehängt komme ich auf 119Mbit down.... Naja sonst läuft alle flüssig war nur mal Interesse halber ob man das irgendwie im Griff bekommt... ich habe gesehen wenn man vom Glasfaser Konverter > in einen Switch fährt und dann in die Barracuda für die PPOE läuft es schneller... Schönen Abend Danke

b123 Als Ergänzung: Mikrotik kann nur auf den SFP Ports keine MTU größer 1492 halten. Und fängt dann an andauernd zu reconnecten(bis der PPPoE Server der Konverto einen für paar Minuten sperrt). Bei den Mikrotiks scheint das aber mehr ein Bug als gewollt zu sein. Mit Tim-ADSL hinter einem Modem klappt eine MTU von 1492 einwandfrei. Bei mir ist deshalb der Mikrotik als Router auch wieder raus geflogen(und wegen Bugs im IPv6 Stack). (Barracuda) Firewalls sollte man meiner Meinung immer hinter einem Router betreiben. Firewalls sind als Firewall konzipiert, nicht als Modem/Router. Die Funktion auch Router zu spielen ist zwar gegeben, bei schnelleren Linien knicken solche Geräte aber schnell ein.

Perfekt ich glaube ihr habt recht, welchen Router würdet ihr für einen 200Mbit/200Mbit empfehlen ? Fritzbox 4040 ? direkt Glasrouter sind eher teuer....

parkesel Prinzipiell würde eine Fritzbox 4040 reichen. Leider können Fritzboxen aber keine VLANs.(Falls du das benötigst) Ich habe mir letztes Jahr einen Huawei AR1220EV günstig auf E-Bay geschossen. Die Lernkurve ist am Anfang zwar recht hoch(Config über CLI - aber mit guter Dokumentation). Funktioniert aber perfekt und hat noch nicht einmal Probleme verursacht.

netgear Mikrotik kann nur auf den SFP Ports keine MTU größer 1492 halten. Und fängt dann an andauernd zu reconnecten (bis der PPPoE Server der Konverto einen für paar Minuten sperrt). Bei den Mikrotiks scheint das aber mehr ein Bug als gewollt zu sein. PPPoE hat eine Standard MTU von 1492 Byte. Mehr gut nur mit explizitem Support von RFC4638, sowohl auf der CPE als auch auf der Provider Seite. Und dass ist auch bei den Top Notch Serien wie dem ASR 9k's afaik ein optionales Setting (sowas wie tag ppp-max-payload maximum 1500 unter der pppoe bba-group ), Aber wie schon gesagt, eine niedrigere MTU ist kein Problem. Schwieriger wird es bei Firewalls hinter PPPoE Routern, die mit 1500 Byte Standard MTU laufen, mit kaputtem PathMTU und VPN's darüber die MSS clamping am PPPoE Router unmöglich machen, da der VPN Payload ja verschlüsselt ist; aber dass ist ein non-Home User setup. @parkesel von Barracuda und PPPoE hört man grundsätzlich nichts gutes. Denke ein Router ist eine sehr gute Idee.

Ne Vlan brauche ich nicht dafür habe ich eventuell ja die Barracuda, brauch eigentlich nur einen Internet Router welcher Stabil läuft... Danke und schönen Abend

netgear Ich hatte damals mit meinem MikroTik direkt mit dem SFP als auch mit Media-Converter Probleme bei einer MTU von >1480 Bytes (an 1492 Bytes gar nicht zu denken) Probleme bei meiner Konverto Linie. Eine genauere Untersuchung auf dem Access-Switch von Edge-Core hat ergeben, dass der PPPoE Intermediate Agent die Pakete vom Mikrotik als malformed deklariert und verworfen hat, wenn dort eine MTU von mehr als 1480 Bytes eingestellt wurde, die PPPoE-Pakete haben den BNG also nie erreicht. Wurde der Intermediate Agent kurzzeitig deaktiviert, ist die Session zustande gekommen. Bei Konverto scheint die maximale MTU für PPPoE bei 1492 Bytes zu liegen: lks@vpn-rtr:~$ ping 195.254.255.230 -s 1464 PING 195.254.255.230 (195.254.255.230) 1464(1492) bytes of data. 1472 bytes from 195.254.255.230: icmp_seq=1 ttl=254 time=2.45 ms 1472 bytes from 195.254.255.230: icmp_seq=2 ttl=254 time=2.35 ms 1472 bytes from 195.254.255.230: icmp_seq=3 ttl=254 time=2.50 ms 1472 bytes from 195.254.255.230: icmp_seq=4 ttl=254 time=2.44 ms 1472 bytes from 195.254.255.230: icmp_seq=5 ttl=254 time=2.56 ms 1472 bytes from 195.254.255.230: icmp_seq=6 ttl=254 time=2.45 ms 1472 bytes from 195.254.255.230: icmp_seq=7 ttl=254 time=3.64 ms 1472 bytes from 195.254.255.230: icmp_seq=8 ttl=254 time=2.55 ms ^C --- 195.254.255.230 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 18ms rtt min/avg/max/mdev = 2.352/2.617/3.636/0.393 ms Addiert man zu den 1464 Bytes (Payload) noch die 20 Bytes des IP-Headers und nochmal 8 Bytes für den ICMP-Header kommt man genau auf 1492 Bytes. Ab 1465 Bytes Payload tritt eine Fragmentierung ein: lks@vpn-rtr:~$ ping 195.254.255.230 -s 1465 PING 195.254.255.230 (195.254.255.230) 1465(1493) bytes of data. ^C --- 195.254.255.230 ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 124ms Die MTU auf dem PPPoE Dialer-Interface wurde auf 1500 Bytes gesetzt. b123 Eine "kaputte" Path-MTU oder eine zickige Path-MTU-Discovery kann einem auch bei IPv6 Probleme bereiten (da ja eine Fragmentierung nicht implementiert ist), dass z.B. gewisse Webseiten beginnen zu hängen. Eine ipv6 mtu 1492 auf dem Dialer Interface hat nicht gereicht, musste den Befehl auch auf den DS-VLANs anwenden. parkesel Zurzeit gibt es auf ebay.it gebrauchte Huawei AR169 mit SFP Port zu vernünftigen Preisen. Dieser schafft ohne Probleme Gigabit-Geschwindigkeiten mit NAT über eine PPPoE Verbindung (habe selbst einen in meinem Netz laufen).

Path-MTU funktioniert im Internet eh nicht zuverlässig, zu viele Firewalls verwerfen die entsprechenden ICMP errors und zuviele Router generieren die ICMP errors erst gar nicht. Deswegen führt um MSS Clamping kein Weg. Dass bedeutet dass im TCP Handshake der MSS Wert vom Router dazwischen heruntergesetzt wird, das ist die maximale Größe des TCP Payload's in einem Packet (deswegen MTU - IP Overhead - TCP overhead). Der TCP Stack fährt dann die payload size so herunter, dass es zu keinen Problemen an den MTU Engpässen kommt. Aber, das funktioniert nur bei reinem TCP, und funktioniert schon nicht mehr wenn TCP in einen VPN Tunnel eingepackt ist.

Ladevorgang läuft…

Beim Laden dieser Seite ist ein Fehler aufgetreten.

Optimale MTU und MSS bei PPOE

« Vorherige Seite