8
VoIP über Glasfaser - LWL - Singlemode - Astlinux
Hi zusammen,
ich habe aktuell folgendes Problem: zwei Gebäude sind per singlemode Glasfaser miteinander verbunden. Das ganze läuft über HP 1910 Switche mit spf Modulen.
Über die Verbindung sollen Internet sowie VoIP Telefonie betrieben werden.
Der Aufbau ist in etwa dieser:
Internetaccess/ISP<---->Router<---->Haus1--HP_Switch1<------[Glasfaser]----->HP_Switch2--Haus2<------>Endgeräte(Telefone, PCs, etc.)
Die Internetanbindung funktioniert ohne Probleme.
Bei der VoIP Anbindung sieht es leider etwas anders aus, ich habe zwei verschiedene Setups probiert.
1. Easybell Cloud Account: Telefone in Haus2 melden sich über das Internet direkt bei Easybell an. Hierbei kommen Gespräche zustande, allerdings sind die Gespräche sehr "zerstückelt" und/oder brechen ab.
2. Astlinux Anlage in Haus1 konfiguriert (wird in Haus1 auch schon genutzt, so soll es letztendlich auch aufgebaut sein): die Telefone aus Haus2 melden sich im LAN an der Astlinux Anlage an, die Telefonie läuft ebenfalls über Easybell, wird aber von der Anlage geregelt. Die Anmeldung der Telefone an der Anlage funktioniert und wird auch nicht getrennt.
Sobald ein Gespräch Aufgebaut wird, egal ob nach extern oder unter den einzelnen Durchwahlen, spuckt die Anlage folgenden Fehler aus: "Retransmission timeout reached on transmission"
Die Verbindung beim Telefonat kommt dabei kurz zustande, keiner der beiden Teilnehmer hört den andere, dann bricht das Gespräch ab und die Durchwahl aus Haus2 wird von der Anlage ab- und kurz darauf wieder angemeldet.
Zum testen, ob es an der Glasfaser zwischen Haus1 und Haus2 liegt, habe ich das gleiche Setup (Glasfaser von Switch1 auf einen anderen Switch) innerhalb von Haus1 aufgebaut und hier treten die Selben Probleme auf, liegt also wie es aussieht am LWL.
Ich habe keine Möglichkeit eine andere Art der Verbindung zu wählen, zwischen Haus1 und Haus2 gibt es nur singlemode Glasfaser.
Online werde ich leider nicht wirklich fündig und da es hier oft Lösungen oder Denkanstöße zu meinen Problemen gab, hoffe ich dass es jetzt auch wieder so ist.
Allen schon mal ein schönes Wochenende
Falk
ich habe aktuell folgendes Problem: zwei Gebäude sind per singlemode Glasfaser miteinander verbunden. Das ganze läuft über HP 1910 Switche mit spf Modulen.
Über die Verbindung sollen Internet sowie VoIP Telefonie betrieben werden.
Der Aufbau ist in etwa dieser:
Internetaccess/ISP<---->Router<---->Haus1--HP_Switch1<------[Glasfaser]----->HP_Switch2--Haus2<------>Endgeräte(Telefone, PCs, etc.)
Die Internetanbindung funktioniert ohne Probleme.
Bei der VoIP Anbindung sieht es leider etwas anders aus, ich habe zwei verschiedene Setups probiert.
1. Easybell Cloud Account: Telefone in Haus2 melden sich über das Internet direkt bei Easybell an. Hierbei kommen Gespräche zustande, allerdings sind die Gespräche sehr "zerstückelt" und/oder brechen ab.
2. Astlinux Anlage in Haus1 konfiguriert (wird in Haus1 auch schon genutzt, so soll es letztendlich auch aufgebaut sein): die Telefone aus Haus2 melden sich im LAN an der Astlinux Anlage an, die Telefonie läuft ebenfalls über Easybell, wird aber von der Anlage geregelt. Die Anmeldung der Telefone an der Anlage funktioniert und wird auch nicht getrennt.
Sobald ein Gespräch Aufgebaut wird, egal ob nach extern oder unter den einzelnen Durchwahlen, spuckt die Anlage folgenden Fehler aus: "Retransmission timeout reached on transmission"
Die Verbindung beim Telefonat kommt dabei kurz zustande, keiner der beiden Teilnehmer hört den andere, dann bricht das Gespräch ab und die Durchwahl aus Haus2 wird von der Anlage ab- und kurz darauf wieder angemeldet.
Zum testen, ob es an der Glasfaser zwischen Haus1 und Haus2 liegt, habe ich das gleiche Setup (Glasfaser von Switch1 auf einen anderen Switch) innerhalb von Haus1 aufgebaut und hier treten die Selben Probleme auf, liegt also wie es aussieht am LWL.
Ich habe keine Möglichkeit eine andere Art der Verbindung zu wählen, zwischen Haus1 und Haus2 gibt es nur singlemode Glasfaser.
Online werde ich leider nicht wirklich fündig und da es hier oft Lösungen oder Denkanstöße zu meinen Problemen gab, hoffe ich dass es jetzt auch wieder so ist.
Allen schon mal ein schönes Wochenende
Falk
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 314267
Url: https://administrator.de/contentid/314267
Ausgedruckt am: 05.11.2024 um 21:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
Genauer Fasertyp?
Module und Optiken passend zur Faser?
Mindestens 2 Faser sind ohne Brüche oder Knicke usw. also Optisch 100% OK?
Verluste auf der Faser inkl Spleiße, Verbindungen uw.?
LWL Patchkabel passend zum Modul bzw. Faser?
LC Stecker? Die ferrule sind OK und sauber? Die Faserenden (innerhalb der Ferrule) sind weder verkratzt noch verstaubt noch anderweitig beschädigt? Begutachtung per Fasermikroskop ist erfolgt? Die LC Buchsen sind auch Ok bzw. frei von Beschädigung insbesondere der Faserenden dort?
HP Switch sagt was zu den beteiligten Ports?
Wireschark Mittschnitt ergebt welches gesamtbild? Retransmissions sind wenig, normal, hoch, sehr hoch, extrem viele....?
Ein VOIP Protokoll Mittschnitt (Astlinux und VOIP Teilnehmer) ergibt was in der Auswertung?
Gruß,
Peter
Zitat von @FalkIT:
ich habe aktuell folgendes Problem: zwei Gebäude sind per singlemode Glasfaser miteinander verbunden. Das ganze läuft über HP 1910 Switche mit spf Modulen.
Entfernung?ich habe aktuell folgendes Problem: zwei Gebäude sind per singlemode Glasfaser miteinander verbunden. Das ganze läuft über HP 1910 Switche mit spf Modulen.
Genauer Fasertyp?
Module und Optiken passend zur Faser?
Mindestens 2 Faser sind ohne Brüche oder Knicke usw. also Optisch 100% OK?
Verluste auf der Faser inkl Spleiße, Verbindungen uw.?
LWL Patchkabel passend zum Modul bzw. Faser?
LC Stecker? Die ferrule sind OK und sauber? Die Faserenden (innerhalb der Ferrule) sind weder verkratzt noch verstaubt noch anderweitig beschädigt? Begutachtung per Fasermikroskop ist erfolgt? Die LC Buchsen sind auch Ok bzw. frei von Beschädigung insbesondere der Faserenden dort?
HP Switch sagt was zu den beteiligten Ports?
Wireschark Mittschnitt ergebt welches gesamtbild? Retransmissions sind wenig, normal, hoch, sehr hoch, extrem viele....?
Ein VOIP Protokoll Mittschnitt (Astlinux und VOIP Teilnehmer) ergibt was in der Auswertung?
Gruß,
Peter
Moin Peter,
Danke für die ganzen Ideen. Ich bin jetzt nicht mehr im Büro, kann daher nicht alle Fragen beantworten.
Durch den testaufbau innerhalb von Haus1 sind aber die meisten von dir genannten Fehlerquellen ausgeschlossen.
Die einzig identische Komponente beim testaufbau ist der Switch in Haus1, allerdings verschiedene Ports mit unterschiedlichen spf Modulen getestet. Per Kupfer macht der Switch in Haus1 keine Probleme bei der Telefonie.
Verschiedene neue Kabel (LC) wurden ebenfalls verwendet. (Länge 0,5 - 1 Meter). Module sauber, Kabel sauber.
Fasermikroskop haben wir nicht, da aber alle Komponenten neu sind (außer Switch in Haus1) gehe ich erst mal davon aus, das hier kein Fehler liegt.
Fasertyp 9/125.
Mitschnitte erfolgen Montag.
Danke für die ganzen Ideen. Ich bin jetzt nicht mehr im Büro, kann daher nicht alle Fragen beantworten.
Durch den testaufbau innerhalb von Haus1 sind aber die meisten von dir genannten Fehlerquellen ausgeschlossen.
Die einzig identische Komponente beim testaufbau ist der Switch in Haus1, allerdings verschiedene Ports mit unterschiedlichen spf Modulen getestet. Per Kupfer macht der Switch in Haus1 keine Probleme bei der Telefonie.
Verschiedene neue Kabel (LC) wurden ebenfalls verwendet. (Länge 0,5 - 1 Meter). Module sauber, Kabel sauber.
Fasermikroskop haben wir nicht, da aber alle Komponenten neu sind (außer Switch in Haus1) gehe ich erst mal davon aus, das hier kein Fehler liegt.
Fasertyp 9/125.
Mitschnitte erfolgen Montag.
mit spf Modulen.
Was sind das für Module ??Oder meinst du ggf. SFP Module (Mini GBIC) ?
https://de.wikipedia.org/wiki/Small_Form-factor_Pluggable
Leider ist deine Beschreibung was die Netzwerk Infrastruktur anbetrifft recht oberflächlich und es fehlen leider viele Details.
- Wie werden die Switches betrieben ? Dummes flaches Netz und rein L2 Kopplung im Default VLAN ?
- Segmentierung in VLANs bzw. Voice VLAN ?
- Nach Layer 3 zu fragen beim Switch erübrigt sich wohl den diese HP Billiggurken können vermutlich kein L3 ?!
- Hoffentlich sind deine Patchkabel auch Monomode Kabel und keine Multimode Kabel mit 50µm
- Port Statistiken auf dem LWL Port (show interface). Kommt es hier zu Frame Errors, Runts oder Giants ?
- Wichtig: Du sagtst du betreibst Monomode Faser also ein 9µm Glasfaser ! Das ist sichr ? Dazu 2 Fragen:
- Hast du die passenden Monomode SFPs dazu ? Also solche die explizit spezifiziert sind für 1000 Base LX und 1310nm Wellenlänge. (Aufdruck SFP Modul)
- Desweiteren: Supportet der HP 1910er Billigswitch überhaupt Monomode SFPs in seinen SFP Slots ? Hast du das anhand des Datenblatts geprüft ?
Ebenso die Verwendung von Multimode 50µ Patchkabeln.
Das solltest du erstmal genau verifizieren und checken ! Letztlich auch die Punkte die Kollege Pjordorf oben schon zu Recht angesprochen hat.
Im zweiten Schritt solltest du die LWL Strecke mal testen. Am besten mit einem Performance Tool wie NetIO:
http://www.ars.de/ars/ars.nsf/docs/netio
bzw.
http://www.nwlab.net/art/netio/netio.html
Die beiden Testrechner dann jeweils an Switch 1 und Switch 2 so das sie über die LWL Strecke verbunden sind.
Hierbei sollten exakt die gleichen Werte rauskommen als wenn die Testrechner direkt auf einem Switch stecken.
Es darf zu keinerlei Ausfällen, Paket Loss usw. kommen.
Hallo
Das ist ja ein bisschen schnell.
LWL per Definition kann dafür nicht verantwortlich sein. Es ist nur ein Kabel, was entweder heil oder kaputt ist.
Es liegt bei Dir an der Kombination der LWL-Kabel, der beiden Switche, den beiden LWL-Modulen und den restlichen Netzwerkkomponenten.
Du wirst die Komponenten einzeln testen müssen um das Problem einzugrenzen.
Tritt das Problem auch mit TP-Kabeln auf. Was ist mit anderen Switch, Modulen, Firmware-Ständen.
Leih Dir LWL-Meßgeräte für einen Tag.
Dann weißt Du schon mal sicher was es nicht ist.
Auch 2 gebrauchte Switche mit LWL-Modulen kosten nicht die Welt.
Ja, das ist sehr aufwendig.
Aber wenn es einfach wäre, könnte es ja Jeder.
Stefan
Das ist ja ein bisschen schnell.
LWL per Definition kann dafür nicht verantwortlich sein. Es ist nur ein Kabel, was entweder heil oder kaputt ist.
Es liegt bei Dir an der Kombination der LWL-Kabel, der beiden Switche, den beiden LWL-Modulen und den restlichen Netzwerkkomponenten.
Du wirst die Komponenten einzeln testen müssen um das Problem einzugrenzen.
Tritt das Problem auch mit TP-Kabeln auf. Was ist mit anderen Switch, Modulen, Firmware-Ständen.
Leih Dir LWL-Meßgeräte für einen Tag.
Dann weißt Du schon mal sicher was es nicht ist.
Auch 2 gebrauchte Switche mit LWL-Modulen kosten nicht die Welt.
Ja, das ist sehr aufwendig.
Aber wenn es einfach wäre, könnte es ja Jeder.
Stefan
Wenn das verlegte Kabel nicht als solches defekt ist oder Probleme wie Brüche, Dämpfung usw. aufweist ist es zu 98,9% wie immer ein Fehler der optischen Komponenten.
Tippen wir mal auf:
Da wird die Auflösung sicher spannend... Wir sind gespannt...
Tippen wir mal auf:
- Falsche SFP Optiken, SX statt LX
- Falsche Patchkabel 50µ Multimode statt 9µ Single Mode
- Die HP Billiggurke supportet keine LX Optiken
Da wird die Auflösung sicher spannend... Wir sind gespannt...
So, die gute Nachricht als erstes, die Telefonie läuft nun wie sie soll, das Problem war die Konfiguration der Telefonanlage.
Ich habe heute morgen alle kabel, Geräte, Module etc. erneut überprüft, ohne etwas fehlerhaftes feststellen zu können.
Daraufhin eine Rufnummer am Rechner als Softphone eingerichtet und ein- sowieo ausgehende Gespräche per Wireshark und der Ausgabe auf der Anlage selbst überwacht.
Danach habe ich die Verbindung wie letzte Woche ohne LWL sondern nur über Kupfer hergestellt und um einen funktionierenden vergleiche zu haben.
Und auch hier sind die selben Probleme aufgetreten.
Die einzige Erklärung die mir dazu einfällt, ist dass ich letzte Woche beim ganzen hin- und -hergepatche statt im gewünschten LAN im LAN der Telefonanlage gelandet bin als die Gespräche ohne Probleme funktionierten.
Also noch einmal getestet, wie es sich verhält, wenn ich das Netz der Telefonanlage über eine Glasfaserstrecke bei mir anbinde - keine Probleme.
Letztendlich war ein falscher Eintrag für externip sowie der Fehlende Eintrag nat=yes.
Hätte also alles viel schneller erledigt sein können, aber gut.
Danke für zügigen die Antworten und allen noch eine schöne Woche.
Falk
Ich habe heute morgen alle kabel, Geräte, Module etc. erneut überprüft, ohne etwas fehlerhaftes feststellen zu können.
Daraufhin eine Rufnummer am Rechner als Softphone eingerichtet und ein- sowieo ausgehende Gespräche per Wireshark und der Ausgabe auf der Anlage selbst überwacht.
Danach habe ich die Verbindung wie letzte Woche ohne LWL sondern nur über Kupfer hergestellt und um einen funktionierenden vergleiche zu haben.
Und auch hier sind die selben Probleme aufgetreten.
Die einzige Erklärung die mir dazu einfällt, ist dass ich letzte Woche beim ganzen hin- und -hergepatche statt im gewünschten LAN im LAN der Telefonanlage gelandet bin als die Gespräche ohne Probleme funktionierten.
Also noch einmal getestet, wie es sich verhält, wenn ich das Netz der Telefonanlage über eine Glasfaserstrecke bei mir anbinde - keine Probleme.
Letztendlich war ein falscher Eintrag für externip sowie der Fehlende Eintrag nat=yes.
Hätte also alles viel schneller erledigt sein können, aber gut.
Danke für zügigen die Antworten und allen noch eine schöne Woche.
Falk
Moin aqui,
das Problem ist zwar gelöst, aber ich würde trotzdem gern wissen, was aus deiner Sicht gegen die genannten HP Switche spricht?
Ich arbeite damit seit einigen Jahren und hatte bisher nie Probleme die auf die Hardware zurückzuführen waren.
Klar sind sie billig, das ist in jedem Fall auch ein Grund warum sie gekauft werden, aber soweit ich es beurteilen kann machen sie das, was sie machen sollen tadellos.
Gruß
Falk
das Problem ist zwar gelöst, aber ich würde trotzdem gern wissen, was aus deiner Sicht gegen die genannten HP Switche spricht?
Ich arbeite damit seit einigen Jahren und hatte bisher nie Probleme die auf die Hardware zurückzuführen waren.
Klar sind sie billig, das ist in jedem Fall auch ein Grund warum sie gekauft werden, aber soweit ich es beurteilen kann machen sie das, was sie machen sollen tadellos.
Gruß
Falk
Das sind billige Taiwan OEM Switches und kein HP Produkt. Mit entsprechendem mickrigen Featureset (Fehlendes Spanning Tree, kein PVSTP Support usw. und sehr schlechter CPU Performance.
Hinzukommt das HP langsam einen Zoo von zugekauften Netzwerk Produkten hat die allsamt nicht von denen selber stammen entsprechend mau ist deren Netzwerk Expertise und auch die Entwicklung in zugünftige Produkte im Netzwerkbereich. Von der Zukunftsfähigkeit der Produkte mal gar nicht zu reden.
Auch wenn sie jetzt mit der "Aruba" Rebranding Aktion versuchen alles einen einheitlichen Namen zu geben bleibt es ein ziemliches Flickwerk was nichtmal in allen Punkten untereinander kompatibel ist.
Für eine langfristige Strategieplanung in Firmen ein NoGo.
Allerdings für den Einsatz in Kleinstnetzen mit sehr wenig bis keinerlei Anforderungen wie bei dir ist das völlig egal und spielt natürlich keine Rolle. Da kannst du weiterhin mit den Gurken arbeiten....und auch allen anderen, keinen Frage. D-Link, NetGear, Longshine macht sowas auch tagellos. Innen drin ist so oder so immer das gleiche von Accton.
Nur auch hier muss man sehen das Hersteller wie TP-Link usw. die schon rechts und links überholt haben was Performance und Featureset anbetrifft. Preis sowieso...
Hinzukommt das HP langsam einen Zoo von zugekauften Netzwerk Produkten hat die allsamt nicht von denen selber stammen entsprechend mau ist deren Netzwerk Expertise und auch die Entwicklung in zugünftige Produkte im Netzwerkbereich. Von der Zukunftsfähigkeit der Produkte mal gar nicht zu reden.
Auch wenn sie jetzt mit der "Aruba" Rebranding Aktion versuchen alles einen einheitlichen Namen zu geben bleibt es ein ziemliches Flickwerk was nichtmal in allen Punkten untereinander kompatibel ist.
Für eine langfristige Strategieplanung in Firmen ein NoGo.
Allerdings für den Einsatz in Kleinstnetzen mit sehr wenig bis keinerlei Anforderungen wie bei dir ist das völlig egal und spielt natürlich keine Rolle. Da kannst du weiterhin mit den Gurken arbeiten....und auch allen anderen, keinen Frage. D-Link, NetGear, Longshine macht sowas auch tagellos. Innen drin ist so oder so immer das gleiche von Accton.
Nur auch hier muss man sehen das Hersteller wie TP-Link usw. die schon rechts und links überholt haben was Performance und Featureset anbetrifft. Preis sowieso...
