garlic
Goto Top

Internetzugang langsam mit MikroTik 750GL

Hi zusammen,

ich nutze den MikroTik 750GL als Router auch um in das Internet zu kommen. Das funktioniert auf den ersten Blick einwandfrei - aber bestimmte Applikationen laufen nun deutlich langsamer als mit meinem simplen TP-Link TL-WR841N, den ich vorher nutze.

Ich habe dann die Download und Upload Geschwindigkeit am PC geprüft - alles okay. Dennoch läuft z.B. Watchever gerne in Pixel-Modus, da die Bandbreite offensichtlich nicht hoch genug für hohe Qualität ist - nutze ich den TP-Link, kann ich das nicht beobachten. Ebenso der Seitenaufbau usw.

Hat jemand eine Idee, ob es Optionen gibt, die ich hierzu berücksichtigen muss? Sorry für die vage Frage, aber ich habe keine Ahnung, woran es liegen kann, wenn normalerweise die Download und Upload Geschwindigkeiten passen.

PS: Ich habe alle Ports auf GBit gestellt, nur den WAN Port habe ich auf 100MBit gelassen.

VG, Garlic

Content-Key: 244046

Url: https://administrator.de/contentid/244046

Ausgedruckt am: 29.03.2024 um 06:03 Uhr

Mitglied: colinardo
colinardo 18.07.2014 aktualisiert um 09:02:44 Uhr
Goto Top
Moin,
hört sich für mich auf den ersten Blick nach fehlenden Quality of Service Regeln für Streaming Traffic an:
http://forum.mikrotik.com/viewtopic.php?f=13&t=73214

Wenn es jeden Traffic betrifft ist eventuell auch die MTU auf dem DSL-Interface zu hoch eingestellt, so dass es zur Fragmentierung der Pakete kommt. Hänge dich mal mit Wireshark rein, damit lässt sich das schnell aufklären.

Grüße Uwe
Mitglied: 108012
108012 18.07.2014 um 08:58:49 Uhr
Goto Top
Hallo,

zusätzlich noch etwas

PS: Ich habe alle Ports auf GBit gestellt, nur den WAN Port habe ich auf 100MBit gelassen.
Kann man machen klar, nur warum? Stell den bitte auch auf GB LAN um.

Gruß
Dobby
Mitglied: garlic
garlic 21.07.2014 um 11:18:43 Uhr
Goto Top
So, ich habe mal auch den auf GBit umstellt - aber das hat nicht geholfen.

Ich habe mir auch den Link angeguckt bzgl. Priorisierung für Traffic, aber kann es das wirklich sein? Im meinem Netz ist doch kein großer Traffic, der stören könnte und die Bandbreite sollte doch auch locker reichen, um das bißchen Watchever rüberzuschaufeln.
Zumal der simple TP-Link Router da vorher keine Probleme hatte.

Ich habe es gestern wieder ausprobiert und es läuft dann 15min reibungslos - plötzlich geht die Qualit runter oder es läuft die Zeit weiter, aber das Bild und Ton stehen und nach 5 Sekunden geht es an der neuen Stelle weiter.

Habe ich alles nicht mit dem alten Router - nur mit dem MikroTik und auch nur sporadisch. Es kann auch mal eine Stunde gut gehen.

Ich konfiguiere über das Web-Config-Tool... Gibt es dort auch die Optionen für die Priorisierung von Traffic?
Nur wie gesagt - das kann ich mir eigentlich wirklich nicht vorstellen. Bandbreite und Traffic sind doch da kein Bottlneck in dem Netz in dem nichts anderes lief...

VG, Garlic
Mitglied: colinardo
colinardo 21.07.2014 aktualisiert um 11:30:18 Uhr
Goto Top
Also einen TP-Link mit einem Mikrotik zu vergleichen geht schon mal garnicht, das ist wie Autos und BobbyCars zu vergleichen.
Der Mikrotik kann viel, dafür muss aber auch dessen Besitzer entsprechend viel wissen. Das was der TP-Link im Hintergrund erledigt, musst du als Mikrotik User alles selber konfigurieren (QOS Priorisierung / Mangle Rules etc. pp), das ist halt keine Fritte die dem User alles abnimmt face-wink

Erste Anlaufstelle wie immer das Mikrotik Wiki:
http://wiki.mikrotik.com/wiki/Bandwidth_Managment_and_Queues

Grüße Uwe
Mitglied: garlic
garlic 21.07.2014 um 13:48:11 Uhr
Goto Top
Ja, keine Frage... das verstehe ich ja auch. Sicherlich bin ich da jetzt kein absoluter Experte und kenne daher nicht jede Einstellung - aber ich hätte doch vermutet, dass die Grundkonfig grob funktionieren sollte.
Grundkonfig also die WAN Konfig bzgl. IP, Gateway usw, dazu das Routing innerhalb des LAN.

Hier geht es jetzt ja um den Spezialfall: Kann es sein, dass der MikroTik etwas ausbremst? Und da würde ich beim Balancing denken: Wenn ich jetzt 2 WANs dranhätte und verschiedene Clients, okay - aber momentan habe ich gerade mal einen Client mit WAN-Zugriff gehabt, ein WAN-Modem am MikroTik direkt im Ether1 und das mit der Basic-Konfiguration....

Gibt es denn ggf. ein Tutorial was hier helfen kann? Die WAN Konfig finde ich als "getting started", aber das ist auch eher die Minimalkonfig, die ich schon gemacht habe und eben nichts darüber hinaus.

Ich habe im Wiki gestöbert: Häufig geht es da ja eher ums limiten. Da hat jemand ein langsamen Internetzugang, aber viele Clients laufen.
Oder eben beim Balancing 2 Internetzugänge und man möchte nun die Streaming oder VoIP Dienste bevorzugen.

So wie ich das sehe, habe ich bei meiner Mini-Konfig derzeit gar keine Limits gesetzt, daher ist mir auch nicht klar, wieso es zu Verzögerungen kommt und dann zu so seltsamen. Ich werde mal den TP-Link wieder dranhängen und verifizieren, dass es nicht doch auf der anderen Seite liegt und es bisher nur Zufall war.

VG, Garlic
Mitglied: colinardo
colinardo 21.07.2014 aktualisiert um 14:16:52 Uhr
Goto Top
aber ich hätte doch vermutet, dass die Grundkonfig grob funktionieren sollte.
Das tut sie ja auch.

Schalte Wireshark ein und du findest die Ursache vermutlich sofort.. oder mit Winbox den Traffic via Torch beobachten und auf dropped und resubmitted packets überprüfen. Wenn das der Fall ist, stimmt die MTU auf dem PPPoE-Interface vermutlich nicht (Max MRU und Max MTU auf 1492 setzen), dann fragmentieren die Pakete und die Geschwindigkeit geht rapide in den Keller.

Wurde schon die aktuellste RouterOS Firmware installiert ?

Grüße Uwe

Mikrotik Router Routerboard 750GL PPPOE Einwahl TELEKOM VDSL50
Mitglied: garlic
garlic 21.07.2014 um 21:33:32 Uhr
Goto Top
Danke dir!

Ich habe mal auf 5.26 geupdatet - es war 5.25 drauf. Außerdem habe ich Torch mir angeguckt, aber irgendwie bin ich blind: Wo sehe ich da, ob da Paket gedropt wurde? Ich sehe da nur die Pakete, die durchkommen, oder?

VG, Garlic
Mitglied: garlic
garlic 23.07.2014 um 14:52:00 Uhr
Goto Top
Zitat von @colinardo:

Schalte Wireshark ein und du findest die Ursache vermutlich sofort.. oder mit Winbox den Traffic via Torch beobachten und auf
dropped und resubmitted packets überprüfen. Wenn das der Fall ist, stimmt die MTU auf dem PPPoE-Interface
vermutlich nicht (Max MRU und Max MTU auf 1492 setzen), dann fragmentieren die Pakete und die Geschwindigkeit geht rapide in den
Keller.


Mit Wireshark müsste ich den WAN Port vorher mirrorn, oder? Damit ich das an einem anderen Port abgreifen kann?
Ich habe daher mal Torch genutzt - kann da aber eben nicht sehen, ob ein Paket gedropt wurde. Habe testweise die MTU umgestellt, aber hilft nix.

Dann habe ich mir mal die IP-Firewall angeguckt. Dort ist ein INBOUND, der recht viel droppt. Da ich gedroppte Pakete in Torch nicht finde, weiß ich nicht was, habe aber das aber mal ausgeschaltet.
Es ist die klassiche Konfig: Also ein Drop für alles am Ende der INBOUND Regeln, was nicht durch einen ALLOW durchgelassen wird. Ich habe keinen ALLOW für "NEW" gefunden, vielleicht liegt es daran? Jedenfalls teste ich das jetzt mal und mache den aus...

Dito bei FORWARD, aber da wird kaum etwas gedropt. Wenn ist es der INBOUND auf dem WAN Port...

VG, Garlic
Mitglied: colinardo
colinardo 23.07.2014 aktualisiert um 19:31:44 Uhr
Goto Top
Dann poste mal deine Firewall Config. Hast du auch sicher eine related und eine established Regel in der Forward-Chain auf accept stehen ?

p.s. fragmentierte Pakete kannst du in den Eigenschaften des WAN-Interfaces auf den Tabs RxStats und TxStats sehen
Mitglied: 108012
108012 23.07.2014 um 19:28:38 Uhr
Goto Top
Und warum nicht auf RouterOS v. 6.7 wenn man mal fragen darf?

Gruß
Dobby
Mitglied: garlic
garlic 23.07.2014 um 21:45:23 Uhr
Goto Top
Es gibt doch ein automatisches Update in Router-OS - und da hat er "nur" die 5.26 angeboten?!
Mitglied: garlic
garlic 23.07.2014 um 21:48:36 Uhr
Goto Top
Zitat von @colinardo:

Dann poste mal deine Firewall Config. Hast du auch sicher eine related und eine established Regel in der Forward-Chain auf
accept stehen ?

p.s. fragmentierte Pakete kannst du in den Eigenschaften des WAN-Interfaces auf den Tabs RxStats und TxStats sehen

Also - es scheint jetzt zu laufen. Forward-Chain habe ich nicht angetastet, sondern nur INPUT:

In Input gab es per Default eine Regel für ICMP und dann für related und established..... dann kam der DROP, der jedoch nur für den WAN Port. Darauf liefen viele Daten.
Ich habe den Drop deaktiviert - alles gut.
Dann habe ich ihn wieder aktiviert und darüber eine Regel erstellt, die "new" akzeptiert (wie die anderen auf allen Interfaces). Scheint auch zu laufen.

Also NEW heißt doch, die erste Verbindung die eröffnet wird. Wenn die vorher nicht durch kam, wie kann man überhaupt Verbindungen aufbauen?

VG; Garlic
Mitglied: colinardo
colinardo 23.07.2014, aktualisiert am 24.07.2014 um 18:06:05 Uhr
Goto Top
Dann habe ich ihn wieder aktiviert und darüber eine Regel erstellt, die "new" akzeptiert (wie die anderen auf allen Interfaces). Scheint auch zu laufen.
laufen tut es so, nur öffnest du dein Netz damit für Eindringlinge wie ein Scheunentoor, wenn du die Regel nicht auf das interne Netz einschränkst.
Das von dir gewünschte Verhalten machen meine oben genannten Forwarding Rules, denn die besagen das wenn ein Client aus deinem Netz eine Anfrage ins Internet sendet die dazugehörigen Pakete(related) auch wieder die Firewall passieren dürfen.

Also hier stimmt definitiv was mit deinem FW Regeln nicht!! Soll ich jetzt andauernd raten oder postest du uns jetzt endlich mal deine Config ?? Danke.
/ip firewall export
Sonst können wir das Thema hier schließen, denn es liegt sehr wahrscheinlich kein echtes Problem sondern ein Verständnisproblem deinerseits vor.

Grüße Uwe

p.s. wegen der Firmware geh mal auf die Mikrotik-Seite, wir sind inzwischen bei 6.17, also Meilen vorraus !!
Mitglied: garlic
garlic 24.07.2014 um 17:13:29 Uhr
Goto Top
also dass es eher ein Verständnisproblem ist, davon konnten wir seit Anfang an ausgehen und nicht unbedingt ein Fhler in der Router-OS.

Ich poste die Konfig - kann ich bloß nicht von hier aus, erst, wenn ich wieder zu Hause bin. Dann geht das aber sowas von los!
Wobei sie exakt so ist wie von mir unten aufgeschrieben, aber klar, ein Post ist eindeutiger!

Ich muss zugeben, dass ich die Rules basierend auf Connection States auch noch nicht 100%ig verstanden habe und mit dafür auch die bassende Lektüre im Netz noch nicht untergekommen ist.
Klar verstehe ich bzgl. new, related (verweis auf andere Protokoll und damit die Freigabe dafür) und established die Unterschiede... mir ist auch klar, dass Input der Router selbst ist und Forward für die Clients gilt - aber warum man new nicht benötigt hat z.B., das war mir ein Rätsel.

Offen wie ein Scheunentor: Ja - aber wie wäre nun ein Home-Router wie der TP-Link. Haben die automatische Settings? Die können doch gar nicht über Connections States filtern, oder?
Bei der Router-Firmeware hatte ich mich halt auf das Auto-Update verlassen. Vermutlich springt das nie von 5 auf 6 sondern nur innerhalb 5?! Auch darum kümmere ich mich heute Abend.

Ich melde mich - danke für eure Geduld!
Mitglied: colinardo
colinardo 24.07.2014 aktualisiert um 17:52:35 Uhr
Goto Top
mit den Default-Configs läuft das auf jeden Fall. Setze die Config zurück und teste damit:
http://wiki.mikrotik.com/wiki/Manual:Default_Configurations#Firewall.2C ...
Von da aus kannst du dann Schritt für Schritt weiter einschränken und zwischendrin immer wieder testen ob noch alles läuft.

Ein universelles Basis-Firewall Script was weiter einschränkt, findest du hier:
http://wiki.mikrotik.com/wiki/Basic_universal_firewall_script

aber wie wäre nun ein Home-Router wie der TP-Link. Haben die automatische Settings? Die können doch gar nicht über Connections States filtern, oder?
Die haben ihren Standardregelsatz, und ja sie können Connectionstates unterscheiden, sind ja auch nur Linux-Derivate im Hintergrund. Alles andere regeln Scripte die die Firewall Config anpassen wenn der User z.B. einen Port über das Web-IF freigibt.
Mitglied: garlic
garlic 24.07.2014 aktualisiert um 20:43:49 Uhr
Goto Top
Hier die Config - kleine Anmerkung: Ich hatte genau die Default-Konfig, aber ohne NEW ging es halt nicht face-sad

[admin@MikroTik] >> /ip firewall export
  1. jul/24/2014 19:04:59 by RouterOS 5.26
  2. software id = KKJ2-NXZI
#
/ip firewall connection tracking
set enabled=yes generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s \
tcp-close-wait-timeout=10s tcp-established-timeout=1d \
tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-syncookie=no \
tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s
/ip firewall filter
add action=accept chain=input comment=\
"accept icmp protocol related connections" disabled=no protocol=icmp
add action=accept chain=input comment="accept established connections" \
connection-state=established disabled=no
add action=accept chain=input comment="accept related connections" \
connection-state=related disabled=no
add action=accept chain=input comment="accept new connections" \
connection-state=new disabled=no
add action=drop chain=input comment=\
"drop all other Connections incoming on WAN" disabled=no in-interface=\
ether1-gateway
add action=accept chain=forward comment="accept established connections" \
connection-state=established disabled=no
add action=accept chain=forward comment="accept related connections" \
connection-state=related disabled=no
add action=drop chain=forward comment="drop invalid connections" \
connection-state=invalid disabled=no
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" disabled=\
no out-interface=ether1-gateway to-addresses=0.0.0.0
/ip firewall service-port
set ftp disabled=no ports=21
set tftp disabled=no ports=69
set irc disabled=no ports=6667
set h323 disabled=no
set sip disabled=no ports=5060,5061 sip-direct-media=yes
set pptp disabled=no
[admin@MikroTik] >>


PS: Habe eben auf 6.17 geupdatet. Geht wohl von 5 auf 6 nicht über das Autoupdate, aber manuell ging es. Danke für den Tipp...
Nun habe ich die NEW Regel wieder rausgeschmissen (also die Zeile:
--
add action=accept chain=input comment="accept new connections" \
connection-state=new disabled=no
---
und mit der neuen FW scheint es auch dann zu laufen!
Mitglied: colinardo
colinardo 24.07.2014 aktualisiert um 20:58:59 Uhr
Goto Top
Zitat von @garlic:
und mit der neuen FW scheint es auch dann zu laufen!
das muss es, denn wenn du dir mal diese Input-Regel anschaust:
add action=drop chain=input comment="drop all other Connections incoming on WAN" disabled=no in-interface=ether1-gateway
wirst du feststellen das hier nur Pakete gedroppt werden die vom WAN her kommen. Deswegen ist deine Input State:NEW-Regel unsinn denn diese Pakete passieren von innen trotzdem die Firewall, da die obige DROP-Regel nur Traffic betrifft der von außen am WAN Port ankommt.
Und mit einer Regel die ohne Angabe eines Interfaces mit Connectionstate NEW angelegt ist, könnte jetzt jeder aus dem Internet auf alle Ports deines Mikrotik zugreifen !!

Grüße Uwe
Mitglied: garlic
garlic 24.07.2014 um 23:02:00 Uhr
Goto Top
In der 5.x musste ich die Drop-Regel deaktivieren oder die unsinnige New einbauen, damit Watchever vernünftig lief.
Seit dem Update geht es mit den default Settings der Firewall ja zum Glück und ich habe natürlich den Unsinn entfernt. warum es vorher nicht lief, ist mir zwar nicht klar - Hauptsache es läuft jetzt und ich kann wieder mit den default IP. Firewall Settings arbeiten.

Ich werde mich da nun mal einarbeiten und die über die Basis-Settings hinaus die Regeln definieren - danke für dem Link!
Mitglied: garlic
garlic 25.07.2014 um 12:20:19 Uhr
Goto Top
So - ich laufe nun wieder mit den Default settings der Firewall und es sieht gut aus.

Abschließend würde ich gerne noch allen, die auf diesen Post stoßen, folgenden Link empfehlen:

http://www.youtube.com/watch?v=3NBtrZxctbA

Dort wird die Firewall des Mikrotik gut erklärt. Leider fehlt auch da der logische Zusammenhang, warum man z.B. NEW nicht erstellt (weil man eben eingehenden Traffic nicht auf NEU zulässt, ausgehenden aber schon), aber es hilft dennoch. Auch die anderen Teile sind für Mikrotik-Neueinsteiger sehr hilfreich und besser als viele andere Tutorials.

Ebenso kann ich die LOG-Firewall-Regel nur empfehlen. So findet man genau die gedroppten Pakete, die einen interessieren - also den Einfluss der Firewall!

Außerdem eine kurze Zusammenfassung:

1) Mein Router Mikrotik 750GL schien Pakete so droppen und dadurch lief das Internet nicht flüssig, vor allem Streams nicht.
2) Es lag offensichtlich an der IP-Firewall, denn deaktivierte man die Drop-Regel, lief es problemlos (also keine Fragmentierung etc. als Ursache)
3) Das Autoupdate bot nicht den Sprung von RouterOS 5.x auf 6.x an
4) Nach dem manuellen Update auf v6.7, lief alles problemlos auch mit den ursprünglichen Firewalleinstellungen

Ich werde nun die Firewall noch etwas detaillierter konfigurieren, um die Sicherheit weiter zu erhöhen - aber das Problem hätte sich damit natürlich nicht gelöst.

Danke an alle, die geholfen haben und genug Geduld hatten face-smile