1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

ako77
Beiträge: 66
Registriert: 23 Aug 2010, 19:13

1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von ako77 »

Hallo,

bin zum Thema QoS/VoIP auf folgende Seiten aufmerksam geworden:
https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument
http://www.johnlose.de/faq-items/qos-di ... qus_thread
M.M.n. sehr gute und verständliche Artikel - Danke dafür!!

Die kurze Version meines Verständnisproblems ist, dass beide Artikel ein miserables Ergebnis in meinem Setup ergeben und ich mich frage, woran das so alles liegen kann. Fehlendes Wissen in den tiefen dieser Materie ist natürlich ein Grund...
Nach durcharbeiten beider Artikel, wird bei mir keinerlei TX/RX-Bandbreite (LanMonitor) reserviert und wenn ich telefoniere und mit einem Speedtest die Leitung ans Limit bringe, ist TX-seitig von meinem Snom 370 zum Handy (also währned des Uploadtests beim Speedtest) nichts mehr zu verstehen.

Ich habe die Regeln entsprechend der Howtos adaptiert, mit ACCEPT_CS5 (signaling_tos!: 160, im Snom eingetragen), Fragmentierung, PMTU-Reduzierung und Bandbreitengarantie:
lc-voip01.png
Egal, ob Bandbreitengarantie pro Session, pro Station, erzwungen oder nicht - keine Reservierung der Bandbreite...

Was aber funktioniert:
Kaum Jittern, sowie die Bandbreitenreservierung funktionieren lediglich, wenn ich den "DiffServ-Kram" weglasse und die Bandbreite pro Station reserviere:
lc-voip03.png
lc-voip04.png
Ok, jetzt könnte ich das einfach so belassen, da ich ja telefonieren kann und es annehmbare Qualität ist. Aber den Grund über dieses Verhalten in meinem Setup würde mich interessieren, weiß aber nicht, wo ich wirklich anfangen soll zu suchen.

FYI:
Ich nutze das interne Modem des LCs, an einem ADSL2+-Anschluß und verfüge über mehrere VLANs (das VLAN-Modul im LC ist aktiv).
Ansonsten kein sonderlich besonderes Setup...

Vllt. können wir uns hier austauschen?!? Danke... :M
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

ako77 hat geschrieben:Die kurze Version meines Verständnisproblems ist, dass beide Artikel ein miserables Ergebnis in meinem Setup ergeben und ich mich frage, woran das so alles liegen kann. Fehlendes Wissen in den tiefen dieser Materie ist natürlich ein Grund...
Nach durcharbeiten beider Artikel, wird bei mir keinerlei TX/RX-Bandbreite (LanMonitor) reserviert und wenn ich telefoniere und mit einem Speedtest die Leitung ans Limit bringe, ist TX-seitig von meinem Snom 370 zum Handy (also währned des Uploadtests beim Speedtest) nichts mehr zu verstehen.
Beide Artikel sind nicht mehr ganz 'up to date' und es wäre dringend einmal notwendig, daß ein umfassendes Dokument zum Thema erstellt wird.

Hier ein paar Anhaltspunkte:

a) Ganz wichtig: Aktuelle Firmware einsetzen !

b) Je nach "Temperament" der Telephonanlage macht sie kein 'direct media setup', sondern fungiert als Relay. Das kann sehr sinnvoll sein, denn es gibt viele gute Gründe, gerade bei SNOM, diese nicht nach außen zu exponieren und daher in ein lokales Netz zu sperren. Würde die Telephonanlage jetzt, qua 'reinvite', Telephon und Gegenstelle miteinander direkt verbinden, wäre das Gesräch verloren.
Also neigen Telephonanlagen dazu, nur den Payload durchzureichen und die Pakete selbst neu zu erzeugen. Dann kannst Du an den SNOM einstellen, was Du willst.

c) Deshalb könntest Du in erster Näherung allen UDP-Traffic von und zur TK-Anlage entsprechend der Anleitung 'shapen'.

d) Die Angelegenheit mit der Fragmentierung kann nach hinten losgehen.

e) Unter Umständen wird das ganze Traffic Shaping ausgehebelt, indem Dein Provider dem LANCOM signalisiert, was er liefern *könnte*, aber nicht, was für einen Durchsatz Du gebucht hast. Der Lancom "sieht", "hach, ich bin ja längst nicht am Limit" und unternimmt nix, aber in Wirklichkeit bist Du längst an der Grenze dessen, was das Shaping auf Seiten des Providers zuläßt.
Dr.Einstein
Beiträge: 2922
Registriert: 12 Jan 2010, 14:10

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Dr.Einstein »

Hi ako77,

die Filter auf Basis des DSCP's funktionieren mit aktuellen und auch mit älteren LCOS Versionen auf jeden Fall, zumindest das im Monitor die Reservierung vernünftig angezeigt wird. Ich würde dir empfehlen, ein Telefongespräch zu führen, und dann für 1..2 Sekunden im Lancom Router den IP-Router Trace zu starten. Hier solltest du eine hohe Anzahl von UDP Pakete zwischen einer Quelle und einem Ziel sehen. In jedem Paket siehst du den jeweiligen DSCP Wert. Vielleicht hast du dich einfach vertan? CS5 ist sehr ungewöhnlich für Sprachpakete, eher EF. Schau einfach mal live nach. Du hast auch was geschrieben von Signalisierungs-DSCP, die sind für die reine Sprachqualität nicht von Bedeutung, denen kannst du vielleicht 5 kbit/s global verpassen.

Und wie Koppelfeld geschrieben hat, lass die Fragmentierung raus, das macht im Normalfall mehr Schaden, als das es nutzt.

(Trace erstellst du via Putty/SSH -> trace # ip-router oder über LanTracer, aufrufbar über Rechtsklick aufs Gerät -> Traceausgabe erstellen)

Gruß Dr.Einstein
ako77
Beiträge: 66
Registriert: 23 Aug 2010, 19:13

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von ako77 »

Hallo Ihr Zwei,

ich habe hier mal ein Trace-Beispiel:

Code: Alles auswählen

[IP-Router] 2016/08/14 03:21:13,617  Devicetime: 2016/08/14 03:21:15,957
IP-Router Rx (INTERNET, RtgTag: 0): 
DstIP: 192.168.30.5, SrcIP: 62.144.211.104, Len: 200, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 7108, SrcPort: 33176
Route: LAN-3 Tx (VOIP): 

[IP-Router] 2016/08/14 03:21:13,617  Devicetime: 2016/08/14 03:21:15,962
IP-Router Rx (LAN-3, VOIP, RtgTag: 0): 
DstIP: 62.144.211.104, SrcIP: 192.168.30.5, Len: 200, DSCP/TOS: 0x04
Prot.: UDP (17), DstPort: 33176, SrcPort: 7108
Route: WAN Tx (INTERNET)
Ist das richtig? Zwei unterschiedliche Werte? 0x00 und 0x04?

Wie ich auf DiffServ CS5 kam? Es ist so eingetragen im Snom und laut einer dieser Tabellen steht der Wert 160 angeblich für CS5.

@Koppelfeld: eine Telefonanlage ist bei mir nicht dazwischen. Das hätte ich vllt. erwähnen sollen :?
Das mit der Fragmentierung habe ich dann korrekterweise wieder entfernt. Ging absolut nicht...

Zu e) ist das nicht anhand der QoS-Daten abzuleiten, die ich im LanMonitor sehe und/oder an den Werten unter Schnittstellen VDSL-Modem?


Danke für Eure Beiträge!
Dr.Einstein
Beiträge: 2922
Registriert: 12 Jan 2010, 14:10

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Dr.Einstein »

Hi ako77,

also die DSCP Werte in deinem Trace sehen doch echt merkwürdig aus. Da steht in Senderichtung 0x04, also Hexidezimal DSCP (Jirka wird mich bestimmt wieder töten, dass ich das mal wieder verwechsel ;) ) den Wert 4. Für den Wert 4 gibt es keine DSCP Bezeichnung, müsste also manuell in der Firewall als Dezimalwert 4 hinterlegt werden. Auch so ist der wert 4 sehr sehr niedrig, das passt nicht. Schaue mal in dein Snom, du solltest da neben deinem Signaling 160 noch einen weiteren Wert haben wie RTP, oder Sprache, irgendsowas. Diesen dann auf Dezimal 184 stellen (= TOS für EF).

Ansonsten die Empfangsrichtung liegt an deinem Provider. Kann am Telefonieprovider liegen, dass dieser keine DSCP Werte für seinen Traffic schickt (ungewöhnlich aber möglich) oder dein Internetprovider die DSCP Werte auf 0 / BE verändert. Wenn ich jetzt zum Beispiel meinen All IP Anschluss Telekom betrachte, empfange ich providerseitig für Voice EF, somit greifen die Lancom QoS Regel auch ankommend basierend auf EF.

Gruß Dr.Einstein
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Jirka »

Hallo,

QoS ist kein Thema, was man in einer Stunde lernen kann. Wenn man jemanden hat, der einem das erklären kann, dann braucht's schon mehrere Stunden, wenn nicht, dann sogar mehrere Tage...
ako77 hat geschrieben:Ist das richtig? Zwei unterschiedliche Werte? 0x00 und 0x04?
Dr. Einstein hat es schon gesagt: Dass von WAN-Seite her keine Markierung erfolgt, ist durchaus normal. Hier muss man allerdings unterscheiden, und das hat er auch geschrieben, ob die z. B. VoIP-RTP-Pakete vom Provider kommen (z. B. Telekom), wo man auch den Internetanschluss hat (im Beispiel Telekom), oder von einem anderen (VoIP-)Provider (z. B. sipgate). Wo je nach Provider und QoS-Verfahren die eigenen Pakete noch markiert sind, wird diese Markierung für fremde Pakete sogar absichtlich gelöscht.
Soweit die Theorie. Nun zur Praxis (obwohl ich nicht weiß, welche Provider hier verwendet werden).
Dieser Wert, also die 0x00, stimmt so nicht. Ich bin mir zwar nicht ganz sicher, aber mir scheint, dass das ein Bug ist. Egal wie man es dreht und wendet, ob als DSCP, ToS oder DiffServ betrachtet, 0x00 dürfte da meiner Ansicht nach nicht stehen. Denn das zeigt der LANCOM z. B. auch bei EF-getaggten Paketen an. Letztlich habe ich mich damit aber nicht so intensiv beschäftigt, da ich von ToS sowieso nicht viel halte und bei mir alle Router seit Anbruch der VoIP-Zeiten im Routing auf DSCP gestellt sind, was bei Dir nicht der Fall ist (Fehler). Folgender Wert gehört also grundsätzlich auf DiffServ (2):

Code: Alles auswählen

set set/ip-rout/rou/routin ?

Possible Entries:
- Routing-Method           :Normal (0), Type-of-service (1), DiffServ (2)
Du findest den Parameter auch in LANconfig: Konfiguration -> IP-Router -> Allgemein -> DiffServ-Feld beachten.
Der Parameter ist seit kurzem auch bei LANCOM defaultmäßig auf diesem Wert, früher war das nicht der Fall. Entweder Du bist mit einer alten Firmware eingestiegen in Deine Konfig, oder Du hast Deine Konfig aus Altbeständen so importiert.
Wenn Du das geändert hast, sollten hier auch sinnvolle Werte stehen, einfach nochmal tracen.
ako77 hat geschrieben:Wie ich auf DiffServ CS5 kam? Es ist so eingetragen im Snom und laut einer dieser Tabellen steht der Wert 160 angeblich für CS5.
Also CS5 ist im snom der Default-Wert fürs DSCP des SIP, wie Dr. Einstein ebenfalls schon schrieb, nicht fürs RTP. Also nicht für die Sprachdaten, sondern für die Signalisierungsdaten. Während bei den Sprachdaten ein Konsens herscht, sind bei den Signalisierungsdaten je nach Hersteller/Provider unterschiedliche Werte anzutreffen.
Ach ja, hier mal meine DSCP-Tabelle: http://www.lancom-forum.de/voip-pakete- ... tml#p50952
ako77 hat geschrieben:@Koppelfeld: eine Telefonanlage ist bei mir nicht dazwischen. Das hätte ich vllt. erwähnen sollen :?
Na ein wenig Beschreibung tut immer ganz gut, damit man sich überhaupt ein Bild der Lage machen kann, was hier überhaupt gewollt ist. Es gibt ja auch noch das SIP-ALG und den VCM, mit denen man das QoS-Problem auch erschlagen kann. Wobei das SIP-ALG mir im NAT-Fall immer sehr unsympatisch ist und ich es daher nicht einsetze, beim normalen Routing, z. B. über VPN, nehme ich es schon eher, der kontinuierliche leichte Speicherverlust ist nach mehreren, monatelangen Korrekturen nun auch endlich gefixt.
ako77 hat geschrieben:Das mit der Fragmentierung habe ich dann korrekterweise wieder entfernt. Ging absolut nicht...
Fragmentierung ist sinnvoll, wenn man Internetzugänge mit geringer Uploadrate (oder Downloadrate, aber die Downloadrate liegt meist höher) hat.
Bei einem 512 kbit/s großem Upload beträgt die Serialisierungszeit, das ist die Zeit, die benötigt wird ein Paket auf die Leitung "zu legen", für ein 1514 Byte großes Datenpaket 23,66 ms. Bei 256 kbit/s sind es dann schon 47,31 ms. Während dieser Zeit muss ein Sprachpaket auf die Übertragung warten, d. h. es entsteht eine Verzögerung von heftigen 47 ms. Bis zur Datenrate von 768 kbit/s (von unten aus betrachtet; entspricht 15,77 ms) rate ich zur Fragmentierung - bzw. noch besser - zur Fragmentierung mit PMTU-Reduzierung.
ako77 hat geschrieben:Zu e) ist das nicht anhand der QoS-Daten abzuleiten, die ich im LanMonitor sehe und/oder an den Werten unter Schnittstellen VDSL-Modem?
Im Allgemeinen ja, aber Koppelfeld meinte hier neue Anschlüsse, an denen die vertraglich vereinbarten Datenraten nicht mit den DSL-Synchronisationsraten überein stimmmen, also niedriger sind, was ein sehr unschönes Problem darstellt, wofür es dann aber in der 9.24 eine Lösung geben soll.

Viele Grüße,
Jirka
ako77
Beiträge: 66
Registriert: 23 Aug 2010, 19:13

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von ako77 »

Moin!
Dr.Einstein hat geschrieben:also die DSCP Werte in deinem Trace sehen doch echt merkwürdig aus.
Die sehen leider immer noch merkwürdig aus, aber etwas anders:

Code: Alles auswählen

[IP-Router] 2016/08/14 14:19:57,044  Devicetime: 2016/08/14 14:20:01,261
IP-Router Rx (INTERNET, RtgTag: 0): 
DstIP: 192.168.30.5, SrcIP: 62.144.211.104, Len: 200, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 7086, SrcPort: 35130
Route: LAN-3 Tx (VOIP): 

[IP-Router] 2016/08/14 14:19:57,044  Devicetime: 2016/08/14 14:20:01,263
IP-Router Rx (LAN-3, VOIP, RtgTag: 0): 
DstIP: 62.144.211.104, SrcIP: 192.168.30.5, Len: 200, DSCP: unknown (0x01), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 35130, SrcPort: 7086
Route: WAN Tx (INTERNET)
Diese Einstellungen habe ich wie folgt vorgenommen:
lc-voip05.png
lc-voip06.png
Jirka hat geschrieben:Na ein wenig Beschreibung tut immer ganz gut, damit man sich überhaupt ein Bild der Lage machen kann
Mein ISP ist easybell und einen Sipgate-Account habe ich auch noch. Da sieht es im Trace genauso aus:

Code: Alles auswählen

[IP-Router] 2016/08/14 14:24:33,198  Devicetime: 2016/08/14 14:24:37,410
IP-Router Rx (INTERNET, RtgTag: 0): 
DstIP: 192.168.30.5, SrcIP: 217.10.77.245, Len: 200, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 7088, SrcPort: 29068
Route: LAN-3 Tx (VOIP): 

[IP-Router] 2016/08/14 14:24:33,200  Devicetime: 2016/08/14 14:24:37,430
IP-Router Rx (LAN-3, VOIP, RtgTag: 0): 
DstIP: 217.10.77.245, SrcIP: 192.168.30.5, Len: 200, DSCP: unknown (0x01), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 29068, SrcPort: 7088
Route: WAN Tx (INTERNET)
Bis auf vllt. einige VLANs ist mein Setup hier ziemlich "Standard" und nichts weiter Wildes. Dachte ich zumindest... Ein weiteres Telefon im Haus ist ein Gigaset C610A-IP, welches von Hause aus DSCP EF senden soll. Das werde ich mal tracen, aber primär geht es weiter um das Snom-Setup. LCOS Version ist 9.10.0426RU3 mit dieser Modem-Software 5.5 (ohne Vectoring), da ich sonst derbe Probleme mit Handshake und Co habe...
Jirka hat geschrieben:Fragmentierung ist sinnvoll, wenn man Internetzugänge mit geringer Uploadrate (oder Downloadrate, aber die Downloadrate liegt meist höher) hat.
Meine Uploadrate ist über 900kbit/s. Dann kommt
Bis zur Datenrate von 768 kbit/s (von unten aus betrachtet; entspricht 15,77 ms) rate ich zur Fragmentierung - bzw. noch besser - zur Fragmentierung mit PMTU-Reduzierung.
wohl nicht mehr in Frage!?
Dr.Einstein hat geschrieben:Ansonsten die Empfangsrichtung liegt an deinem Provider. Kann am Telefonieprovider liegen, dass dieser keine DSCP Werte für seinen Traffic schickt (ungewöhnlich aber möglich) oder dein Internetprovider die DSCP Werte auf 0 / BE verändert. Wenn ich jetzt zum Beispiel meinen All IP Anschluss Telekom betrachte, empfange ich providerseitig für Voice EF, somit greifen die Lancom QoS Regel auch ankommend basierend auf EF.
Den könnte ich mal ansprechen, was es damit auf sich hat!?

Nachtrag, Trace am C610A-IP:
[IP-Router] 2016/08/14 14:43:57,622 Devicetime: 2016/08/14 14:44:01,870
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.30.8, SrcIP: 62.144.211.104, Len: 200, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 30974, SrcPort: 38440
Route: LAN-3 Tx (VOIP):

[IP-Router] 2016/08/14 14:43:57,622 Devicetime: 2016/08/14 14:44:01,889
IP-Router Rx (LAN-3, VOIP, RtgTag: 0):
DstIP: 62.144.211.104, SrcIP: 192.168.30.8, Len: 200, DSCP: EF (0x2e), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 38440, SrcPort: 30974
Route: WAN Tx (INTERNET)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

Guten Abend,
um jetzt weiterzukommen, wäre es Zeit für eine Untersuchung mit 'wireshark'.

Bleibt die Frage, ob das für Dich zielführend ist.
Persönlich habe ich ja tiefstes Mißtrauen in "Snom" und "Gigaset", gefühlt überall, wo das Zeugs verbaut ist, gibt es ungelöste Probleme. Die Dinger machen einfach, was sie wollen.

Dein Problem ist ja die mangelnde Diskriminierung der zu priorisierenden Pakete. Dann mach' diese doch an anderen Kriterien fest. Intern, im LAN, ist QoS in 99,998% der Fälle nicht nur überflüssig, sondern schädlich. Also kann man das getrost ignorieren.

Im WAN kannst Du auch nur den Traffic kontrollieren, den Du selber verursachst. Sprich: Wenn Dich jemand mit UDP-Paketen zuscheißt, ist die Leitung dicht - Du kommst halt nicht an die andere Seite Deiner limitierten WAN-Strecke.


Also: Versuchst Du erstmal "QoS für Arme" und reservierst, für jede UDP-Verbindung vom und zum SIP-Provider, 110 KBit/s. Wenn es so klappt, dann bist Du erstmal ein gutes Stück weiter.

Dummerweise werden jetzt aber zu viele Verbindungen, beispielsweise SIP und RTCP, reserviert.

Wenn Du aber brauchbare Ergebnisse mit Test 1 erreichen konntest, dann gehe Schritt zwei: Opfere 60,-- und bestelle Dir die Voice-Callmanager - Option für Deinen Router. Dann registrierst Du den Easybell direkt auf dem VCM und hast auf einmal eine ganze Palette von Vorteilen:

a) kann der Provider jetzt endlich an eine öffentliche IP senden und kein Gespräch geht Dir verloren.
Das wird "Louis" wieder fürchterlich in Rage bringen, aber sei's drum: Als Kind habe ich mir beim Verstehen von Röhrenschaltbildern damit geholfen, mir vorzustellen, ich wäre der elektrische Strom, der, wie in einem Auto, durch die Leitungen fährt. Da mache ich übrigens heute bei unseren Industriesteuerungen genauso, bloß würde ich es den Auftraggebern nicht unter die Nase binden.
Dieses "kindliche" Verfahren funktioniert bei mir auch mit IP. Ich stelle mir halt vor, ich wäre eine Draisine auf einer Gleisanlage, und drauf steht "Ziel: IP/Port -- UDP/SIP INVITE". Nun lande ich als Indikator für ein kommendes Gespräch, sicher geleitet durch diverse Routing-Tabellen, auf Deinem LANCOM. Woher soll ich denn jetzt wissen, welche Deiner (vielleicht 200) Intranet-Adressen ich jetzt aufsuchen soll ? Denn der Router selbst ist es 'mal sicher nicht.
Die Lösung ist, daß sich Dein SNOM irgendwann 'mal beim Provider registriert hat. Nun hält der Router in einer NAT-Tabelle die Registrierung (also deren Port/IP-Paarung) fest und hat jetzt einen gewissen Anhaltspunkt, wohin das SIP INVITE - Paket zu leiten wäre.
Dumm nur: Das klappt nicht immer. Denn die NAT-Tabellen haben eine typische "Haltezeit", bei LANCOM sind das im Default 20 Sekunden. Die Abstände zwischen den Registrierungsversuche werden sowohl vom Provider als auch vom Telephon bestimmt und sind in der Regel länger.
Deswegen kommt es speziell bei einem bestimmten Massenprovider zu häufigen Fällen von Unerreichbarkeit, weil dieser mindestens 120 Sekunden Wartezeit zwischen den Registrierungen verlangt.
Aus ähnlichen Gründen klappt auch die ganze "Cloud-Technologie" nicht. Firma "Nfon" hat so ein schönes "Erklärbär-Video", wie toll doch so eine "Cloud-Lösung" ist, ich würde gern einmal mit einer guten Graphikerin so ein Video machen, warum der ganze "Cloud-Scheiß" sehr häufig in die Hose geht.
Nun könnte man auf die clevere Idee kommen, die NAT-Haltezeit zu verlängern. Gute Idee, aber tunlichst nicht umsetzen beispielsweise in einer Hartz 4 - WG. Denn deren bevorzugtes Transportmittel ist UDP, für die vielen Raubkopieen, die sie ziehen. Und irgendwann einmal ist die Tabelle voll und der Router wird undeterministisch. Also: Alles nicht vermutet, sondern erlebt. Ähnliches gilt für DNS-Abfragen, ein unterschätztes Problem: Immer mehr Spinner fordern "zeitgemäße" Seiten, und wenn Du zeitgemäß auf "Bild.de" klickst, triggerst Du 'mal eben ein paar hundert DNS-Abfragen.
Also: Scheiß - Idee. Es ist auch kein Kraut dagegen gewachsen.
Diverse Hersteller eiern herum, indem sie diverse conntrack-Module des Linux-Kernels verwenden oder eigene bauen.
Gemurkse wird aber nicht besser durch noch mehr Gemurkse.
Also: Drei Lösungen:
- IPv6 nehmen. Denn das ist dazu gemacht worden, um das NAPT endgültig zu beerdigen. Leider haben diverse Ausschisse das nicht verstanden und als erstes NAPT nachimplementiert.
Dumm nur, wenn man keines hat und keines kriegt.
- SIP ALG nehmen. Das gibt der ALG-Bezieher seiner Familie. Ernsthaft: Auch hier wird Komplexität mit Komplexität behoben und der arme, hier beheimatete 'cpuprofi' könnte nicht nur ein Lied, sondern eine ganze Oper -- ach was, den kompletten Nibelungenring davon singen.
- Voice Call Manager nehmen. Ist eine komplette Telephonanlage und kann als "Dediziertes ALG" betrieben werden.
Entscheidend ist, daß jetzt der Router beim Provider registriert und die gequirlte NAT-Scheiße nicht mehr stört.

b) "weiß" der Voice Call Manager, welche Pakete der Sprachübertragung dienen und welche der Signalisierung.
Entsprechend kann er das einstellen. Du kannst also sicher sein, daß kein "Beifang" existiert, der Dir unnütz Leitungskapazitäten bindet. Allein das ist schon die 60 Euro wert.

c) Kann man mit dem Voice Call Manager pro Provider Routing Tags vergeben und so bequem den Voice-Traffic auf ein dediziertes WAN-Interface geben. Dieses Feature wird im Anfang gern unterschätzt.

d) Du bist unabhängig von Deinem "Endgeräte-Streichelzoo"


Alles in allem:
60 Eier, die sich lohnen.
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

Koppelfeld hat geschrieben: Alles in allem:
60 Eier, die sich lohnen.
Ach ja: Ich poste hier nur Lösungen, die sich über einen längeren Zeitraum gut bewährt haben.
Und umgekehrt: Alle beschriebenen Probleme durfte ich am eigenen Leib erleben.
Dr.Einstein
Beiträge: 2922
Registriert: 12 Jan 2010, 14:10

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Dr.Einstein »

Hi,

also mit dem SNOM und DSCP Werte hinterlegen hatte ich bei noch keinem Modell Probleme :? Kann es vielleicht sein, dass dein VLAN Switch irgendetwas an diesem Port neben VLAN in Richtung QoS eingestellt hat? Switche können auch auf Layer2 / Layer3 das ToS Feld verändern.

Gruß Dr.Einstein
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

Dr.Einstein hat geschrieben: also mit dem SNOM und DSCP Werte hinterlegen hatte ich bei noch keinem Modell Probleme :? Kann es vielleicht sein, dass dein VLAN Switch irgendetwas an diesem Port neben VLAN in Richtung QoS eingestellt hat? Switche können auch auf Layer2 / Layer3 das ToS Feld verändern.
Guuuuuuuuut!
Stimmt, hatte ich auch schon, ist noch gar nicht so lange her. "Smart Switch", wertete eigentändig LLDP/CDP aus und wies sogar die VLANs eigenmächtig zu. "Linksys by Cisco".
Mit zop-zeitgemäßem Webinterface, voll animiert. Wir sind bekloppt geworden. Haben wir dann aber rituell weggeworfen und durch einen HP ersetzt.
Auch hier wieder ein schönes Beispiel, wie "Jusebility" mehr schadet als nützt.

Ich bleibe trotzdem dabei: VCM und gut ist
ako77
Beiträge: 66
Registriert: 23 Aug 2010, 19:13

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von ako77 »

Guten Abend,

ich bin schwer begeistert, dass sich da Leute wie Ihr soviel Zeit nehmen und so ausführlich einem erklären, welche Erfahrungen gemacht wurden oder welche Hintergründe es so gibt usw. Vielen Dank! Wenn es irgendwo einen "Donate-Button" gäbe, würde ich mich erkenntlich zeigen...

Die 60€-Lösung gefällt mir. Macht jetzt schon einen guten Eindruck auf mich, was Du schreibst, Koppelfeld.

VLAN erledigen hier, wie gesagt, das VLAN-Modul im LC und zwei HP ProCurves aus der 1800er Serie. Ich hoffe, dass ich sie nicht austauschen muss und annähernd richtig konfiguriert habe :-) Alternativ könnte ich an den LC auch einen alten Catalyst 3550 hängen.
Koppelfeld hat geschrieben:Persönlich habe ich ja tiefstes Mißtrauen in "Snom" und "Gigaset"
...welche Geräte sind denn Dir gesonnen? Ich meine, sehe ja jetzt selber, dass zumindest mal das Snom irgendwie macht, was es will, wenn die Traces nicht zu den eingestellten Werten passen!? Warum ist das nur so :-(

Ok, dann besorge ich mir mal den VCM...
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

ako77 hat geschrieben:ich bin schwer begeistert, dass sich da Leute wie Ihr soviel Zeit nehmen und so ausführlich einem erklären, welche Erfahrungen gemacht wurden oder welche Hintergründe es so gibt usw. Vielen Dank! Wenn es irgendwo einen "Donate-Button" gäbe, würde ich mich erkenntlich zeigen...
Ich glaube, den "Button" gibt es sogar. Meiner unzeitgemäßen Meinung nach ist viel wichtiger, daß Foren dieser Art eine sichtbare Manifestation der Erkenntnis sind, daß Wissen das einzige Gut ist, welches sich vermehrt, wenn man es teilt.
Ohne die Hinweise von Dr. Einstein, backslash, Jirka, cpuprofi, langewiesche, stefanbunzel und vielen anderen mehr hätte ich viele Dinge extrem aufwendig und höchstwahrscheinlich auch weniger "schön" hinbekommen.
Die von LANCOM gelieferten Anleitungen sind "zeitgemäß", also eine lästige Ansammlung von Screenshots. Es wird dort nicht ansatzweise erklärt, wie der Router funktioniert und was beispielsweise die LANCOM - DMZ von der "klassischen" unterscheidet. Das ist aber Hintergrundwissen, welches man auch schon in einem mäßig komplizierten Setup braucht, um nicht böse auf die Nase zu fallen.
So ein Forum klappt aber nur, wenn man nicht nur partizipiert, sondern die gewonnenen Erfahrungen auch zurückgibt.
Das ist eigentlich der USENET-Gedanke, der aber auf dem Altar der vermeintlichen "Innovation" geopfert wurde.[/quote]
VLAN erledigen hier, wie gesagt, das VLAN-Modul im LC
... welches im Normalfall abgeschaltet ist, wohl aus Performancegründen.
Dir ist bekannt, daß Du in "einfachen" Situationen, sprich, wenn ein- und dasselbe Netz nicht auf unterschiedlichen Ports auf unterschiedlichen VLANs herausgeführt werden muß, gar kein VLAN-Modul brauchst ?
und zwei HP ProCurves aus der 1800er Serie. Ich hoffe, dass ich sie nicht austauschen muss und annähernd richtig konfiguriert habe :-)
Das ist schon eher ein Problem, denn die 1800er sind in Wirklichkeit 3Com-Geräte (HP hat den Laden gekauft).
Davon hatten wir allein in diesem Jahr zwei kaputte. Sehr ärgerlich: Einer davon hat sich ab und zu komplett aufgehängt.
HP ist eigentlich unser Lieblings-Switchhersteller, ich empfehle gern guterhaltene gebrauchte. Bei HP gibt es auch für wirklich alte Geräte aktuelle Firmwares und vor allen Dingen das unübertroffen gute CLI.
Vor ein paar Tagen habe ich mir mit einem modernen "Goey" die Finger abgebrochen, wo bei HP ein einfaches "vlan 2 tagged 37-41" gereicht hätte. Dank des CLI kannst Du auch jederzeit und schnell mit 'write terminal' die komplette aktuelle Config übersehen -- ganz im Gegensatz zu den fiesen Tretminen, die irgendwer an irgendeiner Stelle des "Goey" versteckt hat. Und gerade, wo jetzt hier gefordert wurde, man müsse alles für Mobiltelephone optimieren:
Das HP-CLI kann man auch mit einem SSH-Client prima administrieren.
Einen gebrauchten 3500yl-48G bekommt man für kleines Geld, da ist dann schon PoE mit dabei.
Koppelfeld hat geschrieben:Persönlich habe ich ja tiefstes Mißtrauen in "Snom" und "Gigaset"
...welche Geräte sind denn Dir gesonnen? Ich meine, sehe ja jetzt selber, dass zumindest mal das Snom irgendwie macht, was es will, wenn die Traces nicht zu den eingestellten Werten passen!? Warum ist das nur so :-(
Weil SNOM ziemlich viel Blösinn mit dem "Branding" macht. Die packen auf bestimmte Serien spezielle Firmwares für spezielle Provider drauf, um ihre Kunden zu gängeln und zu fesseln. SNOM ist, wie AVM, eine Marketing-Maschen-Maschine mit angeschlossener Firmware-Abteilung.
Meiner unmaßgeblichen, innovationsfeindlichen und reaktionären Meinig nach sollte ein Telephon vor allen Dingen erstklassige Sprachqualität bieten. Dazu ist es nämlich da, was von den Innovationshengsten gern übersehen wird - die wollen nur spielen. Und IPhone-Integration.
Was Sprachqualität angeht, kommt es nicht nur darauf an, daß hochauflösende Codizes wie g.722 unterstützt werden, sondern vor allem auf die Qualität des Audioteiils. Und da ist schon ein Einsteigermodell von Polycom besser als das Flaggschiff von Snom. Gute Verständigung ist die Grundvoraussetzung für ein gutes Gesprächsklima.
Seit Jahren robust und unprätentiös kommen die Polycom SoundPoind 650 daher, das Design ist allerdings nicht sonderlich gelungen.
Auch mit erstklassiger Sprachqualität, aber schlechter Ergonomie (an die man sich freilich gewöhnen kann) kommen die Polycom VVX.
Sehr, sehr viel Telephon für's Geld, gute Ergonomie und ansprechendes, übersichtliches Aussehen bieten die Yealink T46G bei immer noch guter Sprachqualität.
Wichtig ist die Langzeitstabilität:
Während die Handapparate bei Snom nach kurzer Zeit einen häßlichen Speckglanz bekommen, bleiben die genannten Modelle über Jahre ansehnlich.
ako77
Beiträge: 66
Registriert: 23 Aug 2010, 19:13

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von ako77 »

Moin,
Koppelfeld hat geschrieben:Die von LANCOM gelieferten Anleitungen sind "zeitgemäß", also eine lästige Ansammlung von Screenshots. Es wird dort nicht ansatzweise erklärt, wie der Router funktioniert und was beispielsweise die LANCOM - DMZ von der "klassischen" unterscheidet. Das ist aber Hintergrundwissen, welches man auch schon in einem mäßig komplizierten Setup braucht, um nicht böse auf die Nase zu fallen.
Die haben sicherlich Interesse daran, zu den Workshops (€€) einzuladen. Ich habe damit jedenfalls schon geliebäugelt.
Koppelfeld hat geschrieben:Ich glaube, den "Button" gibt es sogar. Meiner unzeitgemäßen Meinung nach ist viel wichtiger, daß Foren dieser Art eine sichtbare Manifestation der Erkenntnis sind, daß Wissen das einzige Gut ist, welches sich vermehrt, wenn man es teilt.
Tolle Ansichten, meinen Respekt :M hast Du bzw. Ihr!
Koppelfeld hat geschrieben:Das ist schon eher ein Problem, denn die 1800er sind in Wirklichkeit 3Com-Geräte
Ich wusste es nicht, dass das 3COM-Geräte sind. Jedoch habe ich diese Switche bereits mehrere Jahre im Einsatz ohne einen Ausfall oder irgendwelcher Probleme (...). Das Kaufkriterium "lüfterlos" war da entscheidend, was der 3500er vmtl. nicht mitbringt. Meine Ciscos laufen z.B. auch nur zeitweise zu Testzwecken (trotz einer eingebauten Lüftersteuerung), da ich alle Geräte im Büro habe.
Hast Du Erfahrungen zu den 1920er von HP? Sind das "echte" ProCurve's?
Koppelfeld hat geschrieben:Dir ist bekannt, daß Du in "einfachen" Situationen, sprich, wenn ein- und dasselbe Netz nicht auf unterschiedlichen Ports auf unterschiedlichen VLANs herausgeführt werden muß, gar kein VLAN-Modul brauchst ?
Ja. Aktuell laufen 6 VLAN's über ETH1-3, wobei ETH2 und 3 jeweils nur für ein VLAN aktiv sind (PVID). Da mir der LC diese Option bietet, wollte ich sie natürlich mal einschalten und konfigurieren. Performanceeinbußen habe ich bisher nicht festgestellt.

Das Yealink T46G sieht mir recht sympathisch aus, aber schöner wäre es, die vorhandene Technik zum korrekten laufen zu bekommen. Ich kenne ein Setup mit Nfon und 20 SNOM 370 und es lief einwandfrei, wobei wir da beim Kunden eine dedizierte SDSL-Leitung hatten... Daraufhin habe ich mir auch das 370 geholt... nun ja...
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: 1781VA-4G - QoS/VoIP - Snom - Verständnisproblem

Beitrag von Koppelfeld »

ako77 hat geschrieben:Aktuell laufen 6 VLAN's über ETH1-3, wobei ETH2 und 3 jeweils nur für ein VLAN aktiv sind (PVID). Da mir der LC diese Option bietet, wollte ich sie natürlich mal einschalten und konfigurieren. Performanceeinbußen habe ich bisher nicht festgestellt.
Das ist dann ein Fall für das VLAN-Modul, d'accord.
Das Yealink T46G sieht mir recht sympathisch aus, aber schöner wäre es, die vorhandene Technik zum korrekten laufen zu bekommen. Ich kenne ein Setup mit Nfon und 20 SNOM 370 und es lief einwandfrei, wobei wir da beim Kunden eine dedizierte SDSL-Leitung hatten... Daraufhin habe ich mir auch das 370 geholt... nun ja...
Es kommt darauf an. In der Standardkonfiguration bei "Cloud-Anbietern" hast Du das häßliche Problem, daß auch Interngespräche, quasi von Schreibtisch zu Nachbarschreibtisch, über die WAN-Strecke gehen. Vor einiger Zeit hat sich Nfon einen Partner gesucht, der sein Geschäft versteht (Lancom...), ob das aber besser geworden ist, sei 'mal dahingestellt.

Durch die degenerativen "Innovationen" ibs. durch Microsoft bedingt besteht, auch in Unternehmen, eine weitverbreitete Toleranz, ja fast schon Akzeptanz von Abstürzen und Ausfällen. Das ist dann halt so. Und je mehr Probleme, desto mehr lieben die "Anwender" ihr Microsoft, das haben sie ja schließlich auch zuhause.
Aber beim Telephonieren ist das ganz anders. Es gibt einen todsicheren Tip, auch bei einer größeren Firma alle Abteilungsleiter und den Chef innerhalb einer Stunde persönlich kennenzulernen: Klemm' das Telephon ab. Da herrscht wirklich Nulltoleranz.
Nulltoleranz-TK und NAT schließen sich aber gegenseitig aus.

Bestimmt bekommst Du, zumal mit dem Voice Call Manager, Dein QoS - Problem gelöst - auch mit SNOM und den preisgünstigen Switches.

Wenn Du aber mehr als einen Apparat betreiben willst, von denen jeder professionell genutzt wird, empfehle ich:
- PoE - Switch (nicht HP19... -- scheußliches GUI, 3Com, kein CLI)
- Einheitliche Telephone
- Kleinen TFTP - Provisioning Server (für FW- und Config-Updates)
- VCM
Das spart doch einiges am Ärger.
Antworten