9
IP-Telefonie priorisieren in Mikrotik Router
Hallo zusammen,
ich verzweifle hier gerade ein wenig, deshalb hoffe ich auf eure Hilfe.
Situation:
Telekom-Privatkunden-All-IP-ADSL-Anschluss mit Modem Vigor Draytek 130 und Mikrotik Router RB750Gr3.
ADSL-Leitung = 6.000er
VoIP-Telefon Gigaset C430A Go, Audio Codec 711 an erste Stelle gesetzt, rest auf default:
SIP-Port 5060(-5076)
RTP-Ports 5004-5020
Mikrotik-Router:
ether1 = Internet-Gateway vie PPPoE
ether2 = LAN 192.168.10/24 (nicht weiter wichtig)
ether5 = Telefonie-Netz 192.168.11/24, VoIP-Telefon direkt angeschlossen mit IP 192.168.11.2
NAT ist natürlich mit im Spiel....
Die Telefonie ist eingerichtet und funktioniert.
Da die Internetverbindung nicht die schnellste ist möchte ich gerne die Telefonie priorisieren, damit sie IMMER mit bester Qualität und garantierter Bandbreite läuft, egal wieviel traffic auf der Leitung ist. Also versuche ich die ganze Zeit schon den ausgehenden Traffic zu manglen und zu priorisieren. Aber irgendwie klappt das (glaube ich) nicht.
Bei einer aktiven Telefonverbindung sehen die Connections so aus:
An Pfeil1 sehen wir den Datentraffic aus dem Telefonat. (Der liegt konstant bei ca 85kbit/s, da ich den Audio Codec 711 gewählt habe, also 64kbit/s + overhead etc).
In der Interface-Ansicht kann ich dann auch ablesen, dass da ca 50 Pakete pro Sekunde durch die Leitung gehen.
Verwirrend finde ich ein wenig, dass bei Pfeil2 zwei öffentliche IPs stehen. Soweit ich das verstehe, ist das der Traffic zwischen SIP-Router der Telekom und meinem Mikrotik.
Was ich vermisse ist, dass dieser Traffic im LAN zu meinem Telefon 192.168.11.2 nicht auftaucht. Aber das liegt vermutlich am STUN, oder?
Jedenfalls habe ich dann einfach erstmal gesagt, er solle alle Pakete auf den UDP-Ports des Telefons manglen:
Jetzt die markierten Pakete aus dem Telefon-ether5-Port mit Priorität 2 belegen und eine Bandbreite von 100kbit/s in beide Richtungen garantieren:
Ich finde, das müsste so gehen. Aber wenn ich mir bei einer aktiven Telefonverbindung den Traffic der Queue anschaue, geht da kaum was durch. Und das verstehe ich nicht.
Da gehen nur einzelne Pakete pro Sekunde durch, wenn überhaupt. Erwarten würde ich aber die ca 50 Pakete/s bzw 85kbit/s.
Alternativ habe ich auch versucht beim Manglen nicht nur die Pakete der betroffenen udp-ports auszuwählen, sondern ich habe als In-Interface einfach ether5 ausgewählt (einfach zu testzwecke, um auszuschließen, dass ich einen Port, ein Protokoll, eine Verbindung übersehe), aber auch dadurch läuft nicht der erwartete Traffic durch die Queue.
Kann da bitte jemand Licht ins Dunkel bringen?
Hab ich irgendwas übersehen, bin ich mal wieder zu doof, oder wie?
weitere Fragen:
1)
UDP ist ja eigentlich verbindungslos, ist klar. Ist das dann richtig, dass ich die UDP-Pakete direkt einzeln markiere, oder gibt es aufgrund des STUN oder so dennoch eine Art Verbindung, sodass ich zunächst die Verbindung (also somit auch inkl related) und dann die zu der Verbindung gehörenden Pakete manglen muss, um alle Pakete zu erwischen?
2)
Welche chain muss ich beim Markieren auswählen? prerouting, forwarding, oder ist das in diesem Fall egal? (Habe da natürlich auch schon alles mögliche getestet, ohne Änderung)
Habe verschiedene HowTo's gesehen - mal wird es so gemacht mal so. Aber was ist richtig?
Falls ihr noch Lust habt, hätte ich noch ne Nebenfrage:
N1)
Muss man auch eingehenden VoIP-Traffic priorisieren? Habe das in verschiedenen HowTo's gesehen. Aber ich denke mal: sobald er am WAN-Port reinkommt, geht er auch ins LAN, ganz nach FIFO.
Was soll man da noch priorisieren? Wenn überhaupt sortiert doch bereits die Telekom beim Versenden an meinen Anschluss die VoIP-Pakete vor anderen Daten in den Datenstrom, oder? Dann kommen sie auch eher an und werden von meinem Router eher verarbeitet, oder habe ich da nen Denkfehler?
Vielen Dank vorab!
Gruß,
Colt
ich verzweifle hier gerade ein wenig, deshalb hoffe ich auf eure Hilfe.
Situation:
Telekom-Privatkunden-All-IP-ADSL-Anschluss mit Modem Vigor Draytek 130 und Mikrotik Router RB750Gr3.
ADSL-Leitung = 6.000er
VoIP-Telefon Gigaset C430A Go, Audio Codec 711 an erste Stelle gesetzt, rest auf default:
SIP-Port 5060(-5076)
RTP-Ports 5004-5020
Mikrotik-Router:
ether1 = Internet-Gateway vie PPPoE
ether2 = LAN 192.168.10/24 (nicht weiter wichtig)
ether5 = Telefonie-Netz 192.168.11/24, VoIP-Telefon direkt angeschlossen mit IP 192.168.11.2
NAT ist natürlich mit im Spiel....
Die Telefonie ist eingerichtet und funktioniert.
Da die Internetverbindung nicht die schnellste ist möchte ich gerne die Telefonie priorisieren, damit sie IMMER mit bester Qualität und garantierter Bandbreite läuft, egal wieviel traffic auf der Leitung ist. Also versuche ich die ganze Zeit schon den ausgehenden Traffic zu manglen und zu priorisieren. Aber irgendwie klappt das (glaube ich) nicht.
Bei einer aktiven Telefonverbindung sehen die Connections so aus:
An Pfeil1 sehen wir den Datentraffic aus dem Telefonat. (Der liegt konstant bei ca 85kbit/s, da ich den Audio Codec 711 gewählt habe, also 64kbit/s + overhead etc).
In der Interface-Ansicht kann ich dann auch ablesen, dass da ca 50 Pakete pro Sekunde durch die Leitung gehen.
Verwirrend finde ich ein wenig, dass bei Pfeil2 zwei öffentliche IPs stehen. Soweit ich das verstehe, ist das der Traffic zwischen SIP-Router der Telekom und meinem Mikrotik.
Was ich vermisse ist, dass dieser Traffic im LAN zu meinem Telefon 192.168.11.2 nicht auftaucht. Aber das liegt vermutlich am STUN, oder?
Jedenfalls habe ich dann einfach erstmal gesagt, er solle alle Pakete auf den UDP-Ports des Telefons manglen:
Jetzt die markierten Pakete aus dem Telefon-ether5-Port mit Priorität 2 belegen und eine Bandbreite von 100kbit/s in beide Richtungen garantieren:
Ich finde, das müsste so gehen. Aber wenn ich mir bei einer aktiven Telefonverbindung den Traffic der Queue anschaue, geht da kaum was durch. Und das verstehe ich nicht.
Da gehen nur einzelne Pakete pro Sekunde durch, wenn überhaupt. Erwarten würde ich aber die ca 50 Pakete/s bzw 85kbit/s.
Alternativ habe ich auch versucht beim Manglen nicht nur die Pakete der betroffenen udp-ports auszuwählen, sondern ich habe als In-Interface einfach ether5 ausgewählt (einfach zu testzwecke, um auszuschließen, dass ich einen Port, ein Protokoll, eine Verbindung übersehe), aber auch dadurch läuft nicht der erwartete Traffic durch die Queue.
Kann da bitte jemand Licht ins Dunkel bringen?
Hab ich irgendwas übersehen, bin ich mal wieder zu doof, oder wie?
weitere Fragen:
1)
UDP ist ja eigentlich verbindungslos, ist klar. Ist das dann richtig, dass ich die UDP-Pakete direkt einzeln markiere, oder gibt es aufgrund des STUN oder so dennoch eine Art Verbindung, sodass ich zunächst die Verbindung (also somit auch inkl related) und dann die zu der Verbindung gehörenden Pakete manglen muss, um alle Pakete zu erwischen?
2)
Welche chain muss ich beim Markieren auswählen? prerouting, forwarding, oder ist das in diesem Fall egal? (Habe da natürlich auch schon alles mögliche getestet, ohne Änderung)
Habe verschiedene HowTo's gesehen - mal wird es so gemacht mal so. Aber was ist richtig?
Falls ihr noch Lust habt, hätte ich noch ne Nebenfrage:
N1)
Muss man auch eingehenden VoIP-Traffic priorisieren? Habe das in verschiedenen HowTo's gesehen. Aber ich denke mal: sobald er am WAN-Port reinkommt, geht er auch ins LAN, ganz nach FIFO.
Was soll man da noch priorisieren? Wenn überhaupt sortiert doch bereits die Telekom beim Versenden an meinen Anschluss die VoIP-Pakete vor anderen Daten in den Datenstrom, oder? Dann kommen sie auch eher an und werden von meinem Router eher verarbeitet, oder habe ich da nen Denkfehler?
Vielen Dank vorab!
Gruß,
Colt
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 330471
Url: https://administrator.de/forum/ip-telefonie-priorisieren-in-mikrotik-router-330471.html
Ausgedruckt am: 05.04.2025 um 22:04 Uhr
9 Kommentare
Neuester Kommentar
Normalerweise solltest du NICHT mit dem Router klassifizieren !! Das sollen wenn möglich IMMER die Endgeräte machen und tun sie, sprich deine Telefone, vermutlich auch.
Hast du mal mit dem Wireshark nachgesehen WIE die Telefone ihren Voice Traffic priorisieren (.1p oder DSCP und mit welchen Werten ??
Einfach mal ein Telefonat mit dem Kabelhai mitschneiden.
Dann hast du ja schon entsprechend klassifizierte Pakete und musst diese Frickelei nicht am Router machen sondern must ihm lediglich sagen wie er mit entsprechend klassifizierten Pakete umgehen soll.
Das ist viel einfacher und stressfreier.
Deine Vorgehensweise ist kontraproduktiv, denn schon wenn jemand das telefon umsteckt ists aus mit der Priorisierung.
Nicht aber wenn der Router global auf eingehende QoS markierte Pakete reagiert wie sie die Endgeräte anliefern.
Hast du mal mit dem Wireshark nachgesehen WIE die Telefone ihren Voice Traffic priorisieren (.1p oder DSCP und mit welchen Werten ??
Einfach mal ein Telefonat mit dem Kabelhai mitschneiden.
Dann hast du ja schon entsprechend klassifizierte Pakete und musst diese Frickelei nicht am Router machen sondern must ihm lediglich sagen wie er mit entsprechend klassifizierten Pakete umgehen soll.
Das ist viel einfacher und stressfreier.
Deine Vorgehensweise ist kontraproduktiv, denn schon wenn jemand das telefon umsteckt ists aus mit der Priorisierung.
Nicht aber wenn der Router global auf eingehende QoS markierte Pakete reagiert wie sie die Endgeräte anliefern.
Hallo,
kann man so oder so sehen. Beide Varianten haben Vor- und Nachteile.
Möchte ich aber auch gar nicht großartig zum Thema machen hier, sondern ich würde viel lieber wissen, was ich falsch mache bzw warum die Pakete in meiner Konfiguration nicht markiert werden.
Gruß,
Colt
kann man so oder so sehen. Beide Varianten haben Vor- und Nachteile.
Möchte ich aber auch gar nicht großartig zum Thema machen hier, sondern ich würde viel lieber wissen, was ich falsch mache bzw warum die Pakete in meiner Konfiguration nicht markiert werden.
Gruß,
Colt
Zitat von @coltseavers:
Möchte ich aber auch gar nicht großartig zum Thema machen hier, sondern ich würde viel lieber wissen, was ich falsch mache bzw warum die Pakete in meiner Konfiguration nicht markiert werden.
Die Ports die du angegeben hast dienen nur der Authentifizierung und Benachrichtigung von SIP und haben mit den übertragenen SIP Daten die über RTP (UDP) laufen nichts gemeinsam. Deswegen laufen die VOICE Daten bei dir auch nicht durch den Queue.Möchte ich aber auch gar nicht großartig zum Thema machen hier, sondern ich würde viel lieber wissen, was ich falsch mache bzw warum die Pakete in meiner Konfiguration nicht markiert werden.
Also musst du wie @aqui schon sagt entweder ein separates Subnetz für VoIP definieren oder ein separates VLAN welches du entweder am Mikrotik definierst oder per Tagging an den Telefonen selber. Dann markierst du sämtliche Pakete aus diesem VLAN/Subnetz für die Priorisierung ausgehend (SRC) sowie eingehend (DST), dann kommt das problemlos zum fliegen.
Gruß
Beide Varianten haben Vor- und Nachteile.
Nein, sorry das ist Quatsch, denn dein Ansatz ist der Falsche und hat die Nachteile. Ein Vermitlungsgerät wie ein Switch oder Router soll niemals Traffic klassifizieren !Das soll immer nur das Endgerät machen. Die Vorteile liegen auf der Hand. Nachteile gibt es keine. Die Vermittlungsgeräte bekommen immer nur ein Profil was mit entsprechend klassifiziertem Traffic zu tun ist. Nie andersrum.
Möchte ich aber auch gar nicht großartig zum Thema machen hier
Das ist auch besser so, denn es gibt KEIN Thema dazu. Das ist durchgängige Praxis.Falsch machst du einiges:
- Was soll UDP Port 17 sein ?? Das ist Qoute of the day und ja rein gar nix mit VoIP zu tun !!
- SIP nutzt 5060 und 5061 und RTP was die eigentlichen Voice Daten transportiert nutzt dynmaische Ports die ausgehandelt werden.
- Für entsprechend klassifizierte Pakete nutzt du die Default Queue ? Warum, dann damit ist nichts priorisiert ?
Sinnvoll wäre das dann den ToS oder CoS Wert an dem Port generell zu setzen. D.h. der Router oder embedded Switch priorisiert dann generell alles was an dem Port reinkommt.
Dann sagst du dem Router noch in welche Prio Queue diese Pakets kommen sollen und gut iss. Alles Aufwand der überflüssig ist wenn die Pakete schon entsprechend klassifiziert in den MT kommen. Das ist mit Sicherheit auch der Fall bei deinem Telefon denn VoIP Endgeräte machen das in der Regel immer per Default. Du musst eben nur sehen welchen Wert und ob CoS oder ToS.
Kollege cruzer hat ja schon alles zu dem Thema gesagt.
Hallo,
@132272
dann hast Du meinen 1. Thread glaube ich nicht gelesen - da steht nämlich alles drin.
1. der SIP-Port ist 5060 (im Telefon ist grau hinterlegt: bis 5076, was immer das heissen mag, ist aber auch egal)
2. die RTP-Ports sind 5004-5020
Aus dem 2. Bild geht klar hervor, dass ich beide Port-Ranges markiere: 5060-5076, 5004-5020.
Ausserdem hat das Telefon durchaus sein eigenes Subnetz 192.168.11.0/24
Ich habe schon längst verschiedene Varianten probiert in der Mangle-Regel alle Pakete zu markieren:
- die als DST in der Port Range liegen (siehe erster Screenshot)
- ALLE UDP-Pakete aus dem Subnetz kommend, egal auf welchem Port (für Testzwecke)
- alle UDP-Pakete, die über ether5 eingehen (für Testzwecke)
es hat nie geklappt.
Ich vermute das Problem beim STUN. Wie man im ersten Bild bei Pfeil 2 sehen kann:
- SRC- und DST-Adresse in der 2. Zeile von unten - BEIDE sind eine öffentliche IP (wohl die dyn-IP des Anschlusses, und die IP des SIP-Gateway des Providers), keine enthält die lokale IP des Telefons.
- Dies ist die einzige connection mit dem Datenstrom. Es gibt also komischerweise keine weitere Connection, die diesen Datenstrom vom/zum Telefon an die lokale IP leitet.
Deshalb gibt es da auch offensichtlich nix zu markieren, obwohl in Wirklichkeit natürlich schon Daten vom Telefon kommen.
Hier scheint das STUN-Protokoll die Pakete umzuadressieren, und dadurch werden sie vom Router auf LAN-Seite gar nicht angezeigt.
Die Frage ist, wie ich Datenpakete vor dem Routing markieren kann, die durch das STUN nicht greifbar scheinen.
(ob ich jetzt nach DSCP oder udp-port gucke kommt ja aufs gleiche raus, ich muss die Pakete nur irgendwie im LAN erstmal noch greifen können).
Ich hoffe zumindest mein Problem ist nun klar geworden?!
Gruß,
Colt
@132272
dann hast Du meinen 1. Thread glaube ich nicht gelesen - da steht nämlich alles drin.
1. der SIP-Port ist 5060 (im Telefon ist grau hinterlegt: bis 5076, was immer das heissen mag, ist aber auch egal)
2. die RTP-Ports sind 5004-5020
Aus dem 2. Bild geht klar hervor, dass ich beide Port-Ranges markiere: 5060-5076, 5004-5020.
Ausserdem hat das Telefon durchaus sein eigenes Subnetz 192.168.11.0/24
Ich habe schon längst verschiedene Varianten probiert in der Mangle-Regel alle Pakete zu markieren:
- die als DST in der Port Range liegen (siehe erster Screenshot)
- ALLE UDP-Pakete aus dem Subnetz kommend, egal auf welchem Port (für Testzwecke)
- alle UDP-Pakete, die über ether5 eingehen (für Testzwecke)
es hat nie geklappt.
Ich vermute das Problem beim STUN. Wie man im ersten Bild bei Pfeil 2 sehen kann:
- SRC- und DST-Adresse in der 2. Zeile von unten - BEIDE sind eine öffentliche IP (wohl die dyn-IP des Anschlusses, und die IP des SIP-Gateway des Providers), keine enthält die lokale IP des Telefons.
- Dies ist die einzige connection mit dem Datenstrom. Es gibt also komischerweise keine weitere Connection, die diesen Datenstrom vom/zum Telefon an die lokale IP leitet.
Deshalb gibt es da auch offensichtlich nix zu markieren, obwohl in Wirklichkeit natürlich schon Daten vom Telefon kommen.
Hier scheint das STUN-Protokoll die Pakete umzuadressieren, und dadurch werden sie vom Router auf LAN-Seite gar nicht angezeigt.
Die Frage ist, wie ich Datenpakete vor dem Routing markieren kann, die durch das STUN nicht greifbar scheinen.
(ob ich jetzt nach DSCP oder udp-port gucke kommt ja aufs gleiche raus, ich muss die Pakete nur irgendwie im LAN erstmal noch greifen können).
Ich hoffe zumindest mein Problem ist nun klar geworden?!
Gruß,
Colt
Zitat von @aqui:
Nein, sorry das ist Quatsch, denn dein Ansatz ist der Falsche und hat die Nachteile. Ein Vermitlungsgerät wie ein Switch oder Router soll niemals Traffic klassifizieren !
Ich klassifziere auch nicht, sondern ich priorisiere Traffic bestimmter Ports.Nein, sorry das ist Quatsch, denn dein Ansatz ist der Falsche und hat die Nachteile. Ein Vermitlungsgerät wie ein Switch oder Router soll niemals Traffic klassifizieren !
Möchte ich aber auch gar nicht großartig zum Thema machen hier
Das ist auch besser so, denn es gibt KEIN Thema dazu. Das ist durchgängige Praxis.Nur weil Du keine Nachteile siehst, heisst es nicht, dass es keine gibt!
* Was soll UDP Port 17 sein ?? Das ist Qoute of the day und ja rein gar nix mit VoIP zu tun !!
Die 17 ist kein Port, sondern die Protokoll-Nummer von UDP im Mikrotik, so wie tcp mit der Nummer 6 bezeichnet wird usw. Es gibt keinen Port 17 in diesem Szenario. Die Ports stehen an anderer Stelle.Habe langsam den Eindruck Du überfliegst die Themen eher nur, bevor Du darauf antwortest.
* SIP nutzt 5060 und 5061 und RTP was die eigentlichen Voice Daten transportiert nutzt dynmaische Ports die ausgehandelt werden.
Auch hier hast Du meinen Thread nicht richtig gelesen: Richtig, für RTP gibt es die Port-Range 5004-5020, und die habe ich natürlich auch in der Mangle-Regel berücksichtigt. Wofür schreibe ich das im OT eigentlich alles sorgfältig auf???Allein hier kannst du schon das Dilemma deiner Vorgehensweise sehen, da du den Traffic nicht sauber anhand des Protokolls klassifizieren kannst.
Ich habe es aber auch anhand der Ports versucht, nicht anhand des Protokolls.Ob ich nun Pakete mit dst-port 5004-5020 priorisiere, oder Pakete, die nen bestimmten Wert enthalten macht erstmal keinen Unterschied.
Ich muss so oder so die Pakete erstmal erwischen. DAS scheint ja nicht zu klappen.
Sinnvoll wäre das dann den ToS oder CoS Wert an dem Port generell zu setzen. D.h. der Router oder embedded Switch priorisiert dann generell alles was an dem Port reinkommt.
Nichts anderes versuche ich die ganze Zeit! Dafür brauche ich aber nur die Ports unhd keinen ToS oder CoS-Wert.
Hallo,
so, habe das Problem nun lösen können.
Fehler war, dass ich die UDP-Pakete direkt versucht habe zu markieren.
Stattdessen musste ich erst die Verbindung manglen, und dann nochmal die Pakete darin.
Hätte ich nicht gedacht, dass dies bei einem verbindungslosen Protokoll erforderlich ist.
Wieder was gelernt.
Gruß,
Der Colt für alle Fälle
so, habe das Problem nun lösen können.
Fehler war, dass ich die UDP-Pakete direkt versucht habe zu markieren.
Stattdessen musste ich erst die Verbindung manglen, und dann nochmal die Pakete darin.
Hätte ich nicht gedacht, dass dies bei einem verbindungslosen Protokoll erforderlich ist.
Wieder was gelernt.
Gruß,
Der Colt für alle Fälle
So isses, hier auch nachzulesen:
https://forum.mikrotik.com/viewtopic.php?t=73214
Und passthrough brauchst du hier ebenfalls keins, das ist beim Markieren kontraproduktiv.
https://forum.mikrotik.com/viewtopic.php?t=73214
Und passthrough brauchst du hier ebenfalls keins, das ist beim Markieren kontraproduktiv.
Zitat von @132272:
Und passthrough brauchst du hier ebenfalls keins, das ist beim Markieren kontraproduktiv.
Danke für den Tip! Und wieder was gelernt! Und passthrough brauchst du hier ebenfalls keins, das ist beim Markieren kontraproduktiv.
