Jul 08, 2016

3784

Außenliegende Nebenstelle per VoIP - QoS im Internet

Hallo zusammen,

ich möchte für eine Kirchengemeinde eine außenliegende Nebenstelle in einem externen Pastorat einrichten. Konkret möchte ich ein COMfortel 1400 IP über einen VPN-Tunnel an eine Auerswald COMpact 5000 anschließen. Wie stelle ich sicher, dass mein VPN-Tunnel mit den VoIP-Daten im Internet ordentlich priorisiert wird. Denn ohne Priorisierung, das scheint hier ja einhellige Meinung zu sein, klappt VoIP nicht wirklich.

Danke im Voraus,
Sarek \\//_

Please also mark the comments that contributed to the solution of the article

Content-Key: 309292

Url: https://administrator.de/contentid/309292

Printed on: April 16, 2024 at 06:04 o'clock

20 Comments

Latest comment

Dem kann ich so nicht zustimmen. Wenn genug Bandbreite vorhanden ist und sonst so gut wie nichts über den Tunnel läuft, funktioniert das auch ohne QoS.

Gruß

Looser

Dem kann ich so nicht zustimmen. Wenn genug Bandbreite vorhanden ist und sonst so gut wie nichts über den Tunnel läuft, funktioniert das auch ohne QoS.

Über den Tunnel läuft außer dem VoIP eine RDP-Verbindung, sonst nichts.
Die Frage ist aber nicht nur, ob ich im Tunnel QoS brauche, sondern ob der Tunnel selbst im Internet priorisiert werden muss. Ich kann mir noch vorstellen, dass da ein einfaches FritzBox-VPN reicht ... oder doch?

Nur so zum Vergleich:

Wir fahren über eine DSL 16000 ein SSL-VPN mit bis zu 2 offenen RDP-Sitzungen und max. 2 Telefonate parallel. Es kam hier noch nie zu Abbrüchen oder Störungen ohne QoS. Allerdings setzen wir schon lange keine Fritzbox mehr ein.

Denn ohne Priorisierung, das scheint hier ja einhellige Meinung zu sein, klappt VoIP nicht wirklich.

Das ist Unsinn und kann man pauschal nicht so sagen. Ein Voice Call nutzt 64kBit/s das kann man heutzutage auch über "Bauern DSL" übertragen !
Wenn man einen anderen Codec nutzt kann man die Voice Datenrate sogar noch drücken.
Fakt ist aber auch: Keinerlei QoS über die Provider Verbindung !
Alle Provider strippen automatisch alle DSCP oder .1q Settings von allen Paketen ab die in ihr Netz gehen.
QoS im Providernetz musst du immer extra bezahlen und dann geht es auch nur bei dem Provider.
Liegt deine Nebenstelle bei Provider A und dein Netz bei Provider B wirds wieder nix.
Logischerweise strippen auch alle Provider jegliche QoS Settings von anderen Providern ab. Warum sollten sie auch fremde Kunden die nix bezahlen bevorzugen...?!

Zitat von @aqui:

Denn ohne Priorisierung, das scheint hier ja einhellige Meinung zu sein, klappt VoIP nicht wirklich.

Das ist Unsinn und kann man pauschal nicht so sagen. Ein Voice Call nutzt 64kBit/s das kann man heutzutage auch über "Bauern DSL" übertragen

Warum wird dann hier so viel Wert auf QoS und/oder vLAN im internen Netz gelegt? Da hatte ich ja mal einen Thread, und der Tenor war: Unbedingt priorisieren!

Alle Provider strippen automatisch alle DSCP oder .1q Settings von allen Paketen ab die in ihr Netz gehen.

Also ginge es letztlich sogar mit 'ner FritzBox?

Zitat von @Looser27:

Allerdings setzen wir schon lange keine Fritzbox mehr ein.

Wir auch nicht - aber vom Prinzip her würde es mich interessieren, ob es selbst damit ginge, weil hier ja immer so auf die FritzBoxen geschimpft wird.

Zitat von @SarekHL:

Zitat von @Looser27:

Allerdings setzen wir schon lange keine Fritzbox mehr ein.

Wir auch nicht - aber vom Prinzip her würde es mich interessieren, ob es selbst damit ginge, weil hier ja immer so auf die FritzBoxen geschimpft wird.

Klar geht das auch mit nem Fritzbox-VPN.

ABER: Du musst die SIP-Ports umbiegen, denn die Fritte nimmt für sich immer den UDP 5060. Von daher ist das nicht zu bevorzugen, weil fehleranfällig. Wenn Du also ne gescheite Lösung einsetzt, hast Du das Problem einfach nicht.

Wir haben das bei uns im internen Netz auch nicht priorisiert und es läuft trotzdem fehlerfrei, weil wir die zur Verfügung stehende Bandbreite bei weitem nicht ausnutzen können.

Es geht auch ohne QoS, aber es kann besonders bei größerer Bandbreitenverwendung zu Problem führen. Auf dem eigenen Anschluss kann man es über den Router realisieren, indem man dem Router einfach die Aufgabe gibt, regelnd einzugreifen (Bandbreitenreservierung, Priorisierungen, MTU-Optimierung). Leider ist der Rest des Weges nicht kontrollierbar. Besonders wenn beide beteiligten Anschlüsse von verschiedenen Providern kommen, ist es sehr kritisch, da die Übergabepunkte grundsätzlich überbucht sind. Wenn es hier also zum Stau kommt, gibt es Probleme. Innerhalb des gleichen Providernetzes ist dieses weniger zu erwarten.

QoS-Informationen müssen zwingend außen an den verschlüsselten VPN-Paketen hängen. Innerhalb des VPN-Pakets kann kein Router diese lesen, bis diese am Endpunkt angekommen sind und ausgepackt wurden.

Zitat von @tikayevent:

QoS-Informationen müssen zwingend außen an den verschlüsselten VPN-Paketen hängen. Innerhalb des VPN-Pakets kann kein Router diese lesen, bis diese am Endpunkt angekommen sind und ausgepackt wurden.

Das ist vermutlich vom Router abhängig? Gibt es einen Fachterminus für diese Option, dass man gezielt danach suchen kann?

Vergiss das gleich wieder und lese bitte was oben steht:
"Alle Provider strippen automatisch alle OoS Settings sei es DSCP oder .1q von allen Paketen ab die in ihr Netz gehen."
Das sagt doch das es sinnfrei ist danach zu suchen. Auch wenn du deine VPN Pakete mit DSCP priorisiert wird das sofort am Eingangsrouter des ISP egalisiert und auf 0 gesetzt.

Gibt es einen Fachterminus für diese Option

Ja. DSCP = Diff.Serv = Layer 3 QoS
802.1p = Layer 2 QoS

Zitat von @aqui:

Gibt es einen Fachterminus für diese Option

Ja. DSCP = Diff.Serv = Layer 3 QoS
802.1p = Layer 2 QoS

Ich meinte eher für das "QoS-Informationen müssen zwingend außen an den verschlüsselten VPN-Paketen hängen". Aber Du hast natürlich recht, wenn das egalisiert wird, ist der Terminus hinfällig.

Es gibt ja nur diese beiden QoS Mechanismen im Netzwerk Umfeld (wenn man jetzt mal von MPLS absieht)
Die Formulierung "von außen" ist etwas unglücklich gewählt.
Wäre man jetzt technisch spitzfinding würde man sagen damit kann nur 802.1p also L2 Priorisierung gemeint sein, denn das ist immer Teil des 802.1q Headers sprich also des VLAN Headers.
Wie man / Netzwerker weiss, liegt der VLAN Tag immer "ganz außen" am Paket

Eine .1p Priorisierung erzwingt also immer ein Tagging was VOR (außen) dem eigentlichen L2 Header (Mac) liegt.
Jeder Netzwerker weiss aber auch das Provider keinerlei tagged Frames annehmen wenn man mal von VDSL (IP-TV) etc. absieht.
Damit ist "von außen" und L2 Priorisierung / QoS mit 802.1p eigentlich schon sofort raus.
DSCP nutzt die ToS Bytes innerhalb des IP Headers, was natürlich sinniger ist.
Allerdings setzt auch die der Provider gnadenlos auf 0 sollten sie gesetzt sein. Du kannst das ganz einfach ausprobieren. Lass deinen Router outgoing Pakete testhalber auf DSCP ToS 56 (CS7) oder 40 (CS5, Video) setzen und schneide mit dem Wireshark diese Pakete am Ziel mit... da kommt nur noch 0 an

Zitat von @aqui:

Jeder Netzwerker weiss aber auch das Provider keinerlei tagged Frames annehmen wenn man mal von VDSL (IP-TV) etc. absieht.

Wer hat sich den Blödsinn denn einfallen lassen? Seit wann ist Fernsehen so wichtig, dass ausgerechnet da eine Priorisierung zugelassen wird? Da gibt es meines Erachtens deutlich wichtigere Anwendungen ...

Ha ha ha.... Man muss es ja nicht priorisieren

Aber du weisst ja wie der gemeine Fussballfan reagiert wenn er la Mannschaft mit Klötzchen auf dem Schirm sieht weil er parallel nackige Damen im Browser ansieht....
Außerdem können das auch Video Konferenz Systeme sein...sieh es mal so. TV ist in der Tat nicht alles...keine Frage. Es gibt ja immer den A Knopf !!!

In dem Sinne ein schönes Wochenende !!

Zitat von @aqui:

Außerdem können das auch Video Konferenz Systeme sein...sieh es mal so. TV ist in der Tat nicht alles...keinen Frage. Es gibt ja immer den A Knopf !!!

Klar gibt es den. Aber wenn IP-TV im Internet priorisiert wird, heißt das auch, dass andere Anwendungen benachteiligt werden. Da habe ich dann schon Verständnis für den damaligen Vorschlag der Telekom, das Anbieter solcher Inhalte zahlen sollen, wenn ihre Daten bevorzugt behandelt werden sollen. Denn letztlich muss ICH als Nicht-Fernseher den Netzausbau mitbezahlen, der erforderlich ist, damit IP-TV-Pakete schnell übertragen werden können.

IP-TV wird mitnichten "im Internet" priorisiert sondern logischerweise lediglich einzig und allein im Backbone des jeweiligen Providers der für seinen Kunden diesen Dienst anbietet.
Mal abgesehen davon das providerspezifische IP-TV Dienste auch niemals dieses Netzwerk verlassen.
Können sie technisch auch gar nicht, denn wie jeder weiss basieren diese Dienste ausnahmslos auf Multicast und Multicast wird bekanntlich im Internet nicht geroutet ! Binsenweisheit...
Nicht das du hier was falsch verstehst...?!

Zitat von @aqui:

Mal abgesehen davon das providerspezifische IP-TV Dienste auch niemals dieses Netzwerk verlassen. Können sie technisch auch gar nicht, denn wie jeder weiss basieren diese Dienste ausnahmslos auf Multicast ..

Nein, jeder weiß das sicher nicht. Das Thema IP-TV ist für mich so irrelevant, dass ich mich mit der Technik nie beschäftigt habe. Gibt es denn nur providerspezifische IP-TV-Dienste?

IP-TV wird mitnichten "im Internet" priorisiert sondern logischerweise lediglich einzig und allein im Backbone des jeweiligen Providers der für seinen Kunden diesen Dienst anbietet.

Das ist eine sehr philosophische Aussage. Meines Wissens gibt es keine verbindliche Aussage darüber, wo das Internet beginnt. Gehört der Backbone des Providers schon zum Internet oder nicht? Umgangssprachlich sicher, denn man wählt sich ja "ins Internet" sein. Und das "inter" kann man sowohl als "zwischen lokalen Netzwerken" als auch als "zwischen Provider-Netzen" definieren ...

Das Internet ist die Summe alle Provider Backbones oder sonstigen öffentlichen Backbones. Lokale Netze gehören per definitionem ganz sicher nicht dazu oder nur sehr bedingt. Jedenfalls das Ende des Internets ist ja hinreichend bekannt:
http://onlinewahn.de/ende.htm
Und ja Multicast basierte Streaming Angebote mit QoS Content sind immer providerspezifisch (z.B. Entertain, Telekom)

Zitat von @aqui:

Das Internet ist die Summe alle Provider Backbones oder sonstigen öffentlichen Backbones.

Ist die Frage, ob ein einzelner Backbone als Teil des Internets dann auch schon mit "das Internet" bezeichnet werden kann. Denn alle Backbones sind ja nie beteiligt, wenn ich Daten versende oder empfange. Insofern ist eine Teilmenge des Internets hier synonym für "im Internet"

Und ja Multicast basierte Streaming Angebote mit QoS Content sind immer providerspezifisch

OK, danke für den Exkurs. Aber ich denke, das sollten wir jetzt nicht vertiefen, da absolut OffTopic ...

st die Frage, ob ein einzelner Backbone als Teil des Internets dann auch schon mit "das Internet" bezeichnet werden kann.

Oha...jetzt wirds philosophisch und wahrlich off topic...
Wenn der Provider z.B. einen gerouteten Glasfaserring betreibt mit einem Router in Amerika, Europa, Afrika, Asien und Ozeanien würde man das sicher als Internet bezeichen.
Wenn die Router Wanne-Eickel, Greetsiel, Durlesbach und Posemuckel verbinden wäre es nur ein Internet wenn es im Universum sonst nix gibt.

German Question Voice over IP Networks