12
HP V1910 48G Voice VLAN-QoS Konfiguration
Hallo,
bei unserer Firma haben wir 2 Gebäude welche mittels VPN Tunnel miteinander verbunden sind.
In beiden Gebäuden haben wir jeweils oben genannten Switch, Firewall und Telefonanlage stehen.
Wir haben öfter Probleme bei Telefonaten zwischen beiden Gebäuden (man hört den Gesprächspartner erst nach x Zeit)
Daraufhin haben wir die Ports wo Firewall und Telefonanlage dran hängen mit höchster Priorisierung versehen.
Des weiteren haben wir ein Voice VLAN eingerichtet.
Jedoch bin ich mir mit den Einstellungen nicht wirklich sicher.
Telefonanlage ist eine von Siemens.
Im Voice VLAN kann ich als Modus nur "Manual" einstellen - erhalte folgende Meldung "Voice VLAN can not be enabled on Access ports when voice VLAN is in auto mode"
Kann mir evtl jemand helfen?
bei unserer Firma haben wir 2 Gebäude welche mittels VPN Tunnel miteinander verbunden sind.
In beiden Gebäuden haben wir jeweils oben genannten Switch, Firewall und Telefonanlage stehen.
Wir haben öfter Probleme bei Telefonaten zwischen beiden Gebäuden (man hört den Gesprächspartner erst nach x Zeit)
Daraufhin haben wir die Ports wo Firewall und Telefonanlage dran hängen mit höchster Priorisierung versehen.
Des weiteren haben wir ein Voice VLAN eingerichtet.
Jedoch bin ich mir mit den Einstellungen nicht wirklich sicher.
Telefonanlage ist eine von Siemens.
Im Voice VLAN kann ich als Modus nur "Manual" einstellen - erhalte folgende Meldung "Voice VLAN can not be enabled on Access ports when voice VLAN is in auto mode"
Kann mir evtl jemand helfen?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 206556
Url: https://administrator.de/contentid/206556
Printed on: April 25, 2024 at 12:04 o'clock
12 Comments
Latest comment
Um was für eine Siemens-Anlage handelt es sich, welchen Softwarestand hat diese und mit welchem Protokoll wurde die Quervernetzung realisiert?
Hi Alf,
Dein Voice-VLAN geht ja nicht zum nächsten Gebäude!
Über den VPN wird ja geroutet. Und in der Route hast du kein QoS.
Du musst dir Gedanken über Routing machen und die Routerwarteschlange.
Die Verbindung der VoIP Telefone erfolgt ja mit 4 unabhängigen Streams:
VOIP Tel1 zu Tel2 (RTP)
VoIP Tel2 zu Tel1
Verbindungsaufbau Tel1 zu Siemens (RTCP) oder Siemens Tunnel
Verbingungsaufbau Tel2 zu Siemens
Da ist es logisch, dass sich die Telefonie anders verhält, wenn sie innerhalb des Gebäudes oder gebäudeübergreifend genutzt wird.
GRuß
Netman
Dein Voice-VLAN geht ja nicht zum nächsten Gebäude!
Über den VPN wird ja geroutet. Und in der Route hast du kein QoS.
Du musst dir Gedanken über Routing machen und die Routerwarteschlange.
Die Verbindung der VoIP Telefone erfolgt ja mit 4 unabhängigen Streams:
VOIP Tel1 zu Tel2 (RTP)
VoIP Tel2 zu Tel1
Verbindungsaufbau Tel1 zu Siemens (RTCP) oder Siemens Tunnel
Verbingungsaufbau Tel2 zu Siemens
Da ist es logisch, dass sich die Telefonie anders verhält, wenn sie innerhalb des Gebäudes oder gebäudeübergreifend genutzt wird.
GRuß
Netman
Zitat von @tikayevent:
Um was für eine Siemens-Anlage handelt es sich, welchen Softwarestand hat diese und mit welchem Protokoll wurde die
Quervernetzung realisiert?
Um was für eine Siemens-Anlage handelt es sich, welchen Softwarestand hat diese und mit welchem Protokoll wurde die
Quervernetzung realisiert?
Anlage1: HiPath 3800
Software Version1: H3K_V9_R2.3.0_037 (HE692P.00.037)
Anlage2: HiPath 3500
Software Version2: H3K_V9_R2.0.0_007 (HE692S.00.007)
Alle Anrufe gehen erst auf Anlage1 und gelangen via Tunnel zu Anlage2
Tunnel nutzt IPSec
Nein, ich meine das Protokoll, mit dem sich die Anlagen unterhalten. ist das SIP.Q oder Cornet-IP?
Ich seh aber schon ein Problem. Die Anlagen haben nicht den gleichen Softwarestand. In einem Anlagenverbund müssen für einen problemlosen Betrieb die Anlagen und die IP-Baugruppen den gleichen Softwarestand haben. Alles andere kann funktionieren, muss aber nicht.
Ist die Verbindung zwischen den Gebäuden eine Internetverbindung, eine Direktleitung oder eine Festverbindung? Wenn es eine Internetverbindung ist, was für ein Typ und welche Geschwindigkeit?
Nicht gut, die Priorisierung sollte anhand der DiffServ-Flags geschehen, da die Sprachdaten absoluten Vorrang haben, was nur mit DiffServ gegeben ist (die Sprachdaten werden von der Anlage als EF markiert).
Ich seh aber schon ein Problem. Die Anlagen haben nicht den gleichen Softwarestand. In einem Anlagenverbund müssen für einen problemlosen Betrieb die Anlagen und die IP-Baugruppen den gleichen Softwarestand haben. Alles andere kann funktionieren, muss aber nicht.
Ist die Verbindung zwischen den Gebäuden eine Internetverbindung, eine Direktleitung oder eine Festverbindung? Wenn es eine Internetverbindung ist, was für ein Typ und welche Geschwindigkeit?
Daraufhin haben wir die Ports wo Firewall und Telefonanlage dran hängen mit höchster Priorisierung versehen.
Nicht gut, die Priorisierung sollte anhand der DiffServ-Flags geschehen, da die Sprachdaten absoluten Vorrang haben, was nur mit DiffServ gegeben ist (die Sprachdaten werden von der Anlage als EF markiert).
Eine Schlüsselfrage ist auch nicht beantwortet !
Machen die Telefone eine Layer 2 Priorisierung ( 802.1p ) oder eine Layer 3 Priorisierung (DSCP) ?
Ohne diese Klärung kommen wir nicht weiter hier.
Frag also den Installateur der Telefonanlage danach !
Davon ist essentiell abhängig was auf den Switches konfiguriert werden muss !
Machen die Telefone eine Layer 2 Priorisierung ( 802.1p ) oder eine Layer 3 Priorisierung (DSCP) ?
Ohne diese Klärung kommen wir nicht weiter hier.
Frag also den Installateur der Telefonanlage danach !
Davon ist essentiell abhängig was auf den Switches konfiguriert werden muss !
1
Wenn es Siemens HFA Geräte sind (HFA15-40) können die beides @aqui - DSCP und 802.1p (wir haben die Geräte auch im Einsatz - fahren allerdings ausschließlich 802.1p da wir nicht überall Layer 3 fähige Geräte haben).
Und @tikayevent muss ich auch recht geben, es bringt nix die beiden "Ports" zu priorisieren, dass wird durch DiffServ gewährleistet - sofern deine eingesetzten Firewalls das unterstützen (haben wir auch so im Einsatz - ohne Probleme)
Wobei sich mir die Frage stellt: wenn Ihr zwei Gebäude habt - wie weit sind diese auseinander? Es klingt nach kurzen Strecken die man z.B. mit Richtfunk schneller angebunden bekommt als via 2 x DSL/SDLS und IPSec Tunneln.
Und @tikayevent muss ich auch recht geben, es bringt nix die beiden "Ports" zu priorisieren, dass wird durch DiffServ gewährleistet - sofern deine eingesetzten Firewalls das unterstützen (haben wir auch so im Einsatz - ohne Probleme)
Wobei sich mir die Frage stellt: wenn Ihr zwei Gebäude habt - wie weit sind diese auseinander? Es klingt nach kurzen Strecken die man z.B. mit Richtfunk schneller angebunden bekommt als via 2 x DSL/SDLS und IPSec Tunneln.
Die Port Priorisierung habe ich gestern noch deaktiviert.
Mail an unseren Techniker ist gestern/heute raus.
Telefone kommen meist Siemens optiPoint 500 economy/Basic zum Einsatz.
Beide Firewalls unterstützen DiffServ.
Gebäude haben eine Luftlinie von <150m
Jedoch sind wir nicht alleine in den jeweiligen Gebäude (mehrere öffentliche/medizinische Einrichtungen im Gebäude)
Denke das ist keine Option. Auch wenn es vielleicht die bessere wäre.
Mail an unseren Techniker ist gestern/heute raus.
Telefone kommen meist Siemens optiPoint 500 economy/Basic zum Einsatz.
Beide Firewalls unterstützen DiffServ.
Gebäude haben eine Luftlinie von <150m
Jedoch sind wir nicht alleine in den jeweiligen Gebäude (mehrere öffentliche/medizinische Einrichtungen im Gebäude)
Denke das ist keine Option. Auch wenn es vielleicht die bessere wäre.
Sie können sicher beides machen aber benutzt wird nur eins meistens. Nämlich das was zentral auf dem Call Manager eingerichtet ist !
Wichtig ist also mal ein VoIP Paket zu sniffern um ganz sicher zu sein. Oder den Telefon Techniker zu fragen...?!
Oft nehmen die aber Diffserv also L3 um nicht in Tagging Problematiken zu kommen, da 802.1p L2 Prio immer Teil von 802.1q ist und das dann getaggte VoIP Links auf die Telefonie Endgeräte erfordert.
Das L3 Prio wiederum (Diffserv, DSCP) erfordert dann aber Switches die Layer QoS aware sind also in den L3 Header sehen können sofern die Access Switches reine L2 Switches sind.
Eine Menge Billigswitches können sowas nicht, dann ists aus mit L3 Prio und man muss L2 machen.
Ob die Firewalls DSCP können ist vollkommen irrelevant denn QoS muss immer Point to Point eingerichtet werden also auf jedem einzelnen Switchhop.
Ne Firewall geht ins Internet (jedenfalls meistens) und da gehen lokale Voice Pakete nicht hin also ist die Firewall QoS Einstellung (meistens) völlig uninteressant.
Das Telefon QoS Verfahren wird zentral auf dem Call Manager eingerichtet.
Wichtig ist also mal ein VoIP Paket zu sniffern um ganz sicher zu sein. Oder den Telefon Techniker zu fragen...?!
Oft nehmen die aber Diffserv also L3 um nicht in Tagging Problematiken zu kommen, da 802.1p L2 Prio immer Teil von 802.1q ist und das dann getaggte VoIP Links auf die Telefonie Endgeräte erfordert.
Das L3 Prio wiederum (Diffserv, DSCP) erfordert dann aber Switches die Layer QoS aware sind also in den L3 Header sehen können sofern die Access Switches reine L2 Switches sind.
Eine Menge Billigswitches können sowas nicht, dann ists aus mit L3 Prio und man muss L2 machen.
Ob die Firewalls DSCP können ist vollkommen irrelevant denn QoS muss immer Point to Point eingerichtet werden also auf jedem einzelnen Switchhop.
Ne Firewall geht ins Internet (jedenfalls meistens) und da gehen lokale Voice Pakete nicht hin also ist die Firewall QoS Einstellung (meistens) völlig uninteressant.
Das Telefon QoS Verfahren wird zentral auf dem Call Manager eingerichtet.
Protokoll der beiden Anlagen: IP Trunk (CorNet NQ)
Telefone priorisieren mit Layer 2 (802.1p)
Bei den Netzwerkkarten der beiden Anlagen konnte man noch einen haken setzen bei "IEEE802.1p/q - Tagging"
Vielleicht schaft nun dieser Haken schon Abhilfe, da ja jetzt erst die Firewalls entsprechend reagieren können.
Telefone priorisieren mit Layer 2 (802.1p)
Bei den Netzwerkkarten der beiden Anlagen konnte man noch einen haken setzen bei "IEEE802.1p/q - Tagging"
Vielleicht schaft nun dieser Haken schon Abhilfe, da ja jetzt erst die Firewalls entsprechend reagieren können.
Vermutlich, denn die .1p Priorisierung ist Teil des .1q Tags.
Fazit: .1p Priorisierung erfordert IMMER tagged Interfaces !
Fazit: .1p Priorisierung erfordert IMMER tagged Interfaces !
Wenn ich jetzt die Ports an denen Firewall und Telefonanlage hängen, änderen will auf TAGGED,, wird der Port Typ auf hybrid geändert von Access. Hat dies irgendwelche Auswirkungen auf mein sonstiges Netz - über die Firewall geht ja nicht nur VoIP.
Nein, denn es werden ja nur die VLAN IDs zusätzlich im Frame übertragen. Auswirkungen hat das nicht. Solande du nicht mit einem tagged Port einen untagged Client betreiben wird ist das OK.
