Hallo zusammen,
ich habe ein Problem mit der L54g Bandbreitenbegrenzung unter QoS für VoIP. Zuerst meine Systembeschreibung:
- Mein gesamtes Netzwerk ist über WLAN an das Internet angeschlossen. Zur Anbindung betreibe ich hierzu einen L54g im Client Mode über WLAN1 (mein Provider hat den WLAN AP an den ich mich per WLAN Client anbinde. Er bietet mir 500kBit/s downstream und 150kBit/s upstream).
- Die LAN Schnittstelle wird im isoliertem Modus betrieben und ist mit meinem internen Switch verbunden (Routing/Firewall ist an und funktionieren).
- An diesem internen Switch hängt neben diversen PCs auch ein ATA (HT486) für VoIP. Das NAT und der DHCP Server des ATAs wurde deaktiviert - für diese Funktionen soll der L54g zuständig sein.
- Für das Bandbreitenmanagement wurde weiterhin unter Interfaces für den WAN Anschluß das DSLoL Interface aktiviert, auf Modus exclusiv gesetzt und unter Downstream 500kBit, unter Upstream 150kBit und unter externer Overhead 0 eingetragen. Das ganze wurde an WLAN-1 gebunden, VLAN ist 0
- Unter IP Router ist das Feld "Type of Service berücksichtigen" selektiert. Der Grandstream ATA hat als Standard Layer 3 QoS = 48 eingetragen.
In der Firewall verfolge ich eine DENY_ALL Strategie. Zur besseren Übersicht und um dem weiter unten beschriebenen Problem auf die Spur zu kommen, habe ich für den Betrieb des ATAs je vier Regeln für Transmit (OUT) und für Receive (IN) aufgestellt:
ALLOW_VOIP_OUT_RTP (beschreibt Pakete vom ATA zum Internet, entspricht Transmit)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 5004-5009
ALLOW_VOIP_OUT_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 8000-8005
ALLOW_VOIP_OUT_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Ziel-Ports 10000-10001
ALLOW_VOIP_OUT_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: TCP, UDP, Ziel-Ports 5060-5065
ALLOW_VOIP_IN_RTP (beschreibt Pakete vom Internet zum ATA, entspricht Receive)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s, Stationen: von allen nach ATA MAC, Dienste: UDP, Ziel-Ports 5004-5009
ALLOW_VOIP_IN_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen anch ATA MAC, Dienste: UDP, Ziel-Ports 8000-8005
ALLOW_VOIP_IN_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: UDP, Quell-Ports 10000-10001
ALLOW_VOIP_IN_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: TCP, UDP, Ziel-Ports 5060-5065
Der Betrieb des ATAs funktioniert, jedoch ist die Sprache schon unter schwacher Netzwerkbelastung zum Internet hin leicht gestört (leichte Knackser). Zur Kontrolle, ob OoS funktioniert, habe ich im LANmonitor das QoS Feld beobachtet: Unter Upstream ist 150kBit und unter Downstream ist 500kBit eingetragen. Sobald der ATA einen Verbindungsaufbau startet wird die PMTU auf 512 gesetzt und nach Abbruch wieder freigegeben. Die Bandbreitenreservierung lautet für die ersten 20 Sekunden (UDP timeout) auf RX=180kBit, Tx=0kBit und nach den 20 Sekunden auf RX=90kBit, Tx=0kBit. Nach Abbruch der Verbindung ist wieder alles auf Rx=0, Tx=0.
Allem Anschein nach reserviert der L54g keine Bandbreite für den ausgehenden Pfad dafür aber die doppelte Anzahl für den eingehenden Verkehr. Warum?
Könnte mir hier bitte jemand helfen? Ich habe bereits mehrere Konstellationen getestet und immer wird nur der RX Pfad reserviert, der TX Pfad jedoch nie. Bin momentan relativ ratlos.
Vielen Dank
Gruß
Jürgen
L54g, QoS mit VoIP, Bandbreitenreservierung doppelt auf Rx
Moderator: Lancom-Systems Moderatoren
Hallo,
diese Thematik scheint doch ein wenig komplexer zu sein. Anbei ein Trace der Firewall und des IP-Routers während eines VoIP Gespräches bei ausgeschaltetem STUN. 5004 = RTP, 5060 = SIP.
Das Interessante daran ist, das sowohl ausgehender Verkehr (LAN -> WLAN ELBRACHT) als auch eingehender Verkehr (WLAN ELBRACHT -> LAN) über die Route "IP-Router Rx" laufen. Damit wird auch klar, warum die zu erwartetende 90kBit/s Bandbreitenreservierung je Rx und Tx letztendlich auf 180kBit/s auf der Rx Route hinauslaufen.
Hat jemand Ideen, wie man den ausgehenden Verkehr über das "IP-Router Tx" Modul bekommt? Oder ist das ein SW-Bug?
Gruß
Jürgen
[/code]
diese Thematik scheint doch ein wenig komplexer zu sein. Anbei ein Trace der Firewall und des IP-Routers während eines VoIP Gespräches bei ausgeschaltetem STUN. 5004 = RTP, 5060 = SIP.
Das Interessante daran ist, das sowohl ausgehender Verkehr (LAN -> WLAN ELBRACHT) als auch eingehender Verkehr (WLAN ELBRACHT -> LAN) über die Route "IP-Router Rx" laufen. Damit wird auch klar, warum die zu erwartetende 90kBit/s Bandbreitenreservierung je Rx und Tx letztendlich auf 180kBit/s auf der Rx Route hinauslaufen.
Hat jemand Ideen, wie man den ausgehenden Verkehr über das "IP-Router Tx" Modul bekommt? Oder ist das ein SW-Bug?
Gruß
Jürgen
Code: Alles auswählen
[IP-Router] 2006/08/12 21:28:37,240
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 858, TOS: ----
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:37,260
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 367, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:37,370
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 873, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:37,380
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 530, TOS: ----
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:37,390
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
[Firewall] 2006/08/12 21:28:37,400
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 217.10.79.48, SrcIP: "My ext. IP Address", Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 59356
reduce PMTU on ELBRACHT to 512
[IP-Router] 2006/08/12 21:28:37,420
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:37,440
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
[Firewall] 2006/08/12 21:28:37,440
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Add Rx minimum of 90 kBit/s to ELBRACHT (result 90 kBit/s)
packet accepted
[IP-Router] 2006/08/12 21:28:37,440
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:37,460
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
:
:
:
:
[IP-Router] 2006/08/12 21:28:39,870
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:39,880
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:39,890
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:39,900
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
:
:
:
:
[IP-Router] 2006/08/12 21:28:40,740
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 518, TOS: ----
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:40,750
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:40,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 515, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Filter (limited)
[IP-Router] 2006/08/12 21:28:40,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 515, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Fragmentation needed => Discard
[IP-Router] 2006/08/12 21:28:41,740
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 518, TOS: ----
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/12 21:28:41,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 515, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Filter (limited)
[IP-Router] 2006/08/12 21:28:41,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 515, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:41,770
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 36, TOS: ----
Prot.: UDP (17), DstPort: 40897, SrcPort: 5005
Route: WAN Tx Peer: ELBRACHT
[Firewall] 2006/08/12 21:28:41,790
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 64, TOS: D---
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 36, TOS: ----
Prot.: UDP (17), DstPort: 40897, SrcPort: 5005
Add Rx minimum of 90 kBit/s to ELBRACHT (result 180 kBit/s)
packet accepted
[IP-Router] 2006/08/12 21:28:41,790
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 64, TOS: D---
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 36, TOS: ----
Prot.: UDP (17), DstPort: 40897, SrcPort: 5005
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:42,960
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 32, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Filter (limited)
[IP-Router] 2006/08/12 21:28:42,960
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 32, TOS: D---
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN Tx
[Firewall] 2006/08/12 21:28:59,790
remove Rx minimum of 90 kBit/s from ELBRACHT (result 90 kBit/s)
[Firewall] 2006/08/12 21:29:01,790
remove Rx minimum of 90 kBit/s from ELBRACHT (result 0 kBit/s)
[Firewall] 2006/08/12 21:29:01,790
restore PMTU on ELBRACHT
Hi Juergen
Das Problem ist, daß dein ATA irgendwann RTCP-Pakete verschickt und daher aufgrund deiner Regel (aller UDP-Traffic reserviert Bandbreite) erneut Bandbreite reserviert wird:
zuerst für die RTP-Session (Port 5004 -> 40896) - beachte dabei, daß die Reservierung immer erst beim Empfang der "Antwort" erfolgt:
und estwas später das RTCP-Paket (Port 5005 -> 40897):
gewöhne deinem ATA entweder ab, RTCP-Pakete zu verschicken, oder zumindest die RTP-Pakete mit dem DiffServ-Codepoint EF zu taggen - dann kannst du nämlich auch die Bandbreitenreservierung nur für EF-getaggte Pakete vornehmen.
Es ist also kein Bug der Firmware - die macht genau, was sie soll...
Gruß
Backslash
Das Problem ist, daß dein ATA irgendwann RTCP-Pakete verschickt und daher aufgrund deiner Regel (aller UDP-Traffic reserviert Bandbreite) erneut Bandbreite reserviert wird:
zuerst für die RTP-Session (Port 5004 -> 40896) - beachte dabei, daß die Reservierung immer erst beim Empfang der "Antwort" erfolgt:
Code: Alles auswählen
[Firewall] 2006/08/12 21:28:37,440
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Add Rx minimum of 90 kBit/s to ELBRACHT (result 90 kBit/s)
packet accepted Code: Alles auswählen
[IP-Router] 2006/08/12 21:28:41,770
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 36, TOS: ----
Prot.: UDP (17), DstPort: 40897, SrcPort: 5005
Route: WAN Tx Peer: ELBRACHT
[Firewall] 2006/08/12 21:28:41,790
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 64, TOS: D---
Prot.: ICMP (1), port unreachable
embedded IP header:
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 36, TOS: ----
Prot.: UDP (17), DstPort: 40897, SrcPort: 5005
Add Rx minimum of 90 kBit/s to ELBRACHT (result 180 kBit/s)
packet accepted Es ist also kein Bug der Firmware - die macht genau, was sie soll...
Gruß
Backslash
Hi Backslash,
vielen Dank für den Tipp - manchmal sieht man den Wald vor lauter Bäumen nicht. Ich weiß nun, wo ich weitermachen kann, und mein 2x Rx Problem ist gelöst.
Bleibt nur noch, daß ich keine Bandbreitenreservierung auf dem Tx Pfad erhalte. Sowohl eingehender als auch ausgehender Verkehr wird über die Route IP-Router Rx gesendet. Somit kann ich wohl nur Rx Bandbreite resevieren, da der Tx Pfad nie aufgerufen wird.
:
[IP-Router] 2006/08/12 21:28:37,440
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:37,460
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
:
Anmerkung 1: Systemaufbau: Internet - WLAN AP (ELBRACHT) -- L54g (Client) - Switch - ATA
Anmerkung 2: Konfiguration: L54g als Client im isolierten Mode mit DSLoL Exklusiv an WLAN-1 gebunden, LAN an den Switch
Mache ich etwas falsch?
Gibt es hier einen Ansatz?
Viele Grüße
Jürgen
vielen Dank für den Tipp - manchmal sieht man den Wald vor lauter Bäumen nicht. Ich weiß nun, wo ich weitermachen kann, und mein 2x Rx Problem ist gelöst.
Bleibt nur noch, daß ich keine Bandbreitenreservierung auf dem Tx Pfad erhalte. Sowohl eingehender als auch ausgehender Verkehr wird über die Route IP-Router Rx gesendet. Somit kann ich wohl nur Rx Bandbreite resevieren, da der Tx Pfad nie aufgerufen wird.
:
[IP-Router] 2006/08/12 21:28:37,440
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.48, Len: 200, TOS: D---
Prot.: UDP (17), DstPort: 5004, SrcPort: 40896
Route: LAN Tx
[IP-Router] 2006/08/12 21:28:37,460
IP-Router Rx (LAN):
DstIP: 217.10.79.48, SrcIP: 192.168.100.248, Len: 200, TOS: ----
Prot.: UDP (17), DstPort: 40896, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
:
Anmerkung 1: Systemaufbau: Internet - WLAN AP (ELBRACHT) -- L54g (Client) - Switch - ATA
Anmerkung 2: Konfiguration: L54g als Client im isolierten Mode mit DSLoL Exklusiv an WLAN-1 gebunden, LAN an den Switch
Mache ich etwas falsch?
Gibt es hier einen Ansatz?
Viele Grüße
Jürgen
Hallo,
die Bandbreitenreservierung in Senderichting ist volldynamisch und wird erst aktiv, wenn aktter sonstiger Traffic die Gesamtbandbreite in Anspurch nimmt. Du kannst du Bandbreite aber auch erzwingen, dass wird sie aber immer fest reserviert und steht keiner anderen Anwedung zur Verfügrung. Dazu einfach den Haken erzwungen in der Aktion der QoS regel setzen.
die Bandbreitenreservierung in Senderichting ist volldynamisch und wird erst aktiv, wenn aktter sonstiger Traffic die Gesamtbandbreite in Anspurch nimmt. Du kannst du Bandbreite aber auch erzwingen, dass wird sie aber immer fest reserviert und steht keiner anderen Anwedung zur Verfügrung. Dazu einfach den Haken erzwungen in der Aktion der QoS regel setzen.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Hallo ittk,
vielen Dank für den Tipp mir der volldynamischen Bandbreitenreservierung in Senderichting, die erst aktiv wird, wenn sonstiger Traffic die Gesamtbandbreite in Anspurch nimmt - das kann man aus dem Referenzhanbuch nicht herauslesen. Mit diesem Wissen konnte ich das beschriebene Verhalten nachvollziehen. Dank Eurer Hilfe habe ich jetzt das mit den Ports, Bandbreiten und PMTUs für VoIP soweit im Griff, und das Ergebnis hört sich schon ganz passabel an.
Mein nächstes Thema wird dann das Einschalten von DiffServe "EF" an einem Grandstream HT486 sein - dessen Menüeinträge für QoS / DiffServe sind etwas unverständlich gehalten (freue mich über Infos, falls hier jemand weiß, was hier sinnvollerweise einzutragen ist):
- Layer 3 QoS:48 (Diff-Serv or Precedence value)
- Layer 2 QoS (VoIP): 802.1Q/VLAN Tag:0, 802.1p priority value (0-7):0
- Layer 2 QoS (PC): 802.1Q/VLAN Tag:0, 802.1p priority value (0-7):0
Nochmals Danke für Eure Hilfe.
Gruß
Jürgen
vielen Dank für den Tipp mir der volldynamischen Bandbreitenreservierung in Senderichting, die erst aktiv wird, wenn sonstiger Traffic die Gesamtbandbreite in Anspurch nimmt - das kann man aus dem Referenzhanbuch nicht herauslesen. Mit diesem Wissen konnte ich das beschriebene Verhalten nachvollziehen. Dank Eurer Hilfe habe ich jetzt das mit den Ports, Bandbreiten und PMTUs für VoIP soweit im Griff, und das Ergebnis hört sich schon ganz passabel an.
Mein nächstes Thema wird dann das Einschalten von DiffServe "EF" an einem Grandstream HT486 sein - dessen Menüeinträge für QoS / DiffServe sind etwas unverständlich gehalten (freue mich über Infos, falls hier jemand weiß, was hier sinnvollerweise einzutragen ist):
- Layer 3 QoS:48 (Diff-Serv or Precedence value)
- Layer 2 QoS (VoIP): 802.1Q/VLAN Tag:0, 802.1p priority value (0-7):0
- Layer 2 QoS (PC): 802.1Q/VLAN Tag:0, 802.1p priority value (0-7):0
Nochmals Danke für Eure Hilfe.
Gruß
Jürgen
Hallo Backslash,
vielen Dank für den "EF" Hinweis - die Knackser im VoIP sind weg.
Beim Routing und bei der Bandbreitenreservierung ist immer noch der Wurm drin - an irgendetwas verschluckt sich die Firewallabfrage.
Kurze Zusammenfassung meiner modifizierten Regeln:
ALLOW_VOIP_OUT_RTP (beschreibt Pakete vom ATA zum Internet, entspricht Transmit)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s erzwungen + global, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 5004
ALLOW_VOIP_IN_RTP (beschreibt Pakete vom Internet zum ATA, entspricht Receive)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s erzwungen + global, Stationen: von allen nach ATA MAC, Dienste: UDP, Ziel-Ports 5004
ALLOW_VOIP_OUT_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 5005
ALLOW_VOIP_IN_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: UDP, Ziel-Ports 5005
ALLOW_VOIP_OUT_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: TCP, UDP, Quell-Ports 5060
ALLOW_VOIP_IN_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: TCP, UDP, Ziel-Ports 5060
ALLOW_VOIP_OUT_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Ziel-Ports 10000-10001
ALLOW_VOIP_IN_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: UDP, Quell-Ports 10000-10001
Nach dem ersten SIP/STUN Verkehr erfolgen RTP Packete, wobei die Firewall jeweils für Tx und Rx 90kBit Bandbreite reserviert alleine aufgrund der Regel ALLOW_VOIP_OUT_RTP! Das ist mir völlig unerklärlich.
Ein paar Pakete später erfolgt eine weitere Resevierung für Rx auf 180kBit/s, diesmal richtigerweise aufgrund der ALLOW_VOIP_IN_RTP Regel (Anmerkung: Resevierung war lediglich erzwungen + global). Danach erfolgen Konflikte mit der Tx Resevierung.
Danach stabilisiert sich der L54g auf 90/90 kBit mit PMTU=512 und der normale RTP Verkehr wird abgewickelt. Der Verbindungsabbau läuft ebenfalls sauber ab und Rx/Tx/PMTU wird wieder freigegeben.
Habe ich noch irgendwo einen Dreher eingebaut?
Wieso spricht die Firewall für Rx Bandbreitenreservierung sowohl auf die IN als auch auf die OUT Regel an?
Gruß
Jürgen
PS: Die RTP Packete kommen allem Anschein nach mit DiffServ=AF22 vom VoIP Provider Sipgate herein - ist es sinnvoll, in der ALLOW_VOIP_IN_RTP Firewall Regel die Packete unter Aktionen mit "Markieren mit DiffServ_CP = EF" zu kennzeichnen? Würde das die Packete in meinem Switch Linksys LRW224 (hat QoS Queues + VLAN Fähigkeiten) priorisiert weiterleiten?
vielen Dank für den "EF" Hinweis - die Knackser im VoIP sind weg.
Beim Routing und bei der Bandbreitenreservierung ist immer noch der Wurm drin - an irgendetwas verschluckt sich die Firewallabfrage.
Kurze Zusammenfassung meiner modifizierten Regeln:
ALLOW_VOIP_OUT_RTP (beschreibt Pakete vom ATA zum Internet, entspricht Transmit)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s erzwungen + global, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 5004
ALLOW_VOIP_IN_RTP (beschreibt Pakete vom Internet zum ATA, entspricht Receive)
Priorität: 2, Regel aktiv und hält Zustände nach, Übertragen, PMTU 512, Bandbreite 90kBit/s erzwungen + global, Stationen: von allen nach ATA MAC, Dienste: UDP, Ziel-Ports 5004
ALLOW_VOIP_OUT_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Quell-Ports 5005
ALLOW_VOIP_IN_RTCP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: UDP, Ziel-Ports 5005
ALLOW_VOIP_OUT_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: TCP, UDP, Quell-Ports 5060
ALLOW_VOIP_IN_SIP
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: TCP, UDP, Ziel-Ports 5060
ALLOW_VOIP_OUT_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von ATA MAC nach allen, Dienste: UDP, Ziel-Ports 10000-10001
ALLOW_VOIP_IN_STUN
Priorität: 1, Regel aktiv und hält Zustände nach, Übertragen, Stationen: von allen nach ATA MAC, Dienste: UDP, Quell-Ports 10000-10001
Nach dem ersten SIP/STUN Verkehr erfolgen RTP Packete, wobei die Firewall jeweils für Tx und Rx 90kBit Bandbreite reserviert alleine aufgrund der Regel ALLOW_VOIP_OUT_RTP! Das ist mir völlig unerklärlich.
Code: Alles auswählen
[IP-Router] 2006/08/14 19:31:56,200
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 32, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/14 19:31:56,450
IP-Router Rx (LAN):
DstIP: 217.10.79.2, SrcIP: 192.168.100.248, Len: 48, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 10000, SrcPort: 1000
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/14 19:31:56,460
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.2, Len: 84, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 1000, SrcPort: 10000
Route: LAN Tx
[Firewall] 2006/08/14 19:31:59,970
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 217.10.79.2, SrcIP: 192.168.100.248, Len: 48, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 10000, SrcPort: 5004
Add Tx minimum of 90 kBit/s to ELBRACHT (result 90 kBit/s)
packet accepted
[IP-Router] 2006/08/14 19:31:59,970
IP-Router Rx (LAN):
DstIP: 217.10.79.2, SrcIP: 192.168.100.248, Len: 48, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 10000, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
[Firewall] 2006/08/14 19:31:59,990
Packet matched rule ALLOW_VOIP_OUT_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.2, Len: 84, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 10000
Add Rx minimum of 90 kBit/s to ELBRACHT (result 90 kBit/s)
packet accepted
[IP-Router] 2006/08/14 19:31:59,990
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.2, Len: 84, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 10000
Route: LAN Tx
Code: Alles auswählen
[IP-Router] 2006/08/14 19:32:00,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.9, Len: 824, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN Tx
[Firewall] 2006/08/14 19:32:00,770
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
reduce PMTU on ELBRACHT to 512
packet accepted
[Firewall] 2006/08/14 19:32:00,770
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: unknown (62), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Add Rx minimum of 90 kBit/s to ELBRACHT (result 180 kBit/s)
packet accepted
[IP-Router] 2006/08/14 19:32:00,770
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Route: LAN Tx
[IP-Router] 2006/08/14 19:32:00,780
IP-Router Rx (LAN):
DstIP: 217.10.79.9, SrcIP: 192.168.100.248, Len: 748, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: WAN Tx Peer: ELBRACHT
[IP-Router] 2006/08/14 19:32:00,780
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Route: LAN Tx
[Firewall] 2006/08/14 19:32:00,800
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Reservation of Tx minimum of 90 kBit/s to ELBRACHT failed
packet rejectedremove Rx minimum of 90 kBit/s from ELBRACHT (result 90 kBit/s)
[IP-Router] 2006/08/14 19:32:00,800
IP-Router Rx (LAN):
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Filter (Port)
[Firewall] 2006/08/14 19:32:00,810
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: unknown (62), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Add Rx minimum of 90 kBit/s to ELBRACHT (result 180 kBit/s)
packet accepted
[IP-Router] 2006/08/14 19:32:00,810
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Route: LAN Tx
[Firewall] 2006/08/14 19:32:00,820
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Reservation of Tx minimum of 90 kBit/s to ELBRACHT failed
packet rejectedremove Rx minimum of 90 kBit/s from ELBRACHT (result 90 kBit/s)
[IP-Router] 2006/08/14 19:32:00,820
IP-Router Rx (LAN):
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Filter (Port)
[Firewall] 2006/08/14 19:32:00,820
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: unknown (62), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Add Rx minimum of 90 kBit/s to ELBRACHT (result 180 kBit/s)
packet accepted
[IP-Router] 2006/08/14 19:32:00,820
IP-Router Rx (ELBRACHT):
DstIP: 192.168.100.248, SrcIP: 217.10.79.30, Len: 200, DSCP: AF22 (20), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5004, SrcPort: 13438
Route: LAN Tx
[Firewall] 2006/08/14 19:32:00,840
Packet matched rule ALLOW_VOIP_IN_RTP
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Reservation of Tx minimum of 90 kBit/s to ELBRACHT failed
packet rejectedremove Rx minimum of 90 kBit/s from ELBRACHT (result 90 kBit/s)
[IP-Router] 2006/08/14 19:32:00,840
IP-Router Rx (LAN):
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Filter (Port)
[IP-Router] 2006/08/14 19:32:00,860
IP-Router Rx (LAN):
DstIP: 217.10.79.30, SrcIP: 192.168.100.248, Len: 200, DSCP: EF (46), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 13438, SrcPort: 5004
Route: WAN Tx Peer: ELBRACHT
Habe ich noch irgendwo einen Dreher eingebaut?
Wieso spricht die Firewall für Rx Bandbreitenreservierung sowohl auf die IN als auch auf die OUT Regel an?
Gruß
Jürgen
PS: Die RTP Packete kommen allem Anschein nach mit DiffServ=AF22 vom VoIP Provider Sipgate herein - ist es sinnvoll, in der ALLOW_VOIP_IN_RTP Firewall Regel die Packete unter Aktionen mit "Markieren mit DiffServ_CP = EF" zu kennzeichnen? Würde das die Packete in meinem Switch Linksys LRW224 (hat QoS Queues + VLAN Fähigkeiten) priorisiert weiterleiten?
Hi Juergen
Des weiteren ist die Firewall im LANCOM eine Stateful-inspection Firewall und kein einfacher Portfilter. Sobald das erste STUN-Paket "abgeht" matcht es auf die ALLOW_VOIP_OUT_RTP Regel und öffnet damit eine Session, die auch für die "ankommenden" Pakete (STUN-Antwort) gilt. Daher gibt es auch die Rx-Reservierung aufgrund der ALLOW_VOIP_OUT_RTP Regel.
Es ist also alles in Ordnung - und nur ein Verständnisfehler deinerseits...
Sette einfach die Priorität der STUN-Regel hoch, so daß sie über der ALLOW_VOIP_OUT_RTP liegt.
Ach ja: Die Regel für einkommende STUN-Pakete kannst du dir sparen (Stichwort Stateful Inspection, s.o.)
Gruß
Backslash
Das liegt daren, daß due die STUN-Regel mit einer niedrigeren Priorität belegt hast als die ALLOW_VOIP_OUT_RTP Regel. Daher matcht die ALLOW_VOIP_OUT_RTP Regel auch auf die STUN-Anfragen...Nach dem ersten SIP/STUN Verkehr erfolgen RTP Packete, wobei die Firewall jeweils für Tx und Rx 90kBit Bandbreite reserviert alleine aufgrund der Regel ALLOW_VOIP_OUT_RTP! Das ist mir völlig unerklärlich.
Des weiteren ist die Firewall im LANCOM eine Stateful-inspection Firewall und kein einfacher Portfilter. Sobald das erste STUN-Paket "abgeht" matcht es auf die ALLOW_VOIP_OUT_RTP Regel und öffnet damit eine Session, die auch für die "ankommenden" Pakete (STUN-Antwort) gilt. Daher gibt es auch die Rx-Reservierung aufgrund der ALLOW_VOIP_OUT_RTP Regel.
Hier ist nun auch die RTP-Session geöffnet worden (siehe die Ports 5004 -> 13438, statt vorher 5004 -> 10000 für STUN). Das sind nun wieder UDP-Daten die zu einer erneuten Bandbreitenreservierung führenEin paar Pakete später erfolgt eine weitere Resevierung für Rx auf 180kBit/s, diesmal richtigerweise aufgrund der ALLOW_VOIP_IN_RTP Regel (Anmerkung: Resevierung war lediglich erzwungen + global).
Wenn du mehr reservierst (180 kBit), als dein upsteram (150 kBit) hergibt, dann lehnt das LANCOM die Reservierung ab, wenn das Häkchen bei "erzwungen" gesetzt ist.Danach erfolgen Konflikte mit der Tx Resevierung
Es ist also alles in Ordnung - und nur ein Verständnisfehler deinerseits...
Sette einfach die Priorität der STUN-Regel hoch, so daß sie über der ALLOW_VOIP_OUT_RTP liegt.
Ach ja: Die Regel für einkommende STUN-Pakete kannst du dir sparen (Stichwort Stateful Inspection, s.o.)
Gruß
Backslash
Danke, Danke, Danke,
es funktioniert wie gewünscht. Die OUT_STUN Regel auf Priorität 3 zu setzen - darauf wäre ich nie gekommen. Wenn man es so erklärt bekommt, ist die Sache eigentlich klar.
Ich hoffe, daß andere Forenteilnehmer, die sich ebenfalls mit dieser Thematik beschäftigen, von meinen "VoIP-Geburtswehen" profitieren können. Nochmals vielen Dank für Eure Geduld mit meinen Fragen.
Gruß
Jürgen
PS: Jetzt werde ich mit Sipgate den Kontakt suchen, um zu klären, warum deren RTP Packete mit DiffServ=AF22 versendet werden. Das erscheint mir für VoIP Daten nicht schlüssig.
es funktioniert wie gewünscht. Die OUT_STUN Regel auf Priorität 3 zu setzen - darauf wäre ich nie gekommen. Wenn man es so erklärt bekommt, ist die Sache eigentlich klar.
Ich hoffe, daß andere Forenteilnehmer, die sich ebenfalls mit dieser Thematik beschäftigen, von meinen "VoIP-Geburtswehen" profitieren können. Nochmals vielen Dank für Eure Geduld mit meinen Fragen.
Gruß
Jürgen
PS: Jetzt werde ich mit Sipgate den Kontakt suchen, um zu klären, warum deren RTP Packete mit DiffServ=AF22 versendet werden. Das erscheint mir für VoIP Daten nicht schlüssig.