Lancom 1781VAW frisst UDP Pakete
Hallo Alle!
was sich im Betreff so einfach anhört ist ein Phänomen welches ich mir nicht erklären kann. Vielleicht habt ihr dazu eine Idee die mich weiter bringt oder sogar eine Lösung.
Ich habe hier folgende Konstellation:
Default Router ist Lancom 1781VAW (Firmware 10.12.0382RU9 / 12.06.2018) mit zwei Internetanschlüssen: Vodafone welches direkt über ADSL2+ und Unitymedia welches über Kabel angeschlossen ist und direkt mit einer öffentlichen IP auf dem Lancom Router terminiert. Der Lancom Router macht Loadbalancing über beide Anschlüsse. Hinter dem Lancom ist direkt das interne Netz angeschlossen.
Im internen Netz steht eine Mitel Office 400 Telefonanlage (IP 192.168.1.20) welche sich bei drei SIP Providern registrieren soll: Vodafone/Arcor, Unitymedia und DUSnet.
Damit die SIP Pakete auch auf das richtige WAN-IF geleitet werden gibt es drei default Routen mit Routing Tag im Lancom:
Und dazu die entsprechenden Firewallregeln, welche die Pakete mit dem richtigen Routing Tag Markieren (Bitte Kommentare beachten):
Die Telefonanlage sendet SIP Register auf UDP Port 5060 an den Provider. Dieser antwortet mit SIP Status 200 OK. Das Antwortpaket wird vom Router Empfangen, durch die Firewall geleitet.
Im Trace des Routers sieht das ungefähr so aus:
Man sieht daß das Paket auf der Gegenstelle INTERNET hereinkommt und über LAN-1 und damit auf ETH-1 geroutet werden soll.
Nun passiert sporadisch folgendes:
Die Telefonanlage sendet das REGISTER. Der Provider antwortet. Aber der Router leitet das Paket nicht weiter:
Der komplette Teil für das absetzen des Pakets auf dem Ethernet fehlt und das Paket wird auch nicht vom Router an das interne Gerät (die Telefonanlage) gesendet.
Dieses Phänomen tritt auf nach jeglicher Konfigurationsänderung (egal welche), vermutlich nach der Zwangstrennung des Providers und zu offenbar zufälligen Zeiten.
Ich habe ein Trace mit einem Portmirror zwischen Router und Telefonanlage gemacht und hier die Zeiten notiert wann der Router die Pakete nicht weiterleitete:
Hat jemand von euch eine Idee:
- was die Ursache für die fehlenden Pakete ist
- wie ich dem Router noch mehr debugging angewöhnen kann damit er ggf. ausspuckt warum er die Pakete nicht auf ETH-1 absetzt?
Vielen Dank für eure Hilfe!
was sich im Betreff so einfach anhört ist ein Phänomen welches ich mir nicht erklären kann. Vielleicht habt ihr dazu eine Idee die mich weiter bringt oder sogar eine Lösung.
Ich habe hier folgende Konstellation:
Default Router ist Lancom 1781VAW (Firmware 10.12.0382RU9 / 12.06.2018) mit zwei Internetanschlüssen: Vodafone welches direkt über ADSL2+ und Unitymedia welches über Kabel angeschlossen ist und direkt mit einer öffentlichen IP auf dem Lancom Router terminiert. Der Lancom Router macht Loadbalancing über beide Anschlüsse. Hinter dem Lancom ist direkt das interne Netz angeschlossen.
Im internen Netz steht eine Mitel Office 400 Telefonanlage (IP 192.168.1.20) welche sich bei drei SIP Providern registrieren soll: Vodafone/Arcor, Unitymedia und DUSnet.
Damit die SIP Pakete auch auf das richtige WAN-IF geleitet werden gibt es drei default Routen mit Routing Tag im Lancom:
Und dazu die entsprechenden Firewallregeln, welche die Pakete mit dem richtigen Routing Tag Markieren (Bitte Kommentare beachten):
Die Telefonanlage sendet SIP Register auf UDP Port 5060 an den Provider. Dieser antwortet mit SIP Status 200 OK. Das Antwortpaket wird vom Router Empfangen, durch die Firewall geleitet.
Im Trace des Routers sieht das ungefähr so aus:
[TraceStarted] 2018/10/29 10:54:08,836
Used config:
# Trace config
trace + IP-Router @ +UDP +"port: 5060"
trace + IPv4-LAN-Packet @ +UDP +"port: 5060"
trace + IPv4-WAN-Packet @ +UDP +"port: 5060"
trace + Ethernet @ -Telnet/SSL +"Dest Address : 192.168.1.20"
[IP-Router] 2018/10/29 10:54:17,308 Devicetime: 2018/10/29 10:54:19,338
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.20, SrcIP: 178.15.141.135, Len: 457, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN-1 Tx (INTRANET):
[Ethernet] 2018/10/29 10:54:17,308 Devicetime: 2018/10/29 10:54:19,338
Sent 471 byte Ethernet packet via LAN-1:
HW Switch Port : ETH-1
IPv4 Hdr Checksum : Dirty
-->IEEE 802.3 Header
Dest : 00:08:5d:97:80:c4
Source : 00:a0:57:2b:98:21 (LANCOM 2b:98:21)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
ToS/DSCP : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length : 457
ID : 0
Fragment : Offset 0
TTL : 124
Protocol : UDP
Checksum : 37324 (updated by hardware)
Src Address : 178.15.141.135
Dest Address : 192.168.1.20
-->UDP Header
Src Port : SIP
Dest Port : SIP
Length : 437
Checksum : 21713 (OK)
-->SIP Packet
Header : SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.20:5060;received=92.209.xxx.xxx;branch=z9hG4bK_AI2018Oct295418482022888636608162;rport=5060
To: <sip:0228xxxxxx@0228.sip.arcor.de>;tag=aprqpjpsms9cg1c23-vf2s1q0010shf
From: <sip:0228xxxxxx@0228.sip.arcor.de>;tag=AI105B31A278E0D6A9
Call-ID: AID1235EA4A9B0B516@192.168.1.20
CSeq: 127224 REGISTER
Contact: <sip:0228xxxxxx@192.168.1.20:5060;line=AIA930EC03C93CC010>;expires=30
Nun passiert sporadisch folgendes:
Die Telefonanlage sendet das REGISTER. Der Provider antwortet. Aber der Router leitet das Paket nicht weiter:
[TraceStarted] 2018/10/29 10:54:08,836
Used config:
# Trace config
trace + IP-Router @ +UDP +"port: 5060"
trace + IPv4-LAN-Packet @ +UDP +"port: 5060"
trace + IPv4-WAN-Packet @ +UDP +"port: 5060"
trace + Ethernet @ -Telnet/SSL +"Dest Address : 192.168.1.20"
[IP-Router] 2018/10/30 11:53:26,985 Devicetime: 2018/10/30 11:53:29,403
IP-Router Rx (INTERNET, RtgTag: 0):
DstIP: 192.168.1.20, SrcIP: 178.15.141.135, Len: 523, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: UDP (17), DstPort: 5060, SrcPort: 5060
Route: LAN-1 Tx (INTRANET):
Dieses Phänomen tritt auf nach jeglicher Konfigurationsänderung (egal welche), vermutlich nach der Zwangstrennung des Providers und zu offenbar zufälligen Zeiten.
Ich habe ein Trace mit einem Portmirror zwischen Router und Telefonanlage gemacht und hier die Zeiten notiert wann der Router die Pakete nicht weiterleitete:
29.10.2018
20:57-20:59
21:29-21:30
21:58-22:01
22:32-22:32
22:52-23:03
23:24-23:35
05:23-05:34
05:55-06:05
06:26-06:37
06:58-07:07
08:08-08:10
08:40-08:42
09:09-09:23
09:54-10:59
10:11-10:25
30.10.2018
11:50-12:01 (allerdings nach Konfig-Änderung)
Hat jemand von euch eine Idee:
- was die Ursache für die fehlenden Pakete ist
- wie ich dem Router noch mehr debugging angewöhnen kann damit er ggf. ausspuckt warum er die Pakete nicht auf ETH-1 absetzt?
Vielen Dank für eure Hilfe!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 391095
Url: https://administrator.de/contentid/391095
Ausgedruckt am: 14.11.2024 um 13:11 Uhr
8 Kommentare
Neuester Kommentar
Als erstes würde ich mal testweise das Load-Balancing raus werfen, nicht das das doppelte taggen zu der Situation führt das die Pakete über zwei Leitungen verteilt werden, das würde dann das Verwerfen der Pakete erklären.
Gruß l.
Gruß l.
Arbeitest du mit statischem Port-Forwarding für die RTP Pakete der VOIP Provider oder macht die Anlage für alle Provider STUN? Oder ist nur SIP selbst betroffen, nicht die Kommunikation?
Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Ich würde erst mal alle Provider nicht gleichzeitig sondern mal nacheinander hinzufügen abwarten und dann bei jedem Hinzufügen und Pause sehen ob die Fehler erneut auftreten. Nicht das die Zuordnung der SIP Pakete auf dem selben Port von unterschiedlichen Providern Probleme bereitet.
Ob der LANCom da noch irgendwelche SIP-Handling-Optionen bietet die da vielleicht in die Kommunikation rein spielen solltest du auch prüfen.
Wenn alles nichts hilft, LANCOM oder MitelSupport mal anfunken ob es da vielleicht in irgendeiner Kombination ein bekanntes Problem gibt.
Würde die Zuordnung nicht klappen würde das Paket schon eher verworfen werden. Oder?
Eigentlich Ja, kenne die LOG-Funktionsweise des Lancom jedoch nicht.
Danke für die Rückmeldung, das erklärt natürlich alles .