15
Was macht ihr in Eurem Netz für die VoIP Priorisierung?
Moin zusammen,
wir bekommen langsam Probleme mit der VoIP Gesprächsqualität intern im Netzwerk, vor allem bei Gesprächen über unsere VPN Tunnel zu den Niederlassungen oder nach extern z.B. zu Handys.
Zu unserer Konfiguration (nur als grober Überblick, es soll keine Remote Glaskugel Detailanalyse werden):
5 Niederlassungen über OpenVPN verbunden, ca 20 HomeOffice OpenVPN Clients, die Firewalls und OpenVPN Server sind Linux Distributionen mit dicken Xeon's. Hauptniederlassung mit ca 150 VoIP Telefonen, Asterisk Anlage, Unifi Switche, Unifi WLAN.
Bevor ich unsere Netzwerk-Jungs aufscheuche, dass alle Tunnelverbindungen und die internen Switche mit QoS und/oder LLDP optimiert werden sollen (evtl machen es bestimmte Geräte ja bereits), oder sogar das Unifi Spielzeug raus geworfen werden muss, würde ich gerne Eure Meinungen lesen was ihr in eurem Netz alles so unternommen habt um in der Sache safe zu bleiben.
Vielen Dank in Voraus and keep rockin'
Der Mike
wir bekommen langsam Probleme mit der VoIP Gesprächsqualität intern im Netzwerk, vor allem bei Gesprächen über unsere VPN Tunnel zu den Niederlassungen oder nach extern z.B. zu Handys.
Zu unserer Konfiguration (nur als grober Überblick, es soll keine Remote Glaskugel Detailanalyse werden):
5 Niederlassungen über OpenVPN verbunden, ca 20 HomeOffice OpenVPN Clients, die Firewalls und OpenVPN Server sind Linux Distributionen mit dicken Xeon's. Hauptniederlassung mit ca 150 VoIP Telefonen, Asterisk Anlage, Unifi Switche, Unifi WLAN.
Bevor ich unsere Netzwerk-Jungs aufscheuche, dass alle Tunnelverbindungen und die internen Switche mit QoS und/oder LLDP optimiert werden sollen (evtl machen es bestimmte Geräte ja bereits), oder sogar das Unifi Spielzeug raus geworfen werden muss, würde ich gerne Eure Meinungen lesen was ihr in eurem Netz alles so unternommen habt um in der Sache safe zu bleiben.
Vielen Dank in Voraus and keep rockin'
Der Mike
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: 1691363631
Url: https://administrator.de/contentid/1691363631
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
15 Kommentare
Neuester Kommentar
vLAN-Abtrennung für VOIP
Danke erst einmal. Hast du das vLAN dann noch irgendwie und wo priorisiert?
Ich persönlich nicht, weils (bisher) nicht nötig war. Aber ich mache ja auch nur so "MIni-Netzwerke".
Macht doch dann auch nur noch im Router der WAN-Schnittstelle Sinn?! Davor haben die Daten nen eigenes vLAN und "dahinter" haste eh keine Kontrolle und bist auf die Priorisierung des ISP angewiesen?!
Was aber offenbar (häufig) nicht genügt: QoS ohne vLAN. Das habe ich schon von unterschiedlichen DLs im Mittelstands-Bereich mitbekommen.
Macht doch dann auch nur noch im Router der WAN-Schnittstelle Sinn?! Davor haben die Daten nen eigenes vLAN und "dahinter" haste eh keine Kontrolle und bist auf die Priorisierung des ISP angewiesen?!
Was aber offenbar (häufig) nicht genügt: QoS ohne vLAN. Das habe ich schon von unterschiedlichen DLs im Mittelstands-Bereich mitbekommen.
Wie groß ist Dein Netz?
Ich habe üblicher Weise nur Kunden bis 10 MAs. Da ist das also alles noch sehr entspannt 
Danke dir, Visucius.
1
Hallo,
Also VoIP ohne eigenes VLAN mit QoS zu betreiben ist echt sportlich. Grade in dem Ausmaß bei 150 Telefonen.
Das würde ich als allererstes ändern.
Sowie das VoIP-Netzwerk soweit wie möglich getrennt vom eigentlichen Netz betreiben (getrennte Fasern, nicht den integrierten Switch der Telefone nutzen, evtl. sogar eigene Switche)
VG
bitnarrator
Also VoIP ohne eigenes VLAN mit QoS zu betreiben ist echt sportlich. Grade in dem Ausmaß bei 150 Telefonen.
Das würde ich als allererstes ändern.
Sowie das VoIP-Netzwerk soweit wie möglich getrennt vom eigentlichen Netz betreiben (getrennte Fasern, nicht den integrierten Switch der Telefone nutzen, evtl. sogar eigene Switche)
VG
bitnarrator
Moin,
definitiv im internen Netz mal die Telefonie in ein eigenen VLAN stopfen und beim QoS die höchste Priorität setzen.
Gruß
em-pie
Manchmal bin ich froh, dass wir noch klassische Systemtelefone einsetzen
definitiv im internen Netz mal die Telefonie in ein eigenen VLAN stopfen und beim QoS die höchste Priorität setzen.
Gruß
em-pie
Manchmal bin ich froh, dass wir noch klassische Systemtelefone einsetzen
Moin,
VLAN für Tel und in der Anlage sowie den Telefonen die richtige Konfig hinterlegen und auch in den Routern / Switchen aktivieren. -> VLAN Prio 5 und ToS EF (46).
Ansonsten sind alle Uplinks doppelt und haben mit 10G mehr als genug Bandbreite.
Gruß
VLAN für Tel und in der Anlage sowie den Telefonen die richtige Konfig hinterlegen und auch in den Routern / Switchen aktivieren. -> VLAN Prio 5 und ToS EF (46).
Ansonsten sind alle Uplinks doppelt und haben mit 10G mehr als genug Bandbreite.
Gruß
VLAN Abtrennung für VoIP was so oder so allein schon aus rechtlichen Grunden in Firmennetzen so sein sollte. (Fernmeldegeheimnis) und gleichzeitig die QoS Aktivierung mit DSCP ! Die Kollegen haben das oben ja schon richtig darauf hingewiesen. Das sind simpelste Standard Setups die man in jedem VoIP Netz grundsätzlich immer so macht. Letzteres ist am wichtigsten.
Allerdings muss man darauf achten das die Switch Infrastruktur das auch supportet bzw. den DSCP Header im IP Paket auch liest.
Nicht alle L2 Switches machen das ohne entsprechende Konfiguration (DSCP Honoring) da sie ja nur im L2 arbeiten und DSCP ein L3 QoS Feature ist. Siehe dazu auch [=590120&token=727 HIER].
DSCP als QoS deshalb, weil du so im Gegensatz zur 802.1p Priorisierung im Layer 2 kein Tagging erzwingen musst.
L2 QoS mit 802.1p CoS Header ist immer Teil des 802.1q Tags, deshalb erzwingt L2 QoS immer Tagging der Endgeräte (Telefone). Wenn die VoIP Telefonie ohne Tagging eingerichtet wurde ist es dann immer sinnvoller auf DSCP, also Layer 3 QoS, zu gehen die Teil des IP Headers (L3) ist.
Das müssen die verwendeten L2 Switches aber supporten denn Switches arbeiten generell ja L2, also Mac Adress, basierend und das dadrüber ist (L3) interessiert sie nicht ! (siehe oben).
Meist senden bzw. klassifizieren die Telefonie Endgeräte schon per DSCP was man aber besser vorab immer nochmal im VoIP Setup oder mit dem Wireshark verifiziert um sicherzugehen.
Wenn das der Fall ist, muss man auf den Telefonieports am Switch lediglich das DSCP Trusting/Honoring aktivieren.
Der Switch forwardet dann die DSCP klassifizierten Frames der Endgeräte in eines seiner Priority Queues. Meist nutzen Switches dafür im Default ein festes Schema, was man aber immer individuell an DSCP Values seiner Geräte anpassen kann.
Hier mal am Beispiel eines Cisco SG/CBS Switches:
DSCP Trust/Honoring Mode aktiviert im L2:
DSCP to Priority Queue Mapping:
Gleiches muss man natürlich auch im Internet Router machen das der dort ebenso DSCP klassifizierte Frames in einer Forwarding Queue priorisiert. Logisch denn das QoS sollte immer durchgängig sein vom Sender zum Empfänger da es pro Hop ausgeführt wird.
Damit rennt dann jegliches VoIP Netz absolut störungsfrei.
Das sind simple Setup Mechanismen in jedem VoIP Netz die man grundsätzlich immer entsprechend so konfigurieren sollte.
Allerdings muss man darauf achten das die Switch Infrastruktur das auch supportet bzw. den DSCP Header im IP Paket auch liest.
Nicht alle L2 Switches machen das ohne entsprechende Konfiguration (DSCP Honoring) da sie ja nur im L2 arbeiten und DSCP ein L3 QoS Feature ist. Siehe dazu auch [=590120&token=727 HIER].
DSCP als QoS deshalb, weil du so im Gegensatz zur 802.1p Priorisierung im Layer 2 kein Tagging erzwingen musst.
L2 QoS mit 802.1p CoS Header ist immer Teil des 802.1q Tags, deshalb erzwingt L2 QoS immer Tagging der Endgeräte (Telefone). Wenn die VoIP Telefonie ohne Tagging eingerichtet wurde ist es dann immer sinnvoller auf DSCP, also Layer 3 QoS, zu gehen die Teil des IP Headers (L3) ist.
Das müssen die verwendeten L2 Switches aber supporten denn Switches arbeiten generell ja L2, also Mac Adress, basierend und das dadrüber ist (L3) interessiert sie nicht ! (siehe oben).
Meist senden bzw. klassifizieren die Telefonie Endgeräte schon per DSCP was man aber besser vorab immer nochmal im VoIP Setup oder mit dem Wireshark verifiziert um sicherzugehen.
Der Switch forwardet dann die DSCP klassifizierten Frames der Endgeräte in eines seiner Priority Queues. Meist nutzen Switches dafür im Default ein festes Schema, was man aber immer individuell an DSCP Values seiner Geräte anpassen kann.
Hier mal am Beispiel eines Cisco SG/CBS Switches:
DSCP Trust/Honoring Mode aktiviert im L2:
DSCP to Priority Queue Mapping:
Gleiches muss man natürlich auch im Internet Router machen das der dort ebenso DSCP klassifizierte Frames in einer Forwarding Queue priorisiert. Logisch denn das QoS sollte immer durchgängig sein vom Sender zum Empfänger da es pro Hop ausgeführt wird.
Damit rennt dann jegliches VoIP Netz absolut störungsfrei.
Das sind simple Setup Mechanismen in jedem VoIP Netz die man grundsätzlich immer entsprechend so konfigurieren sollte.
1
Keine Angst, ein eigenes VLAN für die VoIP Geräte war als erstes da.
Deswegen habe ich die Frage so gestellt:
Oder anders gesagt, ich schaue mich nach dem "Best Practice" um. Nicht, wie es sein "sollte" (wenn es danach geht, muss sowieso der allergrößte Cisco her), sondern, wie es bei ublichen Systemen in dieser Größe im Feld "ist" oder sogar "gewachsen ist".
Ich bin mir sicher, dass das vLAN alleine nicht reicht. QoS im internen Netzwerk (also nicht zu den WAN Schnittstellen hin) würde bedeuten, dass das gesamte Unifi Geraffel raus muss, die Unifi Switche können kein QoS. Aber, ist es wirklich nötig? Das kann man nur an den (bei euch) funktionierenden Netzwerken erkennen, wenn sie die gleiche Größenordnung haben).
Ein eigenes Netzwerk mit eigenen Fasern dafür aufzubauen würde bestimmt funktionieren, das wäre ja dann eine eigene ungestörte Infrastruktur, es scheitert dann jedoch an der Tatsache, dass die Leute vermehrt Konferenzen mit den Laptops durchführen (Videokonferenzen, Softphones). Und da ist das WLAN die nächste Komponente, die untersucht werden muss. Es lässt sich also nicht komplett trennen und muss Protokolltechnisch gelöst werden.
Deswegen habe ich die Frage so gestellt:
... was ihr in eurem Netz alles so unternommen habt
und nichtwas könnte ich bei uns noch verändern
Oder anders gesagt, ich schaue mich nach dem "Best Practice" um. Nicht, wie es sein "sollte" (wenn es danach geht, muss sowieso der allergrößte Cisco her), sondern, wie es bei ublichen Systemen in dieser Größe im Feld "ist" oder sogar "gewachsen ist".
Ich bin mir sicher, dass das vLAN alleine nicht reicht. QoS im internen Netzwerk (also nicht zu den WAN Schnittstellen hin) würde bedeuten, dass das gesamte Unifi Geraffel raus muss, die Unifi Switche können kein QoS. Aber, ist es wirklich nötig? Das kann man nur an den (bei euch) funktionierenden Netzwerken erkennen, wenn sie die gleiche Größenordnung haben).
Ein eigenes Netzwerk mit eigenen Fasern dafür aufzubauen würde bestimmt funktionieren, das wäre ja dann eine eigene ungestörte Infrastruktur, es scheitert dann jedoch an der Tatsache, dass die Leute vermehrt Konferenzen mit den Laptops durchführen (Videokonferenzen, Softphones). Und da ist das WLAN die nächste Komponente, die untersucht werden muss. Es lässt sich also nicht komplett trennen und muss Protokolltechnisch gelöst werden.
Na, die Frage ist ja auch, wie die Priorisierung speziell bei den VPN-Verbindungen zu den Zweigstellen läuft, wenn ich das richtig verstehe!
ich schaue mich nach dem "Best Practice" um.
Was das ist steht ja oben !muss sowieso der allergrößte Cisco her
Wie immer Blödsinn, denn das kann sogar der dümmste Chinesen Switch vom Blödmarkt Grabbeltisch. Außer Unify natürlich.... 🤣Ich bin mir sicher, dass das vLAN alleine nicht reicht.
Nein reicht nicht, das ist richtig ! Wie denn auch ? Wenn in allen anderen VLANs Überlast herrscht schützt ein VLAN keineswegs for Packet Drops.Da hilft logischerweise einzig und allein nur Priorisierung also QoS ! Sagt einem auch schon der gesunde IT Verstand.
dass das gesamte Unifi Geraffel raus muss, die Unifi Switche können kein QoS.
Na ja...wer solch einen Schrott verbaut muss sich auch nicht wundern.... No comment !Und da ist das WLAN die nächste Komponente, die untersucht werden muss.
Da gilt dann das gleiche Spiel. WMM aktivieren im WLAN und QoS. Natürlich ohne UBQT Schrott...und muss Protokolltechnisch gelöst werden.
Nöö, mit Protokollen hat das nicht das geringste zu tun. Aber mit intelligenter QoS Konfiguration ! 😉1
Naja, bei Unifi nennt sich das doch SmartQueue?!
Das von aqui klingt ordentlich, hat sich leider in den Beiträgen etwas überschnitten.
Naja, bei Unifi nennt sich das doch SmartQueue?!
Aber nur im USG, also Richtung WAN.
