Firewall / QoS Settings laut LANCOM KB - keine Verbindung

[Chaosphere64]

Hallo zusammen,

ich habe bei meinem LANCOM 1781VA die Konfiguration von Firewall / QoS laut neuem KB Eintrag zur Optimierung von VoIP vorgenommen. Ergebnis: Es wird keine Verbindung mehr aufgebaut oder aber über eine aufgebaute Verbindung wird nichts mehr übertragen. Die Bandbreitenreservierung für SIP macht wohl kein Problem, die QoS Settings für RTP muss ich aber deaktivieren um wieder telefonieren zu können. Firmware: LCOS 9.0.4 RU3.

Hat jemand eine Idee woran das liegen könnte?

Besten Dank vorab

[Chaosphere64]

Hallo zusammen,

da ich leider bisher keinerlei Feedback erhalten habe, wollte ich noch einmal kurz nachhaken. In dem erwähnte KB-Artikel steht ja zu Beginn, dass die Änderungen auf beiden Seiten der Verbindung einzurichten seien. Sollten diese Einstellungen denn nicht auch eine Qualitätsverbesserung bei VoIP-Telefonie bewirken, wenn man über einen LANCOM Router "ganz normal" eine VoIP-Verbindung über einen ISP wie die DTAG nutzt?

Meine Konfiguration sieht aus wie folgt: Der LANCOM 1781-VA hängt an einem All-IP-Anschluss der DTAG (VDSL 25). Im LAN arbeitet eine FRITZ!Box als Telefonanlage für DECT und VoIP-Geräte. Sie versieht VoIP Traffic mit DiffServ EF (dazu ist ein Eingriff per Telnet nötig, das funktioniert laut Wireshark aber wie gewünscht). Am LANCOM ist bisher nur eingestellt, dass er als IP-Router das DiffServ-Feld beachtet, ein weitergehendes QoS ist nicht eingerichtet. Leider ist die Verbindungsqualität manchmal ziemlich schlecht, daher wollte ich durch die QoS Maßnahmen des KB-Artikels die Qualität verbessern. Leider führt das zu dem erwähnten Effekt. Zwischen Router und Telefonanlage liegen Switches, die DiffServ EF Traffic in die Queue 4 (höchste Priorität) stecken, auch das klappt wie gewünscht.

Hat jemand einen Tipp?

[backslash]

Hi Chaosphere64,

was soll man dazu sagen... Wenn du es wirklich so eingerichtet hast, wie im KB-Dokument, dann wird es auch funktionieren...
Und sowas wie "keine Verbindung" tritt dabei sicherlich auch nicht zutage, da die Regeln, ja keine "Reject"-Aktion enthalten, sondern nur Mindestbandbreiten resevieren.
Das deutet also alles darauf hin, daß du es eben nicht se eingerichtet hast, wie im KB-Dokument....

BTW: bei einem DSL25-Anschluß kannst du dir die PMTU-Reduzierung und Zwangsfragmentierung eigentlich sparen

Gruß
Backslash

[Dr.Einstein]

Hallo Chaosphere64,

du brauchst wirklich bei einem VDSL25 QoS? Normalerweise flutscht ein VoIP Gespräch mit max 100 Kbit/s doch immer durch.

Wenn du eine normale QoS Regel anlegst, kann das erstmal keinen Einfluss auf die normale Funktion habe. Außer du nutzt sowas wie eine Deny All Regel oder besitzt weitere Default Routen mit anderen Tags und hast dadurch mit deiner QoS Regel etwas verbogen.

Gruß Dr.Einstein

[Chaosphere64]

Danke für die Hinweise! Ich habe jetzt erst einmal nur die Mindestbandbreiten-Reservierung für SIP und RTP laut KB-Artikel gemacht und bisher keine Probleme festgestellt. Mal schauen ob das anhält. Vielleicht jage ich ja auch ein Gespenst, und der Fehler liegt nicht im LAN sondern bei der DTAG.

[marci]

Hallo Chaos,

wollte mal kurz nachfragen, ob das bei Dir funktioniert hat?

Ich bin neu mit Lancom Routern, und versuche auch gerade meine Fritzbox 7390 hinter einem 1781A mit LCOS 9.04 als Telekom SIP / DECT Telefonanlage zu nutzen...

Hab hier mal was dazu geschrieben.. kann aber auch sein das ich komplett falsch liege

https://telekomhilft.telekom.de/t5/V-DS ... 658#M87714

Auf Lancom bin ich eigentlich nur gekommen, weil mich die Smart Certificate Funktion ab LCOS 9.10 interessiert (Aber das ist nochmals eine ganz andere Sache)
http://www.lancom-systems.de/fileadmin/ ... pdf#page=5

VG Marc

[Chaosphere64]

Hallo Marci,

ich habe dieses Setup mehr oder minder erfolgreich am Laufen, ja. Es treten bisweilen Probleme mit der VoIP-Tonqualität auf, die ich bisher nicht lösen konnte. Ich kann aber nicht sagen, woher die kommen. Soweit ich das überblicke, habe ich im LAN alles Notwendige getan, um optimale Bedingungen für VoIP-Traffic zu haben (extrem kurze Latenzzeiten, QoS auf Router und Switches etc.).

Anders als Du habe ich aber keinerlei Portforwarding eingerichtet und brauche das auch nicht. Der Thread hier diente lediglich dazu um den Router möglichst optimal für VoIP Traffic zu konfigurieren.

Gruß

[marci]

Dank Dir für die Info. Ich hatte es mittlerweile irgendwie hinbekommen, ohne Port forwarding aktiviert zu lassen. Jenachdem wie man die Fritzbox hinter den Lancom hängt, gibt es auch in der Fritzbox unterschiedliche Optionen wie mit den VOIP Settings umgegangen wird. Die beste Lösung hat sch ergeben, wenn die Fritzbox als IP-Client in das vorhandene Netz eingebunden wird. dann wird die interne firewall weitgehend deaktiviert, die Fritzbox holt sich je nach konfig per dhcp das standard gateway und mann muss nur noch einmalig die folgene Option in der Fritzbox runterstellen:

Aktivieren Sie die Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten".

Quelle:
http://avm.de/nc/service/fritzbox/fritz ... efonieren/

Ich hatte auch noch ein paar andere Sachen ausprobiert, machbar ist viel, frage ist nur wie sinnig das ist. Ich hatte das gleiche Szenario mal mit einen Cisco 886VA ausprobiert, da waren die Symptome wieder anders.. Wie auch immer, muss mir wohl was anderes mit meinen IP PBXen ausdenken
Dank Dir nochmals

[Chaosphere64]

Hallo marci,

die FB läuft bei mir im IP-Client-Modus hinter dem LANCOM und bezieht alle Netzwerkeinstellungen von diesem per DHCP. Als VoIP-Telefone habe ich Cisco IP Phone 7970 im Einsatz. Die Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" der FB habe ich auch aktiviert. Das klingt für mich nach UPnP und wäre somit beim LANCOM sinnlos aber bitte.

Zusätzlich habe ich noch per Telnet Änderungen an der voip.cfg vorgenommen.

Code: Alles auswählen

sip_prio = 26;
rtp_prio = 46;
rtcp_prio = 46;

Grund dieser Änderung: Bisher hat die FB ausgehende RTP-Pakete Richtung VoIP-Telefon AF12 (Decimal 12, ToS Hex 0x30) getagt, Richtung Router gar nicht. In der Vergangenheit gab es mal die Option "Sprachpakete kennzeichnen" (Type of Service) mit der man so etwas machen konnte, aber die finde ich in meinem Modell nicht mehr.

Mittels Wireshark habe ich festgestellt, dass die FB nun RTP in Richtung WAN korrekt mit DSCP 46 (EF) tagt. In Richtung VoIP Telefon im LAN schickt sie allerdings weiterhin DSCP 48 (CoS Class 6 Selector). Das landet in der Standard Konfiguration der meisten Switches nicht in der höchsten Queue. In dem bei mir an der FB verwendeten Cisco SG-300 etwa landet das in Queue 3 statt 4.

Das finde ich erstaunlich, um so mehr, als dass die FB von beiden Teilnehmern (VoIP Telefon im LAN und Gegenstelle im Internet) korrekt mit DSCP 46 (EF) getagte Pakete erhält.

Am LANCOM habe ich unter "IP-Router" die Option "DiffServ-Feld beachten" aktiviert und hoffe, dass dies ausreicht um Pakete auch wirklich zu priorisieren. Da wäre ich für einen Hinweis dankbar, falls das nicht so ist bzw. nicht ausreicht.

Insgesamt bin ich mit der VoIP Sprachqualität nicht zufrieden. Ob die FB der Grund ist und man mit einer dedizierten VoIP TA bessere Ergebnisse erzielt vermag ich noch nicht zu sagen.

VG

[backslash]

Hi Chaosphere64,

Code: Alles auswählen

sip_prio = 26;
rtp_prio = 46;
rtcp_prio = 46;

RTCP solltest du tunlichst nicht euf EF setzen, denn sonst reserviert dir das LANCOM bei jedem Telefonat die doppelte Bandbreite - und das wo über RTCP quasi keine Daten laufen...

Insgesamt bin ich mit der VoIP Sprachqualität nicht zufrieden.

also wenn du dich an das KB-Dokument gehalten hast, sollte die Sprachqualität top sein - ohne stottern und Aussetzer, selbst bei parallelem Up- und Dpownload, die die Leitung komplett dicht machen - zumindest solange der DSL-Sync dem entspricht, was auch wirklich über die Leitung geht.

Gruß
Backslash

[marsbewohner]

Hi zusammen,

in Bezug auf den verlinkten KB Artikel, wie ist denn der Hinweis

Info: Die hier beschriebenen Firewall-Regeln müssen Sie auf beiden Seiten der VoIP-Verbindung konfigurieren.

zu verstehen? Bei einem Site-to-Site VPN und entsprechendem Traffic darüber erschließt sich das ja, aber bei den ganzen Hosted/Cloud Angeboten muss ich die Gegenseite ja so nehmen wie sie kommt...?

Danke & Gruß,

[backslash]

Hi marsbewohner,

das bezieht sich auch nur auf Site-To-Size-VPNs...

Es bringt nichts, wenn auf einer Seite priorisiert wird und auf der anderen nicht... Durch eine "einseitige" Priorisierung wird zwar der Traffic durch den VPN-Tunnel shön geregelt - auch auf der "unpriorisierten" Seite. Dort kann aber der normale Internet-Traffic den Traffic durch den Tunnel "überfahren"....

Bei Verwendung eines Cloud-Anbieters kannst du davon ausgehen, daß dieser doch deutlich breitbandiger angeschlossen ist, als du selbst - wodurch dein eigener Internetzugang zur Engstelle wird und auch nur dort eine Priorisierung nötig ist...

Gruß
Backslash

[marsbewohner]

Danke, so dachte ich mir das schon

Gruß,

[Chaosphere64]

Hi Chaosphere64,

Code: Alles auswählen

sip_prio = 26;
rtp_prio = 46;
rtcp_prio = 46;

RTCP solltest du tunlichst nicht euf EF setzen, denn sonst reserviert dir das LANCOM bei jedem Telefonat die doppelte Bandbreite - und das wo über RTCP quasi keine Daten laufen...

Danke für den Hinweis! Ich habe jetzt die Werte auf angeblich standardkonforme DSCP Codepoints für VoIP gesetzt und RTCP ohne Priorisierung gelassen.

Code: Alles auswählen

sip_prio = 40;
rtp_prio = 46;
rtcp_prio = 0;

Mal schauen was das bringt.

[marci]

Hi Chaos,

hast Du an Deinem Setting seit LCOS 9.04 nochmals etwas geändert? (oder hast Du das neue LCOS 9.10 eingespielt? das evtl. damit besser umgehen kann?)

(Ich frage nur, weil es wieder Winter wird und ich dann in meiner Bastelkammer wieder versuche das Zeugs zusammenzustöpseln)
(Fritz ?<->? 1741AW)

VG
Marci