8
SBC - Paketgröße verringern, Ursache für großes Paket?
Hallo Community,
ich bin aktuell an einem Projekt dranne, wo ich mir die Zähne ausbeiße und mittlerweile meine Ideen ausgegangen sind. Vielleicht hat jemand noch einen Denkanstoß für mich.
Ich habe für einen Kunden einen SBC installiert. Dieser dient dazu die Verbindung zwischen TK-System (PBX) und SIP-Service-Provider (SIP-SP) abzusichern, indem nur bestimmte Paketdaten durchgelassen sollen. Bei diese Projekt sind es speziell nur das SIP-Protokoll auf UDP-Basis.
Momentan ist der Aufbau folgender Maßen:
PBX <-> SBC <-> Core-Switch <-> Medienwandler <-> SIP-SP
Also das TK-System soll das Sprachpaket über den SBC bis hin zum SIP-SP senden. Die Konfiguration des SBC ist soweit in Ordnung, als das Gespräche von extern bereits am TK-System ankommen (verkürzt: ext. Anrufer <-> SIP-SP <-> SBC <-> PBX funktioniert).
Leider funktioniert die Verbindung in die andere RIchtung nicht, es ist aktuell also nicht möglich eine Gesprächsverbindung über den SIP-SP aufzubauen. Ich habe bereits mit dem SIP-SP Email-Kontakt gehabt (Leider keine andere Möglichkeit). Daraufhin kam nach Analysen von dem SIP-SP heraus, dass das SIP-Invite-Paket, welches bei ihm ankommt zu groß sei. Ein 1620 Byte Paket kommt an, aber es werden maximal 1480 akzeptiert, somit wird das gesendete Paket also direkt verworfen. Somit schließe ich daraus, dass die Konfiguration des SBC grundsätzlich in Ordnung ist.
Auf dem SBC habe ich versucht jegliche aufblähende Einstellung zu deaktiveren, um es auszutesten. Also Verschlüsselung (SRTP und TLS) wurden deaktiviert. DIE MTU-Größe wurde testweise auf 1300 gesetzt.
Die Verbindung ohne SBC und Core-Switch, also PBX <-> SIP-SP hat ohne Probleme funktioniert, sowohl ausgehender als auch eingehender Anruf.
Nun zu meinen Fragen:
Vielen Dank für jede Idee,LiN
ich bin aktuell an einem Projekt dranne, wo ich mir die Zähne ausbeiße und mittlerweile meine Ideen ausgegangen sind. Vielleicht hat jemand noch einen Denkanstoß für mich.
Ich habe für einen Kunden einen SBC installiert. Dieser dient dazu die Verbindung zwischen TK-System (PBX) und SIP-Service-Provider (SIP-SP) abzusichern, indem nur bestimmte Paketdaten durchgelassen sollen. Bei diese Projekt sind es speziell nur das SIP-Protokoll auf UDP-Basis.
Momentan ist der Aufbau folgender Maßen:
PBX <-> SBC <-> Core-Switch <-> Medienwandler <-> SIP-SP
Also das TK-System soll das Sprachpaket über den SBC bis hin zum SIP-SP senden. Die Konfiguration des SBC ist soweit in Ordnung, als das Gespräche von extern bereits am TK-System ankommen (verkürzt: ext. Anrufer <-> SIP-SP <-> SBC <-> PBX funktioniert).
Leider funktioniert die Verbindung in die andere RIchtung nicht, es ist aktuell also nicht möglich eine Gesprächsverbindung über den SIP-SP aufzubauen. Ich habe bereits mit dem SIP-SP Email-Kontakt gehabt (Leider keine andere Möglichkeit). Daraufhin kam nach Analysen von dem SIP-SP heraus, dass das SIP-Invite-Paket, welches bei ihm ankommt zu groß sei. Ein 1620 Byte Paket kommt an, aber es werden maximal 1480 akzeptiert, somit wird das gesendete Paket also direkt verworfen. Somit schließe ich daraus, dass die Konfiguration des SBC grundsätzlich in Ordnung ist.
Auf dem SBC habe ich versucht jegliche aufblähende Einstellung zu deaktiveren, um es auszutesten. Also Verschlüsselung (SRTP und TLS) wurden deaktiviert. DIE MTU-Größe wurde testweise auf 1300 gesetzt.
Die Verbindung ohne SBC und Core-Switch, also PBX <-> SIP-SP hat ohne Probleme funktioniert, sowohl ausgehender als auch eingehender Anruf.
Nun zu meinen Fragen:
- Könnte der Enterasys Core-Switch irgendwelche Eingriffe in das Datenpaket machen, dass dies deutlich aufgebläht wird?
- Kann der Switch eine Verschlüsselung dem Paket hinzufügen?
- Ein Netzwerkpaket, welches auf dem SBC mit tethereal (ja etwas alt) mitgeschnitten wurde und knapp 900 Byte angibt, kann beim Verlassen der WAN-Schnittstelle noch auf 1620 Byte aufgebläht werden? Wenn ja, woran kann das liegen?
- Hat jemand Erfahrung mit einem Unify-SBC? Wenn ja, gibt es weitere Parameter, die eine Vergrößerung des Datenpakets verursachen können?
- Verändert ein Medienwandler (Kupfer auf LWL) das Datenpaket? Ich bin bislang der Meinung, dass der nichts verändert.
- Was bewirkt eine MTU-Einstellung, wenn ich diese kleiner einstelle, kann es mir bei dem Problem überhaupt helfen oder gilt solch eine Einstellung überhaupt nicht bei ausgehendem Verkehr?
Vielen Dank für jede Idee,LiN
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: 244855
Url: https://administrator.de/contentid/244855
Ausgedruckt am: 13.11.2024 um 11:11 Uhr
8 Kommentare
Neuester Kommentar
Hi
Wir hatten vor kurzem einen ähnlichen fall. Grundsätzlich kann jede Netzwerkkomponente das Packet ändern allerdings ist in deinem Fall am Warscheinlichsten das dieses Packet vor dem verlassen ins internet geändert wird. Was hast du den für eine Firewall laufen ?
Gibt es Firewallregeln wie eine Priorisierung für Sprachpackete ? Ist möglicherweise eine Prüfung durch die Firewall konfiguriert ? (Antivirus usw.)
Bei jeder Firewall solltest du bei den einstellungen der WAN Schnittstelle die MTU Size einstellen können das gilt dann für alle Packete die ins Netz gesendet werden.
PS: Bei uns war das Problem ein mikrotik Router auf dem Weg zum SIP Provider.
PPS: Die MTU Size kann dir bei dem Problem helfen da sie die grösse eines IP Packets regelt und es Passieren kann das zb. ein Packet nur bis zu einer gewissen grösse angenommen wird. Stellst du die MTU Size bei deiner Firewall (WAN) auf 1450 oder 1300 teilt die Firewall alle Packete die ins internet gehen in 1300 oder 1450 grössen auf.
LG Andy
Wir hatten vor kurzem einen ähnlichen fall. Grundsätzlich kann jede Netzwerkkomponente das Packet ändern allerdings ist in deinem Fall am Warscheinlichsten das dieses Packet vor dem verlassen ins internet geändert wird. Was hast du den für eine Firewall laufen ?
Gibt es Firewallregeln wie eine Priorisierung für Sprachpackete ? Ist möglicherweise eine Prüfung durch die Firewall konfiguriert ? (Antivirus usw.)
Bei jeder Firewall solltest du bei den einstellungen der WAN Schnittstelle die MTU Size einstellen können das gilt dann für alle Packete die ins Netz gesendet werden.
PS: Bei uns war das Problem ein mikrotik Router auf dem Weg zum SIP Provider.
PPS: Die MTU Size kann dir bei dem Problem helfen da sie die grösse eines IP Packets regelt und es Passieren kann das zb. ein Packet nur bis zu einer gewissen grösse angenommen wird. Stellst du die MTU Size bei deiner Firewall (WAN) auf 1450 oder 1300 teilt die Firewall alle Packete die ins internet gehen in 1300 oder 1450 grössen auf.
LG Andy
Hi,
danke für deine Antwort. Ich bin leider nicht früher dazu gekommen hier zu antworten.
Es ist keine dedizierte Firewall. Denn der SBC ist die Firewall bzw. hat die Firewall integriert. Dort konnte ich zwar die MTU auf 1300 setzen, aber es machte leider keinerlei Unterschied. Die Firewall auf dem SBC ist so eingestellt, dass dort nur SIP, RTP, UDP und TCP durchgeht. Weil es halt nur eine Verbindung direkt zum SIP-Provider gibt. Es ist nicht möglich darüber zu surfen. Es ist gibt auch keine Untersuchung der ausgehenden/eingehenden Pakete durch einen Virenscanner o.ä.. Da die Verbindung wirklich nur Customer-SBC <-> Provider-SBC im Prinzip ist.
Nun weiß ich nicht inwieweit auf der Provider-Seite noch ein Router in die Suppe spuckt. Da ich mittlerweile erfahren habe, dass es dort einen Router geben soll. Das war bislang nicht sichergestellt.
Leider haben wir nebenbei noch ein anderes Problem aktuell, sodass ich nicht weiter testen kann. Denn der Kollege, der die PBX mit Gateway konfiguriert, sagte mir, dass es bei Ihm ohne SBC ohne Probleme lief. Nur läuft aktuell diese Verbindung auch nicht mehr...
danke für deine Antwort. Ich bin leider nicht früher dazu gekommen hier zu antworten.
Es ist keine dedizierte Firewall. Denn der SBC ist die Firewall bzw. hat die Firewall integriert. Dort konnte ich zwar die MTU auf 1300 setzen, aber es machte leider keinerlei Unterschied. Die Firewall auf dem SBC ist so eingestellt, dass dort nur SIP, RTP, UDP und TCP durchgeht. Weil es halt nur eine Verbindung direkt zum SIP-Provider gibt. Es ist nicht möglich darüber zu surfen. Es ist gibt auch keine Untersuchung der ausgehenden/eingehenden Pakete durch einen Virenscanner o.ä.. Da die Verbindung wirklich nur Customer-SBC <-> Provider-SBC im Prinzip ist.
Nun weiß ich nicht inwieweit auf der Provider-Seite noch ein Router in die Suppe spuckt. Da ich mittlerweile erfahren habe, dass es dort einen Router geben soll. Das war bislang nicht sichergestellt.
Leider haben wir nebenbei noch ein anderes Problem aktuell, sodass ich nicht weiter testen kann. Denn der Kollege, der die PBX mit Gateway konfiguriert, sagte mir, dass es bei Ihm ohne SBC ohne Probleme lief. Nur läuft aktuell diese Verbindung auch nicht mehr...
Hi
Wenn du wie du schreibst die MTU auf 1300 gestelllt hast und das deine ausgehende schnittstelle (Wan) ist kann beim Provider kein grösseres Packet ankommen. Da muss dann ein Router dazwischen sein der das Packet abändert.
Möglicherweise wurde etwas geändert beim Provider ? Gibt es die möglichkeit ein Tracert ( Routenverfolgung ) zu machen um zu sehen wieviele Hops das Packet braucht bis zum Endpunkt ? Dann siehst du sofort wieviele Router dazwischenhängen.
Meiner meinung nach kann das problem hier nur beim Provider liegen.
LG Andy
Wenn du wie du schreibst die MTU auf 1300 gestelllt hast und das deine ausgehende schnittstelle (Wan) ist kann beim Provider kein grösseres Packet ankommen. Da muss dann ein Router dazwischen sein der das Packet abändert.
Möglicherweise wurde etwas geändert beim Provider ? Gibt es die möglichkeit ein Tracert ( Routenverfolgung ) zu machen um zu sehen wieviele Hops das Packet braucht bis zum Endpunkt ? Dann siehst du sofort wieviele Router dazwischenhängen.
Meiner meinung nach kann das problem hier nur beim Provider liegen.
LG Andy
Hi,
danke für deine Antwort.
Ich komme dort leider nicht vor Ort, um zu tracen. Auf dem SBC ist das Tracen sehr beschränkt. Somit kann ich leider keine Aussage zu den Hops oder ähnliches treffen. Denn die Funktion Traceroute vom SBC gibt mir absolut keine Ausgabe zurück.
Ich werde dort heute nochmal neu den Versuch starten etwas zu konfigurieren.
Jedoch habe ich auch dir Vermutung der Provider hat etwas geändert.
Ich meld mich mal, wenn ich weiter gekommen bin.
danke für deine Antwort.
Ich komme dort leider nicht vor Ort, um zu tracen. Auf dem SBC ist das Tracen sehr beschränkt. Somit kann ich leider keine Aussage zu den Hops oder ähnliches treffen. Denn die Funktion Traceroute vom SBC gibt mir absolut keine Ausgabe zurück.
Ich werde dort heute nochmal neu den Versuch starten etwas zu konfigurieren.
Jedoch habe ich auch dir Vermutung der Provider hat etwas geändert.
Ich meld mich mal, wenn ich weiter gekommen bin.
Hi
Gerne.
Es sollte ja auch im interesse des Providers sein das Problem zu lösen ich denke du solltest wenn du vorort bist einen termin mit einem der Techniker vereinbaren um hier zu einer lösung zu kommen.
Viel erfolg sollten sich fragen ergeben einfach posten.
LG
Gerne.
Es sollte ja auch im interesse des Providers sein das Problem zu lösen ich denke du solltest wenn du vorort bist einen termin mit einem der Techniker vereinbaren um hier zu einer lösung zu kommen.
Viel erfolg sollten sich fragen ergeben einfach posten.
LG
Hallo,
das Problem ließe sich nur lösen, wenn der Provider das Protokoll auf TCP ändert, weil die Konvertierung der TCP- zu UDP-Paketen durch den SBC das Netzwerkpaket zu stark wachsen lässt. Dadurch dass die MTU auf 1500 eingestellt ist und das Paket rund 1600 Byes groß ist, werden zwei Frames rausgeschickt. Dass das zweite Paket nicht ankommt, kann ich leider nicht weiter analysieren und muss somit im ungewissen bleiben.
Am SBC gibt es laut Hersteller kein Optimierungspotential, um die Paketgröße zu beeinflussen.
Da beide Gegenstellen auf ihrem Standpunkt beharren, d.h. der Provider kann aus "bestimmten technischen Gründen" das Protokoll nicht ändern und der SBC-Hersteller kann seine Software nicht optimieren.
das Problem ließe sich nur lösen, wenn der Provider das Protokoll auf TCP ändert, weil die Konvertierung der TCP- zu UDP-Paketen durch den SBC das Netzwerkpaket zu stark wachsen lässt. Dadurch dass die MTU auf 1500 eingestellt ist und das Paket rund 1600 Byes groß ist, werden zwei Frames rausgeschickt. Dass das zweite Paket nicht ankommt, kann ich leider nicht weiter analysieren und muss somit im ungewissen bleiben.
Am SBC gibt es laut Hersteller kein Optimierungspotential, um die Paketgröße zu beeinflussen.
Da beide Gegenstellen auf ihrem Standpunkt beharren, d.h. der Provider kann aus "bestimmten technischen Gründen" das Protokoll nicht ändern und der SBC-Hersteller kann seine Software nicht optimieren.
Hi
Das ist unmöglich der SBC Hersteller muss das Problem lösen können da jede DSL Leitung mit einer Paketgrösse von 1500 läuft. Sollten sie das nicht können wäre Ihr Produkt auf UDP basis nicht über eine Standard DSL Leitung nutzbar.
Das bedeutet es gibt keine Lösung ??? Ich dachte es hat schon funktioniert ? Eingespielte Updates haben die gösse auch nicht geändert ?
Aktivierter Virenschutz usw.
LG
Das ist unmöglich der SBC Hersteller muss das Problem lösen können da jede DSL Leitung mit einer Paketgrösse von 1500 läuft. Sollten sie das nicht können wäre Ihr Produkt auf UDP basis nicht über eine Standard DSL Leitung nutzbar.
Das bedeutet es gibt keine Lösung ??? Ich dachte es hat schon funktioniert ? Eingespielte Updates haben die gösse auch nicht geändert ?
Aktivierter Virenschutz usw.
LG
Hallo,
ne der Hersteller sagt, er kann da nichts weiter machen. Der SIP-Provider solle das Protokoll auf TCP ändern, denn in Deutschland scheinen einige SIP-Provider mit dem Protokoll zu arbeiten.
Dass es gar nicht auf UDP funktioniert möchte ich nicht sagen, da ich nicht weiß, wo genau der Frame "verloren" geht.
Ich habe mittlerweile mehrere Updates eingespielt, es änderte nichts an der Paketgröße. Es bleibt dabei, dass es nicht funktioniert. Somit wird nun auf eine andere Lösung umgestellt, sobald möglich. Ein Antivirenschutz kann ich ausschließen, der hat nichts mit dem Paket zu tun, da es keinen dazwischen gibt.
ne der Hersteller sagt, er kann da nichts weiter machen. Der SIP-Provider solle das Protokoll auf TCP ändern, denn in Deutschland scheinen einige SIP-Provider mit dem Protokoll zu arbeiten.
Dass es gar nicht auf UDP funktioniert möchte ich nicht sagen, da ich nicht weiß, wo genau der Frame "verloren" geht.
Ich habe mittlerweile mehrere Updates eingespielt, es änderte nichts an der Paketgröße. Es bleibt dabei, dass es nicht funktioniert. Somit wird nun auf eine andere Lösung umgestellt, sobald möglich. Ein Antivirenschutz kann ich ausschließen, der hat nichts mit dem Paket zu tun, da es keinen dazwischen gibt.
