Anfängerguide für "Profi"-Switches: QoS für VoIP via SIP

[Kinehs]

Hallo zusammen,

ich habe einen HP 1810G-24 ProCurve Switch 24-Port für mein Heimnetzwerk. An diesem sind auch per LAN einige VoIP Telefone via SIP an meine AVM FritzBox gekoppelt. An einem Port des Switches hängt auch die Vodafone-Kabel-Deutschland-FritzBox. Nun möchte ich im Switch QoS einstellen, sprich meine VoIP Themen priorisieren, damit ich mal lerne, mit so einem Profiswitch umzugehen.

Ich habe schon oft Ports oder IPs in den Privatanwender-Routern (wie avm, DLINK...) priorisiert aber dieser Switch ist total anders aufgebaut. Hier muss man irgendwie VLANs erstellen?

Ich habe schon einige Dokumente gefunden (siehe Link). aber die sind mir zu hoch, da mir das logische Basiswissen für die Einstellungen solcher Profiswitches fehlt.

Gibt es irgendwo einen Anfängerguide oder jemanden hier, der mir ein paar Zusammenhänge erklären kann, damit ich selbst durchstarten kann?

ftp://ftp.hp.com/pub/networking/software/2810-AdvTrafficMgmt-July2007-59914733.pdf

https://i.imgur.com/bvNmpQD.png

[RaumKraehe]

Grundsätzlich brauchst du die VLANs nicht für QoS.

Aber damit kann man sich natürlich die Konfiguration erleichtern. Je nach dem.

Vlan erstellen und dann per QoS das Vlan an bestimmten Ports priorisieren. Zum Beispiel am Abgang zum Router. Siehe ab Kapitel 6-10 in der Anleitung.

Doch denke ich das man das praktisch nicht wirklich braucht. Zumindest nicht zu Hause. Der Switch hat doch Power genug.

Gibt es denn Probleme ohne das QoS?

[Kinehs]

Hi, ich hätte gerne ein Problem ausgeschlossen, deswegen möchte ich qos machen. Mir eigentlich egal wie ob über vlan aber ich habe im Moment leider keine Durchblick wie das geht. Und ich möchte es mal lernen, ist ja immer gut fürs Leben. Kannst du mir mal die ganz groben Zusammenhänge erklären, glaube dann komm ich selber einige Schritte weiter.

[Zettabit]

Witzig, wollte mich damit auch mal beschäftigen, wird hoffentlich am WE was :D

Wenn ich da genaueres herausgefunden habe, melde ich mich.

Würde gern einige Sachen gern priorisieren (z.B. Gamestream vom Gaming-PC zur Shield, Gaming-PC ins Internet etc.). Mal sehen obs klappt :)

[Jasch]

Kann man machen ist aber totaler quatsch für den Heimgebrauch.
Die Dinger haben ca 100Gbits Durchsatz, wenn du da rann kommst dann macht das ganze Sinn.
Vorher limitiert immer was anders meistens der Router , da qos machen ist sinvoll.

[Zettabit]

Bei QoS geht es eher um Latenz als um Bandbreite.

[Kinehs]

Genau, beispielsweise hat mein DLINK WLAN Router, an dem auch ein VoIP DECT Fon hing, die ganzen Gespräche zerhackt. Obwohl der Durchsatz an Bandbreite für VoIP natürlich marginalst ist. Sicherlich ist mein Switch im Keller (der ProCurve) deutlich performanter, aber ich würds trotzdem gerne lernen, basteln und priorisieren, auch wenns am Ende vielleicht gar nichts bringt. Wir sind halt Männer ;D;D;D

[lumines]

Genau, beispielsweise hat mein DLINK WLAN Router, an dem auch ein VoIP DECT Fon hing, die ganzen Gespräche zerhackt. Obwohl der Durchsatz an Bandbreite für VoIP natürlich marginalst ist. Sicherlich ist mein Switch im Keller (der ProCurve) deutlich performanter, aber ich würds trotzdem gerne lernen, basteln und priorisieren, auch wenns am Ende vielleicht gar nichts bringt. Wir sind halt Männer ;D;D;D

QoS wird nur einen Teil des Problems lösen. Damit kannst du zwar eine gewisse Bandbreite garantieren, aber VoIP ist ja eher latenzkritisch, deshalb helfen viele QoS-Lösungen da nicht wirklich. Viele (nicht alle) gehen nur nach der Bandbreite und verbessern eher als Nebeneffekt teilweise auch die Latenz. QoS ist auch ein sehr allgemeines Konzept. Kommt also drauf an, was man letztendlich damit meint und um welche Netzwerkschicht es geht.

Gerade bei ausgelastetem Up- oder Download kann man auch trotz QoS Probleme bekommen. Eine Priorisierung bringt leider nicht so viel, wenn die Leitung an sich nicht mehr richtig performt. QoS geht deshalb mit Traffic Shaping meistens Hand in Hand, weil man mit Letzterem mehr Kontrolle über die Leitung bekommt, quasi.

Siehe auch: http://www.bufferbloat.net/

Dir sollte auch klar sein, dass eine Priorisierung nur dort überhaupt greift, wo sich die Leitung staut. Bei dir ist das sehr wahrscheinlich die Verbindung ins Internet und nicht im LAN. Im Switch irgendeine Form von QoS anzuwenden macht deshalb nicht so wahnsinnig viel Sinn. Man lastet sehr selten GBit-Ports vollständig aus. Soweit ich weiß, können viele Switches aber nach gewissen Merkmalen (Ports, VLAN ID etc.) schauen und dann Flags in den Headern der Pakete setzen, die dann an anderer Stelle für die Priorität beachtet werden. Ist allerdings eher unwahrscheinlich, dass der D-Link damit etwas anfangen kann.

Ist zwar etwas OT, aber du solltest dir einmal fq_codel, sqm-scripts und vielleicht Ubiquitis smart queue anschauen. Damit kann man generell Latenzprobleme in den Griff bekommen und auch die Fairness zwischen Netzwerk Flows verbessern. Meistens muss man dann auch gar keine Dienste mehr speziell priorisieren, weil das schon auf einer etwas allgemeineren Ebene gelöst wird. Siehe auch: http://www.bufferbloat.net/projects/codel/wiki

[Zettabit]

QoS wird nur einen Teil des Problems lösen. Damit kannst du zwar eine gewisse Bandbreite garantieren, aber VoIP ist ja eher latenzkritisch, deshalb helfen viele QoS-Lösungen da nicht wirklich. Viele (nicht alle) gehen nur nach der Bandbreite und verbessern eher als Nebeneffekt teilweise auch die Latenz. QoS ist auch ein sehr allgemeines Konzept. Kommt also drauf an, was man letztendlich damit meint und um welche Netzwerkschicht es geht.

Gerade bei ausgelastetem Up- oder Download kann man auch trotz QoS Probleme bekommen. Eine Priorisierung bringt leider nicht so viel, wenn die Leitung an sich nicht mehr richtig performt. QoS geht deshalb mit Traffic Shaping meistens Hand in Hand, weil man mit Letzterem mehr Kontrolle über die Leitung bekommt, quasi.
Das mag bei billigen Routern so sein, wenn du dagegen ein Managed Switch hast, kann der heute auch IEEE P802.1p und damit Priorisierung des Traffics.

D.h. an das VLAN-Tag tackert der Switch auch noch eine Priorität und diese wird innerhalb des Netzes versucht einzuhalten. Wenn du dann VoIP entsprechend taggst, wird anderer Traffic eingebremst, um eine niedrige VoIP-Latenz zu garantieren.

[The_Invisible]

Im eigenen Netz wirst wohl kaum Probleme haben. Wenn du trotzdem paranoid bist kannste natürlich eigene VLANs setzen und diese Pakete priorisieren, die dann via Trunking in der Firewall terminieren. Dann solltest aber auch eine gescheite Firewall haben die das Nadelöhr Internet richtig verwaltet. Am Besten eine gewissen Bandbreite für VOIP immer reservieren, je nachdem wieviele Gespräche gleichzeitig du am Laufen hast. Normale Homerouter sind da aber recht eingeschränkt, wenns billig sein soll ansonsten Mikrotik anschauen: http://routerboard.com/

Mit einer gescheiten Firewall könntest dann auch gleich 2 Internetzugänge verwalten. Haben wir selber in der Firma und bei zahlreichen Kunden so eingesetzt und gibt keine Probleme beim VOIP auch wenn einer mal das halbe Internet runtersaugen will. :D

[lumines]

Das mag bei billigen Routern so sein, wenn du dagegen ein Managed Switch hast, kann der heute auch IEEE P802.1p und damit Priorisierung des Traffics.

Das eine ersetzt ja nicht das andere. Ein Router macht eben L3 und ein Switch L2. Wenn das Nadelöhr die Internetleitung ist, dann kann man noch so viel QoS im LAN auf L2-Ebene machen, aber sobald es sich am Router staut, hat man davon nichts.

D.h. an das VLAN-Tag tackert der Switch auch noch eine Priorität und diese wird innerhalb des Netzes versucht einzuhalten. Wenn du dann VoIP entsprechend taggst, wird anderer Traffic eingebremst, um eine niedrige VoIP-Latenz zu garantieren.

Schon klar, aber das ist nicht das Problem des TEs. Er hat ja keine Stauungen am Switch.

Wobei das mit dem „Bremsen“ vielleicht etwas irreführend ist. Die Pakete werden je nach Priorität entsprechend gewichtet in einer Queue abgearbeitet. Wie die Queue das letztendlich handhabt (eher: wie sie Pakete droppt), kommt auf die Implementierung an. FIFO ist z.B. nicht besonders toll für die Latenz, wird aber oft benutzt. SFQ ist da schon besser. Dann gibt es noch RED, das theoretisch besser für die Latenz ist, aber wohl einige fundamentale Probleme hat und deshalb selten benutzt wird. State of the Art wäre dagegen fq_codel. Ich vermute allerdings ziemlich stark, dass die meisten Switches entweder irgendeine Form von SFQ oder FIFO machen. Das ist nicht besonders schlimm, weil vor allem aktuelle Implementierungen für SFQ aus dem Linux-Kernel gar nicht so übel sind, aber speziell auf Latenz sind die eben auch nicht optimiert.

Normale Homerouter sind da aber recht eingeschränkt, wenns billig sein soll ansonsten Mikrotik anschauen: http://routerboard.com/

Benutze ich auch im Moment (einen hAP lite), um den Upload bei einer Internetleitung zu shapen. Als Queue reicht dann schon SFQ ohne irgendwelche Klassen, um die Bandbreite fair zu verteilen und die Latenz halbwegs unter Last unten zu halten. Ist natürlich nicht optimal (fq_codel wird wohl mit RouterOS v7 kommen), aber definitiv tausendmal besser als nix. QoS könnte man natürlich auch noch machen, aber wenn man schon Fair Queueing hat (z.B. eben SFQ ohne Klassen), ist das gerade im Heimbetrieb oft gar nicht nötig.

Um nicht ganz OT zu sein: Wenn man wirklich QoS haben will, würde ich mit dem Switch den VoIP-Traffic entsprechend taggen und dann irgendwo am Router in das L3-QoS entsprechend gewichtet miteinfließen lassen. Nie gemacht, aber ich glaube, dass das so die Richtige Lösung™ sein sollte.

[Kinehs]

Fang ich mal mit ner einfachen Frage an: Kann ich das ganze QoS, Trafficshaping meines HP 1810G-24 ProCurve Switch im Webinterface machen oder programmiere ich im Shell? Ich habe bei einigen Guides lauter ipconfig o.ä. Befehle gesehen.

[lumines]

Wenn die Befehle auf deinen Switch passen, kannst du das wohl ziemlich einfach per CLI machen: http://www.ingentive.net/sites/default/files/anwenderdokumente/hp_procurve_befehlsuebersicht.pdf

Der Switch macht übrigens kein Traffic Shaping. Das will man innerhalb des LANs auch nicht, sondern irgendwo in der Nähe vom Router.