13
Brocade VLAN Layer2 priority
Hallo,
irgendwie habe ich es in meinen kleinen Infrastrukturen nie gebraucht und mich demzufolge nicht wirklich intensiv damit beschäftigt. Folgende Situation:
In einem VoIP-VLAN 30 sind sehr hohe Latenzen festgestellt worden, die dazu führen das vor allem bei den DECT-Zellen die Synchronisation kurzzeitig verloren geht und einige Phänomene auftreten wie, Nebenstelle besetzt obwohl frei oder Probleme beim Transfer von Gesprächen.
An dem Switch für die DECT-Zellen habe ich bereits die Priorität auf 7 für das VLAN gesetzt. Es handelt sich dabei um einen Cisco SG350. Dieser widerum ist über einen Trunk mit meinem Core verbunden. Einem Brocade/Ruckus ICX7250 Stack im Layer 2 Betrieb (Version 08070g) . Dort dran, ebenfalls per Trunk, ein Router und der Host für die VM der PBX.
Ich möchte nun auf dem ICX die Layer2-Priorisierung für das VLAN 30 anheben um möglichst bessere Latenzen zu erzielen und eine mögliche Fehlerquelle zu beseitigen.
Wenn ich das nun richtig verstanden habe muss man eine med policy anlegen. So würde die jetzt aussehen:
Output VLAN 30
Habe ich das richtig verstanden? Funktioniert das überhaupt? Kann man das während des laufenden Betriebs ohne Gefahr ausführen?
Gruß
irgendwie habe ich es in meinen kleinen Infrastrukturen nie gebraucht und mich demzufolge nicht wirklich intensiv damit beschäftigt. Folgende Situation:
In einem VoIP-VLAN 30 sind sehr hohe Latenzen festgestellt worden, die dazu führen das vor allem bei den DECT-Zellen die Synchronisation kurzzeitig verloren geht und einige Phänomene auftreten wie, Nebenstelle besetzt obwohl frei oder Probleme beim Transfer von Gesprächen.
An dem Switch für die DECT-Zellen habe ich bereits die Priorität auf 7 für das VLAN gesetzt. Es handelt sich dabei um einen Cisco SG350. Dieser widerum ist über einen Trunk mit meinem Core verbunden. Einem Brocade/Ruckus ICX7250 Stack im Layer 2 Betrieb (Version 08070g) . Dort dran, ebenfalls per Trunk, ein Router und der Host für die VM der PBX.
Ich möchte nun auf dem ICX die Layer2-Priorisierung für das VLAN 30 anheben um möglichst bessere Latenzen zu erzielen und eine mögliche Fehlerquelle zu beseitigen.
Wenn ich das nun richtig verstanden habe muss man eine med policy anlegen. So würde die jetzt aussehen:
lldp med network-policy application voice tagged vlan 30 priority 7 dscp 46 ports ethernet {alle Portmember von VLAN 30}Output VLAN 30
SSH@ICX7250-24 Switch#show vlan 30
Total PORT-VLAN entries: 19
Maximum PORT-VLAN entries: 64
Legend: [Stk=Stack-Id, S=Slot]
PORT-VLAN 30, Name VOIP, Priority level0, in single spanning tree domain
Untagged Ports: None
Tagged Ports: (U1/M1) 11
Tagged Ports: (U1/M2) 2
Tagged Ports: (U2/M2) 2
Tagged Ports: (U3/M2) 4
Uplink Ports: None
DualMode Ports: None
Mac-Vlan Ports: None
Monitoring: DisabledHabe ich das richtig verstanden? Funktioniert das überhaupt? Kann man das während des laufenden Betriebs ohne Gefahr ausführen?
Gruß
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: 590120
Url: https://administrator.de/contentid/590120
Ausgedruckt am: 26.11.2024 um 01:11 Uhr
13 Kommentare
Neuester Kommentar
Man merkt leider etwas die Planlosigkeit und Lösung nach dem Gieskannenprinzip.
Du solltest dir wirklich erstmal klar werden ob du bzw. deine Voice Endgeräte ein Layer 2 QoS auf Basis 802.1q oder ein Layer 3 QoS mit DiffServ DSCP machen. Beides geht nicht.
.1q erzwingt auch das alle Voice Pakete dann Tagged sind, denn 802.1p ist immer Teile eines VLAN Tags.
Taggen deine Voice Endgeräte gar nicht, dann machst du gar kein Layer 2 QoS und alle Einstellungen wären völlig sinnfrei weil dann logischerweise für den Switch gar nichts zu Priorisieren ist.
Das Thema wird hier
Kaufberatung - Switches mit VoIP-Priorisierung
und in den Folgethreads dort umfassend behandelt.
Du machst leider keinerlei Aussagen WIE das QoS in der PBX und den DECT Zellen APs eingestellt ist. Einzig DAS wäre aber wichtig !! Denn eine QoS Klassifizierung sollten immer die Endgeräte machen aber niemals der Switch selber. Sprich der Switch soll nur die gesendete QoS Klassifizierung im Paket lesen und dann diesen Traffic priorisieren. Dazu muss er aber wissen ob er im Layer 2 oder Layer 3 nachsehen muss. Ein Layer 2 Switch sieht niemals in den Layer 3 eine IP Frames es sei denn man sagt es ihm explizit am Port. Ganz simples Prinzip...
Im Setup der PBX sollte also immer die entsprechende Klassifizierung und die Aert der Klassifizierung konfiguriert sein ! Siehe hier am Beispiel einer einfachen Auerswald PBX die DSCP priorisiert:
Üblich ist in der Regel die DSCP Priorisierung, denn wie gesagt ein L2 Priorisieren erfordert zwingend ein Tagging. Es darf bezweifelt werden das das bei dir durchgängig gemacht wird denn in billigen Consumer PBXen ist das eher unüblich da dort sehr viel fachunkundiges Personal sowas einrichtet. Folglich lassen die Hersteller diese Anlagen im Default mit DSCP und einem festen ToS Wert. Welcher das ist sollte aus dem Anlagen Setup oder dem Handbuich ersichtlich sein.
Im Zweifel nimmt man immer einen Wireshark und misst das selber nach zur Sicherheit ! Wie beim folgenden Beispiel mit einem Cisco Phone:
Das vorab was du sicher klären musst aber oben leider auf der Strecke geblieben ist. 
Der Ruckus ICX Switch hat im Gegensatz zu anderen Switches zum Glück ein immer ein aktives Default QoS Profil wo er Standard QoS und ToS Werte in die entsprechenden Queues bringt. In der Regel muss man auf dem Switch deshalb nichts extra einstellen !
Lediglich wenn du DSCP machst und ein L2 Image fährst auf dem Switch, dann musst du die Ports mit dem Kommando trust dscp entsprechend markieren das der Switch überhaupt DSCP Werte liest und auswertet.
Der Traffic Management Guide von Ruckus erklärt dir die Profile im Detail:
http://docs.ruckuswireless.com/fastiron/08.0.80/fastiron-08080-trafficg ...
(Seite 23)
Ein sh qos-tos gibt dir das auch aus. Eine weiteres Beispiel für ein Cisco Phone DSCP 46 in Queue 4 und 5 an Port 1/1/5:
Dein oben gepostetes LLDP Beispiel ist lediglich ein Automatismus bei dem der Switch einem angeschlossenen LLDP Endgerät diese Einstellungen automatisch per LLDP Protokoll mitteilt. Generell ist das der richtige Weg um QoS Einstellungen an solchen Endgeräten zu erzwingen sofern sie nicht über die eigene Konfig oder Bootimage bezogen werden.
Aaaaber... Dazu müssen der Switch selber und diese Geräte auch LLDP supporten. Ansonsten ist das für die Katz und wird ignoriert und alles ist dann wieder wirkungslos.
lldp run ist also ein Muss für dich auf dem ICX und dann müssten zwingend andere Infrastruktur Protokolle wie CDP und FDP zwingend deaktiviert sein. (no cdp run, no fdp run !)
Ein show lldp neigh zeigt dir immer an ob deine Endgeräte LLDP können.
Soviel zum Switch...
Nochwas allgemein.
Die Priority 7 sollte man niemals vergeben, denn das nutzt der Switch selber für wichtige Infrastruktur Protokolle wie STP, LACP usw. Damit schränkt man ggf. die Betriebssicherheit ein. Für Voice und SIP reicht es allemal aus immer einen drunter zu nehmen also 6
SIP hast du übrigens vergessen. Vollständig wäre also:
lldp med network-policy application voice tagged vlan 30 priority 6 dscp 46 ports ethe 1/1/28
lldp med network-policy application voice-signaling tagged vlan 30 priority 3 dscp 26 ports ethe 1/1/28
lldp run
LLDP hat aber nichts mit der Priorisierung an sich zu tun, rein nur mit der Übermittlung der QoS Parameter an Endgeräte.
Du solltest dir wirklich erstmal klar werden ob du bzw. deine Voice Endgeräte ein Layer 2 QoS auf Basis 802.1q oder ein Layer 3 QoS mit DiffServ DSCP machen. Beides geht nicht.
.1q erzwingt auch das alle Voice Pakete dann Tagged sind, denn 802.1p ist immer Teile eines VLAN Tags.
Taggen deine Voice Endgeräte gar nicht, dann machst du gar kein Layer 2 QoS und alle Einstellungen wären völlig sinnfrei weil dann logischerweise für den Switch gar nichts zu Priorisieren ist.
Das Thema wird hier
Kaufberatung - Switches mit VoIP-Priorisierung
und in den Folgethreads dort umfassend behandelt.
Du machst leider keinerlei Aussagen WIE das QoS in der PBX und den DECT Zellen APs eingestellt ist. Einzig DAS wäre aber wichtig !! Denn eine QoS Klassifizierung sollten immer die Endgeräte machen aber niemals der Switch selber. Sprich der Switch soll nur die gesendete QoS Klassifizierung im Paket lesen und dann diesen Traffic priorisieren. Dazu muss er aber wissen ob er im Layer 2 oder Layer 3 nachsehen muss. Ein Layer 2 Switch sieht niemals in den Layer 3 eine IP Frames es sei denn man sagt es ihm explizit am Port. Ganz simples Prinzip...
Im Setup der PBX sollte also immer die entsprechende Klassifizierung und die Aert der Klassifizierung konfiguriert sein ! Siehe hier am Beispiel einer einfachen Auerswald PBX die DSCP priorisiert:
Üblich ist in der Regel die DSCP Priorisierung, denn wie gesagt ein L2 Priorisieren erfordert zwingend ein Tagging. Es darf bezweifelt werden das das bei dir durchgängig gemacht wird denn in billigen Consumer PBXen ist das eher unüblich da dort sehr viel fachunkundiges Personal sowas einrichtet. Folglich lassen die Hersteller diese Anlagen im Default mit DSCP und einem festen ToS Wert. Welcher das ist sollte aus dem Anlagen Setup oder dem Handbuich ersichtlich sein.
Im Zweifel nimmt man immer einen Wireshark und misst das selber nach zur Sicherheit ! Wie beim folgenden Beispiel mit einem Cisco Phone:
Der Ruckus ICX Switch hat im Gegensatz zu anderen Switches zum Glück ein immer ein aktives Default QoS Profil wo er Standard QoS und ToS Werte in die entsprechenden Queues bringt. In der Regel muss man auf dem Switch deshalb nichts extra einstellen !
Lediglich wenn du DSCP machst und ein L2 Image fährst auf dem Switch, dann musst du die Ports mit dem Kommando trust dscp entsprechend markieren das der Switch überhaupt DSCP Werte liest und auswertet.
Der Traffic Management Guide von Ruckus erklärt dir die Profile im Detail:
http://docs.ruckuswireless.com/fastiron/08.0.80/fastiron-08080-trafficg ...
(Seite 23)
Ein sh qos-tos gibt dir das auch aus. Eine weiteres Beispiel für ein Cisco Phone DSCP 46 in Queue 4 und 5 an Port 1/1/5:
telnet@ICX7150-C08P Switch#sh lldp nei
Lcl Port Chassis ID Port ID Port Description System Name
1/1/5 172.16.10.187 925904945 SW PORT SEP7001B57642~
telnet@ICX7150-Switch#sh int eth 1/1/5
GigabitEthernet1/1/5 is up, line protocol is up
Port up for 60 day(s) 22 hour(s) 55 minute(s) 4 second(s)
Hardware is GigabitEthernet, address is d4c1.9e29
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Untagged member of L2 VLAN 1, port state is FORWARDING
Egress queues:
Queue counters Queued packets Dropped Packets
0 5949662 0
1 0 0
2 0 0
3 0 0
4 210554 0
5 427611 0
6 13092 0
7 2807297 0 Aaaaber... Dazu müssen der Switch selber und diese Geräte auch LLDP supporten. Ansonsten ist das für die Katz und wird ignoriert und alles ist dann wieder wirkungslos.
lldp run ist also ein Muss für dich auf dem ICX und dann müssten zwingend andere Infrastruktur Protokolle wie CDP und FDP zwingend deaktiviert sein. (no cdp run, no fdp run !)
Ein show lldp neigh zeigt dir immer an ob deine Endgeräte LLDP können.
Soviel zum Switch...
Nochwas allgemein.
Die Priority 7 sollte man niemals vergeben, denn das nutzt der Switch selber für wichtige Infrastruktur Protokolle wie STP, LACP usw. Damit schränkt man ggf. die Betriebssicherheit ein. Für Voice und SIP reicht es allemal aus immer einen drunter zu nehmen also 6
SIP hast du übrigens vergessen. Vollständig wäre also:
lldp med network-policy application voice tagged vlan 30 priority 6 dscp 46 ports ethe 1/1/28
lldp med network-policy application voice-signaling tagged vlan 30 priority 3 dscp 26 ports ethe 1/1/28
lldp run
LLDP hat aber nichts mit der Priorisierung an sich zu tun, rein nur mit der Übermittlung der QoS Parameter an Endgeräte.
Ok. Das leuchtet mir ein.
Als DECT-System ist das Gigaset N870 im Einsatz. Diese sind derzeit an einem Untagged Port im Einsatz und haben auch die Möglichkeit unter Einstellungen>Telefonie>VoIP die Werte für DiffServ (DSCP) anzupassen. Diese stehen bei mir derzeit auf SIP-ToS 34 und RTP-ToS 46.
Für die PBX (3cx VM) ist derzeit noch gar nichts eingestellt, da sich als OS Linux drauf befindet, müsste man dort erstmal per IPTables einen Wert festlegen. Vorher wird da auch nichts klassifiziert.
802.1q --> Layer 2
DSCP --> Layer 3
Check. Aber würde doch zwingend ein Routing-Interface voraussetzen? Oder reicht hier das sich alle Endgeräte im selben Netzsegment/Subnetz befinden?
Da DSCP aber nur eine Klassifizierung vornimmt, müsste doch ein zentrales Gerät, wie ein Router, anhand der Klassifizierung eine Priorisierung umsetzen. Oder etwa nicht?
Tatsächlich wäre ein Layer 3 Umsetzung schneller zu bewerkstelligen, wenn ein dscp trust auf den entsprechenden Interfaces reicht und kein zusätzliches Router-Interface benötigt wird. Müsste dann eine angeschlossene pfSense als Routing für VLAN, ebenfalls dcsp unterstützen?
Edit: Aber würde bei Layer 2 Priority nicht zum Beispiel helfen um den Uplink Trunk zwischen zwei Switchen optimieren, wenn das rein hypothetisch der Flaschenhals wäre? Auch wenn die Endgeräte dahinter nicht tagged interfaces hängen?
Als DECT-System ist das Gigaset N870 im Einsatz. Diese sind derzeit an einem Untagged Port im Einsatz und haben auch die Möglichkeit unter Einstellungen>Telefonie>VoIP die Werte für DiffServ (DSCP) anzupassen. Diese stehen bei mir derzeit auf SIP-ToS 34 und RTP-ToS 46.
Für die PBX (3cx VM) ist derzeit noch gar nichts eingestellt, da sich als OS Linux drauf befindet, müsste man dort erstmal per IPTables einen Wert festlegen. Vorher wird da auch nichts klassifiziert.
802.1q --> Layer 2
DSCP --> Layer 3
Check. Aber würde doch zwingend ein Routing-Interface voraussetzen? Oder reicht hier das sich alle Endgeräte im selben Netzsegment/Subnetz befinden?
Da DSCP aber nur eine Klassifizierung vornimmt, müsste doch ein zentrales Gerät, wie ein Router, anhand der Klassifizierung eine Priorisierung umsetzen. Oder etwa nicht?
Tatsächlich wäre ein Layer 3 Umsetzung schneller zu bewerkstelligen, wenn ein dscp trust auf den entsprechenden Interfaces reicht und kein zusätzliches Router-Interface benötigt wird. Müsste dann eine angeschlossene pfSense als Routing für VLAN, ebenfalls dcsp unterstützen?
Edit: Aber würde bei Layer 2 Priority nicht zum Beispiel helfen um den Uplink Trunk zwischen zwei Switchen optimieren, wenn das rein hypothetisch der Flaschenhals wäre? Auch wenn die Endgeräte dahinter nicht tagged interfaces hängen?
Diese sind derzeit an einem Untagged Port im Einsatz
Damit kannst du Layer 2 Priorisierung wie du sie oben beschreibst ja schonmal komplett ausschliessen. Das machst du also de facto NICHT und alle Einstellungen dazu sind in deinem netz donn logischerweise vollkommen wirkungslos !Diese stehen bei mir derzeit auf SIP-ToS 34 und RTP-ToS 46.
Das sind übliche Standardwerte im DSCP. Zeigt aber auch glaich das deine Geräte dann vermutlich eine L3 Priorisierung mit DSCP machen !Für die PBX (3cx VM) ist derzeit noch gar nichts eingestellt,
Was natürlich tödlich ist. Zeigt auch das derjenige der sie aufgestellt hat, konfiguriert hat und wartet vermutlich keinerlei Fachkenntnoisse im Bereich VoIP hat ! (Hoffentlich warst DU das jetzt nicht ?! )da sich als OS Linux drauf befindet
Hat damit doch gar nichts zu tun und weisst du als Netzwerker doch auch selber. Das OS ist doch völlig irrelevant, denn immer die Anwendung selber bestimmt doch wie ausgehende Pakete klassifiziert werden !Solche simplen Basics sollte man aber wissen.
Es muss also im Setup der PBX irgendwo dieser Wert oder die Option eingestellt werden. Oben siehst du das an einer 150 Euro Auerswald ja auch das die das kann.
müsste man dort erstmal per IPTables einen Wert festlegen.
Das ist Quatsch...vergiss das. Es hat nichts mit dem Betriebssystem zu tun !! Bei Windows kannst du sowas nativ ja auch gar nicht einstellen. Also vergessen....Aber würde doch zwingend ein Routing-Interface voraussetzen?
Nein !Nur du musst einem L2 Switch der ja nur Mac Adressen kennt immer Port basierend sagen: "Hey Bro, hier am Port guckste aber mal statt nur L2 in den L3 IP Header und checkst mal ob da was steht...!"
Genau DAS sagst du ihm mit dem trust dscp an dem Port. Das muss dann logischerweise auf ALLEN Switchports gesetzt sein die im VoIP Flow sind, sprich also den Telefonports, DECT AP Ports, Backbone und der PBX selber natürlich.
Da DSCP aber nur eine Klassifizierung vornimmt,
Nein ! Du hast es scheinbar immer noch nicht verstanden.... DSCP selber macht KEINE Klassifizierung des Traffics. Die Klassizizierung machen immer die Endgeräte bzw. immer deren Anwendungen dort !! Diese setzen also die entsprechenden DSCP ToS Bits im IP Header und "klassifizieren" so den Traffic der von ihnen dann via Netzwerkkarte ins Netz abgeht. Der Switch oder Router "liest" das nur aus und behandelt das Forwarding dieser Pakete dann entsprechend anders. Nämlich erheblich beschleunigt und VOR allen anderen Paketen.
So einfach ist das...
Tatsächlich wäre ein Layer 3 Umsetzung schneller zu bewerkstelligen
Deshalb wird das auch häufiger gemacht weil ein L2 Priorisieren mit 802.1p Tagging viele Anfänger nicht verstehen....DSCP meist auch nicht aber das ist ein ganz anderes Thema ! Müsste dann eine angeschlossene pfSense als Routing für VLAN, ebenfalls dcsp unterstützen?
Ja, natürlich und kann sie auch !JEDES Gerät das im IP Flow der VoIP Daten liegt muss das kennen. Denn jeder "Verteilungshop" liest ja wieder für sich aufs Neue die DSCP Daten und verhält sich danach. Es ist also immer eine Hop für Hop Geschichte !
Logisch, denn wie sollte es auch anders sein ? Sonst müsste ja irgendwie eine zentrale Instanz an ALLE aktiven Netzwerk Geräte irgendwie sagen: "Hey, an alle: DECT AP xyz macht DSCP mit 46 alles alles was von dem mit Absender IP xyz kommt priorisieren". Sowas ist naive Utopie und gibt es natürlich nicht. Wäre ja auch höchst ineffizient den mit jedem einzelnen Telefon bräuchte man so eine Instanz. Vergiss das also ganz schnell wieder und denke dran...immer Hop by Hop egal ob das ein L2 Switching Hop ist oder ein L3 Routing Hop !
Aber würde bei Layer 2 Priority nicht zum Beispiel helfen um den Uplink Trunk zwischen zwei Switchen optimieren, wenn das rein hypothetisch der Flaschenhals wäre?
Ja, theoretisch hast du da Recht. Da .1p ja immer im VLAN Tag drin ist könnte man da 2 Fliegen mit einer Klappe schlagen.So einfach ist es dann aber doch nicht.
Deine Geräte machen ja DSCP wie du oben selber beschrieben hast. DSCP und .1p sind aber 2 völlig getrennte Welten die sich nicht "sehen". Du müsstest dem Switch also sagen: "Hey wenn DSCP 46 auf Port x reinkommt dann sende es Tagged auf Port y mit .1p Prio 6 wieder raus"
So ein QoS Remapping supporten bessere Switches wie dein Ruckus ICX natürlich, wären aber Unsinn in deinem Umfeld. Sie machen nur Sinn wenn am Port y und dahinter keinerlei DSCP Option vorhanden ist und man die Paket global auf .1p umlabeln muss.
Ist bei dir ja niemals der Fall, denn es reicht ja wenn der Switch den DSCP Header liest das Paket priorisiert und weitersendet. Am nächsten Hop, sofern der DSCP versteht, geht es ja genau so. Ein Umlabeln ist also in einem DSCP fähigen Gesamtumfeld völlig unnötig.
Hope this helps...?!
Ja, das hilft.
Die 3cx hat leider solch eine Einstellung nicht im Webinterface. Deshalb macht man das über die Iptables Firewall. Eine sogenannte "Catch-All"-Regel muss dazu eingerichtet werden. Deshalb sagte ich das bereits. Siehe:
https://www.3cx.com/blog/voip-howto/qos-linux/
Die 3cx hat keinerlei Möglichkeit im Webinterface Werte für ToS zu setzen. Stattdessen sagt man im obengenannten TUT, das stattdessen der gesamte Traffic mit dscp und einem bestimmten Wert versehen werden soll.
Unter Windows kann man im übrigen ebenfalls ToS-Werte in den lokalen Gruppenrichtlinien setzen: https://www.3cx.com/blog/voip-howto/qos-windows-2008-server-local-policy ...
Aber das nur mal der Vollständigkeit halber.
Auf dem Cisco-Switch ist das schon alles eingerichtet und scheint zu funktionieren. Bringt natürlich nichts, wenn es nicht durchgängig vollzogen wird.
Deshalb werde ich heute Abend die erforderlichen Einstellungen an der PBX durchführen und auf den entsprechenden Schnittstellen am ICX Switch trust dscp aktivieren.
Kann man mit einer einfachen Messung der Latenz zwischen PBX und DECT dann die Wirksamkeit nachprüfen oder kommt dies nur bei Auslastung zum tragen?
Die 3cx hat leider solch eine Einstellung nicht im Webinterface. Deshalb macht man das über die Iptables Firewall. Eine sogenannte "Catch-All"-Regel muss dazu eingerichtet werden. Deshalb sagte ich das bereits. Siehe:
https://www.3cx.com/blog/voip-howto/qos-linux/
Die 3cx hat keinerlei Möglichkeit im Webinterface Werte für ToS zu setzen. Stattdessen sagt man im obengenannten TUT, das stattdessen der gesamte Traffic mit dscp und einem bestimmten Wert versehen werden soll.
Unter Windows kann man im übrigen ebenfalls ToS-Werte in den lokalen Gruppenrichtlinien setzen: https://www.3cx.com/blog/voip-howto/qos-windows-2008-server-local-policy ...
Aber das nur mal der Vollständigkeit halber.
Auf dem Cisco-Switch ist das schon alles eingerichtet und scheint zu funktionieren. Bringt natürlich nichts, wenn es nicht durchgängig vollzogen wird.
Deshalb werde ich heute Abend die erforderlichen Einstellungen an der PBX durchführen und auf den entsprechenden Schnittstellen am ICX Switch trust dscp aktivieren.
Kann man mit einer einfachen Messung der Latenz zwischen PBX und DECT dann die Wirksamkeit nachprüfen oder kommt dies nur bei Auslastung zum tragen?
Die 3cx hat leider solch eine Einstellung nicht im Webinterface.
Das wäre mehr als ungewöhnlich und absolut unüblich im VoIP Umfeld. Es ist dann vermutlich so das das dann hardgecodet ist in der Anwendung. Das wäre nicht unüblich.Hast du dir denn wenigstens den PBX Traffic mal mit einem simplen Wireshark Trace angesehen ??
Damit kannst du doch dann sofort sehen ob der PBX Traffic per se DSCP priorisiert ist.
Das kostet max. 5 Minuten Aufwand und schafft dann 100%ige Sicherheit was die DSCP Klassifizierung der PBX anbetrifft.
Da kommt man doch als Netzwerker auch ohne ein Administrator Forum nun als Allererstes drauf !
Deshalb macht man das über die Iptables Firewall. Eine sogenannte "Catch-All"-Regel muss dazu eingerichtet werden
Eigentlich niemals. Das ist ein Frickel Workaround. Siehe Beispiel der 150 Euro Auerswald oben !! Wenn so ein billiges Consumer Massenprodukt das kann, dann sollten es auch alle können was in der Regel ja auch durchgehend der Fall ist.3cx selber schreibt selber blumige_Blogs über QoS, also sollte es sich doch auch konform dazu verhalten.
Es wäre höchst unüblich und auch ein ziemliches Armutszeugnis wenn ein kommerzielles VoIP Produkt kein DSCP Support hätte.
Aber gesetzt den Fall dem wäre so, dann musst du natürlich nicht zwingend auf dem OS des PBX rumfrickeln und irgendwelche quick and dirty Workarounds nutzen sondern kannst den Switch selber anweisen zu klassifizieren. Sollte man wie gesagt nicht machen, denn das ist immer Port bezogen aber in deinem Fall hättest du ja keine Wahl wenn du es nicht im OS selber machen willst. Steckt einer mal die PBX um auf einem anderen Port oder ersetzt den Switch ist's sofort aus mit der DSCP Klassifizierung....
Aber gehen wir mal davon aus das das nicht passiert und die 3cx ihren festen Port hat und auch der Switch bleibt, dann sagst du dem Switch in der Konfig: "Hey, alles was hier rausgeht ist DSCP 46 klassifiziert" Das ist einfacher und ungefährlicher als die undokumentierte Frickelei im PBX OS. Seite 33 im Ruckus Traffic Management Guide, das ist das ip dscp-remark x Kommando am Port.
...und scheint zu funktionieren.
Scheint...?? Die Queue Statistics am Port zeigen das. Dort kannst du sehen ob die Counter der EF DSCP 46 Queue hochzählen bei Voice Ports.Bringt natürlich nichts, wenn es nicht durchgängig vollzogen wird.
So ist es ? Kann man mit einer einfachen Messung
Einfach mit Bordmitteln lassen sich reine Latenzen in dem Mikro- Sekundenbereichen nicht messen. Relevant wird das ja auch eigentlich nur in Überlast Situationen. Was aber nicht davon ablenken soll das man Voice Traffic aus guten Gründen generell immer priorisieren sollte.Nur mal nebenbei: Wenn du Cisco SG Switches und Ruckus ICX zusammen betreibst hast du daran gedacht den Ruckus ICX zwingend auf Single Span Spanning Tree umzustellen ?? Die Ciscos können kein PVSTP was ihre großen Brüder die Catalysten im Default machen und auch der ICX. Beide STP Modi sind inkompatibel und können zu Unterbrechungen im Netz führen. Hast du das auch bedacht ?!
Der ICX muss dann zwingend:
!
spanning-tree single
!
spanning-tree single 802-1w
spanning-tree single 802-1w priority 8192
!
vlan 1 name DEFAULT-VLAN by port
spanning-tree
management-vlan
default-gateway 192.168.1.254 1
!
vlan 10 name Test by port
tagged ethe 1/2/1 to 1/2/2
untagged ethe 1/1/7 to 1/1/8
spanning-tree
!
global konfiguriert haben und sollte, wenn er der zentrale Root Switch ist, eine entsprechende STP Priority größer 32768 gesetzt haben modulo 4096 also z.B. 8192.
Aber es scheint so. Es gibt keine Option. Bin jetzt verschiedene Wiki-Einträge und die kompletten Settings durch. Im Support-Forum wird auch keine andere Möglichkeit erwähnt. Vielleicht verlässt man sich da bewusst auf die Einstellungen im jeweiligen OS. Warum auch immer...
Dann finde ich es aber besser das "Gefrickel" des OS zu verwenden. Den wie du erwähnst: Wenn ich das auf den Port mache und es steckt mal einer um, war es das.
So sieht die Config bei mir aus:
Der Cisco hat dann STP Priority von 32768.
Beim SG350 scheint auch PVSTP möglich zu sein. Das können die SG200er und SG300er nicht.
Dann finde ich es aber besser das "Gefrickel" des OS zu verwenden. Den wie du erwähnst: Wenn ich das auf den Port mache und es steckt mal einer um, war es das.
So sieht die Config bei mir aus:
!
spanning-tree single
!
!
vlan 30 name VOIP by port
tagged ethe 1/1/11 ethe 1/2/2 ethe 2/2/2 ethe 3/2/4
spanning-tree
!
!
spanning-tree single 802-1w
spanning-tree single 802-1w priority 4096
!Der Cisco hat dann STP Priority von 32768.
Beim SG350 scheint auch PVSTP möglich zu sein. Das können die SG200er und SG300er nicht.
Hier mal eine Aufzeichnung von einem Sync-Request einer DECT-Zelle:
Wie man sehen kann CS7.
Hier mal eine Übertragung von der PBX an ein FXS Gateway:
Das steht CS0. Bedeutet das jetzt das es aktiv ist aber eben nur der Falsche Wert oder bedeutet das einfach das er Default ist weil nichts der gleichen vorhanden ist?
Bei der Kommunikation über SSH sagt er nämlich bei DiffServ "Unknown", was ich jetzt durchgängig erwartet hätte.
Wie man sehen kann CS7.
Hier mal eine Übertragung von der PBX an ein FXS Gateway:
Das steht CS0. Bedeutet das jetzt das es aktiv ist aber eben nur der Falsche Wert oder bedeutet das einfach das er Default ist weil nichts der gleichen vorhanden ist?
Bei der Kommunikation über SSH sagt er nämlich bei DiffServ "Unknown", was ich jetzt durchgängig erwartet hätte.
So sieht die Config bei mir aus:
Perfekt und richtig ! 👍Hier mal eine Aufzeichnung von einem Sync-Request einer DECT-Zelle:
Gut ein Sync Request ist kein VoIP sondern lediglich ein Management Frame aber wenn er die Voice Daten auch CS7 Priorisiert ist das recht hoch (Class 4) und schonmal sehr gut. Du solltest über den DECT AP mal anrufen und den Traffic ansehen.Das steht CS0.
CS0 ist gar nix ! Das heisst keinerlei Priorisierung. Der Traffic der PBX wird also nur in der Standard Queue (Best Efford) geforwardet wie alles andere im Netz auch. Da solltest du also in der Tat was tun...!das jetzt das es aktiv ist aber eben nur der Falsche Wert
Gar kein Wert ! Jedes IP Paket hat ja einen DSCP Header der aber standardmässig immer auf 0 gesetzt ist (Best Efford)Bei der Kommunikation über SSH sagt er nämlich bei DiffServ "Unknown"
Das mag sein wenn dein Sniffer nur die üblichen ToS Standardwerte anzeigt ! Oder du hast einen kaputten SSH Client !Guckst du hier:
Welche Bitfolge bzw. Wert hat denn das "unknown" ?? Bei SSH ist das ziemlich ungewöhnlich.
Steht zumindest so im Wireshark:
Ist auch wirr und technisch falsch. Was ist das für ein SSH Client ? Das muss ein Bug sein, denn dort ist einzig nur das Delay Bit gesetzt alles andere aber auf 0. Das ist im DSCP RFC gar nicht definiert und ein Zustand der nie vorkommen kann weil unlogisch. Deshalb "unknown". Der Wireshark hat da Recht.
Es handelt sich um OpenSSH_7.6p1 unter Ubuntu. Komisch.
An der Schnittstelle zur PBX und Uplink für Cisco SG350 habe ich jetzt jeweils trust dscp gesetzt. Jetzt gehen die Counter in den Queues 5 und 6 nach oben:
Per Iptables habe ich den Output auf dscp 46 gestellt:
Jetzt bleibt abzuwarten, ob eine Besserung eintritt.
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 42351044 0
1 0 0
2 0 0
3 0 0
4 600496 0
5 2362 0
6 7 0
7 1933355 0Per Iptables habe ich den Output auf dscp 46 gestellt:
Jetzt bleibt abzuwarten, ob eine Besserung eintritt.
Jetzt gehen die Counter in den Queues 5 und 6 nach oben:
Bingo !Ein sicheres Zeichen das es nun klappt mit dem QoS ! 👍
Wenn das jetzt für alle L2 und L3 Hops intern durchgehend bis zum Internet Router geht hast du jedenfalls intern alles gemacht was möglich ist.
Dort, Richtung Internet werden dann eh vom Provider alle DSCP Bits abgestrippt !
