6
Global Parent für Simple Queue wirklich nötig?
Hallo Admins,
ROS v7.5:
Als ich meine Mikrotiks vor etwa zwei Jahren bekam, hat der Verkäufer eine Grundkonfiguration erstellt, die Folgendes mit beinhaltet:
Dank der Unterhaltung mit BRMateus2 über PCQ Queue size and total queue size recommendations for 1G/50M internet habe ich die Simple Queue aktualisiert, aber immer noch kein Globales Parent verwendet, da mir gesagt wurde, dass ROS dafür sorgt, dass die Bandbreite gleichmäßig verteilt wird.
und
ABER Kürzlich ist mir jedoch aufgefallen, dass ein VLAN, das kontinuierlich Downloads durchführt, die gesamte Bandbreite verbraucht, obwohl für Benutzer 3 eine Mindestbandbreite festgelegt ist.
der Hardware geht es auch gut:
also habe ich die Konfiguration noch einmal überprüft:
basic:
advanced:
Die einzige "Abhilfe", die ich gefunden habe, ist die Verwendung eines Globalen Parents:
und machte alle vorherigen Einträge, wie im ersten Code-Block zu einem Child dieses Global Parent.
Es funktioniert nur, wenn das Ziel auf 0.0.0.0/0 gesetzt ist; wenn es nur auf dem Uplink liegt, hat das keine Auswirkungen.
Meine Theorie ist, dass dem Algorithmus nicht bekannt ist, auf welche Route/Schnittstelle sich die 20M beziehen, d.h. er weiß nicht, dass alle VLAN-Schnittstellen vom selben Kuchen essen. Wenn also Benutzer 6 kontinuierlich herunterlädt, frisst er immer freie Bandbreite, wenn ein anderer Benutzer eine Pause macht und am Ende die volle Bandbreite frisst. Wie kann ich dem Algorithmus sagen, dass die 20M zwischen allen Warteschlangen der obersten Ebene geteilt werden müssen?
Da mein Verkäufer hatte den gleichen Ansatz wie im obigen Code Block für die Anfangskonfiguration verwendet, daher bin ich ziemlich überrascht, dass ich dieses Global Parent benötige.
Gibt es einen Anhaltspunkt, warum?
merci
Stefan
ROS v7.5:
Als ich meine Mikrotiks vor etwa zwei Jahren bekam, hat der Verkäufer eine Grundkonfiguration erstellt, die Folgendes mit beinhaltet:
/queue simple
add limit-at=100M/100M max-limit=1G/1G name=admin target=vlan20-admin.sfp+
add limit-at=100M/100M max-limit=1G/1G name=mieter1 target=vlan21-mieter1.sfp+
add limit-at=100M/100M max-limit=1G/1G name=mieter2 target=vlan22-mieter2.sfp+
add limit-at=100M/100M max-limit=1G/1G name=mieter3 target=vlan23-mieter3.sfp+
add limit-at=50M/50M max-limit=100M/100M name=wlan-gast target=br.wlan-gast Dank der Unterhaltung mit BRMateus2 über PCQ Queue size and total queue size recommendations for 1G/50M internet habe ich die Simple Queue aktualisiert, aber immer noch kein Globales Parent verwendet, da mir gesagt wurde, dass ROS dafür sorgt, dass die Bandbreite gleichmäßig verteilt wird.
/queue simple
add limit-at=0/0 max-limit=0/0 name=Intranet_unlimited target=10.10.0.0/18 dst=10.10.0.0/18 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER1 target=VLAN_USER1 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER2 target=VLAN_USER2 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER3 target=VLAN_USER3 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER4 target=VLAN_USER4 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER5 target=VLAN_USER5 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER6 target=VLAN_USER6 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER7 target=VLAN_USER7 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=USER8 target=VLAN_USER8 queue=pcq-up/pcq-down
add limit-at=10M/10M max-limit=90M/90M name=GUEST target=VLAN_GUEST queue=pcq-up/pcq-down
add max-limit=10M/10M name=SERVICES-GLOBAL target=Combo1
add limit-at=1M/1M max-limit=10M/10M name=COMMON-SERVICES target=VLAN_COMMON queue=pcq-up/pcq-down parent="SERVICES-GLOBAL"
add limit-at=1M/1M max-limit=10M/10M name=SYSTEM-SERVICES target=VLAN_SYS queue=pcq-up/pcq-down parent="SERVICES-GLOBAL"
add limit-at=1M/1M max-limit=10M/10M name=IoT target=VLAN_IoT queue=pcq-up/pcq-down parent="SERVICES-GLOBAL" [adminuser@CR_2B_MT-CCR1009-8G-1S-1S+] /queue/type> print
Flags: * - default
5 name="pcq-up" kind=pcq pcq-rate=0 pcq-limit=4KiB pcq-classifier=src-address,dst-address pcq-total-limit=400KiB pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-src-address-mask=32 pcq-dst-address-mask=32 pcq-src-address6-mask=128
pcq-dst-address6-mask=128
6 name="pcq-down" kind=pcq pcq-rate=0 pcq-limit=4KiB pcq-classifier=src-address,dst-address pcq-total-limit=400KiB pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-src-address-mask=32 pcq-dst-address-mask=32
pcq-src-address6-mask=128 pcq-dst-address6-mask=128 ABER Kürzlich ist mir jedoch aufgefallen, dass ein VLAN, das kontinuierlich Downloads durchführt, die gesamte Bandbreite verbraucht, obwohl für Benutzer 3 eine Mindestbandbreite festgelegt ist.
basic:
advanced:
Die einzige "Abhilfe", die ich gefunden habe, ist die Verwendung eines Globalen Parents:
1 name="UPLINK" target="" parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=20M/20M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 Es funktioniert nur, wenn das Ziel auf 0.0.0.0/0 gesetzt ist; wenn es nur auf dem Uplink liegt, hat das keine Auswirkungen.
Meine Theorie ist, dass dem Algorithmus nicht bekannt ist, auf welche Route/Schnittstelle sich die 20M beziehen, d.h. er weiß nicht, dass alle VLAN-Schnittstellen vom selben Kuchen essen. Wenn also Benutzer 6 kontinuierlich herunterlädt, frisst er immer freie Bandbreite, wenn ein anderer Benutzer eine Pause macht und am Ende die volle Bandbreite frisst. Wie kann ich dem Algorithmus sagen, dass die 20M zwischen allen Warteschlangen der obersten Ebene geteilt werden müssen?
Da mein Verkäufer hatte den gleichen Ansatz wie im obigen Code Block für die Anfangskonfiguration verwendet, daher bin ich ziemlich überrascht, dass ich dieses Global Parent benötige.
Gibt es einen Anhaltspunkt, warum?
merci
Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4833128143
Url: https://administrator.de/contentid/4833128143
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
6 Kommentare
Neuester Kommentar
Deine einzelnen Simple-Queues gelten immer nur für einen User da aber ein Queue wenn er nicht mehrere User mit einbezieht nicht die Bandbreite auf mehrere User verteilen kann braucht es eine Instanz die festlegt was insgesamt an Bandbreite da ist nämlich einen Parent-Queue mit Max-Limit auf den max. Durchsatz gesetzt.
Alternativ markierst du die Pakete der User und trägst die PaketMark in einen Queue ein dann gilt ein Queue für mehrere User und die Bandbreite wird wieder korrekt aufgeteilt, weil die User alle zu diesem Queue gehören.
Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
Siehe:
https://help.mikrotik.com/docs/display/ROS/Queues
Uk.
Alternativ markierst du die Pakete der User und trägst die PaketMark in einen Queue ein dann gilt ein Queue für mehrere User und die Bandbreite wird wieder korrekt aufgeteilt, weil die User alle zu diesem Queue gehören.
Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
Siehe:
https://help.mikrotik.com/docs/display/ROS/Queues
Uk.
2
Danke für die wahnsinnig schnelle Antwort 😃.
Dein Hinweis auf den Packet Flow hat mich nochmals grübeln lassen. Ich beschäftige mich zu unregelmäßig damit, daß ich es mir auf Anhieb wieder klar ist.
Das es für mich nach einem Jahr auch wieder klar ist, möchte ich es wie in Packet Flow in RouterOS aufzeichnen, ähnlich wie hier im Forum.
Ich bekomme aber jedesmal Kopfweh, wenn ich die Details lese in der Dokumentation 🤯. So steht zum Beispiel im Decapsulation Pfad VLAN aber weiter unten heisst es
Daher vielleicht erstmal ein paar grundlegende Fragen:
Mich wundert nur, warum ein bekannter zertifizierter MT Verkäufer, dies dann nicht so gemacht hat.
War vielleicht unvollständig, sehe auch dass kein vlan-filtering=yes eingestellt worden ist. Muss ihn mal darauf ansprechen.
Bei FastTrack heist es
Es sei denn, Dank Queue Tree und Mangle, gehen nur die Establishedauf FastTrack und New & Relatedgehen erstmal den SlowPath
Bzgl. Queue sind es dann mau aus, ausser das
Dein Hinweis auf den Packet Flow hat mich nochmals grübeln lassen. Ich beschäftige mich zu unregelmäßig damit, daß ich es mir auf Anhieb wieder klar ist.
Das es für mich nach einem Jahr auch wieder klar ist, möchte ich es wie in Packet Flow in RouterOS aufzeichnen, ähnlich wie hier im Forum.
Ich bekomme aber jedesmal Kopfweh, wenn ich die Details lese in der Dokumentation 🤯. So steht zum Beispiel im Decapsulation Pfad VLAN aber weiter unten heisst es
Tagged packets might get decapsulated on the "BRIDGING DECISION" block, which means these packets will no longer match the mac-protocol=vlan and vlan-encap settings. Decapsulation can happen if the packet's VLAN ID matches the port's untagged VLAN membership.
Daher vielleicht erstmal ein paar grundlegende Fragen:
- Das sagenumwobenen Bridge CPU Port ist kein Logical Interface, somit nicht Teil des Packet Flow. Es ist nur da um um den Zugang von L2 auf L3 einzustellen. (VLAN Bridge (CPU Port) Question about tagged/untagged und RouterOS bridge mysteries explained kenen ich)
- Wenn 1. korrekt und keine Queue, Firewall etc.:
- Input in das VLAN Interface dann Bridging Decision (VLAN Tag entfernt) von dort ins IP Stack, bzw. Abfrage des Routing Table dann Forwardzum Physical Interface "Uplink" und ab raus gen ISP.
- In welchen Fällen wird das Bridge-Interface (bridge-VLANs) verwendet, bzw. wann muss es in meine Überlegungen mit einbeziehen ausser beim erstellen von /interface/bridge/vlan.
> interface/print
Flags: D - DYNAMIC; R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU, L2MTU, MAX-L2MTU, MAC-ADDRESS
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 R combo1 ether 1500 1580 10222 08:....
39 R bridge-VLANs bridge 1500 1580 08:55:31:31:24:88
....
35 R VLAN_MGMT vlan 1500 1576 08:55:31:31:24:88
36 R VLAN_USER3 vlan 1500 1576 08:55:31:31:24:88
37 R VLAN_USER6 vlan 1500 1576 08:55:31:31:24:88
....
Zitat von @4400667902:
Deine einzelnen Simple-Queues gelten immer nur für einen User da aber ein Queue wenn er nicht mehrere User mit einbezieht nicht die Bandbreite auf mehrere User verteilen kann braucht es eine Instanz die festlegt was insgesamt an Bandbreite da ist nämlich einen Parent-Queue mit Max-Limit auf den max. Durchsatz gesetzt.
sprich das ist meine Kuchentheorie.Deine einzelnen Simple-Queues gelten immer nur für einen User da aber ein Queue wenn er nicht mehrere User mit einbezieht nicht die Bandbreite auf mehrere User verteilen kann braucht es eine Instanz die festlegt was insgesamt an Bandbreite da ist nämlich einen Parent-Queue mit Max-Limit auf den max. Durchsatz gesetzt.
Mich wundert nur, warum ein bekannter zertifizierter MT Verkäufer, dies dann nicht so gemacht hat.
War vielleicht unvollständig, sehe auch dass kein vlan-filtering=yes eingestellt worden ist. Muss ihn mal darauf ansprechen.
Zitat von @4400667902:
Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
Ich habe erstmal Simple verwendet, da es einfacher ist 😄, es läuft alles auf meinen CCR1009-8G-1S-1S+ Core Router.Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
Bei FastTrack heist es
FastTrack packets bypass firewall, connection tracking, simple queues, queue tree with parent=global
Somit get der Datenverkehr an der Firewall vorbei, daher war das nie Thema für mich.Es sei denn, Dank Queue Tree und Mangle, gehen nur die Establishedauf FastTrack und New & Relatedgehen erstmal den SlowPath
Bzgl. Queue sind es dann mau aus, ausser das
queue tree with parent=global
lässt hier noch nen Ausweg zu aber keine Ahnung was damit gemeint ist.Zitat von @4400667902:
Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
steht in Queues - RouterOS - MikroTik Documentation etwas anders:Und zur Info, Shaping wird immer nur aus den jeweiligen Interfaces ausgehend vorgenommen, siehe PacketFlow.
These hierarchical structures can be attached at two different places, the Packet Flow diagram illustrate both input and postrouting chains.
Wobei ich Postrouting nur im Routing stattfindet ausser use-ip-firewall=yes ist gesetzt für Bridges (letzteres gilt dann für alle Bridges in /interface/bridge/vlan).
vielleicht ist es so einfach wie folgt:
Eine beliebige logische oder physische Schnittstelle muss eine IP haben, um >=L3-Dienste darauf zu ermöglichen.
Da das Bridge-Interface ( “new” way of handling multiple VLANs ) keine IP haben darf, wird sie nirgends verwendet, außer für die Handhabung von L2-Sachen für Geräte/Ports, die mit ihr verbunden sind.
Eine beliebige logische oder physische Schnittstelle muss eine IP haben, um >=L3-Dienste darauf zu ermöglichen.
Da das Bridge-Interface ( “new” way of handling multiple VLANs ) keine IP haben darf, wird sie nirgends verwendet, außer für die Handhabung von L2-Sachen für Geräte/Ports, die mit ihr verbunden sind.
@44
Zitat von @4400667902:
Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
ich komme da nicht richtig weiter, siehe meine erste Antwort, hast du Rat?Ich würde solche Szenarien lieber mit Queue-Trees und Tags realisieren. Simple-Queues sind hier um einiges eingeschränkt unter anderem wenn es um aktiviertes Fasttracking geht dann gehen die Pakete mal eben bei Simple-Queues an diesen vorbei und nicht mehr durch den Queue.
Quote from @PackElend:
Die einzige "Abhilfe", die ich gefunden habe, ist die Verwendung eines Globalen Parents:
und machte alle vorherigen Einträge, wie im ersten Code-Block zu einem Child dieses Global Parent.
Es funktioniert nur, wenn das Ziel auf 0.0.0.0/0 gesetzt ist; wenn es nur auf dem Uplink liegt, hat das keine Auswirkungen.
Meine Theorie ist, dass dem Algorithmus nicht bekannt ist, auf welche Route/Schnittstelle sich die 20M beziehen, d.h. er weiß nicht, dass alle VLAN-Schnittstellen vom selben Kuchen essen. Wenn also Benutzer 6 kontinuierlich herunterlädt, frisst er immer freie Bandbreite, wenn ein anderer Benutzer eine Pause macht und am Ende die volle Bandbreite frisst. Wie kann ich dem Algorithmus sagen, dass die 20M zwischen allen Warteschlangen der obersten Ebene geteilt werden müssen?
Da mein Verkäufer hatte den gleichen Ansatz wie im obigen Code Block für die Anfangskonfiguration verwendet, daher bin ich ziemlich überrascht, dass ich dieses Global Parent benötige.
Gibt es einen Anhaltspunkt, warum?
merci
Stefan
Die einzige "Abhilfe", die ich gefunden habe, ist die Verwendung eines Globalen Parents:
1 name="UPLINK" target="" parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=0/0 max-limit=20M/20M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 Es funktioniert nur, wenn das Ziel auf 0.0.0.0/0 gesetzt ist; wenn es nur auf dem Uplink liegt, hat das keine Auswirkungen.
Meine Theorie ist, dass dem Algorithmus nicht bekannt ist, auf welche Route/Schnittstelle sich die 20M beziehen, d.h. er weiß nicht, dass alle VLAN-Schnittstellen vom selben Kuchen essen. Wenn also Benutzer 6 kontinuierlich herunterlädt, frisst er immer freie Bandbreite, wenn ein anderer Benutzer eine Pause macht und am Ende die volle Bandbreite frisst. Wie kann ich dem Algorithmus sagen, dass die 20M zwischen allen Warteschlangen der obersten Ebene geteilt werden müssen?
Da mein Verkäufer hatte den gleichen Ansatz wie im obigen Code Block für die Anfangskonfiguration verwendet, daher bin ich ziemlich überrascht, dass ich dieses Global Parent benötige.
Gibt es einen Anhaltspunkt, warum?
merci
Stefan
Antworten sind hier geben:
limit-at and priority work only if you use hierarchy (parent)
https://mum.mikrotik.com/presentations/HU11/valens.pdfWithout parent, limit-at and priority will be ignored
- https://mum.mikrotik.com/presentations/HU11/valens.pdfhttps://mum.mikrotik.com/presentations/KH15/valens.pdf
sowie
target-address is the address of (for example) your client who's speed you are about to limit.
dst-address is the server to which this client will connect (if you like to limit his speed only when he connects to this one specific server)
https://forum.mikrotik.com/viewtopic.php?t=2557#p10171dst-address is the server to which this client will connect (if you like to limit his speed only when he connects to this one specific server)
https://forum.mikrotik.com/viewtopic.php?t=10442
werde es nochmal testen
getan und es hat sich bestätig.
Böld nur, dass keine Interface Listen hinterlegt werden können, nur IP-Adressebereich(e) und einzelen Interface(s).
Muss meine Regel dann wohl etwas anpassen (Bridge --> alle VLAN Interfaces auflisten).
